Pull to refresh
0
Rating

Облачное хранилище Clodo

Clodo corporate blog
Мы рады представить сообществу «Хабрахабра» наш новый сервис — Облачное Хранилище. Как и все решения подобного класса, оно предназначено для хранения и быстрой раздачи статического контента — в том числе контента веб-сайтов.

Те, кто посетил прекрасную конференцию Highload++, имели возможность, в числе прочего, услышать наш доклад про то, как устроено хранилище. Краткое изложение того, о чем мы говорили, мы предлагаем уважаемой аудитории «Хабрахабра».

Суть любого облака заключается в возможности оперативно получить требуемое количество ресурсов заданного типа по запросу. Есть привычные благодаря десктопам — дисковое пространство, процессорные мощности, оперативная память. Взяв понемногу того, другого и третьего (например, приобретя виртуальную машину с 256 мегабайтами памяти и диском на пару сотен гигабайт), пользователь надеется раздать эти гигабайты в виде тысяч маленьких файлов — причем раздать быстро и любому количеству клиентов: очевидно при помощи какой-то специальной «облачной магии», про которую ему напели недалёкие маркетологи. На самом деле, есть и другие, не такие привычные типы ресурсов, которые следует иметь в виду, проектируя свой сервис — например, ресурс раздачи контента или балансировки нагрузки.

Удачная архитектура облачного веб-проекта

Используя упомянутые выше типы сущностей, можно построить архитектуру решения, которая, используя традиционный LAMP-стек, будет предназначена как раз для реализации той самой «облачной магии» и легкости масштабирования при увеличении нагрузки. Мы планомерно реализуем то, что необходимо для реализации такой схемы.

Так, например, серверы баз данных при использовании привычного MySQL, как известно плохо поддаются горизонтальному масштабированию, поэтому их имеет смысл масштабировать вертикально — для этого у нас работаю Scale Server. Обращающиеся к ним application-серверы, в идеале стоящие за балансировщиком нагрузки, можно масштабировать горизонтально, плодя при помощи API копии-клоны. Для того, чтобы можно было использовать точные клоны, статическую информацию имеет смысл распространять через специально для этого созданное хранилище — это позволяет не заниматься синхронизацией, которая часто не поспевает за обновлениями контента.

Итак, мы поставили перед собой задачу создать хранилище:
  • Надёжно хранящее данные;
  • С простым управлением данными — в том числе посредством API,
    поскольку его нужно использовать из программного кода;
  • Умеющее быстро раздавать по HTTP «горячий» контент;
  • Предоставляющее привычное для не самых опытных пользователей интерфейс взаимодействия (FTP, FUSE). На хранилище должен иметь возможность загрузить файл любой контент-менеджер сайта провинциального дома культуры (да, у нас есть и такие клиенты);


Решив не изобретать велосипедов, в качестве хранилища мы выбрали Openstack Swift — то же хранилище, которое используют наши западные коллеги из Rackspace. Картинка достаточно хорошо поясняет его устройство.

Архитектура OpenStack Swift

Клиент из интернета приходит на авторизационный узел, предъявляет там свой токен, и в зависимости от токена ему дается доступ к тому или иному участку хранилища. Хранилище плоское: структура директорий задается при помощи мета-атрибутов файлов (мета-атрибуты в Swift дают вообще достаточно богатый инструментарий — об этом мы можем рассказать подробнее, если будет такой интерес).

Для начала мы попробовали решение, целиком и полностью основанное на Swift со Swift Proxy на фронтендах под управлением Pacemaker.

Первая попытка сделать CloudStorage

Решение рабочее, но начало проседать по процессору уже при 400 запросах в секунду на фронтенд, что в наших условиях совсем никуда не годится. Поэтому мы решили добавить NGINX в качестве кеширующего прокси. Кеш мы разместили на SAS-дисках. Так как nginx по умолчанию не умеет хранить кеш на нескольких томах, а тратить дорогие SAS-диски на overhead RAID 6 нам не хотелось, мы обратились к catap и уже вскоре у нас был nginx с мультизонным кешем. Эта конфигурация позволила нашим фронтендам легко выдерживать по 12000 запросов, упираясь при этом не в процессор, а в гигабитный канал на фронтенде.

Вторая попытка сделать CloudStorage

После этого началась доработка сервиса согласно пожеланиям клиентов. Для начала, никому не понравились публичные ссылки вида
http://cs1.clodo.ru/v1/CLODO_0563290e28e0d6f79a83ab6a84b42b7d/public/logo.gif — все хотели что-нибудь в духе http://st.clodo.ru/logo.gif. Помимо возможности подключения доменов, требовалось убрать из URL адрес публичного контейнера по умолчанию public. Это решилось небольшим «программированием на конфигах nginx».

Следующая проблема — существенно более основательная. После удаления с бэкенда файл остается в кэше и может быть доступен еще некоторое время. Наши коллеги из Rackspace считают, что эту проблему решать необязательно (да и вообще по всем вопросам публичной раздачи отсылают к CDN-партнерам). Мы решили попробовать решить эту проблему — и в этом нам помог демон Кеша.

Как работает Демон Кеша

Обаятельный демон, написанный на Perl и взаимодействующий с nginx посредством FastCGI, при каждом удалении данных инвалидирует кэш. При этом он пытается проявить интеллект, и, например, при удалении файла из директории удаляет из кэша не только сам файл, но и листинг директории.

Мы уже наметили несколько направлений развития хранилища:
  • Возможность получения клиентом логов своего хранилища;
  • Раздача медийного контента, стриминг;
  • Репликация между ЦОДами;
  • Авторизация по pubcookies;
  • Включение всей функциональности Swift-proxy в качестве модуля nginx;
  • Полная поддержка HTTP 1.1;

Наше нынешнее решение позволяет в одном сегменте хранилища иметь до 840 Тб дискового пространства, 7 Тб кеша и 512 Гб кеша в оперативной памяти. Все это влезает в 30 юнитов в ЦОДе. Все это автоматически разворачивается при помощи Chef на Debian Live, управляется Pacemaker и панелью Clodo (операции, реализованные за пределом Openstack — например, подцепление своего домена). В принципе, аналогичное решение можно построить и для себя с заметно меньшим количеством железа и развернуть в своем маленьком частном облачке.

Облачное хранилище работает в production уже месяц, и пока нашим клиентам нравится то, что его очень просто использовать, и тарификация его самая простая, какая может быть — 1 копейка за хранение 1 Гб в течение 1 часа и 1 рубль за 1 Гб исходящего трафика. Никаких непредсказуемых нагрузок на процессоры и оперативную память и взлета цен при увеличении нагрузки на ресурс: оценить затраты на облачном хранилище на порядок проще, чем на обычном облачном хостинге.

P.S. Картинки в этом посте размещены на нашем Cloud Storage.
Tags: облачный хостингоблачные сервисыоблачное хранилищеcdn-сервисблекджекopenstack
Hubs: Clodo corporate blog
Total votes 32: ↑21 and ↓11 +10
Comments 26
Comments Comments 26

Top of the last 24 hours

Information

Founded
Location
Россия
Website
www.clodo.ru
Employees
11–30 employees
Registered