🥇Historia e krijimit të një shërbimi cloud, i spërkatur me cyberpunk

Ndërsa përvoja juaj në IT rritet, filloni të vini re se sistemet kanë karakterin e tyre. Ato mund të jenë të përshtatshme, të heshtura, kapriçioze ose të ashpra. Ato mund të jenë tërheqëse ose të neveritshme. Sidoqoftë, duhet të negocioni me ta, të kapërceni grackat e tyre dhe të ndërtoni marrëdhënie midis tyre.

Na është dhënë nderi të ndërtojmë një platformë cloud, por për ta bërë këtë, na është dashur të "bindnim" disa nënsisteme që të punonin me ne. Për fat të mirë, ne kemi një gjuhë API, një dorë të qëndrueshme dhe shumë entuziazëm.

Ky artikull nuk do të jetë teknikisht i vështirë, por do të përshkruajë sfidat që hasëm gjatë ndërtimit të resë kompjuterike. Kam vendosur ta përshkruaj udhëtimin tonë si një fantazi të lehtë teknike rreth asaj se si gjetëm terren të përbashkët me sistemet dhe çfarë doli prej saj.

Mirë se vini nën prerje.

Fillimi i një udhëtimi

Pak kohë më parë, ekipit tonë iu ngarkua detyra e lançimit të një platforme cloud për klientët tanë. Ne kishim mbështetje menaxheriale, burime, një paketë harduerësh dhe lirinë për të zgjedhur teknologjitë për zbatimin e softuerit të shërbimit.

Kishte edhe një sërë kërkesash:

shërbimi ka nevojë për një llogari personale të përshtatshme;
platforma duhet të integrohet në sistemin ekzistues të faturimit;
softuer dhe harduer: OpenStack + Tungsten Fabric (Open Contrail), të cilin inxhinierët tanë kanë mësuar ta "gatuajnë" mjaft mirë.

Do t'ju tregojmë se si u mblodh ekipi, u zhvillua ndërfaqja e llogarisë personale dhe vendimet e dizajnit u morën një herë tjetër, nëse komuniteti Habr është i interesuar.
Mjetet që vendosëm të përdorim:

Python + Flask + Swagger + SQLAlchemy është një bashkësi Python mjaft standarde;
Vue.js për frontend;
Ne vendosëm të zbatojmë bashkëveprimin midis komponentëve dhe shërbimeve duke përdorur Celery mbi AMQP.

Duke parashikuar pyetje në lidhje me zgjedhjen e Python, më lejoni të shpjegoj. Gjuha ka gjetur vendin e saj në kompaninë tonë dhe një kulturë e vogël, por ende e rëndësishme, është zhvilluar rreth saj. Prandaj, vendosëm ta ndërtojmë shërbimin duke e përdorur atë. Sidomos pasi shpejtësia e zhvillimit është shpesh thelbësore në projekte të tilla.

Pra, le të fillojmë njohjen tonë.

Faturë e Heshtur - faturim

E njihnim këtë djalë prej kohësh. Ai gjithmonë ulej pranë nesh, duke bërë llogaritje në heshtje. Ndonjëherë na përcillte kërkesat e përdoruesve, lëshonte fatura për klientët dhe menaxhonte shërbimet. Një djalë tipik punëtor. Vërtet, kishte disa sfida. Ai është i qetë, ndonjëherë i menduar dhe shpesh ka një anë sekrete.

Faturimi ishte sistemi i parë që u përpoqëm të integronim. Dhe vështirësia e parë që hasëm ishte përpunimi i shërbimeve.

Për shembull, kur krijohet ose fshihet një detyrë, ajo shtohet në një radhë të brendshme faturimi. Kështu zbatohet sistemi asinkron i menaxhimit të shërbimeve. Për të përpunuar llojet e shërbimeve tona, na duhej të "ruanim" detyrat tona në këtë radhë. Dhe këtu hasëm një problem: mungesë dokumentacioni.

Duke gjykuar nga përshkrimi i API-t, ky problem mund të zgjidhej, por nuk kishim kohë ta bënim inxhinierinë e kundërt, kështu që e eksternalizuam logjikën dhe zbatuam një radhë detyrash në krye të RabbitMQ. Një operacion shërbimi iniciohet nga klienti nga llogaria e tij, i mbështjellë në një detyrë Celery në backend dhe ekzekutohet nga sistemet e faturimit dhe OpenStack. Celery lejon menaxhim mjaft të përshtatshëm të detyrave, përsëritje dhe monitorim të statusit. Mund të lexoni më shumë rreth Celery, për shembull, këtu.

