Me rritjen e përvojës në IT, fillon të vëresh se sistemet kanë karakterin e tyre. Ato mund të jenë të qeta, të heshtura, të çmendura, të ashpra. Ato mund të tërheqin ose të largojnë. Në një mënyrë apo tjetrën, duhet të "kesh biseda" me to, të manovrosh midis "kërcënimeve" dhe të ndërtojnë lidhjet e tyre të bashkëpunimit.
Kështu që na është dhënë nderi të ndërtojmë një platformë cloud, dhe për këtë na duhej të "bindim" disa nën-sisteme që të punonin me ne. Fatmirësisht, ne kemi "gjuhën API", duar të drejta dhe një mori entuziazmi.
Në këtë artikull nuk do të kemi të bëjmë me ashpërsinë teknike, por do të përshkruajmë problemet me të cilat u përballëm gjatë ndërtimit të cloud-it. Kam vendosur ta përshkruaj rrugën tonë në formën e një fantazie teknike të lehtë mbi mënyrën se si kërkuam gjuhën e përbashkët me sistemet dhe çfarë dolën prej saj.
Mirë se vini nën artikull.
Fillimi i rrugës
Disa kohĂ« mĂ« parĂ«, ekipi ynĂ« u ngarkua me detyrĂ«n â tĂ« nisĂ« njĂ« platformĂ« cloud pĂ«r klientĂ«t tanĂ«. NĂ« dispozicion ishim mbĂ«shtetje nga drejtuesit, burime, njĂ« grumbull hardware dhe liri nĂ« zgjedhjen e teknologjive pĂ«r realizimin e pjesĂ«s softuerike tĂ« shĂ«rbimit.
Ishte gjithashtu një sërë kërkesash:
- shërbimi iu nevojitet një panel i lehtë për t'u përdorur;
- platforma duhet të integrohet në sistemin ekzistues të faturimit;
- pjesa software-hardware: OpenStack + Tungsten Fabric (Open Contrail), të cilat inxhinierët tanë mësuan të "gatuajnë" mjaft mirë.
Për mënyrën se si u mblodh ekipi, u zhvillua ndërfaqja e përdoruesit dhe u morën vendime dizajni, do të flasim herën tjetër, nëse komuniteti i Habrës do të ketë interes.
Instrumentet që vendosëm të përdorim:
- Python + Flask + Swagger + SQLAlchemy â njĂ« grup standard Python;
- Vue.js për frontend-in;
- ndërveprimin midis komponentëve dhe shërbimeve vendosëm ta bëjmë me Celery mbi AMQP.
Për të parashikuar pyetjet rreth zgjedhjes së Python, shpjegoj. Gjuha ka marrë një pozitë në kompaninë tonë dhe rreth saj është ndërtuar një kulturë e vogël, por megjithatë e rëndësishme. Prandaj, u vendos të fillonim ndërtimin e shërbimit pikërisht në të. Veçanërisht, sepse shpejtësia e zhvillimit në këto detyra shpesh është vendimtare.
Pra, le të fillojmë njohjen tonë.
Bill i heshtur â faturimi
Me kĂ«tĂ« djalĂ« ishim njohur prej kohĂ«sh. Ai gjithmonĂ« qĂ«ndronte afĂ«r dhe numĂ«ronte diçka nĂ« heshtje. NdonjĂ«herĂ« na dĂ«rgonte kĂ«rkesat e pĂ«rdoruesve, lĂ«shonte faturat e klientĂ«ve, menaxhonte shĂ«rbimet. NjĂ« djalĂ« i zakonshĂ«m punĂ«tor. MegjithatĂ«, kishte vĂ«shtirĂ«si. Ai Ă«shtĂ« i heshtur, ndonjĂ«herĂ« i menduar dhe shpesh â nĂ« mendimet e tij.
Faturimi është sistemi i parë me të cilin u përpoqëm të bëjmë miqësi. Dhe vështirësia e parë na u paraqit gjatë përpunimit të shërbimeve.
Për shembull, kur krijohet ose fshihet, detyra shkon në radhën e brendshme të faturimit. Kjo është mënyra se si realizohet sistemi i punës asinkrone me shërbimet. Për të përpunuar tipet tona të shërbimeve, na duhej të "ngjitim" detyrat tona në këtë radhë. Dhe këtu u përballëm me problemin: mungesa e dokumentacionit.
Sipas përshkrimit të API-së software, zgjidhja e këtij problemi është e mundur, por nuk kishim kohë të merremi me inxhinierinë e zëvendësimit, prandaj e nxorrëm logjikën jashtë dhe organizuam një radhë detyrash mbi RabbitMQ. Operacioni mbi shërbimin inicohet nga klienti nga paneli i tij personal, i mbështjellë në një "detyrë" Celery në backend dhe ekzekutohet në anën e faturimit dhe OpenStack-it. Celery lejon menaxhimin mjaft të rehatshëm të detyrave, organizimin e ripërsëritjeve dhe ndjekjen e gjendjes. Më shumë mbi "selarin" mund të lexoni, për shembull, .
Gjithashtu, faturimi nuk e ndalonte projektin, në të cilin kishin mbaruar fondet. Duke biseduar me zhvilluesit, zbuluam se gjatë llogaritjeve të statistikave (dhe na duhet të realizojmë pikërisht një logjikë të tillë) ka një lidhje të komplikuar rregullash ndalimi. Por këto modele nuk përputhen mirë me realitetin tonë. Po ashtu, e realizuam përmes detyrave në Celery, duke marrë në anën e backend-it logjikën e menaxhimit të shërbimeve.
Të dy problemet e mësipërme çuan në atë që kodi u fry më tepër dhe ne në të ardhmen do të na duhet të merremi me rrethin e tij, për të nxjerrë logjikën e punës me detyrat në një shërbim të veçantë. Ne gjithashtu duhet të ruajmë një pjesë të informacionit rreth përdoruesve dhe shërbimeve të tyre në tabelat tona, për të mbështetur këtë logjikë.
Një tjetër problem është heshtja.
Për disa kërkesa në API, Bill heshtur përgjigjet "Ok". Kështu ka ndodhur, kur ne bëmë regjistrimet e pagesave të premtuara gjatë testit (për të cilin do të flasim më vonë). Kërkesat u ekzekutuan saktë dhe ne nuk pamë gabime.
Na duhej të studionim logët, duke punuar me sistemin përmes UI. Doli se faturimi vetë kryen kërkesa të tilla, duke ndryshuar skopin për një përdorues të caktuar, për shembull, admin, duke e kaluar atë në parametrin su.
Në përgjithësi, megjithëse ka disa mungesa në dokumentacion dhe disa gabime të vogla në API, gjithçka ka shkuar mjaft mirë. Loget mund të lexohen edhe nën ngarkesë të madhe, për sa kohë që kupton si janë strukturuar dhe çfarë duhet të kërkosh. Struktura e bazës së të dhënave është e ndërlikuar, por mjaft logjike dhe në disa aspekte mjaft të tërheqëse.
Pra, përmbledhjeve, problemet kryesore që na kanë dalë përpara gjatë fazës së ndërveprimit lidhen me veçoritë e implementimit të sistemit të caktuar:
- veçori të pa dokumentuara, të cilat na ndikonin në mënyrë të ndryshme;
- kodet e mbyllura (blloku Ă«shtĂ« shkruar nĂ« C++), si pasojĂ« â pamundĂ«sia pĂ«r tĂ« zgjidhur problemin 1 nĂ« asnjĂ« mĂ«nyrĂ« tjetĂ«r veç 'metodĂ«s sĂ« provave dhe gabimeve'.
Fatmirësisht, produkti ka një API mjaft të gjerë dhe ne integrojmë në panelin tonë personal sistemet e mëposhtme:
- moduli i mbĂ«shtetjes teknik â kĂ«rkesat nga paneli personal âprokurohenâ nĂ« bllokimin e faturave nĂ« mĂ«nyrĂ« tĂ« dukshme pĂ«r klientĂ«t e shĂ«rbimit;
- moduli financiar â lejon lĂ«shimin e faturave pĂ«r klientĂ«t aktualĂ«, tĂ« bĂ«jĂ« shkarkime dhe tĂ« formojĂ« dokumente pagese;
- moduli i menaxhimit tĂ« shĂ«rbimeve â pĂ«r tĂ«, na duhej tĂ« implementonim njĂ« trajtues tĂ« ri. ZgjerueshmĂ«ria e sistemit na ndihmoi dhe ne âmĂ«suamâ Billie pĂ«r njĂ« lloj tĂ« ri shĂ«rbimesh.
Na duhej tĂ« punonim, por nĂ« njĂ« farĂ« mĂ«nyre, mendoj se me Billie do tâi biem nĂ« pĂ«rputhje.
ShĂ«titjet nĂ« fushat tungsten â Tungsten Fabric
Fushat tungsten, tĂ« mbushura me qindra kabuj qĂ« kalojnĂ« mijĂ«ra bit-e informacioni. Informacioni mbledhĂ«t nĂ« âpaketaâ, analizohet, duke ndĂ«rtuar rrugĂ« tĂ« ndĂ«rlikuara, si me magji.
Kjo Ă«shtĂ« mbretĂ«ria e sistemit tĂ« dytĂ«, me tĂ« cilin duhej tĂ« bashkĂ«punonim â Tungsten Fabric (TF), i njohur mĂ« parĂ« si OpenContrail. Detyra e tij Ă«shtĂ« tĂ« menaxhojĂ« pajisjet rrjetĂ«rore, duke ofruar njĂ« abstraksion softuerik pĂ«r ne, si pĂ«rdorues. TF Ă«shtĂ« SDN, inkorporon logjikĂ«n e ndĂ«rlikuar tĂ« punĂ«s me pajisjet rrjetĂ«rore. PĂ«r teknologjinĂ« vetĂ« ka njĂ« artikull tĂ« mirĂ«, pĂ«r shembull, .
Sistemi është i integruar me OpenStack (për të do të flasim më poshtë) përmes një plani të Neutron.
Ndërveprimi i shërbimeve OpenStack.
Këtë sistem na e prezantuan djemtë nga departamenti i operacioneve. Ne përdorim API-në e sistemit për të menaxhuar rrjetin tonë të shërbimeve. Nuk kemi pasur probleme të mëdha ose shqetësime këtu (nuk do marr përsipër të flas për djemtë nga OE), megjithatë ka pasur disa situata komike gjatë ndërveprimit.
E para dukej kĂ«shtu: komandat qĂ« kĂ«rkonin tĂ« nxirrnin njĂ« sasi tĂ« madhe tĂ« dhĂ«nash nĂ« konsolĂ«n e instancĂ«s gjatĂ« lidhjes pĂ«rmes SSH thjesht âbllokoninâ lidhjen, ndĂ«rkohĂ« qĂ« pĂ«rmes VNC gjithçka funksiononte normalisht.
PĂ«r ata qĂ« nuk e njohin problemin, kjo duket mjaft qesharake: ls /root funksionon siç duhet, ndonĂ«se, pĂ«r shembull, top ângrihetâ deri nĂ« bllokim. FatmirĂ«sisht, ne kishim hasur nĂ« probleme tĂ« ngjashme mĂ« parĂ«. Kjo u zgjidh me tunimin e MTU-sĂ« nĂ« rrugĂ«n nga nodet e llogaritjes deri te ruterat. PĂ«r ta thĂ«nĂ« ndryshe, kjo nuk ishte as njĂ« problem pĂ«r TF.
Problemi tjetĂ«r na priste pas kthesĂ«s. NĂ« njĂ« moment âtĂ« mrekullueshĂ«mâ magia e rrugĂ«zimit kishte zhdukur, aq thjesht. TF ndali menaxhimin e rrugĂ«zimit nĂ« pajisjet.
Ne punuam me OpenStack nga niveli admin dhe mĂ« pas kaluam nĂ« nivelin e pĂ«rdoruesit tĂ« nevojshĂ«m. SDN, duket se âkapâ skopin e pĂ«rdoruesit me tĂ« cilin veprohet. ĂĂ«shtja Ă«shtĂ« se ky llogari admini pĂ«rdoret pĂ«r lidhjen mes TF dhe OpenStack. NĂ« hapin e kalimit tek pĂ«rdoruesi âmagjiaâ humbiste. U zgjidh tĂ« hapim njĂ« llogari tĂ« veçantĂ« pĂ«r punĂ« me sistemin. Kjo lehtĂ«soi punĂ«n, pa prishur funksionalitetin e integrimit.
Forma tĂ« silikonit â OpenStack
Një krijesë silikoni në formën e çuditshme jeton afër fushave tungsten. Më shumë duket si një fëmijë gjigant që me një gjest mund të na shkatërrojë, por nuk lëshon asnjë agresivitet të dukshëm. Nuk shfaq frikë, por përmasat e tij ngjallin shqetësim. Ashtu si edhe kompleksiteti i asaj që ndodh rreth tij.
OpenStack është thelbi i platformës sonë.
OpenStack ka disa nĂ«n-sisteme, nga tĂ« cilat ne pĂ«r momentin pĂ«rdorim mĂ« aktivisht Nova, Glance dhe Cinder. Ădo njĂ«ra prej tyre ka API tĂ« saj. Nova pĂ«rgjigjet pĂ«r burimet e llogaritjes dhe krijimin e instancave, Cinder â pĂ«r menaxhimin e volumĂ«ve dhe imazheve tĂ« tyre, Glance â shĂ«rbimi i imazheve, i cili menaxhon shabllonet e OS dhe metainformacionin pĂ«r to.
Ădo shĂ«rbim aktivizohet nĂ« njĂ« kontenier, dhe brokeri i mesazheve Ă«shtĂ« âkrolja e bardhĂ«â â RabbitMQ.
Ky sistem na ka sjellë më shumë shqetësime të papritura.
Dhe problemi i parë nuk vonoi të shfaqej, kur përpiqeshim të lidhnim një volum shtesë me serverin. API i Cinder refuzonte kategorikisht të realizonte këtë detyrë. Më saktë, nëse besojmë OpenStack, lidhja vendoset, megjithatë brenda serverit virtual pajisja e diskut mungon.
Ne vendosëm t'i shkojmë një rruge tjetër dhe kërkuam të njëjtin veprim nga Nova API. Rezultati - pajisja lidhet siç duhet dhe është e aksesueshme brenda serverit. Duket se problemi ndodh kur block-storage nuk përgjigjet Cinder-it.
Një sfidë tjetër na priste gjatë punës me diskët. Volume sistemik nuk arrinte të shkëputej nga serveri.
Gjithashtu, vetë OpenStack 'premton' se ka shkatërruar lidhjen dhe tani është e mundur të punosh me volume-n veçmas. Por API refuzonte kategorikisht të kryente operacione mbi diskun.
KĂ«tu vendosĂ«m tĂ« mos luftojmĂ« shumĂ«, por tĂ« ndryshojmĂ« pikĂ«pamjen mbi logjikĂ«n e funksionimit tĂ« shĂ«rbimit. NĂ«se ka njĂ« instance, duhet tĂ« ketĂ« edhe njĂ« volume sistemik. Prandaj pĂ«rdoruesi pĂ«r momentin nuk mund tĂ« fshijĂ« ose tĂ« shkĂ«putĂ« disku âsistemikâ pa fshirĂ« âserverinâ.
OpenStack është një kompleks sistemesh mjaft i komplikuar me logjikën e tij të ndërveprimit dhe API të ndërlikuar. Dokumentacioni mjaft i detajuar na ndihmon, dhe sigurisht, metoda e provave dhe gabimeve (ku ta di) është e nevojshme.
Testim fillestar
Testimi fillestar e bëmë në dhjetor të vitit të kaluar. Qëllimi kryesor ishte të kontrollonim në mënyrë operative projektin tonë nga ana teknike dhe nga ana e UX. Audienca u ftuar në mënyrë selektive dhe testimi ishte i mbyllur. Megjithatë, ne gjithashtu lanë mundësinë për të kërkuar akses për testim në faqen tonë.
Testi, natyrisht, nuk kaloi pa momente kurioze, pasi aventura jonë sapo kishte filluar.
Së pari, ne vlerësuam disi pasaktë interesin për projektin dhe na duhej të shtojmë node compute pikërisht në kohë gjatë testit. Një rast normal për klaster, megjithatë kishte edhe këtu nuanca. Në dokumentacionin për versionin specifik të TF, është e caktuar një version i veçantë i kernelit, mbi të cilin ishte testuar funksionimi me vRouter. Ne vendosëm të fillojmë node me kernela më të rinj. Si pasojë - TF nuk mori rrugët nga node. Duhej të rikthenim urgjentisht kernelin.
NjĂ« tjetĂ«r incident Ă«shtĂ« lidhur me funksionalitetin e butonit ândrysho fjalĂ«kaliminâ nĂ« panelin personal.
VendosĂ«m tĂ« pĂ«rdorim JWT pĂ«r tĂ« organizuar aksesin nĂ« panelin personal, pĂ«r tĂ« mos punuar me sesionet. PĂ«rderisa sistemet janĂ« shumĂ« tĂ« larmishme dhe tĂ« shpĂ«rndara, ne menaxhojmĂ« token-in tonĂ«, nĂ« tĂ« cilin ândĂ«rtojmĂ«â sesionet nga faturimi dhe token nga OpenStack. Kur ndryshohet fjalĂ«kalimi, token-i, sigurisht, âskadonâ, pasi tĂ« dhĂ«nat e pĂ«rdoruesit tashmĂ« nuk janĂ« tĂ« vlefshme dhe duhet tĂ« ri-lĂ«shohet.
E humbëm këtë moment nga vëmendja, dhe nuk kishim burime për të shkruar shpejt këtë pjesë. Na duhej të hiqnim funksionalitetin pikërisht para se të fillonim testin.
Në këtë moment, ne kryejmë logout për përdoruesin, nëse është ndryshuar fjalëkalimi.
Pavarësisht këtyre nuancave, testimi kaloi mirë. Gjatë disa javëve rreth 300 njerëz na vizituan. Na arriti të shihnim produktin nga këndvështrimi i përdoruesve, ta testonim në betejë dhe të mbledhim feedback të dobishëm.
Vazhdon
PĂ«r shumicĂ«n nga ne, ky Ă«shtĂ« projekti i parĂ« i kĂ«tij pĂ«rmasash. Ne nxorĂ«m disa mĂ«sime tĂ« vlefshme rreth mĂ«nyrĂ«s se si tĂ« punojmĂ« nĂ« ekip, tĂ« marrim vendime arkitekturore dhe dizajnuese. Si tĂ« integrojmĂ« sisteme tĂ« komplikuara me burime tĂ« pakta dhe tâi nxjerrim ato nĂ« prodhim.
Sigurisht, ka shumë për të punuar në lidhje me kodin dhe në ndërprerjet e integrimit të sistemeve. Projekti është mjaft i ri, por ne jemi plot ambicie për ta rritur atë në një shërbim të besueshëm dhe të përshtatshëm.
Sistemet tashmĂ« i kemi bindur. Billi angazhohet me pĂ«rllogaritjet, lĂ«shimin e faturave dhe kĂ«rkesat e pĂ«rdoruesve nĂ« dhomĂ«n e tij. âMagjiaâ e fushave tĂ« tungstenit na ofron njĂ« lidhje tĂ« qĂ«ndrueshme. Dhe vetĂ«m OpenStack ndonjĂ«herĂ« bĂ«n kapriçio, duke thĂ«nĂ« diçka si âWSREP ende nuk e ka pĂ«rgatitur node pĂ«r pĂ«rdorim aplikacioniâ. Por kjo Ă«shtĂ« njĂ« histori krejt tjetĂ«r...
Kohët e fundit filluam shërbimin.
Të gjitha detajet mund të mësoni në .
Ekipi i zhvillimit CLO
Linqe të dobishme
OpenStack
Tungsten Fabric
Burimi: habr.com
