🥇Pilveteenuse loomise lugu, maitsestatud küberpungiga

IT-valdkonnas töötades hakkad märkama, et süsteemidel on oma iseloom. Need võivad olla alti, vaiksed, kapriissed, karmid. Need võivad sind tõmmata või peletada. Igal juhul pead nendega "kokkuleppele" jõudma, navigeerima "aluste kivide" vahel ja looma nende koostöö ahelad.

Nüüd on meie võimalus ehitada pilveplatvorm, milleks oli vajalik "veenda" paar alam-süsteemi meiega koostööd tegema. Õnneks on meil olemas "API keel", osavad käed ja hulk entusiasmi.

Selles artiklis ei käsitleta tehnilisi detaile, vaid tuuakse välja probleemid, millega me silmitsi seisime pilve loomise protsessis. Otsustasin meie teekonna kirjeldada kerge tehnilise fantaasiana, kuidas me süsteemidega ühist keelt otsisime ja mis sellest välja tuli.

Tere tulemast allapoole.

Teekonna algus

Mõni aeg tagasi pandi meie meeskonnale ülesanne — käivitada pilveplatvorm meie klientidele. Meil olid olemas juhtkonna toetus, ressursid, riistvaraline struktuur ja vabadus tehnoloogiate valimisel teenuse tarkvara osa teostamiseks.

Oli ka mitmeid nõudeid:

teenus vajab mugavat isiklikku kabinetti;
platvorm peab olema integreeritud olemasolevasse arveldamise süsteemi;
programmi-riistvara osa: OpenStack + Tungsten Fabric (Open Contrail), mida meie insenerid on piisavalt hästi "valmistama" õppinud.

Kuidas meeskond kokku kutsuti, isikliku kabineti liidest arendati ja disainiotsuseid tehti — sellest räägime järgmisel korral, kui Habr-ühisusele huvi tekib.
Tööriistad, mida me otsustasime kasutada:

Python + Flask + Swagger + SQLAlchemy — täiesti standardne Python komplekt;
Vue.js frontendi jaoks;
komponentide ja teenuste vaheline suhtlus otsustati teha Celery abil AMQP üle.

Eeldades küsimusi Python'i valiku kohta, selgitan. Keel on leidnud oma koha meie ettevõttes ja selle ümber on kujunenud väike, kuid siiski kultuur. Seetõttu otsustati alustada teenuse ehitamist just sellega. Eriti kuna arendamise kiirus sellistes ülesannetes mängib sageli suurt rolli.

Alustame siis meie tutvumist.

Vaikne Bill — arveldamine

Selle tüübiga olime me pikka aega tuttavad. Ta istus alati kõrval ja vaikselt midagi arvestas. Mõnikord suunas ta meile kasutajate päringud, koostas kliendiarveid ja haldas teenuseid. Tavaline töökas mees. Tõsi, olid ka raskused. Ta on vaikne, mõnikord mõtlik ja sageli — omaette.

Kliendihaldustarkvara on esimene süsteem, millega me püüdsime sõbraks saada. Ja esimene raskus kohtas meid teenuste töötlemisel.

Näiteks, kui loome või kustutame teenuseid, satub ülesanne sisemisse kliendihalduse järjekorda. Nii on rakendatud asünkroonset töötlemist teenustega. Oma teenuste tüüpide töötlemiseks pidime oma ülesandeid selle järjekorra juurde „panema”. Ja siin kohtasime probleemi: dokumentatsiooni puudus.

API kirjelduse järgi on selle ülesande lahendamine siiski võimalik, kuid meil ei olnud aega pöördinseneri töödeks, seega tõstsime loogika välja ja korraldasime ülesannete järjekorra RabbitMQ peal. Teenuse operatsioon algatatakse kliendi poolt isiklikus kabinetis, see pakitakse Celery 'ülesandesse' tagaosas ja täidetakse arvelduse ja OpenStack'i külgedel. Celery võimaldab piisavalt mugavalt hallata ülesandeid, korraldada kordusi ja jälgida olekut. Rohkem teavet 'selleri' kohta saab lugeda näiteks siit.

Arveldamine ei peatunud ka projektis, mille rahad said otsa. Suheldes arendajatega, selgus, et statistika arvestamisel (ja me peame rakendama just sellist loogikat) on keeruline peatamisreeglite omavaheline seos. Kuid need mudelid ei sobi hästi meie oludesse. Samuti rakendasime selle Celery ülesannete kaudu, viies teenuste haldamise loogika tagaossa.

Mõlemad ülaltoodud probleemid on viinud sellele, et kood on veidi paisunud ja tulevikus peame tegelema refaktoreerimisega, et eraldi teenusesse välja võtta ülesannete töötlemise loogika. Me peame samuti salvestama osa teavet kasutajate ja nende teenuste kohta oma tabelitesse, et seda loogikat toetada.

Veel üks probleem on vaikimine.

