Zbuduj magazyn w chmurze do przechowywania i dostarczania zawartości statycznej w oparciu o integrację Nginx i Openstack Swift

Stanislav Bogatyrev: Cześć! Nazywam się Stanislav Bogatyrev. Przedstawiam „chmurę” hostującą Clodo. Porozmawiam również o magazynie „chmury” dla różnych danych, w tym danych binarnych. Niedawno go uruchomiliśmy. Chciałbym podzielić się niektórymi aspektami wdrożenia i napotkanymi problemami.

Tak więc każde rozwiązanie powinno być stworzone dla pewnego rodzaju problemu. Problem „chmury” w Rosji i na całym świecie to marketing, który ukształtował złe oczekiwania ludzi, czasami absolutnie fantastyczne.

Użytkownik przychodzi więc do „chmury” ze swoją stroną internetową, wykonaną w zwykłym CMS-ie przy użyciu długiego stosu, i ma nadzieję, że magicznie natychmiast będzie w stanie wytrzymać każde obciążenie, obsłużyć dowolną liczbę użytkowników i nie wydawać pieniędzy. Niestety tak nie jest.

Technicznie rzecz biorąc, „chmura” jest rodzajem zasobów, łącząc to, co programista może stworzyć własne rozwiązanie. Przy takich typach zasobów „chmury” jak procesor, pamięć lub dysk twardy wszystko jest mniej lub bardziej jasne (znane są zwykłym użytkownikom pracy na stacjonarnych komputerach). W przypadku innych rodzajów zasobów sytuacja jest nieco bardziej skomplikowana. Próbując połączyć już znane typy, użytkownicy tworzą własne rozwiązania. Nie są najskuteczniejsze. Ludzie denerwują się i rozczarowują „chmurami”. To nie jest dokładnie to, czego chcielibyśmy.

Typy zasobów „chmury” można również przypisać na przykład zasobom równoważącym obciążenie i zasobom dostarczania treści (myślę, że ten temat jest bliski każdemu). Oto, z czym ma do czynienia każda osoba: przesyłanie zdjęć z serwera do użytkowników i tak dalej.

Często trzeba obserwować następujący obraz: użytkownik korzysta z serwera wirtualnego, wiedząc, że jest łatwy do skalowania w pionie. Osoba bierze ogromny dysk twardy, umieszcza wiele małych plików w jednym katalogu, dystrybuuje je - i nie działa.

W tym slajdzie proponujemy bardziej „zaostrzone” zastosowanie architektury „chmury”. Na rosyjskich „chmurach” nie można było w pełni zrealizować, ponieważ Rosyjskie „chmury” są trzy dostępne dla wszystkich zasobów. Ale dlaczego „jak wszyscy inni”? Postanowiliśmy stać się trochę lepsi i stworzyliśmy usługę dostarczania treści (Cloud Storage), do dystrybucji i przechowywania danych, a wkrótce wprowadzimy równoważenie. W ten sposób pozwolimy użytkownikowi umieścić swoją decyzję w takim schemacie.

Tutaj potrzebujemy minimalnych ulepszeń zwykłej architektury. Mamy tutaj bazy danych znane wszystkim. Jak wiemy, w klasycznej wersji stosu LVM nie skalują się one dobrze w poziomie. Wygodne jest dla nich pobranie niewielkiej liczby pionowo skalowalnych serwerów. Dynamiczne generatory treści mogą być dokładnie takie same, pod warunkiem, że usuniemy wszystkie statyczne, wszystkie pliki w pamięci „chmury” i rozprowadzimy je za pośrednictwem niektórych usług zewnętrznych. Są niedrogie w zasobach, mogą być łatwo skalowane w poziomie, w razie potrzeby. Obciążenie między nimi jest dzielone przez naszą zewnętrzną usługę równoważenia obciążenia.

