Хмарне сховище Clodo
Ми раді представити спільноті "Хабрахабра" наш новий сервіс - Хмарне Сховище. Як і всі рішення подібного класу, воно призначене для зберігання та швидкої роздачі статичного контенту – у тому числі контенту веб-сайтів.
Ті, хто відвідав чудову конференцію Highload++, мали можливість, серед іншого, почути нашу доповідь про те, як влаштовано сховище. Короткий виклад того, про що ми говорили, пропонуємо шановній аудиторії «Хабрахабра». Суть будь-якої хмари полягає у можливості оперативно отримати необхідну кількість ресурсів заданого типу на запит. Є звичні завдяки десктопам дисковий простір, процесорні потужності, оперативна пам'ять. Взявши потроху того, іншого та третього (наприклад, придбавши віртуальну машину з 256 мегабайтами пам'яті та диском на пару сотень гігабайт), користувач сподівається роздати ці гігабайти у вигляді тисяч маленьких файлів – причому роздати швидко та будь-якій кількості клієнтів: очевидно за допомогою якоїсь спеціальної «хмарної магії», про яку йому наспівали недалекі маркетологи. Насправді є й інші, не такі звичні типи ресурсів, які слід мати на увазі, проектуючи свій сервіс — наприклад, ресурс роздачі контенту або балансування навантаження.
Використовуючи згадані вище типи сутностей, можна побудувати архітектуру рішення, яка, використовуючи традиційний LAMP-стек, буде призначена саме для реалізації тієї самої «хмарної магії» та легкості масштабування зі збільшенням навантаження. Ми планомірно реалізуємо те, що потрібно для реалізації такої схеми.
Так, наприклад, сервери баз даних при використанні звичного MySQL, як відомо, погано піддаються горизонтальному масштабуванню, тому їх має сенс масштабувати вертикально — для цього у наспрацюю Scale Server. application-сервери, що звертаються до них, в ідеалі стоять за балансувальником навантаження, можна масштабувати горизонтально, плодячи за допомогою API копії-клони. Для того, щоб можна було використовувати точні клони, статичну інформацію має сенс поширювати через спеціально для цього створене сховище — це дозволяє не займатися синхронізацією, яка часто не встигає за оновленнями контенту.
Отже, ми поставили собі завдання створити сховище:
- Надійно зберігає дані;
- З простим керуванням даними — у тому числі за допомогою API, оскільки його потрібно використовувати з програмного коду;
- Вміє швидко роздавати по HTTP "гарячий" контент;
- Надає звичне для не найдосвідченіших користувачів інтерфейс взаємодії (FTP, FUSE). На сховище повинен мати можливість завантажити будь-який контент-менеджер сайту провінційного будинку культури (так, у нас є і такі клієнти);
Вирішивши не винаходити велосипедів, як сховище ми вибрали Openstack Swift - те ж сховище, яке використовують наші західні колеги з Rackspace. Зображення досить добре пояснює його пристрій.
Спочатку ми спробували рішення, повністю та повністю засноване на Swift з Swift Proxy на фронтендах під керуванням Pacemaker.
Рішення робоче, але почало просідати процесором вже за 400 запитах на секунду на фронтенд, що у умовах зовсім нікуди годиться. Тому ми вирішили додати NGINX як кешуючий проксі. Кеш ми розмістили на дисках SAS. Так як nginx за замовчуванням не вміє зберігати кеш на декількох томах, а витрачати дорогі SAS-диски на overhead RAID 6 нам не хотілося, ми звернулися до catap і вже невдовзі ми мали nginx з мультизонним.кешем. Ця конфігурація дозволила нашим фронтендам легко витримувати по 12000 запитів, упираючись у своїй над процесор, а гігабітний канал на фронтенде.
Наступна проблема — значно ґрунтовніша. Після видалення з бекенд файл залишається в кеші і може бути доступний ще деякий час. Наші колеги з Rackspace вважають, що цю проблему вирішувати необов'язково (та й взагалі, з усіх питань публічної роздачі відсилають до CDN-партнерів). Ми вирішили спробувати вирішити цю проблему і в цьому нам допоміг демон Кеша.
Чарівний демон, написаний на Perl і взаємодіючий із nginx за допомогою FastCGI, при кожному видаленні даних інвалідує кеш. При цьому він намагається виявити інтелект, і, наприклад, при видаленні файлу з директорії видаляє з кешу не лише сам файл, а й лістинг директорії.
Ми вже намітили кілька напрямків розвитку сховища:
- можливість отримання клієнтом логів свого сховища;
- Роздача медійного контенту, стрімінг;
- Реплікація між ЦОДами;
- Авторизація по pubcookies;
- Включення всієї функціональності Swift-proxy як модуль nginx;
- Повна підтримка HTTP 1.1;
Хмарне сховище працює у production вже місяць, і поки щоНашим клієнтам подобається те, що його дуже просто використовувати, і тарифікація його найпростіша, яка може бути - 1 копійка за зберігання 1 Гб протягом 1 години і 1 рубль за 1 Гб вихідного трафіку. Жодних непередбачуваних навантажень на процесори та оперативну пам'ять та зльоту цін зі збільшенням навантаження на ресурс: оцінити витрати на хмарному сховищі на порядок простіше, ніж на звичайному хмарному хостингу.