Mõne API päringu puhul vastab Billing vaikselt "Ok". Näiteks juhtus see, kui tasusime lubatud makseid testimise ajal (sellest hiljem). Päringud täideti korrektselt ja me ei näinud vigu.

Pidime logisid uurima, töötades süsteemiga kaudu UI. Selgus, et billing ise täidab sarnaseid päringuid, muutes scope'i konkreetse kasutaja, näiteks admin, jaoks ja edastades selle parameetris su.

Üldiselt, vaatamata dokumentatsiooni puudujääkidele ja väikestele API vigadele, läks kõik suhteliselt sujuvalt. Logisid on võimalik lugeda isegi suure koormuse korral, kui aru saada, kuidas need on üles ehitatud ja mida otsida. Andmebaasi struktuur on keeruline, kuid täiesti loogiline ja mingil määral isegi atraktiivne.

Kokkuvõttes on meie peamised probleemid, mis tekkisid suhtlemise etapis, seotud konkreetse süsteemi rakendamise eripäradega:

dokumenteerimata «funktsioonid», mis vahetult meid puudutasid;
suletud lähtekoodid (arveldamine on kirjutatud C++ keeles), mis tähendab, et me ei saanud probleemi lahendada muul viisil kui «katse ja eksituse meetod».

Kliendil on õnneks piisavalt ulatuslik API ning oleme integreerinud oma isikliku kabineti järgmised alamsüsteemid:

tehnilise toe moodul — päringud isiklikust kabinetist suunatakse arveldamisse teenuse kasutajatele nähtamatult;
rahanduslik moodul — võimaldab esitada arveid praegustele klientidele, teostada arvelduseid ja vormistada maksedokumente;
teenuste haldamise moodul — selle jaoks pidime rakendama oma töötlija. Süsteemi laiendatavus aitas meid ja oleme «koolitanud» Billy uut tüüpi teenustega.
Töötamine võttis aega, kuid ometigi, ma usun, et Billyga saame sina ja mina läbi.

Matkad volframiväljade vahel — Tungsten Fabric

Volframipõllud, mida katab sadu juhtmeid, mis edastavad läbi nende tuhandeid bitte infot. Teave kogutakse 'pakettidesse', töödeldakse ja suunatakse keerukatesse marsruutidesse, justkui nõiaga.

See on teise süsteemi ala, millega pidime sõbraks saama — Tungsten Fabric (TF), endine OpenContrail. Selle ülesanne on hallata võrgu seadmeid, pakkudes meile, kasutajatele, tarkvaralist abstraktsiooni. TF on SDN, mis sisaldab endas keerukat loogikat võrgu seadmete töötlemiseks. Tehnoloogia kohta on olemas hea artikkel, näiteks, siin.

Süsteem on integreeritud OpenStackiga (sellest räägime allpool) Neutroni plugina kaudu.

OpenStacki teenuste suhtlemine.

Selle süsteemiga tutvustasid meid töötajad käituse osakonnast. Kasutame süsteemi API-d meie teenuste võrgustiku haldamiseks. Tõsiseid probleeme või ebamugavusi see meile seni ei ole valmistanud (kuid käituse osakonna töö eest ei saa ma vastutada), siiski on olnud mõned naljakad juhtumid suhtlemisel.

Esimene nägi välja järgmine: käsklused, mis nõudsid suure hulga andmete väljastamist instantsi konsoolile SSH kaudu, lihtsalt 'külmutasid' ühenduse, samas kui VNC kaudu töötas kõik korrektselt.

Need for those unfamiliar with the issue, it looks quite amusing: ls /root works correctly, while top, for example, completely freezes. Fortunately, we have dealt with similar issues before. It was resolved by tuning the MTU on the route from compute nodes to the routers. By the way, this isn't a problem for TF.

The next problem was lurking around the corner. At one 'beautiful' moment, the magic of routing simply vanished. TF stopped managing routing on the equipment.

We worked with OpenStack from the admin level and then switched to the required user level. It seems SDN 'takes over' the user scope under which actions are executed. The thing is, this same admin account is used for communication between TF and OpenStack. When switching to the user, the 'magic' disappeared. It was decided to create a separate account for working with the system. This allowed us to operate without breaking the integration functionality.

Silicon life forms — OpenStack

Kujuteldav kummaline olend elab wolframiväljade lähedal. See sarnaneb kõige rohkem kasvava lapsega, kes võib meie ühekätega purustada, kuid sellest ei kiirgu ilmset agressiivsust. See ei tekita hirmu, kuid selle suurus on hirmutav. Nagu ka keerukus, mis toimub selle ümber.

OpenStack on meie platvormi tuum.

OpenStackil on mitu alam-süsteemi, millest hetkel kasutame kõige aktiivsemalt Nova, Glance ja Cinder. Igal neist on oma API. Nova vastutab arvutusressursside ja instantside loomise eest, Cinder haldab mahtusid ja nende pilte, Glance on pilditeenus, mis haldab OS-i malli ja nende kohta metainfot.