W związku z tym żądania klienta dotyczące statyki przechodzą do Cloud Storage w celu dystrybucji. Dystrybucja następuje szybko - ze względu na fakt, że wszystko to jest buforowane. W tym celu sprzęt jest „wyostrzony”: jest szybki kanał i tak dalej. Płatny czas procesora, dysku i pamięci (usługi tradycyjne) stanowi tylko część generowania dynamiki użytkownika. To znaczne oszczędności. Kilku naszych klientów przeszło na tę architekturę. Wzrosła jakość i szybkość dystrybucji, a co dziwne koszty spadły.

Jakie cechy powinny mieć dobre przechowywanie w chmurze?

Kiedy stworzyliśmy nasze repozytorium, pomyśleliśmy o tym, jak powinno być.

• Po pierwsze, musi bezpiecznie przechowywać dane użytkownika. To oczywiste.

• Chcieliśmy, aby nasze repozytorium miało proste, łatwe w użyciu, intuicyjne API do zarządzania danymi. Od tego czasu większość serwerów jest używana nie tylko przez ludzi, ale także przez różne roboty, API musi być również dostosowane do programów.

• Główną funkcją, oprócz przechowywania, jest szybka dystrybucja treści w dużych ilościach za pomocą protokołu HTTP.

• Pojawił się również następujący problem: ludzie nie są gotowi do natychmiastowego pobrania i przepisania swojej usługi lub strony internetowej i przejścia na inny rodzaj dostępu do danych. Dlatego w okresie migracji konieczne było stworzenie dogodnej opcji dostępu pośredniego do systemu plików - możliwie przy użyciu protokołu FTP.

Zdecydowaliśmy się na OpenStack Swift. Pierwszy to rozwiązanie Open Source. Po drugie, spełniło wszystkie nasze wymagania, architektonicznie dopasowane do naszych pomysłów. Zamiast wymyślać nasz rower, postanowiliśmy udoskonalić istniejący.

Co to jest Swift? Zdjęcie pokazuje, jak jest zorganizowane architektonicznie. „Auth node” jest pewnym serwerem autoryzacji, do którego użytkownik wchodzi podczas uzyskiwania dostępu za pośrednictwem interfejsu API (nie mówimy teraz o dystrybucji HTTP, mówimy o pracy nad API). Określa login, hasło i odbiera token, przez który wszystkie jego żądania będą autoryzowane. Otrzymuje także klaster URL, z którym musi pracować. Następnie przechodzi do węzła proxy (węzeł proxy), przez który przechodzą wszystkie żądania. Węzeł proxy na pierścieniu mieszania znajduje serwer zaplecza, do którego musi uzyskać dostęp. Wysyła żądanie, odbiera dane, wraca do użytkownika. To proste.

Swift działa z trzema podmiotami. Aby wyjaśnić, w jaki sposób różni się od plików: jest to pamięć obiektów. Istnieją 3 typy podmiotów.

1. Po pierwsze, najwyższy poziom - to konto. To rodzaj agregatora kontenerów.

2. Kontener jest katalogiem pierwszego poziomu w postaci dla użytkownika, który może mieć pewne atrybuty meta. Na przykład prawa dostępu.

3. Najnowszą i najbardziej poszukiwaną jednostką użytkownika są obiekty dołączone do kontenerów. Obiekty są trzymane płasko. Nie ma struktury katalogów. Katalog to tylko iluzja z nazwami.

W kontenerze może być nieograniczona liczba obiektów. Mieliśmy milion obiektów, programiści Swift próbowali użyć 10 milionów obiektów. Każdy typ obiektu jest powiązany z własnym pierścieniem mieszającym. Wszystko działa szybko. Gdy klaster jest wypełniony maksymalną liczbą obiektów, prędkość praktycznie się nie zmienia. Jeśli chodzi o dostęp, wszystko działa w prawie taki sam sposób, jak przy pustym.

Co zrobiliśmy najpierw? Najpierw pobraliśmy i wdrożyliśmy OpenStat i Swift zgodnie z zaleceniami społeczności programistów. Wzięliśmy serwery front-end, niektóre serwery zaplecza i poddaliśmy je kontroli rozwiązania Pacemaker. Uwielbiamy automatyzować wszystko i oszczędzać siłę pracowników.

