Pracując w IT, zaczynasz zauważać, że systemy mają swój własny charakter. Mogą być elastyczne, ciche, ekscentryczne i surowe. Mogą przyciągać lub odpychać. Tak czy inaczej trzeba z nimi „negocjować”, manewrować pomiędzy „pułapkami” i budować łańcuchy ich interakcji.
Mieliśmy więc zaszczyt zbudować platformę chmurową i do tego musieliśmy „namówić” kilka podsystemów do współpracy z nami. Na szczęście mamy „język API”, bezpośrednie ręce i mnóstwo entuzjazmu.
Artykuł ten nie będzie trudny technicznie, ale opisze problemy, jakie napotkaliśmy podczas budowania chmury. Postanowiłem opisać naszą drogę w formie lekkiej technicznej fantazji o tym, jak szukaliśmy wspólnego języka z systemami i co z tego wyszło.
Witamy w kocie.
Początku drogi
Jakiś czas temu nasz zespół otrzymał zadanie uruchomienia platformy chmurowej dla naszych klientów. Mieliśmy wsparcie zarządcze, zasoby, stos sprzętowy oraz swobodę w wyborze technologii realizacji części programowej usługi.
Było też kilka wymagań:
- usługa wymaga wygodnego konta osobistego;
- platforma musi zostać zintegrowana z istniejącym systemem bilingowym;
- oprogramowanie i sprzęt: OpenStack + Tungsten Fabric (Open Contrail), które nasi inżynierowie nauczyli się całkiem nieźle „gotować”.
O tym, jak skompletowano zespół, opracowano interfejs konta osobistego i podjęto decyzje projektowe, opowiemy innym razem, jeśli społeczność Habra będzie zainteresowana.
Narzędzia, które zdecydowaliśmy się zastosować:
- Python + Flask + Swagger + SQLAlchemy - całkowicie standardowy zestaw Pythona;
- Vue.js dla frontendu;
- Zdecydowaliśmy się na interakcję między komponentami i usługami przy użyciu Celery za pośrednictwem AMQP.
Uprzedzając pytania dotyczące wyboru Pythona, już wyjaśniam. Język znalazł w naszej firmie swoją niszę i wokół niego rozwinęła się niewielka, ale jednak kultura. Dlatego zdecydowano się rozpocząć na nim budowę serwisu. Co więcej, często decydująca jest szybkość rozwoju takich problemów.
Zacznijmy więc naszą znajomość.
Cichy rachunek – fakturowanie
Znamy tego gościa od dawna. Zawsze siadał obok mnie i w milczeniu coś liczył. Czasami przekazywał nam żądania użytkowników, wystawiał faktury dla klientów i zarządzał usługami. Zwykły, ciężko pracujący facet. To prawda, że były trudności. Jest cichy, czasem zamyślony, często pogrążony w myślach.
Billing to pierwszy system, z którym próbowaliśmy się zaprzyjaźnić. Pierwszą trudnością, jaką napotkaliśmy, było przetwarzanie usług.
Na przykład po utworzeniu lub usunięciu zadanie trafia do wewnętrznej kolejki rozliczeniowej. W ten sposób zaimplementowano system asynchronicznej pracy z usługami. Aby przetworzyć nasze typy usług, musieliśmy „umieścić” nasze zadania w tej kolejce. I tu napotkaliśmy problem: brak dokumentacji.
Sądząc po opisie API oprogramowania, nadal można rozwiązać ten problem, ale nie mieliśmy czasu na inżynierię wsteczną, więc wynieśliśmy logikę na zewnątrz i zorganizowaliśmy kolejkę zadań na RabbitMQ. Operacja na usłudze jest inicjowana przez klienta z jego konta osobistego, zamienia się w „zadanie” Selera na backendzie i jest wykonywana po stronie rozliczeniowej i OpenStack. Seler ułatwia zarządzanie zadaniami, organizowanie powtórzeń i monitorowanie statusu. Więcej o selerze można przeczytać np. .
Ponadto rozliczenie nie powstrzymało projektu, w którym zabrakło pieniędzy. Komunikując się z twórcami, dowiedzieliśmy się, że podczas obliczania statystyk (a musimy wdrożyć dokładnie taką logikę) istnieje złożona współzależność reguł zatrzymywania. Ale te modele nie pasują do naszej rzeczywistości. Wdrożyliśmy go również poprzez zadania na Celery, przenosząc logikę zarządzania usługami na stronę backendu.
Obydwa powyższe problemy spowodowały, że kod stał się nieco rozdęty i w przyszłości będziemy musieli przeprowadzić refaktoryzację, aby przenieść logikę pracy z zadaniami do osobnej usługi. Aby wspierać tę logikę, musimy również przechowywać w naszych tabelach pewne informacje o użytkownikach i ich usługach.
Kolejnym problemem jest cisza.
Billy cicho odpowiada „OK” na niektóre żądania API. Tak było np. gdy w trakcie testu realizowaliśmy obiecane płatności (więcej o tym później). Żądania zostały wykonane poprawnie i nie zauważyliśmy żadnych błędów.
Musiałem przestudiować logi podczas pracy z systemem za pośrednictwem interfejsu użytkownika. Okazało się, że sam billing wykonuje podobne żądania, zmieniając zakres na konkretnego użytkownika, np. admin, przekazując go w parametrze su.
Ogólnie rzecz biorąc, pomimo luk w dokumentacji i drobnych błędów w API, wszystko poszło całkiem nieźle. Dzienniki można odczytać nawet pod dużym obciążeniem, jeśli rozumiesz ich strukturę i na co zwrócić uwagę. Struktura bazy danych jest ozdobna, ale dość logiczna i pod pewnymi względami nawet atrakcyjna.
Podsumowując, główne problemy, które napotkaliśmy na etapie interakcji, są związane z cechami implementacyjnymi konkretnego systemu:
- nieudokumentowane „cechy”, które wpłynęły na nas w taki czy inny sposób;
- zamknięte źródło (rozliczenia są napisane w C++), w rezultacie - nie da się rozwiązać problemu 1 w żaden inny sposób niż „próbami i błędami”.
Na szczęście produkt posiada dość rozbudowane API i do naszego konta osobistego zintegrowaliśmy następujące podsystemy:
- moduł wsparcia technicznego - żądania z Twojego konta osobistego są „przekazywane” do rozliczeń w sposób przejrzysty dla klientów usługi;
- moduł finansowy - umożliwia wystawianie faktur obecnym klientom, dokonywanie odpisów oraz generowanie dokumentów płatniczych;
- moduł kontroli usług - w tym celu musieliśmy zaimplementować własny handler. Możliwość rozbudowy systemu zadziałała w nasze ręce i „nauczyliśmy” Billy’ego nowego rodzaju usług.
Było to trochę kłopotliwe, ale tak czy inaczej myślę, że Billy i ja będziemy się dogadywać.
Spacer po polach wolframu – tkanina wolframowa
Pola wolframu usiane setkami drutów przepuszczają przez nie tysiące bitów informacji. Informacje są gromadzone w „pakietach”, analizowane, tworząc skomplikowane trasy, jak za dotknięciem czarodziejskiej różdżki.
To domena drugiego systemu, z którym musieliśmy się zaprzyjaźnić – Tungsten Fabric (TF), dawniej OpenContrail. Jego zadaniem jest zarządzanie sprzętem sieciowym, dostarczanie nam, jako użytkownikom, abstrakcji oprogramowania. TF - SDN, zawiera złożoną logikę pracy ze sprzętem sieciowym. Jest dobry artykuł o samej technologii, np. .
System jest zintegrowany z OpenStack (omówione poniżej) poprzez wtyczkę Neutron.
Interakcja usług OpenStack.
Chłopaki z działu operacyjnego zapoznali nas z tym systemem. Do zarządzania stosem sieciowym naszych usług wykorzystujemy API systemu. Nie spowodowało to jeszcze żadnych poważnych problemów ani niedogodności (nie mogę się wypowiadać za chłopaków z OE), ale były pewne dziwactwa w interakcji.
Pierwsza wyglądała tak: polecenia wymagające wysłania dużej ilości danych do konsoli instancji podczas łączenia się przez SSH po prostu „rozłączały” połączenie, natomiast przez VNC wszystko działało poprawnie.
Dla nieobeznanych z problemem wygląda to dość zabawnie: ls /root działa poprawnie, natomiast np. top „zawiesza się” całkowicie. Na szczęście już wcześniej napotykaliśmy podobne problemy. Zdecydowano o dostrojeniu MTU na trasie od węzłów obliczeniowych do routerów. Nawiasem mówiąc, to nie jest problem TF.
Następny problem czaił się tuż za rogiem. W jednym „pięknym” momencie magia routingu zniknęła, tak po prostu. TF przestał zarządzać routingiem na sprzęcie.
Pracowaliśmy z Openstack od poziomu administratora, a następnie przeszliśmy na wymagany poziom użytkownika. Wygląda na to, że SDN „przejmuje” zakres użytkownika, który wykonuje czynności. Faktem jest, że to samo konto administratora służy do łączenia TF i OpenStack. Na etapie przejścia na użytkownika „magia” zniknęła. Zdecydowano o utworzeniu osobnego konta do pracy z systemem. Dzięki temu mogliśmy pracować bez psucia funkcjonalności integracji.
Silikonowe formy życia — OpenStack
W pobliżu pól wolframu żyje silikonowa istota o dziwnym kształcie. Przede wszystkim wygląda jak przerośnięte dziecko, które jednym zamachem może nas zmiażdżyć, ale nie widać w nim wyraźnej agresji. Nie powoduje strachu, ale jego wielkość budzi strach. Podobnie jak złożoność tego, co dzieje się wokół.
OpenStack jest sercem naszej platformy.
OpenStack posiada kilka podsystemów, z których obecnie najaktywniej korzystamy z Nova, Glance i Cinder. Każdy z nich posiada własne API. Nova odpowiada za zasoby obliczeniowe i tworzenie instancji, Cinder odpowiada za zarządzanie woluminami i ich migawkami, Glance to usługa obrazowa zarządzająca szablonami systemów operacyjnych i znajdującymi się na nich metainformacjami.
Każda usługa działa w kontenerze, a brokerem komunikatów jest „biały królik” – RabbitMQ.
Ten system sprawił nam najbardziej nieoczekiwane kłopoty.
A pierwszy problem nie trwał długo, gdy próbowaliśmy podłączyć dodatkowy wolumin do serwera. Cinder API kategorycznie odmówił wykonania tego zadania. Dokładniej, jeśli wierzyć samemu OpenStack, połączenie zostanie nawiązane, ale wewnątrz serwera wirtualnego nie ma urządzenia dyskowego.
Zdecydowaliśmy się na objazd i poprosiliśmy o to samo działanie w interfejsie API Nova. W rezultacie urządzenie łączy się prawidłowo i jest dostępne w obrębie serwera. Wygląda na to, że problem występuje, gdy pamięć blokowa nie reaguje na Cinder.
Kolejna trudność czekała nas podczas pracy z dyskami. Nie można odłączyć wolumenu systemowego od serwera.
Ponownie sam OpenStack „przysięga”, że zniszczył połączenie i teraz możesz poprawnie pracować z głośnością osobno. Ale API kategorycznie nie chciało wykonywać operacji na dysku.
Tutaj postanowiliśmy nie walczyć szczególnie, ale zmienić nasz pogląd na logikę nabożeństwa. Jeśli istnieje instancja, musi istnieć również wolumin systemowy. Dlatego użytkownik nie może jeszcze usunąć ani wyłączyć „dysku” systemowego bez usunięcia „serwera”.
OpenStack to dość złożony zestaw systemów z własną logiką interakcji i ozdobnym API. Pomaga nam dość szczegółowa dokumentacja i oczywiście metoda prób i błędów (gdzie byśmy bez niej byli).
Testowe uruchomienie
Testowe uruchomienie przeprowadziliśmy w grudniu ubiegłego roku. Głównym zadaniem było przetestowanie naszego projektu w trybie bojowym od strony technicznej oraz od strony UX. Publiczność była zapraszana wybiórczo, a testy zamknięto. Jednakże pozostawiliśmy również możliwość zażądania dostępu do testów na naszej stronie internetowej.
Sam test oczywiście nie obył się bez zabawnych momentów, bo to właśnie tam dopiero zaczynają się nasze przygody.
Po pierwsze, nieco błędnie oceniliśmy zainteresowanie projektem i musieliśmy szybko dodać węzły obliczeniowe już w trakcie testu. Typowy przypadek klastra, ale i tutaj były pewne niuanse. Dokumentacja dla konkretnej wersji TF wskazuje konkretną wersję jądra, na której testowano współpracę z vRouterem. Zdecydowaliśmy się uruchomić węzły z nowszymi jądrami. W rezultacie TF nie otrzymał tras z węzłów. Musiałem pilnie wycofać jądra.
Kolejna ciekawostka związana jest z funkcjonalnością przycisku „zmień hasło” w koncie osobistym.
Postanowiliśmy wykorzystać JWT do zorganizowania dostępu do naszego konta osobistego, aby nie pracować z sesjami. Ponieważ systemy są różnorodne i mocno rozproszone, zarządzamy własnym tokenem, w który „opakowujemy” sesje z billingu i token z OpenStack. Po zmianie hasła token oczywiście „ulega uszkodzeniu”, ponieważ dane użytkownika tracą ważność i należy je ponownie wystawić.
Straciliśmy ten punkt z oczu i po prostu nie było wystarczających zasobów, aby szybko ukończyć ten artykuł. Musieliśmy wyciąć tę funkcjonalność tuż przed uruchomieniem testu.
Obecnie wylogowujemy użytkownika, jeśli hasło zostało zmienione.
Pomimo tych niuansów testy wypadły dobrze. W ciągu kilku tygodni odwiedziło nas około 300 osób. Udało nam się spojrzeć na produkt oczami użytkowników, przetestować go w działaniu i zebrać wysokiej jakości opinie.
Aby być kontynuowane
Dla wielu z nas jest to pierwszy projekt na taką skalę. Dowiedzieliśmy się wielu cennych lekcji na temat pracy zespołowej i podejmowania decyzji architektonicznych i projektowych. Jak zintegrować złożone systemy przy niewielkich zasobach i wdrożyć je na produkcję.
Oczywiście jest nad czym pracować zarówno jeśli chodzi o kod, jak i przy interfejsach integracji systemów. Projekt jest dość młody, ale mamy ambicje, aby przekształcić go w niezawodną i wygodną usługę.
Udało nam się już przekonać systemy. Bill sumiennie zajmuje się liczeniem, fakturowaniem i żądaniami użytkowników w swojej szafie. „Magia” pól wolframowych zapewnia nam stabilną komunikację. I tylko OpenStack czasami ulega kaprysowi i krzyczy coś w rodzaju „WSREP nie przygotował jeszcze węzła do użycia aplikacji”. Ale to zupełnie inna historia...
Niedawno uruchomiliśmy usługę.
Wszystkie szczegóły znajdziesz na naszej stronie .
Zespół Rozwoju CLO
Przydatne linki
OpenStack
Tkanina wolframowa
Źródło: www.habr.com