Облачно хранилище Clodo
Имаме удоволствието да представим нашата нова услуга, Cloud Storage, на общността на Habrahabra. Както всички решения от този клас, той е предназначен за съхранение и бързо разпространение на статично съдържание, включително съдържание на уебсайтове.
Тези, които присъстваха на отличната конференция Highload++, имаха възможност, наред с други неща, да чуят нашия доклад за това как работи съхранението. Предлагаме обобщение на това, за което говорихме на уважаемата публика на Хабрахабр. Същността на всеки облак е способността бързо да се получи необходимото количество ресурси от даден тип при поискване. Има познати благодарение на настолните компютри - дисково пространство, мощност на процесора, RAM. Вземайки малко от това, другото и третото (например чрез закупуване на виртуална машина с 256 мегабайта памет и диск за няколкостотин гигабайта), потребителят се надява да разпространява тези гигабайти под формата на хиляди малки файлове - и да ги разпространява бързо и на произволен брой клиенти: очевидно с помощта на някаква специална "облачна магия", за която тесногръди търговци му пееха. Всъщност има и други, не толкова познати видове ресурси, които трябва да имате предвид, когато проектирате услугата си - например ресурс за разпространение на съдържание или балансиране на натоварването.
Използвайки типовете обекти, споменати по-горе, е възможно да се изгради архитектура на решение, която, използвайки традиционен LAMP стек, ще бъде проектирана само за прилагане на самата „облачна магия“ и лекота на мащабиране с нарастващо натоварване. Ние системно изпълняваме необходимото за прилагане на такава схема.
Така например е известно, че сървърите на бази данни, когато се използва обичайният MySQL, са трудни за хоризонтално мащабиране, така че има смисъл да се мащабират вертикално - за това имамеРаботя със Scale Server. Сървърите на приложения, които имат достъп до тях, в идеалния случай зад балансьор на натоварването, могат да бъдат мащабирани хоризонтално чрез създаване на клонирани копия с помощта на API. За да можете да използвате точни клонинги, има смисъл да разпространявате статична информация чрез хранилище, специално създадено за това - това ви позволява да не се занимавате със синхронизация, която често не е в крак с актуализациите на съдържанието.
И така, ние си поставихме задачата да създадем хранилище:
- Сигурно съхраняване на данни;
- С просто управление на данни - включително чрез API, тъй като трябва да се използва от програмния код;
- Възможност за бързо разпространение на "горещо" съдържание чрез HTTP;
- Осигуряване на интерфейс за взаимодействие, познат на не най-опитните потребители (FTP, FUSE). Всеки мениджър на съдържанието на сайта на провинциален дом на културата трябва да може да качи файл в хранилището (да, имаме и такива клиенти);
Решавайки да не преоткриваме колелото, ние избрахме Openstack Swift като хранилище - същото хранилище, което нашите западни колеги от Rackspace използват. Картината го обяснява достатъчно добре.
Като начало изпробвахме решение, базирано изцяло на Swift със Swift Proxy на интерфейси, управлявани от Pacemaker.
Решението работи, но започна да провисва в процесора вече при 400 заявки в секунда към фронтенда, което в нашите условия е напълно безполезно. Затова решихме да добавим NGINX като кеширащ прокси. Поставихме кеша на SAS дискове. Тъй като nginx по подразбиране не може да съхранява кеша на множество томове и не искахме да хабим скъпи SAS дискове за overhead RAID 6, се обърнахме към catap и скоро имахме nginx с multizoneкеш памет. Тази конфигурация позволи на нашите интерфейси лесно да обработват 12 000 заявки всяка, без да бъдат ограничени от процесора, а от гигабитовия канал на интерфейса.
Следващият проблем е много по-фундаментален. След като бъде изтрит от бекенда, файлът остава в кеша и може да бъде достъпен известно време. Нашите колеги от Rackspace смятат, че не е необходимо да се решава този проблем (и като цяло за всички въпроси на публичното разпространение се обръщат към партньорите на CDN). Решихме да се опитаме да разрешим този проблем - и демонът Кеша ни помогна с това.
Очарователен демон, написан на Perl и взаимодействащ с nginx чрез FastCGI, анулира кеша при всяко изтриване на данни. В същото време се опитва да покаже интелигентност и например при изтриване на файл от директория изтрива не само самия файл от кеша, но и листинга на директорията.
Вече очертахме няколко посоки за развитие на хранилището:
- Възможността клиентът да получава логове на своето хранилище;
- Разпространение на медийно съдържание, стрийминг;
- Репликация между центрове за данни;
- Оторизация чрез pubcookies;
- Включва цялата функционалност на Swift-прокси като nginx модул;
- Пълна поддръжка за HTTP 1.1;
Облачното хранилище е в производство от месец и досеганашите клиенти харесват факта, че е много лесен за използване и ценообразуването му е възможно най-просто - 1 копейка за съхранение на 1 GB за 1 час и 1 рубла за 1 GB изходящ трафик. Без непредсказуеми натоварвания на процесорите и RAM и рязко покачване на цените, когато натоварването на ресурса се увеличи: много по-лесно е да се изчислят разходите за облачно съхранение, отколкото при обикновен облачен хостинг.