Me rritjen e eksperiencës në IT, fillon të kuptosh se sistemet kanë karakterin e tyre. Ato mund të jenë të bindura, të heshtura, kapriçioze, të ashpra. Mund të të tërheqin apo të të pengojnë. Pavarësisht kësaj, duhet të "bisedosh" me to, të manovrosh midis "peshqve nën ujë" dhe të ndërtosh zinxhirët e bashkëveprimit të tyre.
Pra, na u dha nderi të krijojmë një platformë cloud, dhe për këtë ishte e nevojshme të "bisedonim" me disa nën-sisteme që të punonin me ne. Fatmirësisht, kemi "gjuha API", duar të drejta dhe shumë entuziazëm.
Në këtë artikull nuk do të ketë hardkor teknik, por do të përshkruhen problemet me të cilat u përballëm gjatë ndërtimit të cloud-it. Vendosa të përshkruaj rrugën tonë në formën e një fantazie teknike të lehtë për atë se si kërkuam një gjuhë të përbashkët me sistemet dhe çfarë doli nga kjo.
Mirë se vini nën kat.
Fillimi i rrugës
Disa kohë më parë, ekipi ynë u ngarkua me detyrën për të lançuar një platformë cloud për klientët tanë. Ne kishim mbështetje nga drejtori, burime, një harduer të përshtatshëm dhe liri në zgjedhjen e teknologjive për realizimin e pjesës software të shërbimit.
Ishte gjithashtu një sërë kërkesash:
- shërbimi ka nevojë për një panel personal të rehatshëm;
- platforma duhet të jetë e integruar në sistemin ekzistues të faturimit;
- pjesa softuerike dhe harduerike: OpenStack + Tungsten Fabric (Open Contrail), të cilat inxhinierët tanë i mësuan mirë të "gatuhen".
Se si u formua ekipi, u zhvillua ndërfaqja e panelit personal dhe u morën vendimet dizajnuese, do ta përshkruajmë një herë tjetër, nëse komuniteti Habr do të ketë interes.
Instrumentet që vendosëm të përdorim:
- Python + Flask + Swagger + SQLAlchemy â njĂ« grup relativisht standard Python;
- Vue.js për front-end;
- bashkëveprimi midis komponentëve dhe shërbimeve u vendos të bëhej me ndihmën e Celery mbi AMQP.
Duke parashikuar pyetje mbi zgjedhjen për Python, do të sqaroj. Gjuha ka marrë një vend të caktuar në kompaninë tonë dhe rreth saj është ndërtuar një kulturë e vogël, por e rëndësishme. Prandaj, u vendos të fillonim ndërtimin e shërbimit saktësisht në të. Sidomos duke pasur parasysh se shpejtësia e zhvillimit shpesh e luan rolin kryesor në këto detyra.
Pra, le të fillojmë njohjen tonë.
Bill-i i heshtur â faturimi
Me dhe kĂ«tĂ« djalĂ« ishim njohur prej kohĂ«sh. Ai gjithmonĂ« kishte ulur dhe numĂ«ronte diçka nĂ« heshtje. Disa herĂ« na dĂ«rgonte kĂ«rkesat e pĂ«rdoruesve, pĂ«rgatiste faturat pĂ«r klientĂ«t, menaxhonte shĂ«rbimet. NjĂ« djalĂ« i zakonshĂ«m punĂ«tor. MegjithatĂ«, kishte vĂ«shtirĂ«si. Ai ishte i heshtur, ndonjĂ«herĂ« mendues dhe shpesh â thjesht me mendimet e tij.
Bllokimi është sistemi i parë me të cilin përpiqeshim të krijonim një marrëdhënie. Dhe vështirësia e parë na u paraqit gjatë përpunimit të shërbimeve.
Për shembull, kur krijohet ose fshihet një shërbim, detyra kalon në listën e brendshme të bllokimit. Kështu është realizuar një sistem i punës asinkrone me shërbimet. Për të përpunuar tipet e veta të shërbimeve, na duhej të 'vendosnim' detyrat tona në këtë listë. Dhe këtu u përballëm me një problem: mungesa e dokumentacionit.
Sipas përshkrimit të API-së programore, të zgjidhim këtë detyrë duhej të ishte e mundur, por nuk kishim kohë për të punuar në inxhinierinë e kundërt, prandaj e zgjidhëm logjikën nga jashtë dhe organizuam listën e detyrave mbi RabbitMQ. Operacioni mbi shërbimin iniciohet nga klienti nga paneli i tij, rrethojë në një 'detyrë' Celery në backend dhe ekzekutohet në anën e bllokimit dhe OpenStack. Celery lejon menaxhimin mjaft të lehtë të detyrave, organizimin e përsëritjeve dhe ndjekjen e gjendjes. Më shumë rreth 'selerisë' mund të lexoni, për shembull, .
Gjithashtu, bllokimi nuk pezullonte projektin kur mbaronin paratë. Duke komunikuar me zhvilluesit, zbuluam se gjatë llogaritjes sipas statistikave (dhe na duhej të realizonim pikërisht një logjikë të tillë) kishte një lidhje të ndërlikuar të rregullave të pezullimit. Por këto modele nuk ishin të përshtatshme për realitetin tonë. E zgjidhëm gjithashtu nëpërmjet detyrave në Celery, duke marrë logjikën e menaxhimit të shërbimeve në anën e backend-it.
Të dy problemet e mësipërme çuan në atë që kodi u frymëzua pak dhe në të ardhmen na duhej të merreshim me rifreskimin e tij, për të nxjerrë në një shërbim të veçantë logjikën e punës me detyrat. Ne gjithashtu duhej të ruanim një pjesë të informacionit rreth përdoruesve dhe shërbimeve të tyre në tabelat tona, në mënyrë që të mbështesim këtë logjikë.
NjĂ« problem tjetĂ«r â heshtja.
Për një pjesë të kërkesave ndaj API-së, Billi përgjigjej në heshtje me 'Ok'. Kështu ndodhi, kur bënim kreditimin e pagesave të premtuara gjatë periudhës së provës (për të cilën do flasim më vonë). Kërkesat u realizuan siç duhej dhe ne nuk pamë gabime.
Duhet të studioja log-et duke punuar me sistemin përmes UI. Doli se vetë faturimi kryen kërkesa të tilla, duke ndryshuar skopin për përdoruesin specifik, për shembull, admin, duke e kaluar atë si parametrin su.
Në përgjithësi, pavarësisht nga boshllëqet në dokumentacion dhe disa ndjesi të vogla API, gjithçka kaloi mjaft mirë. Log-et është e qartë të lexohen edhe me një ngarkesë të madhe, nëse kupton se si janë ndërtuar dhe çfarë duhet të kërkosh. Struktura e bazës së të dhënave është komplekse, por mjaft logjike dhe në disa aspekte edhe tërheqëse.
Pra, duke përmbledhur, problemet kryesore që përjetuam gjatë ndërveprimit lidhen me veçoritë e implementimit të sistemit të caktuar:
- karakteristika të pa dokumentuara, të cilat na preknin nga çdo anë;
- kodet e mbyllura (faturimi Ă«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 të avancuar dhe ne e integrojmë në kabinetin tonë të personalizuar sistemet e mëposhtme:
- moduli i mbĂ«shtetjes teknike â kĂ«rkesat nga kabineti personal "proksyohen" nĂ« faturim nĂ« mĂ«nyrĂ« tĂ« qartĂ« pĂ«r klientĂ«t e shĂ«rbimit;
- moduli financiar â lejon qĂ« tĂ« lĂ«shohen faturat pĂ«r klientĂ«t aktualĂ«, tĂ« pĂ«rfundojnĂ« pagesat dhe tĂ« formojnĂ« dokumentet e pagesĂ«s;
- moduli i menaxhimit tĂ« shĂ«rbimeve â pĂ«r tĂ« ne duhej tĂ« realizonim trajtuesin tonĂ«. ZgjerueshmĂ«ria e sistemit na ndihmoi dhe ne "mĂ«suam" Billi pĂ«r njĂ« lloj tĂ« ri shĂ«rbimesh.
Duhet të merremi me këtë, por megjithatë, mendoj se me Billi do të kemi një marrëveshje.
ShĂ«titje nĂ« fushat tungsten â Tungsten Fabric
Fushat tungsten janë të mbushura me qindra kabllosh që kalojnë mijëra bita informacioni. Informacioni mblidhet në "paketa", dekodohet, duke ndërtuar rrugë komplekse, ashtu si me magji.
Ky Ă«shtĂ« domeni i sistemit tĂ« dytĂ«, me tĂ« cilin na duhej tĂ« bĂ«jmĂ« miqĂ«si â Tungsten Fabric (TF), dikur OpenContrail. Detyra e saj Ă«shtĂ« tĂ« menaxhojĂ« pajisjet rrjet, duke ofruar njĂ« abstraksion programor pĂ«r ne si pĂ«rdorues. TF â SDN, pĂ«rmbledh logjikĂ«n komplekse tĂ« punĂ«s me pajisjet rrjet. .
Sistemi është i integruar me OpenStack (për të cilin do të flasim më poshtë) përmes plugin-it Neutron.
Ndërveprimi i shërbimeve OpenStack.
Ne kemi njohur këtë sistem falë djemve nga departamenti i shfrytëzimit. Ne përdorim API-në e sistemit për të menaxhuar rrjetin e shërbimeve tona. Deri tani nuk na ka shkaktuar probleme serioze apo shqetësime (nuk do ta marrë përsipër të flas për djemtë e O.E.), megjithatë ka pasur disa situata qesharake gjatë bashkëpunimit.
I pari dukej kështu: komandat që kërkonin të nxirrnin një sasi të madhe të dhënash në konsolën e instancës, kur lidhen me SSH, thjesht "ngarkonin" lidhjen, ndërsa përmes VNC gjithçka funksiononte siç duhet.
Për ata që nuk janë të njohur me problemin, kjo duket mjaft qesharake: ls /root punon pa probleme, ndërsa, për shembull, top "ngarkon" krejtësisht. Fatmirësisht, ne tashmë ishim përballur me probleme të tilla. E zgjidhëm duke rregulluar MTU-në në rrugën nga nodet e compute deri te ruterët. Për t'u thënë të vërtetën, kjo nuk ishte një problem për TF.
Problemi tjetër na priste pas kthesës. Në një "moment të mrekullueshëm", magia e routing-ut zhduku, kështu thjesht. TF ndaloi së menaxhuari routing-un në pajisjet.
Ne punonim me OpenStack nga niveli admin dhe më pas kalonim në nivelin e përdoruesit të nevojshëm. SDN, duket se "kap" skopin e përdoruesit me të cilin kryhen veprimet. Problemi është se ky llogari admini përdoret për të lidhur TF dhe OpenStack. Në hapin e kalimit te përdoruesi, "magjia" zhdukej. E zgjidhëm duke hapur një llogari të veçantë për të punuar me sistemin. Kjo e bëri të mundur punimin pa prishur funksionalitetin e integrimit.
Forma tĂ« jetĂ«s silikoni â OpenStack
Një krijesë silikoni me forma të çuditshme jeton pranë fushave të tungstenit. Ajo më shumë i ngjan një fëmije mbi të rritur, i cili me një goditje mund të na shkelë, por nuk shfaq agresion të qartë. Nuk ngjall frikë, por përmasat e saj japin një ndjenjë shqetësimi. Po ashtu, edhe kompleksiteti i asaj që ndodh përreth.
OpenStack është thelbi i platformës sonë.
OpenStack ka disa nĂ«n-sisteme, nga tĂ« cilat deri tani kemi pĂ«rdorur mĂ« aktivisht Nova, Glance dhe Cinder. Ădo njĂ«ra ka API-nĂ« e vet. Nova Ă«shtĂ« pĂ«rgjegjĂ«se pĂ«r burimet compute dhe krijimin e instancave, Cinder pĂ«r menaxhimin e volume-ve dhe snapshot-eve tĂ« tyre, Glance Ă«shtĂ« shĂ«rbimi i imazhit qĂ« menaxhon shabllonet e OS-sĂ« dhe metainformacionin mbi to.
Ădo shĂ«rbim starton nĂ« njĂ« konteiner, ndĂ«rsa "tĂ« bardhi" Ă«shtĂ« brokeri i mesazheve â RabbitMQ.
Ky sistem na ka sjellë më shumë shqetësime të papritura.
Problemi i parë nuk vonoi shumë, kur përpiqeshim të lidhim një volum shtesë me serverin. API Cinder refuzonte kategorikisht të kryente këtë detyrë. Më saktë, nëse i besojmë OpenStack-it, lidhja vendoset, por brenda serverit virtual, disku mungon.
Ne vendosĂ«m tĂ« "anashkalojmĂ«" kĂ«tĂ« problem dhe kĂ«rkuam tĂ« njĂ«jtin veprim nga API Nova. Rezultati â pajisja lidhet siç duhet dhe Ă«shtĂ« e disponueshme brenda serverit. Duket se problemi ndodh kur ruajtja e bllokut nuk i pĂ«rgjigjet Cinder-it.
Një vështirësi tjetër na priste gjatë punës me disqet. Volumi sistemor nuk mund të shkëputej nga serveri.
Sërish, vetë OpenStack "premton" se lidhja është shkatërruar dhe tani mund të punojmë siç duhet me volumet veçmas. Por API refuzonte kategorikisht të kryente operacione mbi disk.
Këtu ne vendosëm të mos luftojmë shumë dhe të ndryshojmë qasjen mbi logjikën e funksionimit të shërbimit. Nëse ekziston një instance, duhet të ketë edhe një volum sistemor. Prandaj, përdoruesi për momentin nuk mund të fshijë ose heqë qafe "diskun" sistemor pa fshirë "serverin".
OpenStack është një kompleks mjaft i ndërlikuar sistemesh me logjikën e vet të ndërveprimit dhe një API të komplikuar. Na ndihmon dokumentacioni mjaft i detajuar dhe, natyrisht, metoda e provave dhe gabimeve (ku do pa të).
Testimi fillestar
Testimi fillestar u zhvillua në dhjetor të vitit të kaluar. Objektivi kryesor ishte të verifikohej në mënyrë praktike projekti ynë nga ana teknike dhe nga perspektiva e UX. Audienca u ftuar në mënyrë selektive dhe testi ishte i mbyllur. Megjithatë, ne gjithashtu lanë mundësinë për të kërkuar akses në testim në faqen tonë.
Sigurisht, testi nuk kaloi pa momente kurioze, sepse këtu aventurat tona sapo kanë filluar.
SĂ« pari, ne vlerĂ«suam disi paqartĂ« interesin pĂ«r projektin dhe na u desh tĂ« shtonim node compute pikĂ«risht gjatĂ« testit. NjĂ« rast i zakonshĂ«m pĂ«r njĂ« grup, megjithatĂ« dhe kĂ«tu pati nuanca. NĂ« dokumentacionin pĂ«r versionin pĂ«rkatĂ«s tĂ« TF, ishte e specifikuar njĂ« version i caktuar i bĂ«rthamĂ«s, mbi tĂ« cilin ishte testuar funksionimi me vRouter. Ne vendosĂ«m tĂ« nisim node me bĂ«rthama mĂ« tĂ« reja. Si pasojĂ« â TF nuk mori rute nga node. Na duhej tĂ« riktheheshim urgjentisht nĂ« bĂ«rthamat mĂ« tĂ« vjetra.
Një moment tjetër kurioz lidhet me funksionalitetin e butonit "ndrysho fjalëkalimin" në panelin personal.
Vendosëm të përdorim JWT për të organizuar qasjen në llogarinë personale, në mënyrë që të mos punojmë me seancat. Duke qenë se sistemet janë të përhapura dhe të ndryshme, ne menaxhojmë tokenin tonë, në të cilin 'mbështesim' sesionet nga faturimi dhe tokenin nga OpenStack. Kur ndryshohet fjalëkalimi, tokeni, natyrisht, 'skadon', pasi të dhënat e përdoruesit nuk janë më të vlefshme dhe ai duhet të rilidhet.
Na iku ky moment nga vështrimi, dhe burimet për të shkruar këtë pjesë shpejt thjesht na mungonin. Na duhej të hiqnim funksionalitetin para lançimit në provë.
Aktualisht, ne kryejmë logout të përdoruesit nëse është ndryshuar fjalëkalimi.
Pavarësisht këtyre nuancave, testi kaloi mirë. Gjatë disa javëve, rreth 300 persona na vizituan. Na u dha mundësia të shihnim produktin nga sytë e përdoruesve, ta testonim në terren dhe të grumbullojmë feedback cilësor.
Vazhdon
PĂ«r shumĂ« nga ne, ky Ă«shtĂ« projekti i parĂ« i kĂ«tij ĐŒĐ°ŃŃŃаба. Ne nxorrĂ«m disa mĂ«sime tĂ« çmuara pĂ«r mĂ«nyrĂ«n se si tĂ« punojmĂ« nĂ« ekip, tĂ« marrim vendime arkitekturore dhe dizajnuese. Si tĂ« integrojmĂ« sisteme tĂ« komplikuara me resurse tĂ« pakta dhe t'i lançojmĂ« ato nĂ« prodhim.
Natyrisht, ka ende për të punuar në kod dhe në lidhjet ndërkombëtare të sistemeve. Projekti është mjaft i ri, por ne jemi plot ambicie për ta rritur në një shërbim të besueshëm dhe të përdorshëm.
Sistemet tashmë i kemi bindur. Billi po merret me llogaritjet, faturimin dhe kërkesat e përdoruesve nga dhoma e tij. 'Magjia' e fushave të tungstenit na siguron lidhje të qëndrueshme. Dhe vetëm OpenStack herë pas here kapriciozon, duke klithur diçka si 'WSREP nuk e ka përgatitur ende nodin për përdorim.' Por kjo është një histori krejt tjetër...
Pak kohë më parë ne lançuam shërbimin.
Të gjitha detajet mund t'i mësoni në .
Ekipi i zhvillimit CLO
Useful links
steal time
Tungsten Fabric
Burimi: habr.com
