Keď pracujete v IT, začínate si všímať, že systémy majú svoj vlastný charakter. Môžu byť flexibilné, tiché, excentrické a prísne. Môžu priťahovať alebo odpudzovať. Tak či onak, musíte s nimi „vyjednávať“, manévrovať medzi „nástrahami“ a budovať reťazce ich interakcie.
Mali sme teda tú česť vybudovať cloudovú platformu, a preto sme potrebovali „presvedčiť“ niekoľko podsystémov, aby s nami spolupracovali. Našťastie máme „jazyk API“, priame ruky a veľa nadšenia.
Tento článok nebude technicky náročný, ale bude popisovať problémy, s ktorými sme sa stretli pri budovaní cloudu. Rozhodol som sa opísať našu cestu formou ľahkej technickej fantázie o tom, ako sme hľadali spoločnú reč so systémami a čo z toho vzišlo.
Vitajte v mačke.
Začiatok cesty
Pred časom bol náš tím poverený spustením cloudovej platformy pre našich klientov. Mali sme podporu manažmentu, zdroje, hardvérový zásobník a slobodu pri výbere technológií na implementáciu softvérovej časti služby.
Bolo tam tiež niekoľko požiadaviek:
- služba potrebuje pohodlný osobný účet;
- platforma musí byť integrovaná do existujúceho fakturačného systému;
- softvér a hardvér: OpenStack + Tungsten Fabric (Open Contrail), ktorý sa naši inžinieri naučili celkom dobre „variť“.
O tom, ako bol tím zostavený, ako bolo vyvinuté rozhranie osobného účtu a prijaté rozhodnutia o dizajne, vám povieme inokedy, ak bude mať komunita Habra záujem.
Nástroje, ktoré sme sa rozhodli použiť:
- Python + Flask + Swagger + SQLAlchemy - úplne štandardná sada Pythonu;
- Vue.js pre frontend;
- Rozhodli sme sa urobiť interakciu medzi komponentmi a službami pomocou Celery cez AMQP.
Očakávajúc otázky týkajúce sa výberu Pythonu, vysvetlím. Jazyk si našiel svoje miesto v našej spoločnosti a vytvorila sa okolo neho malá, no stále kultúra. Preto sa rozhodlo, že službu na ňom začne stavať. Navyše rýchlosť vývoja takýchto problémov je často rozhodujúca.
Začnime teda naše zoznámenie.
Tichý účet - účtovanie
Tohto chlapíka poznáme už dlho. Vždy sedel vedľa mňa a ticho niečo počítal. Niekedy nám preposielal požiadavky používateľov, vystavoval klientske faktúry a spravoval služby. Obyčajný pracovitý chlap. Pravda, vyskytli sa ťažkosti. Je tichý, niekedy zamyslený a často na vlastnú päsť.
Fakturácia je prvý systém, s ktorým sme sa snažili spriateliť. A prvý problém, s ktorým sme sa stretli, bol pri spracovaní služieb.
Napríklad po vytvorení alebo odstránení úloha prejde do interného fakturačného frontu. Je teda implementovaný systém asynchrónnej práce so službami. Na spracovanie našich typov služieb sme potrebovali „zaradiť“ naše úlohy do tohto frontu. A tu sme narazili na problém: nedostatok dokumentácie.
Súdiac podľa popisu softvérového API, je stále možné tento problém vyriešiť, ale nemali sme čas na reverzné inžinierstvo, takže sme vzali logiku von a zorganizovali sme rad úloh na vrchole RabbitMQ. Operáciu na službe iniciuje klient zo svojho osobného účtu, na backende sa zmení na celerovskú „úlohu“ a vykoná sa na strane fakturácie a OpenStacku. Vďaka zeleru je celkom pohodlné spravovať úlohy, organizovať opakovania a sledovať stav. Viac o „zeleri“ si môžete prečítať napr. .
Účtovanie tiež nezastavilo projekt, ktorému došli peniaze. Pri komunikácii s vývojármi sme zistili, že pri výpočte štatistík (a musíme implementovať presne túto logiku) existuje zložitý vzájomný vzťah medzi pravidlami zastavenia. Tieto modely však nezodpovedajú našej realite. Implementovali sme to aj prostredníctvom úloh na Celery, pričom logiku správy služieb sme preniesli na backendovú stranu.
Oba vyššie uvedené problémy viedli k tomu, že kód sa trochu nafúkol a v budúcnosti budeme musieť refaktorovať, aby sa logika pre prácu s úlohami presunula do samostatnej služby. Na podporu tejto logiky musíme v našich tabuľkách uložiť aj niektoré informácie o používateľoch a ich službách.
Ďalším problémom je ticho.
Billy potichu odpovedá „OK“ na niektoré požiadavky API. Tak to bolo napríklad vtedy, keď sme počas testu realizovali platby sľúbených platieb (o tom neskôr). Požiadavky boli vykonané správne a nezaznamenali sme žiadne chyby.
Pri práci so systémom cez UI som musel študovať logy. Ukázalo sa, že samotná fakturácia vykonáva podobné požiadavky, pričom mení rozsah na konkrétneho používateľa, napríklad admin, a odovzdáva ho v parametri su.
Vo všeobecnosti, napriek medzerám v dokumentácii a menším chybám API, všetko išlo celkom dobre. Protokoly je možné čítať aj pri veľkom zaťažení, ak rozumiete ich štruktúre a čo hľadať. Štruktúra databázy je vyšperkovaná, no celkom logická a v niektorých smeroch dokonca atraktívna.
Aby sme to zhrnuli, hlavné problémy, s ktorými sme sa stretli vo fáze interakcie, súvisia s implementačnými vlastnosťami konkrétneho systému:
- nezdokumentované „funkcie“, ktoré nás tak či onak ovplyvnili;
- uzavretý zdroj (účtovanie je napísané v C++), v dôsledku toho nie je možné vyriešiť problém 1 iným spôsobom ako „pokus-omyl“.
Našťastie má produkt pomerne rozsiahle API a do nášho osobného účtu sme integrovali nasledujúce podsystémy:
- modul technickej podpory - požiadavky z vášho osobného účtu sú „spropriované“ k fakturácii transparentne pre klientov služieb;
- finančný modul - umožňuje vystavovať faktúry súčasným klientom, robiť odpisy a generovať platobné doklady;
- servisný riadiaci modul - na to sme museli implementovať vlastný handler. Rozšíriteľnosť systému nám hrala do karát a Billyho sme „naučili“ nový typ služby.
Bol to trochu problém, ale tak či onak si myslím, že Billy a ja si budeme rozumieť.
Prechádzka volfrámovými poliami – Tungsten Fabric
Volfrámové polia posiate stovkami drôtov, ktoré cez ne prenášajú tisíce bitov informácií. Informácie sa zhromažďujú do „paketov“, analyzujú a vytvárajú zložité trasy, akoby mágiou.
To je doména druhého systému, s ktorým sme sa museli spriateliť – Tungsten Fabric (TF), predtým OpenContrail. Jeho úlohou je spravovať sieťové zariadenia a poskytovať nám ako používateľom softvérovú abstrakciu. TF - SDN, zahŕňa komplexnú logiku práce so sieťovými zariadeniami. O samotnej technológii je dobrý článok, napr. .
Systém je integrovaný s OpenStack (diskutované nižšie) prostredníctvom pluginu Neutron.
Interakcia služieb OpenStack.
S týmto systémom nás oboznámili chalani z operačného oddelenia. Na správu sieťového zásobníka našich služieb používame systémové API. Zatiaľ nám to nespôsobilo žiadne vážne problémy ani nepríjemnosti (nemôžem hovoriť za chlapcov z OE), ale v interakcii sa vyskytli nejaké zvláštnosti.
Prvý vyzeral takto: príkazy, ktoré vyžadovali výstup veľkého množstva údajov do konzoly inštancie pri pripojení cez SSH, jednoducho „zavesili“ pripojenie, zatiaľ čo cez VNC všetko fungovalo správne.
Pre tých, ktorí nie sú oboznámení s problémom, to vyzerá celkom vtipne: ls /root funguje správne, zatiaľ čo napríklad top úplne „zamrzne“. Našťastie, s podobnými problémami sme sa už stretli. Rozhodlo o tom vyladenie MTU na trase od výpočtových uzlov k smerovačom. Mimochodom, toto nie je problém TF.
Ďalší problém bol hneď za rohom. V jednom „krásnom“ momente kúzlo smerovania zmizlo, len tak. TF prestal spravovať smerovanie na zariadení.
S Openstackom sme pracovali od administrátorskej úrovne a potom sme prešli na požadovanú užívateľskú úroveň. Zdá sa, že SDN „unesie“ rozsah používateľa, ktorý tieto akcie vykonáva. Faktom je, že rovnaký účet správcu sa používa na pripojenie TF a OpenStack. V kroku prechodu na používateľa „kúzlo“ zmizlo. Bolo rozhodnuté vytvoriť samostatný účet na prácu so systémom. To nám umožnilo pracovať bez narušenia integračnej funkcie.
Silicon Lifeforms - OpenStack
V blízkosti volfrámových polí žije zvláštne tvarované silikónové stvorenie. Predovšetkým vyzerá ako prerastené dieťa, ktoré nás dokáže rozdrviť jedným švihom, no žiadna zjavná agresivita z neho nevychádza. Nevyvoláva strach, ale jeho veľkosť vzbudzuje strach. Rovnako ako zložitosť toho, čo sa deje okolo.
OpenStack je jadrom našej platformy.
OpenStack má niekoľko podsystémov, z ktorých momentálne najaktívnejšie využívame Nova, Glance a Cinder. Každý z nich má svoje vlastné API. Nova je zodpovedná za výpočtové zdroje a vytváranie inštancií, Cinder je zodpovedná za správu zväzkov a ich snímok, Glance je obrázková služba, ktorá spravuje šablóny OS a metainformácie o nich.
Každá služba beží v kontajneri a sprostredkovateľom správ je „biely králik“ - RabbitMQ.
Tento systém nám spôsobil najneočakávanejšie problémy.
A prvý problém na seba nenechal dlho čakať, keď sme sa pokúsili pripojiť ďalší zväzok k serveru. Cinder API rozhodne odmietlo vykonať túto úlohu. Presnejšie, ak veríte samotnému OpenStacku, spojenie je vytvorené, ale vo virtuálnom serveri nie je žiadne diskové zariadenie.
Rozhodli sme sa pre obchádzku a rovnakú akciu sme požadovali od rozhrania Nova API. Výsledkom je, že zariadenie sa správne pripojí a je dostupné na serveri. Zdá sa, že problém nastáva, keď blokové úložisko nereaguje na Cinder.
Ďalšia ťažkosť nás čakala pri práci s diskami. Systémový zväzok sa nepodarilo odpojiť od servera.
Samotný OpenStack opäť „prisahá“, že zničil spojenie a teraz môžete správne pracovať s hlasitosťou samostatne. Ale API kategoricky nechcelo vykonávať operácie na disku.
Tu sme sa rozhodli zvlášť nebojovať, ale zmeniť náš pohľad na logiku služby. Ak existuje inštancia, musí existovať aj systémový zväzok. Používateľ preto zatiaľ nemôže odstrániť alebo zakázať systémový „disk“ bez odstránenia „servera“.
OpenStack je pomerne zložitý súbor systémov s vlastnou interakčnou logikou a vyšperkovaným API. Pomáha nám pomerne podrobná dokumentácia a samozrejme pokus-omyl (kde by sme bez nej boli).
Skúšobná prevádzka
Testovacie spustenie sme vykonali v decembri minulého roka. Hlavnou úlohou bolo otestovať náš projekt v bojovom režime z technickej stránky a z UX stránky. Publikum bolo pozvané selektívne a testovanie bolo uzavreté. Ponechali sme však aj možnosť požiadať o prístup k testovaniu na našej stránke.
Samotný test sa samozrejme nezaobišiel bez vtipných momentov, pretože tu sa naše dobrodružstvá len začínajú.
Jednak sme trochu nesprávne vyhodnotili záujem o projekt a museli sme rýchlo pridávať výpočtové uzly hneď počas testu. Bežný prípad pre klaster, ale aj tu boli určité nuansy. V dokumentácii pre konkrétnu verziu TF je uvedená konkrétna verzia jadra, na ktorej bola testovaná práca s vRouterom. Rozhodli sme sa spustiť uzly s novšími jadrami. V dôsledku toho TF neprijímal trasy z uzlov. Musel som urýchlene vrátiť späť jadrá.
Ďalšia kuriozita súvisí s funkcionalitou tlačidla „zmeniť heslo“ vo vašom osobnom účte.
Rozhodli sme sa použiť JWT na usporiadanie prístupu k nášmu osobnému účtu, aby sme nepracovali s reláciami. Keďže systémy sú rôznorodé a značne rozptýlené, spravujeme vlastný token, do ktorého „balíme“ relácie z fakturácie a token z OpenStacku. Pri zmene hesla sa token, samozrejme, „pokazí“, pretože používateľské údaje už nie sú platné a je potrebné ich znovu vydať.
Tento bod sme stratili zo zreteľa a jednoducho nebolo dostatok zdrojov na rýchle dokončenie tohto dielu. Funkcionalitu sme museli vystrihnúť tesne pred spustením testu.
V súčasnosti odhlasujeme používateľa, ak bolo heslo zmenené.
Napriek týmto nuansám testovanie dopadlo dobre. Za pár týždňov sa tu zastavilo asi 300 ľudí. Mohli sme sa na produkt pozrieť očami používateľov, otestovať ho v akcii a zozbierať kvalitnú spätnú väzbu.
Ak sa chcete pokračovať
Pre mnohých z nás je to prvý projekt takéhoto rozsahu. Naučili sme sa množstvo cenných lekcií o tom, ako pracovať ako tím a robiť architektonické a dizajnérske rozhodnutia. Ako integrovať zložité systémy s malými zdrojmi a uviesť ich do výroby.
Samozrejme, je na čom pracovať ako z hľadiska kódu, tak aj na rozhraniach systémovej integrácie. Projekt je pomerne mladý, ale máme ambície prerásť z neho do spoľahlivej a pohodlnej služby.
Systémy sa nám už podarilo presvedčiť. Bill vo svojom šatníku poslušne rieši počítanie, účtovanie a požiadavky používateľov. „Mágia“ volfrámových polí nám poskytuje stabilnú komunikáciu. A iba OpenStack je niekedy rozmarný a kričí niečo ako „WSREP ešte nepripravil uzol na použitie aplikácie“. Ale to je úplne iný príbeh...
Službu sme nedávno spustili.
Všetky podrobnosti sa dozviete na našom .
Vývojový tím CLO
Užitočné odkazy
OpenStack
Volfrámová tkanina
Zdroj: hab.com