🥇Pilveteenuse loomise lugu, maitsestatud küberpunkiga

IT-algusesse astudes hakkad märkama, et süsteemidel on oma iseloom. Need võivad olla sõbralikud, vaiksed, kapriissed või karmid. Need võivad meeldida või pigem tõukavad eemale. Niisiis peame „kokkuleppele“ jõudma, vältima „alateid“ ja looma nendevahelisi sidemeid.

Nüüd on meil au ehitada pilveplatvorm ja selle jaoks pidime „veenduma“ paari alamsüsteemi töötama meiega. Õnneks on meil olemas „API keel“, osavad käed ja hunnik entusiasmi.

Selles artiklis ei ole mingit tehnilist hardcore'i, vaid räägime probleemidest, millega me silmitsi seisime pilve loomise protsessis. Otsustasin kirjeldada meie teekonda kerge tehnilise fantaasiana selle kohta, kuidas me ühe keele leidmiseks süsteemidega kokku leppisime ja mis sellest välja tuli.

Tere tulemast edasi lugema.

Teekonna algus

Mõni aeg tagasi seati meie meeskonnale ülesanne – luua pilveplatvorm meie klientidele. Meil olid juhitöötajate toetused, ressursid, riistvarakogum ja vabadus valida tehnoloogiaid rakenduse arendamiseks.

Sealjuures oli ka mõned nõudmised:

teenusele on vajalik mugav isiklik konto;
platvorm peab olema integreeritud olemasoleva arveldamise süsteemiga;
programmi- ja riistvaragrupi kombinatsioon: OpenStack + Tungsten Fabric (Open Contrail), mille meie insenerid on piisavalt hästi „valmistama“ õppinud.

Kuidas me meeskonna kokku panime, arendasime isiklikku konto liidest ja tegime disainilisi otsuseid, räägime mõnel teisel korral, kui hubarate kogukonnal on huvi.
Tööriistad, mida me otsustasime kasutada:

Python + Flask + Swagger + SQLAlchemy – täiesti tavaline Python’i komplekt;
Vue.js koduosas;
komponentide ja teenuste vahelise suhtluse tegime läbi Celery AMQP peal.

Küsimuste vältimiseks, miks valida Python, selgitan. Keel on leidnud oma niši meie ettevõttes ja selle ümber on kujunenud väike, kuid siiski kultuur. Seetõttu otsustasime alustada teenuse ehitamist just sellel. Eriti kuna nende ülesannete puhul mängib arenduse kiirus tihti suurt rolli.

Nii et alustame meie tutvustamist.

Vaikne Bill – arveldamine

Me oleme selle kuttiga pikka aega tuttavad. Ta istus alati kõrval ja luges midagi vaikselt. Mõnikord suunas ta meile kasutajate päringud, koostas klientide arveid, haldas teenuseid. Tavaline töökas poiss. Tõsi, olid ka raskused. Ta on vaikne, mõnikord mõtlemapanev ja sageli — oma mõtetes.

Arveldussüsteem on esimene süsteem, millega me üritasime tutvuda. Ja esimene probleem tuli meile vastu teenuste töötlemisel.

Näiteks, teenuste loomisel või kustutamisel, satub ülesanne arveldussüsteemi sisejärjekorda. Nii on ellu viidud asünkroonse töötlemise süsteem teenustega. Oma teenuste tüüpide töötlemiseks pidime «kokku panema» oma ülesanded sellesse järjekorda. Ja siin seisis meil probleem: dokumentatsiooni puudumine.

Programm API kirjelduse põhjal on selle ülesande lahendamine siiski võimalik, kuid meil ei olnud aega tagasiotsingu tegemiseks, seetõttu viisime loogika välja ja korraldasime ülesande järjekorra RabbitMQ peal. Teenuse operatsioon algatatakse kliendi poolt isiklikust kabinetist, mähitakse «ülesandeks» Celery backendis ja täidetakse arveldussüsteemis ja OpenStackis. Celery võimaldab üsna mugavalt ülesandeid hallata, korraldada kordusi ja jälgida olekut. Täiendavat teavet «selleri» kohta saab lugeda näiteks, siin.

Lisaks ei peatunud arveldussüsteem projekt, millel raha otsa sai. Suheldes arendajatega, selgitasime, et statistika arvutamisel (ja me peame just seda loogikat ellu viima) on keeruline peatamisreeglite omavaheline seos. Kuid need mudelid ei sobi meie tingimustega. Samuti rakendasime selle Celery ülesannete kaudu, viies tagasiendisse teenuste juhtimise loogika.

Kaks ülaltoodud probleemi viisid selleni, et kood paisus natuke ja tulevikus peame tegelema refaktoreerimisega, et välja tuua teenuste ülesannete töötlemise loogika eraldi teenusesse. Me peame ka salvestama osa teavet kasutajate ja nende teenuste kohta oma tabelitesse, et toetada seda loogikat.

Veel üks probleem — vaikimine.