Na serwerach zaplecza mieliśmy dyski twarde SATA z dostosowanym systemem plików XFS (nieznacznie zoptymalizowaliśmy ustawienia). Na serwerach zaplecza wdrożyliśmy wszystkie usługi pamięci masowej Swift (obiekt, konto, kontener). Dodatkowo umieszczamy tam rejestrowanie i fakturowanie, ponieważ musieliśmy brać pieniądze od użytkowników. To również było uważane za serwery zaplecza.

Na serwerach front-end zainstalowaliśmy Swift Proxy. Ponieważ każdy klaster musi być w nas niezawodny, istnieje pewien zestaw pływających adresów IP, które są przesyłane do serwerów na żywo za pomocą Pacemaker.

„Podnieśliśmy” tę decyzję, ale niestety, zgodnie z testami na froncie, otrzymaliśmy wydajność tylko 400 żądań na sekundę, co jest bardzo smutne. Dlatego zdecydowaliśmy się pomyśleć, co dalej.

Pierwszym, najbardziej oczywistym rozwiązaniem jest postawienie NGINX przed Swift Proxy. Działało. Analiza wniosków wykazała, że ​​nigdzie nie zastosowano buforowania. Cykl życia żądania od momentu wysłania żądania przez klienta do odpowiedzi był nadal przekazywany do serwerów zaplecza i z powrotem. Dlatego użycie buforowania w jakiejś formie było oczywistym rozwiązaniem.

Na serwerach front-end ustawiamy dyski SAS dla pamięci podręcznej w ReiserFS. Nie chcieliśmy marnować pojemności dysku w RAID, więc są tylko dodane dyski. Każdy dysk ma oddzielną strefę pamięci podręcznej. Aby to zrobić, musiałem trochę poprawić NGINX, dodając obsługę kilku pamięci podręcznych. Dzięki Cyrylowi z Koryntu pomógł w tym.

W tej wersji testów otrzymaliśmy już 12 tysięcy wniosków o front-end. To jest bardziej akceptowalne rozwiązanie. Klastry w centrum danych mogą mieć wiele. Dla każdego klastra istnieje kanał agregacji o wielkości około 4 Gbps dla każdego frontonu. Ogólnie dość dobre wykorzystanie zarówno kanału, jak i procesora.

W tym przypadku w pierwszym przypadku „odpoczęliśmy” od zasobów systemowych, ponieważ Swift jest napisany w Pythonie i zużywa znaczną ilość zasobów. W drugim przypadku, przy maksymalnym obciążeniu, prawie połowa zasobów jest relatywnie darmowa, a my już wiemy, do czego je wykorzystać.

Kiedy uruchomiliśmy usługę, użytkownicy zaczęli mieć problemy. Po pierwsze, nie podobał im się format linków podanych po umieszczeniu danych w repozytoriach.

Co to jest na górnym linku? cs1.clodo.ru to klaster, którym należy się zająć, aby uzyskać dane. v1 jest wersją protokołu, wszystko to jest analizowane przez serwer frontonu. Następnie mamy konto użytkownika. Ponadto przedrostek „public” oznacza kontener. images / image01.gif to nazwa obiektu. To nie jest katalog „obrazów” z plikiem obrazu.

Aby rozwiązać ten problem, ponownie użyliśmy NGINX. Zaczęliśmy przydzielać każdemu użytkownikowi wirtualny serwer HTTP (nie według procesu, mianowicie przez konfigurację) z jego domeną „publiczną”. Działało. Dodatkowo byliśmy w stanie kontrolować parametry buforowania danych każdego użytkownika, a także ustawić ważność i tak dalej.

Użytkownicy twierdzili, że nie podobał im się prefiks „public”. Na przykład, jeśli mają obraz umieszczony w publicznym kontenerze, chcą zobaczyć tylko „obrazy” w linku. Postanowiliśmy to również przy pomocy NGINX. Po prostu statystycznie wyglądał, gdzie częściej „użytkownicy szturchają”. W 98% przypadków nasze oczekiwania zostały spełnione, więc nie odczuwamy żadnej utraty wydajności.

