Jak pracujete v IT, začínáte si všímat, že systémy mají svůj vlastní charakter. Mohou být flexibilní, tiché, excentrické a přísné. Mohou přitahovat nebo odpuzovat. Tak či onak s nimi musíte „vyjednávat“, manévrovat mezi „nástrahami“ a budovat řetězce jejich interakce.
Měli jsme tu čest vybudovat cloudovou platformu, a proto jsme potřebovali „přesvědčit“ několik subsystémů, aby s námi spolupracovaly. Naštěstí máme „jazyk API“, přímé ruce a spoustu nadšení.
Tento článek nebude technicky hardcore, ale popíše problémy, na které jsme narazili při budování cloudu. Rozhodl jsem se popsat naši cestu formou lehké technické fantazie o tom, jak jsme hledali společnou řeč se systémy a co z toho vzešlo.
Vítejte u kočky.
Začátek cesty
Před časem byl náš tým pověřen spuštěním cloudové platformy pro naše klienty. Měli jsme podporu pro správu, zdroje, hardwarovou sadu a svobodu při výběru technologií pro implementaci softwarové části služby.
Bylo zde také několik požadavků:
- služba potřebuje pohodlný osobní účet;
- platforma musí být integrována do stávajícího fakturačního systému;
- software a hardware: OpenStack + Tungsten Fabric (Open Contrail), kterou se naši inženýři naučili docela dobře „vařit“.
Pokud bude mít komunita Habra zájem, o tom, jak byl tým sestaven, bylo vyvinuto rozhraní osobního účtu a učiněna rozhodnutí o designu, vám povíme jindy.
Nástroje, které jsme se rozhodli použít:
- Python + Flask + Swagger + SQLAlchemy - zcela standardní sada Pythonu;
- Vue.js pro frontend;
- Rozhodli jsme se provést interakci mezi komponentami a službami pomocí Celery přes AMQP.
Předjímám otázky ohledně výběru Pythonu, vysvětlím. Jazyk si v naší společnosti našel své místo a vytvořila se kolem něj malá, ale přesto kultura. Proto bylo rozhodnuto službu na něm začít stavět. Navíc rychlost vývoje takových problémů je často rozhodující.
Začněme tedy naše seznamování.
Tichý účet - vyúčtování
Toho chlapa známe dlouho. Vždycky seděl vedle mě a tiše něco počítal. Někdy nám přeposílal požadavky uživatelů, vystavoval klientské faktury a spravoval služby. Obyčejný pracovitý chlap. Pravda, byly potíže. Je tichý, někdy přemýšlivý a často myslí na své.
Fakturace je první systém, se kterým jsme se snažili spřátelit. A první problém, na který jsme narazili, byl při zpracování služeb.
Například, když je vytvořen nebo odstraněn, úkol přejde do interní fakturační fronty. Je tedy implementován systém asynchronní práce se službami. Abychom mohli zpracovat naše typy služeb, museli jsme „zařadit“ naše úkoly do této fronty. A zde jsme narazili na problém: nedostatek dokumentace.
Soudě podle popisu softwarového API je stále možné tento problém vyřešit, ale neměli jsme čas na reverzní inženýrství, takže jsme vzali logiku mimo a zorganizovali frontu úloh nad RabbitMQ. Operaci na službě iniciuje klient ze svého osobního účtu, na backendu se promění v Celery „úkol“ a provádí se na straně fakturace a OpenStacku. Celer umožňuje poměrně pohodlně spravovat úkoly, organizovat opakování a sledovat stav. Více o „celeru“ si můžete přečíst např. .
Vyúčtování také nezastavilo projekt, kterému došly peníze. Při komunikaci s vývojáři jsme zjistili, že při výpočtu statistik (a přesně tuto logiku potřebujeme implementovat) existuje složitý vzájemný vztah zastavovacích pravidel. Tyto modely ale příliš nezapadají do naší reality. Implementovali jsme to také prostřednictvím úloh na Celery, čímž jsme logiku správy služeb přenesli na backendovou stranu.
Oba výše uvedené problémy vedly k tomu, že se kód trochu nafoukl a v budoucnu budeme muset refaktorovat, abychom přesunuli logiku pro práci s úkoly do samostatné služby. Abychom tuto logiku podpořili, musíme v našich tabulkách uložit některé informace o uživatelích a jejich službách.
Dalším problémem je ticho.
Billy tiše odpovídá „OK“ na některé požadavky API. Bylo tomu tak například v případě, kdy jsme během testu prováděli platby slíbených plateb (o tom později). Požadavky byly provedeny správně a nezaznamenali jsme žádné chyby.
Musel jsem studovat logy při práci se systémem přes UI. Ukázalo se, že podobné požadavky provádí samotná fakturace, která mění rozsah na konkrétního uživatele, například admin, a předává jej v parametru su.
Obecně platí, že i přes mezery v dokumentaci a drobné nedostatky API šlo vše docela dobře. Protokoly lze číst i při velkém zatížení, pokud rozumíte tomu, jak jsou strukturovány a co hledat. Struktura databáze je zdobná, ale vcelku logická a v některých ohledech i atraktivní.
Abychom to shrnuli, hlavní problémy, se kterými jsme se setkali ve fázi interakce, souvisí s implementačními prvky konkrétního systému:
- nezdokumentované „funkce“, které nás tak či onak ovlivnily;
- uzavřený zdroj (fakturace je napsána v C++), v důsledku toho není možné vyřešit problém 1 jiným způsobem než „pokusem a omylem“.
Naštěstí má produkt poměrně rozsáhlé API a do našeho osobního účtu jsme integrovali následující subsystémy:
- modul technické podpory - požadavky z vašeho osobního účtu jsou transparentně „zprostředkovány“ fakturaci pro klienty služeb;
- finanční modul - umožňuje vystavovat faktury stávajícím klientům, provádět odpisy a generovat platební doklady;
- servisní modul - k tomu jsme museli implementovat vlastní handler. Rozšiřitelnost systému nám hrála do karet a Billyho jsme „naučili“ nový typ služby.
Byl to trochu problém, ale tak či onak si myslím, že si Billy a já rozumíme.
Procházka wolframovými poli – Tungsten Fabric
Wolframová pole posetá stovkami drátů, jimiž procházejí tisíce bitů informací. Informace se jako kouzlem shromažďují do „balíčků“, analyzují a vytvářejí složité trasy.
To je doména druhého systému, se kterým jsme se museli spřátelit – Tungsten Fabric (TF), dříve OpenContrail. Jeho úkolem je správa síťových zařízení a poskytování softwarové abstrakce nám jako uživatelům. TF - SDN, zapouzdřuje komplexní logiku práce se síťovým zařízením. O samotné technologii je dobrý článek, např. .
Systém je integrován s OpenStack (probráno níže) prostřednictvím pluginu Neutron.
Interakce služeb OpenStack.
S tímto systémem nás seznámili kluci z provozního oddělení. Ke správě síťového zásobníku našich služeb používáme systémové API. Zatím nám to nezpůsobilo žádné vážné problémy nebo nepříjemnosti (nemohu mluvit za kluky z OE), ale v interakci se objevily nějaké zvláštnosti.
První vypadal takto: příkazy, které při připojení přes SSH vyžadovaly výstup velkého množství dat do konzole instance, připojení jednoduše „zavěsily“, zatímco přes VNC vše fungovalo správně.
Pro ty, kteří se v problému neznají, to vypadá docela legračně: ls /root funguje správně, zatímco například top úplně „zamrzne“. Naštěstí jsme se již dříve setkali s podobnými problémy. Rozhodlo se ladění MTU na trase od výpočetních uzlů k routerům. Mimochodem, toto není problém TF.
Další problém byl hned za rohem. V jednom „krásném“ okamžiku zmizelo kouzlo routování, jen tak. TF přestal spravovat směrování na zařízení.
S Openstack jsme pracovali z úrovně administrátora a poté jsme přešli na požadovanou uživatelskou úroveň. Zdá se, že SDN „unese“ rozsah uživatele, který tyto akce provádí. Faktem je, že pro připojení TF a OpenStack se používá stejný účet správce. V kroku přechodu na uživatele „kouzlo“ zmizelo. Bylo rozhodnuto vytvořit samostatný účet pro práci se systémem. To nám umožnilo pracovat bez porušení integrační funkce.
Silicon Lifeforms - OpenStack
Bizarně tvarovaný silikonový tvor žije poblíž wolframových polí. Ze všeho nejvíc to vypadá jako přerostlé dítě, které nás dokáže rozdrtit jedním švihem, ale žádná zjevná agresivita z něj nejde. Nevyvolává strach, ale jeho velikost vzbuzuje strach. Stejně jako složitost toho, co se děje kolem.
OpenStack je jádrem naší platformy.
OpenStack má několik podsystémů, z nichž v současnosti nejaktivněji využíváme Nova, Glance a Cinder. Každý z nich má své vlastní API. Nova je zodpovědná za výpočetní zdroje a tvorbu instancí, Cinder je zodpovědná za správu svazků a jejich snapshotů, Glance je image služba, která spravuje šablony OS a metainformace na nich.
Každá služba běží v kontejneru a zprostředkovatelem zpráv je „bílý králík“ - RabbitMQ.
Tento systém nám způsobil nejneočekávanější potíže.
A první problém na sebe nenechal dlouho čekat, když jsme se pokusili k serveru připojit další svazek. Cinder API rozhodně odmítlo provést tento úkol. Přesněji řečeno, pokud věříte samotnému OpenStacku, spojení je navázáno, ale uvnitř virtuálního serveru není žádné diskové zařízení.
Rozhodli jsme se jít oklikou a stejnou akci jsme požadovali od Nova API. Výsledkem je, že se zařízení správně připojuje a je přístupné na serveru. Zdá se, že problém nastane, když block-storage nereaguje na Cinder.
Další úskalí nás čekalo při práci s disky. Systémový svazek nelze odpojit od serveru.
OpenStack sám opět „přísahá“, že zničil spojení a nyní můžete správně pracovat s objemem samostatně. Ale API kategoricky nechtělo provádět operace na disku.
Zde jsme se rozhodli nijak zvlášť nebojovat, ale změnit náš pohled na logiku služby. Pokud existuje instance, musí existovat také systémový svazek. Uživatel tedy zatím nemůže odebrat nebo deaktivovat systémový „disk“, aniž by smazal „server“.
OpenStack je poměrně složitá sada systémů s vlastní logikou interakce a vyšperkovaným API. Pomáhá nám poměrně podrobná dokumentace a samozřejmě metoda pokus-omyl (kde bychom bez ní byli).
Zkušební provoz
Testovací spuštění jsme provedli v prosinci loňského roku. Hlavním úkolem bylo otestovat náš projekt v bojovém režimu po technické stránce i po stránce UX. Publikum bylo pozváno selektivně a testování bylo uzavřeno. Ponechali jsme však i možnost požádat o přístup k testování na našem webu.
Samotný test se samozřejmě neobešel bez vtipných momentů, protože tady naše dobrodružství teprve začínají.
Jednak jsme poněkud nesprávně vyhodnotili zájem o projekt a museli jsme rychle přidávat výpočetní uzly hned během testu. Běžný případ pro cluster, ale i zde byly určité nuance. V dokumentaci ke konkrétní verzi TF je uvedena konkrétní verze jádra, na kterém byla testována práce s vRouterem. Rozhodli jsme se spustit uzly s novějšími jádry. V důsledku toho TF nepřijímal cesty z uzlů. Musel jsem urychleně vrátit jádra zpět.
Další kuriozita souvisí s funkčností tlačítka „změnit heslo“ ve vašem osobním účtu.
Rozhodli jsme se použít JWT k uspořádání přístupu k našemu osobnímu účtu, abychom nepracovali s relacemi. Vzhledem k tomu, že systémy jsou různorodé a široce rozptýlené, spravujeme vlastní token, do kterého „zabalujeme“ relace z fakturace a token z OpenStacku. Při změně hesla se token samozřejmě „pokazí“, protože uživatelská data již nejsou platná a je třeba je znovu vydat.
Tento bod jsme ztratili ze zřetele a na rychlé dokončení tohoto dílu prostě nebylo dost zdrojů. Funkčnost jsme museli vystřihnout těsně před spuštěním testu.
V současné době odhlašujeme uživatele, pokud bylo heslo změněno.
Navzdory těmto nuancím dopadlo testování dobře. Za pár týdnů se u nás zastavilo asi 300 lidí. Mohli jsme se na produkt podívat očima uživatelů, otestovat jej v akci a shromáždit kvalitní zpětnou vazbu.
Chcete-li se pokračovat
Pro mnohé z nás je to první projekt takového rozsahu. Získali jsme řadu cenných lekcí o tom, jak pracovat jako tým a činit architektonická a designová rozhodnutí. Jak integrovat složité systémy s malými prostředky a uvést je do výroby.
Samozřejmě je na čem pracovat jak po stránce kódu, tak na rozhraních systémové integrace. Projekt je poměrně mladý, ale my jsme plní ambicí rozvinout jej ve spolehlivou a pohodlnou službu.
Systémy se nám již podařilo přesvědčit. Bill ve své skříni svědomitě vyřizuje počítání, účtování a požadavky uživatelů. „Kouzlo“ wolframových polí nám poskytuje stabilní komunikaci. A pouze OpenStack je někdy rozmarný a křičí něco jako „WSREP ještě nepřipravil uzel pro použití aplikací“. Ale to je úplně jiný příběh...
Nedávno jsme službu spustili.
Veškeré podrobnosti se dozvíte na našem .
vývojový tým CLO
Užitečné odkazy
OpenStack
Wolframová tkanina
Zdroj: www.habr.com