Sistemi i faturimit gjithashtu nuk e ndërpreu projektin kur mbaruan fondet. Ndërsa punonim me zhvilluesit, zbuluam se kur llogaritnim bazuar në statistika (dhe kjo është logjika që duhej të zbatonim), kishte një ndërveprim kompleks të rregullave të ndalimit. Megjithatë, këto modele nuk i përshtateshin shumë mirë nevojave tona. Ne e zbatuam këtë edhe përmes detyrave Celery, duke e zhvendosur logjikën e menaxhimit të shërbimit në backend.

Të dyja problemet e mësipërme kanë rezultuar në një mbingarkesë të vogël të kodit dhe do të na duhet ta rifaktojmë atë në të ardhmen për të zhvendosur logjikën e menaxhimit të detyrave në një shërbim të veçantë. Gjithashtu, duhet të ruajmë disa informacione rreth përdoruesve dhe shërbimeve të tyre në tabelat e tyre për të mbështetur këtë logjikë.

Një problem tjetër është heshtja.

Billy në heshtje përgjigjet me "OK" për disa kërkesa API. Kjo ndodhi, për shembull, kur po kreditonim pagesat e premtuara gjatë një prove (më shumë për këtë më vonë). Kërkesat u ekzekutuan saktë dhe nuk pamë gabime.

Më është dashur të studioj regjistrat ndërsa punoja me sistemin përmes ndërfaqes së përdoruesit. Doli që vetë sistemi i faturimit ekzekuton kërkesa të ngjashme, duke ndryshuar fushëveprimin te një përdorues specifik, për shembull, admin, duke e kaluar atë në parametrin su.

Në përgjithësi, pavarësisht disa boshllëqeve në dokumentacion dhe problemeve të vogla me API-n, gjithçka shkoi mjaft mirë. Regjistrat janë mjaft të lexueshëm edhe nën ngarkesë të madhe, me kusht që të kuptoni se si janë strukturuar dhe çfarë duhet të kërkoni. Struktura e bazës së të dhënave është disi e ndërlikuar, por mjaft logjike dhe madje tërheqëse në disa mënyra.

Pra, për ta përmbledhur, problemet kryesore që hasëm gjatë fazës së ndërveprimit lidheshin me karakteristikat specifike të zbatimit të sistemit specifik:

karakteristika të padokumentuara që na prekën në një mënyrë ose në një tjetër;
kod burimor i mbyllur (faturimi është shkruar në C++), si rezultat - pamundësia e zgjidhjes së problemit 1 në ndonjë mënyrë tjetër përveç "provës dhe gabimit".

Për fat të mirë, produkti ka një API mjaft të gjerë dhe ne kemi integruar nënsistemet e mëposhtme në llogarinë tonë personale:

Moduli i mbështetjes teknike - kërkesat nga llogaria personale "proksohen" në sistemin e faturimit në mënyrë transparente për klientët e shërbimit;
Moduli financiar – ju lejon të lëshoni fatura për klientët aktualë, të bëni shlyerje borxhesh dhe të gjeneroni dokumente pagese;
Na u desh të implementonim trajtuesin tonë për modulin e menaxhimit të shërbimeve. Zgjerueshmëria e sistemit na vlejti dhe ne e "trajnuam" Billin për të trajtuar një lloj të ri shërbimi.
Më duhej pak punë, por mendoj se unë dhe Billi do të shkojmë mirë me njëri-tjetrin.

Duke ecur nëpër fushat e tungstenit — Pëlhurë tungsteni

Fushat e tungstenit, të mbushura me qindra tela, kanalizojnë mijëra pjesë informacioni. Informacioni mblidhet në "paketa", sortohet dhe ndërtohet në rrugë komplekse, sikur me magji.

Ky është domeni i sistemit të dytë me të cilin na u desh të bëheshim miq—Tungsten Fabric (TF), më parë OpenContrail. Qëllimi i tij është të menaxhojë pajisjet e rrjetit, duke na ofruar neve, përdoruesve, një abstraksion softueri. TF është një SDN që përmbledh logjikën komplekse të punës me pajisjet e rrjetit. Ka një artikull të mirë rreth vetë teknologjisë, për shembull, këtu.