Osadele API päringutele vastab Billy vaikselt «Ok». Näiteks juhtus see, kui me tegime lubatud maksete sissemakseid testimisperioodi ajal (millest hiljem). Päringud täideti korrektselt ja me ei näinud mingeid vigu.

Pidin uurima logisid, töötades süsteemiga läbi kasutajaliidese. Selgus, et arveldamine teeb selliseid päringuid, muutes scope'i konkreetse kasutaja, näiteks admin, jaoks ja edastades selle su parameetris.

Kokkuvõttes, vaatamata dokumentatsiooni puudustele ja mõningatele API viperustele, läks kõik piisavalt hästi. Logisid on täiesti võimalik lugeda isegi suure koormuse korral, kui mõista, kuidas need on üles ehitatud ja mida otsida. Andmebaasi struktuur on kätkeline, kuid täiesti loogiline ja mõnes mõttes isegi atraktiivne.

Seega, kokkuvõtteks, peamised probleemid, millega me silmitsi seisisime koosteetapis, olid seotud konkreetse süsteemi teostuse eripäradega:

dokumenteerimata 'funktsioonid', mis mingil moel meid puudutasid;
suletud allikakood (arveldamine on kirjutatud C++), mille tulemusena ei olnud võimalik probleemi lahendada muul viisil kui 'katse-eksituse' meetodil.

Õnneks on tootest piisavalt ulatuslik API ja integreerisime oma isiklikku kabinetti järgmised alamsüsteemid:

tehnilise toe moodul — päringud isiklikust kabinetist ‘proksitakse’ arveldamisse klientide teenuste jaoks läbipaistvalt;
rahandusmoodul — võimaldab koostada arveid praegustele klientidele, teostada makseid ja vormistada maksedokumente;
teenuse haldamise moodul — selle jaoks pidime ellu viima oma töötleja. Süsteemi laiendatavus aitas meid ja me 'koolitasime' Billit uue teenustüübi jaoks.
Pidin veidi vaeva nägema, kuid nii või teisiti, arvan, et Billiga saame me läbi.

Käigud volframi väljade vahel — Tungsten Fabric

Volframi väljad, mis on kaetud sadade juhtmetega, mis edastavad läbi end tuhat bitsi teavet. Teave kogutakse 'pakettidesse', dekodeeritakse, luues keerulisi marsruute, nagu maagia.

See on teise süsteemi valdus, millega meie pidime sõbrune ma — Tungsten Fabric (TF), endine OpenContrail. Selle ülesanne on juhtida võrgu seadmeid, pakkudes meile, kasutajatena, programmilise abstraktsiooni. TF — SDN, kapseldab endas keerulise loogika töötamiseks võrgu seadmetega. Tehnoloogia kohta on olemas hea artikkel, näiteks, siit.

Süsteem on integreeritud OpenStackiga (millest räägime allpool) Neutrona pistiku kaudu.

OpenStacki teenuste vahelise suhtluse.

Selle süsteemiga tutvustasid meid teeninduse töötajad. Kasutame süsteemi API-d oma teenuste võrguhnaku haldamiseks. Serious problems or inconveniences have not been posed so far (I cannot speak for the service guys), but there were some amusing interactions.

Esimene probleem nägi välja järgmine: SSH-i kaudu ühendatud instantsi konsoolile suuri andmemahtusid nõudvad käsud lihtsalt „kukutasid“ ühenduse, samas kui VNC kaudu töötas kõik korrektselt.

Neile, kes ei tunne probleemi, näeb see üsna naljakas välja: ls /root töötab korrektselt, samas kui näiteks top „hangub“ täielikult. Õnneks oleme selliste probleemidega juba kokku puutunud. Probleem lahendati MTU häälestamise kaudu marsruudil compute-node'ide ja marsruuterite vahel. Rääkides, see ei ole probleemi TF.

Järgmine probleem ootas nurga taga. Ühel „ilusas“ hetkel kadus marsruutimise maagia, nii lihtsalt. TF lõpetas seadmete marsruutimise haldamise.

Töötasime OpenStackiga administraatori tasemelt ja seejärel läksime soovitud kasutaja tasemele. SDN, tundub, „püüab kinni“ kasutaja ulatuse, millega teostatakse toimingud. Asi on selles, et sama administraatori kontot kasutatakse TF ja OpenStacki vaheliseks suhtlemiseks. Kasutaja peale ülemineku hetkel kadus „maagia“. Lahenduseks oli seadistada eraldi konto süsteemiga töötamiseks. See lubas töötada, rikkumata integreerimise funktsionaalsust.

Silicon Life Forms — OpenStack

Silicon Victim of Strange Form elab lähedal volframiväljadele. See sarnaneb enim ülekaalulise lapsega, kes ühe käeliigutusega võib meid ära purustada, kuid otsest agressiivsust ei näita. See ei tekita hirmu, kuid selle suurus tekitab muret. Nii nagu keerukus, mis toimub ümberringi.

OpenStack on meie platvormi süda.