Użytkownicy powiedzieli nam o innym problemie: „Usunąłem go i wszystko jest widoczne”. Wielu użytkowników narzekało na to.

W czym problem? Ponieważ buforujemy odpowiedzi serwera przez chwilę, istnieją dwie sytuacje.

Pierwszy. Użytkownik spojrzał na listę plików. Dodałem plik, spojrzałem na listę plików i byłem zaskoczony: „Gdzie jest mój plik?” Oczywiście, że tam jest. Jeśli sam poprosi o plik, otrzyma go, ale nie zobaczy go na liście. Użytkownik jest zdenerwowany.

Drugi problem jest bardziej istotny. Użytkownik przypadkowo umieścił swoje niefortunne zdjęcie w wannie, a następnie usunął je. Zdjęcie jest już buforowane. To naprawdę nieprzyjemne.

Podobne usługi, takie jak RackSpace, powiązane z zewnętrzną siecią CDN, odpowiadają: „To jest twój problem. Po 24 godzinach zdjęcie zostanie usunięte z pamięci podręcznej. ” Ale będzie za późno. Ponieważ wśród naszych klientów, którzy potrzebują tej usługi, są czasopisma i banki zdjęć związanych z dziennikarstwem, sytuacja ta w ogóle im nie odpowiadała.

Dlatego musieliśmy rozwiązać ten problem. Mamy demona w pobliżu NginX, który zarządza pamięcią podręczną. Początkowo próbowaliśmy programować w plikach konfiguracyjnych NginX i zapisywać logikę do czyszczenia pamięci podręcznej w NginX.

Najpierw dużo używaliśmy, jeśli. To nie było najlepsze rozwiązanie i natychmiast odmówiliśmy. Użyliśmy go nie dłużej niż 5 minut.

Następnie wypróbowaliśmy zintegrowane rozwiązanie Lua. Czas, który musieliśmy wydać na przetworzenie prośby, wciąż był wydawany na kilka nieciekawych rzeczy. Nie podobało nam się to.

Teraz, podczas przetwarzania żądania w akcji post, wysyłamy do FastCGI tylko samo żądanie (żądanie angielskie) użytkownika bez „treści”. Demon pamięci podręcznej zachowuje te żądania i czyści niezbędną pamięć podręczną w zoptymalizowany sposób. Na przykład, jeśli użytkownik usunął plik images / party / banya / jpg, musisz zaktualizować pamięć podręczną dla katalogu „party”, upuścić pamięć podręczną zgodnie z listą. Jeśli użytkownik usunął plik, musisz wyczyścić pamięć podręczną tego pliku. Co więcej, nie tylko na jednym serwerze frontonu; oczywiście demon czyści go na wszystkich serwerach frontonu w oczekującym klastrze. To bardzo miłe z jego strony.

Projekt w trakcie produkcji trwa już około trzech tygodni po wydaniu i testowaniu. On żyje i się rozwija. Mamy plany na przyszłość.

Najpierw stworzymy projekt „Wszystkie dzienniki dla ludzi!”. Jest on w jakiś sposób połączony z fakturowaniem, ponieważ Swift zapewnia możliwość naliczania opłat za pomocą analizy logów, ale z małym założeniem. Nie robimy nic przez pierwszą godzinę i czekamy na dane przez ostatnią godzinę przed początkiem drugiej godziny. Pod koniec trzeciej godziny przetwarzamy je, rozliczając. Ponieważ fakturowanie jest zawsze na sekundę lub minutę po minucie, rozwiązanie to nie pasowało do nas. Przepisaliśmy system rozliczeń, analizy logów i statystyk dla Swift. Jako miły bonus, udało nam się dodać dzienniki dystrybucji użytkowników do ich magazynu „chmury” w celu dalszej analizy. Zgadzasz się, to bardzo przydatna rzecz.