Iga teenus töötab konteineris ja sõnumite edastamiseks kasutame 'valget jänest' — RabbitMQ.

See süsteem on meile põhjustanud kõige rohkem ootamatuid probleeme.

Esimene probleem tekkis kohe, kui proovisime lisamahtu serverile ühendada. Cinder API keeldus seda ülesannet täitmast. Täpsemalt, kui usaldada OpenStack’ile, siis ühendus luuakse, kuid virtuaalmasina sees puudub ketase.

Otsustasime "mööda minna" ja küsisime sama tegevuse Nova API-lt. Tulemus — seade ühendub korrektselt ja on serveris saadaval. Tundub, et probleem tekib, kui block-storage ei vasta Cinder'ile.

Käidi läbi veel üks keeruline olukord, töötades kõvaketastega. Süsteemi volume'i ei saanud serverist lahti ühendada.

Jälle väidab OpenStack, et ühendus on hävitatud ja nüüd saab volume'iga õigesti töötada. Kuid API keeldus kategooriliselt ketta operatsioonide teostamisest.

Siin otsustasime eriti mitte võidelda, vaid muuta oma vaadet teenuse toimimise loogikale. Kui instance on olemas, peab olema ka süsteemi volume. Seega ei saa kasutaja praegu süsteemset "ketast" kustutada või lahti ühendada, ilma et "serverit" kustutaks.

OpenStack on piisavalt keeruline süsteemide kompleks oma suhtlemisloogikaga ja keerulise API-ga. Meid aitab piisavalt detailne dokumentatsioon ja, loomulikult, meetod proovimisest ja eksimisest (kuhu ka ilma selleta ei saa).

Testkäivitus

Meie testkäivitus toimus eelmisel detsembril. Peamine ülesanne oli kontrollida meie projekti töötamist nii tehnilisest kui ka kasutajakogemuse (UX) aspektist. Vaatlejad kutsuti valikuliselt ja testimine oli suletud. Siiski, me jätsime võimaluse registreerida juurdepääs testimisele meie veebisaidil.

Isegi test ei möödunud ilma kummaliste hetkedeta, sest meie seiklused alles alustavad.

Esiteks hindasime projekti huvi veidi valesti ja pidime testimise ajal kiirelt lisama compute-node'e. Tavaline juhtum klastris, kuid ka siin olid nüansid. Konkreetse TF versiooni dokumentatsioonis on märgitud konkreetne tuumaversioon, millega vRouteri toimimist testiti. Otsustasime käivitada node'id uuemate tuumadega. Tulemuseks — TF ei saanud node'itelt marsruute. Pidi kiirelt tuumad tagasi kerima.

Teine kummaline juhtum on seotud isikliku konto parooli muutmise nupuga.

Otsustasime kasutada JWT-d juurdepääsu korraldamiseks isiklikule kontole, et mitte töötada sessioonide kallal. Kuna süsteemid on mitmekesised ja laialdaselt hajutatud, haldame oma tokenit, kuhu „pakime” sessioonid arveldamisest ja OpenStacki tokenist. Parooli muutmisel „kaob” token, kuna kasutaja andmed ei ole enam kehtivad ning see tuleb uuesti välja anda.

Me jättisime selle hetke tähelepanuta ning ressursse oli lihtsalt liiga vähe, et selle osa kiiresti juurde kirjutada. Olime sunnitud funktsionaalsuse lõikama vahetult enne testimise käivitamist.
Praegusel hetkel logime välja kasutaja, kui parooli on muudetud.

Hoolimata neist nüanssidest läks testimine hästi. Paari nädalaga külastas meid umbes 300 inimest. Õnnestus vaadata toodet kasutajate silmade kaudu, testida seda reaalses keskkonnas ja koguda kvaliteetset tagasisidet.

Jätkub

Paljudele meist on see esimeseks projektiks sellise ulatuse tõttu. Saime väärtuslikke õppetunde, kuidas meeskonnas töötada, arhitektuuri ja disainiotsuseid langetada. Kuidas integreerida keerulisi süsteeme piiratud ressursside korral ning viia need tootmisse.

Muidugi on nii koodi kui ka süsteemide integreerimise osas palju parandada. Projekt on piisavalt noor, kuid oleme täis ambitsioone kasvatada sellest usaldusväärne ja mugav teenus.

Süsteemidega oleme juba suutnud kokkuleppele jõuda. Bill askeldab usinalt arvestuste, arvete koostamise ja kasutajate päringutega oma ruumis. Tungsteni valkude "maagia" tagab meile stabiilse ühenduse. Ainult OpenStack üllatab meid vahel, karjudes midagi sellist nagu "'WSREP has not yet prepared node for application use." Aga see on juba hoopis teine lugu...

Hiljuti käivitasime teenuse.
Kõik üksikasjad leiate meie veebilehel.

CLO arendusmeeskond