Sistemi është i integruar me OpenStack (i diskutuar më poshtë) nëpërmjet plugin-it Neutron.

Ndërveprimi i shërbimeve OpenStack.

Djemtë në Departamentin e Operacioneve na prezantuan me këtë sistem. Ne përdorim API-n e sistemit për të menaxhuar rrjetin e shërbimeve tona. Deri më tani nuk na ka shkaktuar probleme apo shqetësime serioze (nuk mund të flas në emër të djemve në Operacione), por ka pasur disa ndërveprime të çuditshme.

E para dukej kështu: komandat që kërkonin daljen e një sasie të madhe të të dhënave në tastierën e instancës kur lidheshin nëpërmjet SSH thjesht "e mbyllnin" lidhjen, ndërsa gjithçka funksiononte siç duhet nëpërmjet VNC.

Për ata që nuk janë të njohur me problemin, duket mjaft qesharak: ls /root funksionon siç duhet, ndërsa, për shembull, top ngrin plotësisht. Për fat të mirë, kemi hasur probleme të ngjashme më parë. U zgjidh duke akorduar MTU në rrugën nga nyjet llogaritëse te routerët. Rastësisht, ky nuk është një problem TF.

Problemi tjetër ishte shumë afër. Në një moment "të mrekullueshëm", magjia e rrugëzimit u zhduk, tamam kështu. TF ndaloi së menaxhuari rrugëzimin në harduer.

Ne punuam me OpenStack nga niveli i administratorit dhe më pas kaluam në nivelin e dëshiruar të përdoruesit. SDN dukej se "kapte" fushëveprimin e përdoruesit që kryente veprimet. Problemi ishte se e njëjta llogari administratori përdorej për komunikim midis TF dhe OpenStack. Kur kaluam në nivelin e përdoruesit, "magjia" u zhduk. Vendosëm të krijonim një llogari të veçantë për të punuar me sistemin. Kjo na lejoi të punonim pa prishur funksionalitetin e integrimit.

Format e Jetës së Silikonit - OpenStack

Një krijesë silikoni me forma të çuditshme jeton pranë fushave të tungstenit. Ajo i ngjan një fëmije të rritur, të aftë të na shtypë me një goditje të vetme, por nuk tregon agresion të hapur. Nuk frymëzon frikë, por madhësia e saj është alarmante. Po kështu është edhe kompleksiteti i asaj që po ndodh përreth saj.

OpenStack është thelbi i platformës sonë.

OpenStack ka disa nënsisteme, nga të cilat aktualisht përdorim më aktivisht Nova, Glance dhe Cinder. Secili ka API-në e vet. Nova është përgjegjëse për burimet llogaritëse dhe krijimin e instancave, Cinder menaxhon vëllimet dhe pamjet e tyre të çastit, dhe Glance është një shërbim imazhesh që menaxhon shabllonet e sistemit operativ dhe meta të dhënat e tyre.

Çdo shërbim funksionon në një kontejner, dhe ndërmjetësi i mesazheve është një "lepur i bardhë" - RabbitMQ.

Ky sistem na ka dhënë problemet më të papritura.

Problemi i parë nuk vonoi shumë të shfaqej kur u përpoqëm të lidhnim një vëllim shtesë me serverin. API-ja e Cinder refuzoi kategorikisht ta kryente këtë detyrë. Më saktësisht, sipas vetë OpenStack, lidhja u krijua, por pajisja e diskut mungonte brenda serverit virtual.

Ne vendosëm të ndërmerrnim një zgjidhje alternative dhe kërkuam të njëjtin veprim nga Nova API. Rezultati: pajisja lidhet saktë dhe është e arritshme brenda serverit. Me sa duket, problemi ndodh kur hapësira e ruajtjes së blloqeve nuk i përgjigjet Cinder-it.

Hasëm një vështirësi tjetër gjatë punës me disqe. Vëllimi i sistemit nuk mund të shkëputej nga serveri.

Përsëri, vetë OpenStack "betohet" se e ka shkatërruar lidhjen dhe tani mund të punojë saktë me vëllimin veçmas. Por API-ja refuzoi kategorikisht të kryente operacione në disk.