Następnie chcemy zoptymalizować to wszystko pod kątem dystrybucji treści multimedialnych, w szczególności wideo. Chcemy również wykonać replikację między różnymi klastrami, najlepiej w różnych centrach danych. Nowa wersja Swift pozwala to zrobić (została wydana niedawno, 22 listopada). Przy następnej aktualizacji wykonamy tę replikację. Ponadto, po zobaczeniu, jak odbywa się ta replikacja, zdaliśmy sobie sprawę, że możliwe jest utworzenie kopii zapasowej części repozytorium bezpośrednio dla użytkownika. Będzie to bardziej efektywne w porównaniu z opcją, w której użytkownik sam pobierze całą swoją zawartość. Po pierwsze, nie załaduje ponownie naszych serwerów front-end. Po drugie, jest to po prostu wygodniejsze.

Następnie chcemy autoryzować pubcookies i podpisane żądania. Teraz mamy kontener, który może być prywatny (angielski prywatny), w którym to przypadku nie jest dostępny przez HTTP bez autoryzacji (403-ty błąd zostanie zwrócony do serwerów frontonu) lub jest publicznie dostępny i wszystko, co jest w pojemniku. Rozwiązanie pośrednie dla scenariusza takiego jak „Wprowadziłem i chcę dać część fotobanku, na przykład zdjęcia w wysokiej rozdzielczości, tylko temu użytkownikowi” nie zostało jeszcze wdrożone. Ale wraz z wprowadzeniem pubcookies rozwiążemy ten problem.

Teraz chcemy narysować Swift Proxy w module NginX, ponieważ obecny Swift Proxy w Pythonie szuka tylko żądanego serwera zaplecza, analizując pierścień hash, po prostu patrzy, gdzie się zwrócić.

Następnie chcemy zakończyć obsługę HTTP 1.1 za pomocą Keep Alive in Upstream, nowej użytecznej funkcji NginX. Konieczne jest nieznaczne zmienienie ładowania danych w pamięci masowej i dodanie inteligencji do demona pamięci podręcznej. Może przepisać go na wszystko inne niż Perl, na którym jest napisane, tylko dla szybkości.

Co mamy w końcu?

Całkowita pojemność na klaster wynosi 840 terabajtów SATA na serwerze zaplecza. Szybka pamięć podręczna na serwerach frontonu, SAS 7 terabajtów. 512 gigabajtów pamięci do buforowania najgorętszych danych. Wszystko to jest umieszczone w 30 jednostkach (jednostka angielska) na stosie.

Używamy Debiana. Nie ma dysków, wszędzie obrazy Debian Live. Klaster jest sprawdzany przez Pacemaker, jest konfigurowany przez Chef. Dane konfiguracyjne to integracja z naszym panelem Clodo. Dzięki temu również przechodzi autoryzacja. To rozwiązanie może być stosowane nie tylko w naszym kraju, ale także w prywatnych „chmurach”. Zebranie tego wszystkiego w domu jest realne, a ponadto w rzeczywistości nie należy powtarzać naszych błędów.

Właściwie wszystko. Jestem gotów wysłuchać każdego z twoich pytań.

Pytania i odpowiedzi

Pytanie publiczności: Cześć! Dziękuję za raport. Pytanie: dlaczego konieczne było całkowite wyłączenie pamięci podręcznej i czy lista taka jak „lista relokacji” lub „lista opóźnień” jest odpowiednia dla tego profilu użytkowania?

Stanislav Bogatyrev: Po pierwsze, konieczne jest unieważnienie skrytek z powodów behawioralnych, które już wyznaczyłem. Chciałem także uzyskać minimalne modyfikacje istniejącego rozwiązania. Mieliśmy już NginX, mieliśmy już Swift. Wszystko działało. Po prostu nie chcieliśmy wprowadzać żadnych znaczących zmian w tej logice, więc uruchomiliśmy oddzielnego demona.

Replika publiczności: W każdym razie dla każdego żądania tworzysz dodatkowe pod-żądanie unieważnienia pamięci podręcznych.

