Ko delate v IT, začnete opažati, da imajo sistemi svoj značaj. Lahko so prilagodljivi, tihi, ekscentrični in strogi. Lahko privlačijo ali odbijajo. Tako ali drugače se morate z njimi »pogajati«, manevrirati med »pastimi« in graditi verige njihove interakcije.
Imeli smo torej čast zgraditi platformo v oblaku in za to smo morali »prepričati« nekaj podsistemov, da so sodelovali z nami. Na srečo imamo »jezik API«, neposredne roke in veliko entuziazma.
Ta članek ne bo tehnično zahteven, ampak bo opisal težave, na katere smo naleteli pri gradnji oblaka. Odločil sem se, da opišem našo pot v obliki lahkotne tehnične fantazije o tem, kako smo iskali skupni jezik s sistemi in kaj se je iz tega izcimilo.
Dobrodošli pri mački.
Začetek potovanja
Pred časom je bila naša ekipa zadolžena za lansiranje platforme v oblaku za naše stranke. Imeli smo podporo pri upravljanju, vire, sklop strojne opreme in svobodo pri izbiri tehnologij za izvajanje programskega dela storitve.
Obstajalo je tudi več zahtev:
- storitev potrebuje priročen osebni račun;
- platforma mora biti integrirana v obstoječi obračunski sistem;
- programska in strojna oprema: OpenStack + Tungsten Fabric (Open Contrail), ki so se ga naši inženirji naučili precej dobro »skuhati«.
O tem, kako je bila sestavljena ekipa, razvit vmesnik osebnega računa in sprejete oblikovalske odločitve, vam bomo povedali drugič, če bo skupnost Habra zanimala.
Orodja, za katera smo se odločili:
- Python + Flask + Swagger + SQLAlchemy - povsem standarden nabor Python;
- Vue.js za frontend;
- Odločili smo se, da bomo izvedli interakcijo med komponentami in storitvami z uporabo Celery preko AMQP.
Če pričakujem vprašanja o izbiri Pythona, bom razložil. Jezik je v našem podjetju našel svojo nišo in okoli njega se je razvila majhna, a še vedno kultura. Zato je bilo odločeno, da se storitev začne graditi na njej. Poleg tega je hitrost razvoja pri tovrstnih težavah pogosto odločilna.
Torej, začnimo naše poznanstvo.
Silent Bill - obračunavanje
Tega tipa poznamo že dolgo. Vedno je sedel poleg mene in tiho nekaj štel. Včasih nam je posredoval zahteve uporabnikov, izstavljal račune strankam in upravljal storitve. Navaden priden človek. Res je, bile so težave. Je molčeč, včasih zamišljen in pogosto samostojen.
Billing je prvi sistem, s katerim smo se poskušali spoprijateljiti. In prva težava, na katero smo naleteli, je bila pri obdelavi storitev.
Ko je na primer ustvarjeno ali izbrisano, gre opravilo v interno čakalno vrsto za obračunavanje. Tako je implementiran sistem asinhronega dela s storitvami. Za obdelavo naših vrst storitev smo morali svoje naloge »postaviti« v to čakalno vrsto. In tu smo naleteli na težavo: pomanjkanje dokumentacije.
Sodeč po opisu programskega API-ja, je to težavo še vedno mogoče rešiti, vendar nismo imeli časa za obratno inženirstvo, zato smo logiko vzeli zunaj in organizirali čakalno vrsto opravil na vrhu RabbitMQ. Operacijo na storitvi sproži odjemalec iz svojega osebnega računa, spremeni se v »opravilo« Celery na zaledju in se izvede na strani zaračunavanja in OpenStack. Celery omogoča zelo priročno upravljanje nalog, organiziranje ponovitev in spremljanje stanja. Več o "zeleni" lahko preberete na primer .
Prav tako zaračunavanje ni ustavilo projekta, za katerega je zmanjkalo denarja. V komunikaciji z razvijalci smo ugotovili, da pri izračunu statistike (in moramo implementirati točno takšno logiko) obstaja zapletena medsebojna povezava pravil zaustavljanja. Toda ti modeli se ne ujemajo dobro z našo realnostjo. Implementirali smo ga tudi prek nalog na Celeryju, pri čemer smo logiko upravljanja storitev prenesli na zaledno stran.
Obe zgornji težavi sta privedli do tega, da je koda postala nekoliko napihnjena in v prihodnosti bomo morali preoblikovati, da bomo logiko za delo z nalogami premaknili v ločeno storitev. Prav tako moramo shraniti nekaj informacij o uporabnikih in njihovih storitvah v naših tabelah, da podpiramo to logiko.
Druga težava je tišina.
Billy tiho odgovori z »V redu« na nekatere zahteve API-ja. Tako je bilo na primer, ko smo med testom izplačali obljubljena plačila (več o tem kasneje). Zahteve so bile izvedene pravilno in nismo opazili nobenih napak.
Med delom s sistemom prek uporabniškega vmesnika sem moral preučiti dnevnike. Izkazalo se je, da samo obračunavanje izvaja podobne zahteve, spreminja obseg na določenega uporabnika, na primer skrbnika, in ga posreduje v parametru su.
Na splošno je kljub vrzeli v dokumentaciji in manjšim pomanjkljivostim API-ja šlo vse dobro. Dnevnike je mogoče brati tudi pod veliko obremenitvijo, če razumete, kako so strukturirani in na kaj morate biti pozorni. Struktura baze je okrašena, vendar precej logična in na nek način celo privlačna.
Torej, če povzamemo, so glavne težave, s katerimi smo se srečali na stopnji interakcije, povezane z izvedbenimi značilnostmi določenega sistema:
- nedokumentirane »lastnosti«, ki so nas tako ali drugače prizadele;
- zaprta koda (zaračunavanje je napisano v C++), posledično - težave 1 je nemogoče rešiti na kakršen koli drug način kot "poskus in napaka".
Na srečo ima izdelek dokaj obsežen API in v naš osebni račun smo integrirali naslednje podsisteme:
- modul za tehnično podporo - zahteve iz vašega osebnega računa so "posredovane" na transparentno zaračunavanje za stranke storitev;
- finančni modul - omogoča izstavljanje računov trenutnim strankam, odpise in generiranje plačilnih dokumentov;
- servisni nadzorni modul - za to smo morali implementirati lastnega krmilnika. Razširljivost sistema nam je šla na roko in Billyja smo »naučili« nove vrste storitev.
Bilo je malo težav, a tako ali drugače mislim, da se bova z Billyjem razumela.
Sprehod po volframovih poljih – Tungsten Fabric
Volframova polja, posejana s stotinami žic, skozi katere prehaja na tisoče informacij. Informacije se zbirajo v »pakete«, razčlenjujejo in gradijo zapletene poti, kot s čarovnijo.
To je domena drugega sistema, s katerim smo se spoprijateljili - Tungsten Fabric (TF), prej OpenContrail. Njegova naloga je upravljanje omrežne opreme, ki nam kot uporabnikom zagotavlja abstrakcijo programske opreme. TF - SDN, zajema kompleksno logiko dela z omrežno opremo. Obstaja dober članek o sami tehnologiji, npr. .
Sistem je integriran z OpenStack (o katerem govorimo spodaj) prek vtičnika Neutron.
Interakcija storitev OpenStack.
Fantje iz operative so nam predstavili ta sistem. Sistemski API uporabljamo za upravljanje omrežnega sklada naših storitev. Resnih težav ali nevšečnosti nam še ni povzročalo (ne morem govoriti v imenu fantov iz OE), je pa bilo nekaj nenavadnosti v interakciji.
Prvi je izgledal takole: ukazi, ki so pri povezovanju prek SSH zahtevali izpis velike količine podatkov na instančno konzolo, so povezavo preprosto "odložili", prek VNC pa je vse delovalo pravilno.
Za tiste, ki težave ne poznajo, je videti precej smešno: ls /root deluje pravilno, medtem ko na primer top popolnoma "zamrzne". Na srečo smo se s podobnimi težavami že srečali. Odločeno je bilo z nastavitvijo MTU na poti od računalniških vozlišč do usmerjevalnikov. Mimogrede, to ni problem TF.
Naslednja težava je bila tik za vogalom. V enem "lepem" trenutku je čarovnija usmerjanja izginila, kar tako. TF je prenehal upravljati usmerjanje na opremi.
Z Openstackom smo delali od administratorske ravni in nato prešli na zahtevano uporabniško raven. Zdi se, da SDN »ugrabi« obseg uporabnika, ki izvaja dejanja. Dejstvo je, da se za povezavo TF in OpenStack uporablja isti skrbniški račun. V koraku preklopa na uporabnika je »čarovnija« izginila. Odločeno je bilo ustvariti ločen račun za delo s sistemom. To nam je omogočilo delo, ne da bi prekinili integracijsko funkcionalnost.
Silicijeve oblike življenja - OpenStack
Silikonsko bitje nenavadne oblike živi v bližini volframovih polj. Predvsem je videti kot prerasel otrok, ki nas lahko z enim zamahom zmečka, a iz njega ni opazne agresije. Ne povzroča strahu, vzbuja pa strah njegova velikost. Kot tudi kompleksnost dogajanja naokoli.
OpenStack je jedro naše platforme.
OpenStack ima več podsistemov, od katerih trenutno najbolj aktivno uporabljamo Nova, Glance in Cinder. Vsak od njih ima svoj API. Nova je odgovorna za računalniške vire in ustvarjanje instanc, Cinder je odgovoren za upravljanje nosilcev in njihovih posnetkov, Glance je slikovna storitev, ki upravlja predloge OS in metainformacije na njih.
Vsaka storitev deluje v vsebniku, posrednik sporočil pa je »beli zajec« - RabbitMQ.
Ta sistem nam je povzročil najbolj nepričakovane težave.
In prva težava ni bila dolga, ko smo poskušali na strežnik povezati dodatno glasnost. Cinder API je odločno zavrnil izvedbo te naloge. Natančneje, če verjamete samemu OpenStacku, je povezava vzpostavljena, vendar znotraj virtualnega strežnika ni diskovne naprave.
Odločili smo se za ovinek in zahtevali enako dejanje od Nova API. Rezultat tega je, da se naprava pravilno poveže in je dostopna znotraj strežnika. Videti je, da do težave pride, ko se blokovna shramba ne odziva na Cinder.
Pri delu z diski nas je čakala še ena težava. Sistemskega nosilca ni bilo mogoče prekiniti povezave s strežnikom.
Tudi sam OpenStack "prisega", da je uničil povezavo in zdaj lahko pravilno delate z glasnostjo ločeno. Toda API kategorično ni želel izvajati operacij na disku.
Tu smo se odločili, da se ne bomo posebej kregali, ampak da bomo spremenili pogled na logiko storitve. Če obstaja primerek, mora obstajati tudi sistemski nosilec. Zato uporabnik še ne more odstraniti ali onemogočiti sistemskega "diska", ne da bi izbrisal "strežnik".
OpenStack je precej zapleten nabor sistemov z lastno logiko interakcije in okrašenim API-jem. Pri tem nam pomaga dokaj podrobna dokumentacija in seveda poskusi in napake (kje bi brez tega).
Testna vožnja
Poskusno izstrelitev smo izvedli decembra lani. Glavna naloga je bila preizkusiti naš projekt v bojnem načinu s tehnične strani in s strani UX. Občinstvo je bilo povabljeno selektivno in testiranje je bilo zaključeno. Pustili pa smo tudi možnost zahtevanja dostopa do testiranja na naši spletni strani.
Na sami preizkušnji pa seveda ni šlo brez smešnih trenutkov, saj se tu naše dogodivščine šele začnejo.
Prvič, nekoliko napačno smo ocenili zanimanje za projekt in smo morali na hitro dodajati računalniška vozlišča kar med testom. Pogost primer za gručo, vendar je bilo tudi tukaj nekaj odtenkov. Dokumentacija za določeno različico TF označuje specifično različico jedra, na katerem je bilo preizkušeno delo z vRouter. Odločili smo se za zagon vozlišč z novejšimi jedri. Posledično TF ni prejel poti od vozlišč. Moral sem nujno vrniti jedra nazaj.
Druga zanimivost je povezana s funkcijo gumba »spremeni geslo« v vašem osebnem računu.
Odločili smo se, da uporabimo JWT za organizacijo dostopa do našega osebnega računa, da ne bi delali s sejami. Ker so sistemi raznoliki in zelo razpršeni, upravljamo lasten žeton, v katerega »zavijemo« seje iz obračunavanja in žeton iz OpenStacka. Ob spremembi gesla se žeton seveda »pokvari«, saj uporabniški podatki niso več veljavni in jih je treba ponovno izdati.
To točko smo izgubili izpred oči in preprosto ni bilo dovolj sredstev za hitro dokončanje tega dela. Funkcionalnost smo morali izrezati tik pred začetkom testa.
Trenutno se uporabnik odjavi, če je bilo geslo spremenjeno.
Kljub tem odtenkom je testiranje potekalo dobro. V nekaj tednih se je ustavilo okoli 300 ljudi. Izdelek smo lahko pogledali skozi oči uporabnikov, ga preizkusili v akciji in zbrali kakovostne povratne informacije.
Se nadaljuje
Za mnoge od nas je to prvi projekt tega obsega. Naučili smo se številnih dragocenih lekcij o timskem delu in sprejemanju arhitekturnih in oblikovalskih odločitev. Kako integrirati kompleksne sisteme z malo sredstvi in jih uvesti v proizvodnjo.
Seveda je treba nekaj delati tako pri kodi kot pri vmesnikih sistemske integracije. Projekt je precej mlad, vendar smo polni ambicij, da ga prerastemo v zanesljivo in priročno storitev.
Sisteme nam je že uspelo prepričati. Bill vestno obravnava štetje, zaračunavanje in zahteve uporabnikov v svoji omari. »Čarovnija« volframovih polj nam zagotavlja stabilno komunikacijo. In le OpenStack včasih postane muhast in zavpije nekaj takega, kot je "WSREP še ni pripravil vozlišča za uporabo v aplikaciji." Ampak to je čisto druga zgodba...
Pred kratkim smo lansirali storitev.
Vse podrobnosti lahko izveste na našem .
CLO razvojna ekipa
Uporabne povezave
OpenStack
Tkanina iz volframa
Vir: www.habr.com