Ne vendosëm të mos luftojmë shumë këtu, por të ndryshojmë qasjen tonë ndaj logjikës operative të shërbimit. Nëse ka një instancë, duhet të ketë edhe një vëllim sistemi. Prandaj, përdoruesi aktualisht nuk mund ta fshijë ose çaktivizojë "diskun" e sistemit pa fshirë "serverin".

OpenStack është një sistem mjaft kompleks me logjikën e vet të ndërveprimit dhe API-në e ndërlikuar. Ne mbështetemi në dokumentacion të detajuar dhe, sigurisht, në metodën e provës dhe gabimit (sigurisht, është e garantuar).

Testimi i ekzekutimit

Ne kryem një lançim testues dhjetorin e kaluar. Qëllimi ynë kryesor ishte të testonim projektin tonë në modalitetin e prodhimit, si teknikisht ashtu edhe nga ana e përdoruesit të përdoruesit. Ftuam një numër të zgjedhur përdoruesish dhe testimi u mbyll. Megjithatë, ne ofruam gjithashtu mundësinë për të kërkuar akses në testim në faqen tonë të internetit.

Sigurisht, testi në vetvete nuk ishte pa momente qesharake, sepse ky është vetëm fillimi i aventurave tona.

Së pari, ne e gjykuam gabim interesin për projektin dhe na u desh të shtonim shpejt nyje llogaritëse gjatë testimit. Ky ishte një skenar i zakonshëm për një klaster, por kishte disa nuanca. Dokumentacioni për një version specifik të TF specifikon versionin specifik të kernelit të përdorur për testim me vRouter. Ne vendosëm të lançonim nyje me kernele më të reja. Si rezultat, TF dështoi të merrte rrugë nga nyjet. Na u desh të anulonim urgjentisht kernelet.

Një gjë tjetër kurioze lidhet me funksionalitetin e butonit "ndrysho fjalëkalimin" në llogarinë tënde personale.

Ne vendosëm të përdorim JWT për të menaxhuar aksesin në llogarinë personale, në vend që të menaxhojmë seancat. Meqenëse sistemet tona janë të larmishme dhe të shpërndara gjerësisht, ne menaxhojmë tokenin tonë, të cilin e përdorim për të mbështjellë seancat e faturimit dhe tokenin OpenStack. Kur ndryshohet fjalëkalimi, tokeni natyrshëm skadon, pasi të dhënat e përdoruesit nuk janë më të vlefshme dhe duhet të rilëshohen.

Ne e anashkaluam këtë problem dhe thjesht nuk kishim burimet për ta përfunduar shpejt. Na u desh ta ndërprisnim funksionalitetin pak para se ta nisnim për testim.
Aktualisht, ne e çregjistrojmë përdoruesin nëse fjalëkalimi është ndryshuar.

Pavarësisht këtyre nuancave, testimi shkoi mirë. Gjatë disa javësh, na vizituan rreth 300 përdorues. Ne arritëm ta shihnim produktin përmes syve të përdoruesve, ta testonim në veprim dhe të mblidhnim reagime me cilësi të lartë.

Për të vazhduar

Për shumë prej nesh, ky ishte projekti ynë i parë i kësaj shkalle. Mësuam një sërë mësimesh të vlefshme rreth punës në grup, marrjes së vendimeve arkitekturore dhe të dizajnit, si dhe si të integrojmë sisteme komplekse dhe t'i vendosim ato në prodhim me burime të kufizuara.

Sigurisht, ka ende punë për t’u bërë, si në aspektin e kodit ashtu edhe në integrimin e sistemeve. Projekti është relativisht i ri, por ne jemi ambiciozë për ta rritur atë në një shërbim të besueshëm dhe miqësor për përdoruesit.

Ne kemi arritur tashmë t'i bindim sistemet. Billi me bindje merret me llogaritjet, faturimin dhe kërkesat e përdoruesve në dhomën e tij të punës. "Magjia" e fushave të tungstenit na siguron një lidhje të qëndrueshme. Vetëm OpenStack vepron herë pas here, duke bërtitur diçka si "WSREP nuk e ka përgatitur ende nyjen për përdorim nga aplikacioni". Por kjo është një histori krejt tjetër...

Ne e lançuam shërbimin së fundmi.
Mund t’i gjeni të gjitha detajet në faqen tonë Online.

Ekipi i Zhvillimit të CLO-së