Stanislav Bogatyrev: Nie, nie całkiem. Demon czyni to inteligentnym. Najpierw ratuje, długo myśli i wykonuje niezbędne minimum sprzątania.

Pytanie od publiczności: Oznacza to, że między usunięciem a faktycznym zaniknięciem treści nadal jest pewien odstęp?

Stanislav Bogatyrev: Tak, jest. Co więcej, gdybyśmy zaczęli usuwać wiele, wiele, długie, długie, ta luka wzrasta. Poprawimy specyficzne algorytmy unieważniania do potrzeb użytkowników. Ale staramy się nie przekraczać pewnej granicy inteligencji. Nie każdy musi wyczyścić pamięć podręczną w czasie rzeczywistym.

Pytanie od publiczności: A ty możesz wypowiedzieć postać? Jak długo zdjęcie znika po usunięciu?

Stanislav Bogatyrev: Jeśli masz szczęście, to prawie natychmiast.

Replika publiczności: Dziękuję.

Pytanie publiczności: Sam mówiłeś o magii „chmury” i ulubionym CMS użytkownika. Okazuje się, że jest to niemożliwe, ponieważ musisz zmodyfikować CMS?

Stanislav Bogatyrev: Są tu przedstawiciele Bitrix, którzy już wszystko sfinalizowali.

Pytanie od publiczności: Więc czekasz, aż większość programistów CMS dostosuje się do twojej chmury?

Stanislav Bogatyrev: Nie do końca. Mamy repozytorium korpusu Clodo na GitHub, powoli umieszczamy tam różne interesujące rzeczy. W Pythonie napisano serwer FTP, który tłumaczy ze zwykłego FTP na naszą „chmurę”. Jesteśmy prawie całkowicie zgodni z API RackSpace. Dlatego możesz korzystać ze wszystkich wydarzeń społeczności światowej w tej dziedzinie. To klient Fuse, to najszerszy zestaw „wrapperów” dla prawie wszystkich języków. Istnieje wiele opcji. Nie możesz niczego zmienić, po prostu zamontuj na Fuse, a to zadziała.

Pytanie od publiczności: Powiedz, proszę, czy mogę jakoś rozpocząć dystrybucję treści nie za pośrednictwem protokołu HTTP, ale używając innego protokołu? Na przykład przez FMS. Mam pliki wideo i chcę je przesyłać strumieniowo do użytkowników.

Stanislav Bogatyrev: W tej chwili nie ma takiej możliwości. Jeśli naprawdę chcesz, porozmawiamy o tym osobno, napisz do mnie.

Pytanie publiczności: Dobrze. Dziękuję Jest jeszcze jedno pytanie. Powiedziałeś, że rozliczenia są zorganizowane po stronie Swift. Jakie zapytania o płatności? Wnioski o przechowywanie lub prośby o zwrot? Prośby o rozliczenie NginX?

Stanislav Bogatyrev: Najwyraźniej niejasno się wyraziłem. Samo przetwarzanie odbywa się po stronie serwera. Rachunek, który zmienia się w NginX. Ruch przychodzący nie jest rozliczany. Fakturowanie jest wysyłane z naszego repozytorium do użytkownika z udanymi odpowiedziami.

Pytanie od publiczności: Proszę mi powiedzieć. Korzystasz z OpenStack jako platformy chmurowej. Prawda?

Stanislav Bogatyrev: Nie.

Pytanie publiczności: Jak go używasz?

Stanislav Bogatyrev: Używamy tylko OpenStack Swift jako podstawy klastra naszej „chmury”. Nie mamy OpenStack. Mamy Zen z własnymi modyfikacjami. W ogóle nie jest to openstack.

Pytanie publiczności: Cześć. Czy masz tymczasową obsługę URL? Przypuśćmy, że są przypadki, w których niektóre prywatne treści mogą być podane przez odniesienie, które będą nieważne po 10-15 sekundach?

Stanislav Bogatyrev: Mamy to w planach wraz z pubcookies, ponieważ NginX ma już wspaniały moduł.