OpenStackil on mitmeid alamsüsteeme, millest me seni aktiivsemalt kasutame Nova, Glance ja Cinder. Igal neist on oma API. Nova vastutab arvutusressursside ja instance'ide loomise eest, Cinder haldab mahtusid ja nende pilte, Glance on image service, mis haldab OS malle ja nende metaandmeid.

Iga teenus käivitatakse konteineris ja sõnumibrokerina toimib „valge küülik“ — RabbitMQ.

See süsteem on meile toonud kõige rohkem ootamatuid muresid.

Ja esimene probleem ei lasknud end kaua oodata, kui proovisime lisamaht serverisse ühendada. Cinder API keeldus kategooriliselt selle ülesande täitmisest. Tegelikult, kui uskuda OpenStack'i, luuakse ühendus, kuid virtuaalses serveris ei leidu ketaseadet.

Otsustasime "ümber käia" ja küsisime sama toimingut Nova API-lt. Tulemuseks on see, et seade ühendatakse korrektselt ja on serveris saadaval. Tundub, et probleem tekib siis, kui block-storage ei vasta Cinder'ile.

Uus keerukus ootas meid töödes ketastega. Süsteemi mahtu ei õnnestunud serverist eemaldada.

Taaskord kinnitab OpenStack, et ta on ühenduse hävitanud ja nüüd saab mahtu eraldi korralikult kasutada. Kuid API keeldus kategooriliselt ketastega operatsioonide teostamisest.

Siin otsustasime eriti mitte sõdida, vaid muuta arusaama teenuse töölogikast. Kui instance on olemas, peaks olema ka süsteemimaht. Seetõttu ei saa kasutaja praegu eemaldada või välja lülitada süsteemi "ketast", eemaldamata "serverit".

OpenStack on piisavalt keeruline süsteemide kompleks oma suhtlemislogikaga ja keeruka API-ga. Meid aitab piisavalt detailsed dokumentatsioon ja loomulikult katse-eksitusmeetod (kuidas siis muidu).

Testkäivitamine

Testkäivitust tegime möödunud aasta detsembris. Peamine eesmärk oli meie projekti tehnilise külje ja UX poole kontrollimine reaalses keskkonnas. Kutsusime publikust valikuliselt ja testimine oli suletud. Küll aga jätsime ka võimaluse küsida ligipääsu testimisele meie veebisaidil.

Isegi test ei möödunud ilma naljakatest momentidest, sest just siin meie seiklused alles algavad.

Esiteks, me hindasime projekti huvi mõnevõrra ebatäpselt ja pidime testimise ajal kiiresti lisama compute-node' s. Tavaline juhtum klastris, kuid ka siin oli nüansse. Konkreetse TF versiooni dokumentatsioonis on märgitud konkreetne kerneliversioon, millel testiti vRouteri töö. Otsustasime käivitada node'id uuemate kernelitega. Tulemuseks — TF ei saanud node'lt marsruute. Pidi kiiresti kernelid tagasi tegema.

Teine naljakas moment on seotud "muuda parool" nupu funktsionaalsusega isiklikus kabinetis.

Me otsustasime kasutada JWT süsteemi juurdepääsu korraldamiseks kasutajaliidesele, et mitte töötada sessioonidega. Kuna süsteemid on erinevad ja laiali valgussenud, haldame oma tokenit, kuhu "pakime" arvelduste sessioonid ja OpenStacki tokeni. Parooli muutmisel token, mõistagi, "aegub", kuna kasutaja andmed ei ole enam kehtivad ja seda tuleb uuesti välja anda.

Me ei märganud seda hetke ja meil polnud lihtsalt ressursse, et kiiresti see osa valmis kirjutada. Meil tuli funktsionaalsus lõigata vahetult enne testimise alustamist.
Praegu logime välja kasutaja, kui parool on muudetud.

Vaatamata nendele nüanssidele läks testimine hästi. Paari nädala jooksul külastas meid umbes 300 inimest. Meil õnnestus vaadata toodet kasutajate silmade läbi, testida seda reaalses olukorras ja koguda kvaliteetset tagasisidet.

Jätkub

Paljudele meist on see esimene projekt sellises mastaabis. Saime mitmeid väärtuslikke õppetunde, kuidas meeskonnas töötada, arhitektuurilisi ja disainilisi otsuseid teha. Kuidas integreerida keerulisi süsteeme väikeste ressurssidega ja neid tootmisse väljastada.

Muidugi on palju, millega tegeleda nii koodi kui ka süsteemide integratsiooni lõikes. Projekt on piisavalt noor, kuid oleme täis ambitsioone kasvatada sellest usaldusväärne ja mugav teenus.

Süsteemidega oleme juba suutnud leppida. Bill teeb usalduslikult arvestusi, arveid ja kasutajate päringuid oma tagatoas. "Karma" volframi väljad tagavad meile stabiilse ühenduse. Ainult OpenStack mõnikord vingub, hüüdes midagi nagu „'WSREP has not yet prepared node for application use”. Kuid see on hoopis teine lugu…

Hiljuti käivitasime teenuse.
Kogu teabe leiate meie veebisaidil.

CLO arendustiim