S vremenom u IT-u počinješ primjećivati da sustavi imaju svoj karakter. Mogu biti pristupačni, tihi, kapriciozni, strogi. Mogu privlačiti ili odbijati. Tako ili onako, moraš «dogovarati» s njima, manevrirati između «podvodnih kamenčića» i graditi lance njihove interakcije.
Eto, i nama je pripala čast izgraditi cloud platformu, a za to je bilo potrebno «uvjeriti» par podsustava da rade s nama. Na sreću, imamo «jezik API», lijepe ruke i hrpu entuzijazma.
U ovom članku neće biti tehničkih hardcore tema, ali će biti opis problema s kojima smo se suočili prilikom izgradnje oblaka. Odlučio sam opisati naš put kao laganu tehničku fantaziju o tome kako smo tražili zajednički jezik sa sustavima i što je od toga proizašlo.
Dobrodošli ispod.
Početak puta
Nedavno je pred naš tim postavljen zadatak — pokrenuti cloud platformu za naše klijente. Imali smo podršku uprave, resurse, hardverski stog i slobodu u izboru tehnologija za realizaciju softverskog dijela usluge.
Bilo je i nekoliko zahtjeva:
- usluga treba imati jednostavno sučelje korisničkog računa;
- platforma mora biti integrirana u postojeći sustav naplate;
- softversko-hardverski dio: OpenStack + Tungsten Fabric (Open Contrail), koje su naši inženjeri naučili dovoljno dobro «pripremati».
O tome kako se okupila ekipa, razvijalo sučelje korisničkog računa i donosile dizajnerske odluke, pričat ćemo drugi put, ako zajednica Habr bude zainteresirana.
Alati koje smo odlučili koristiti:
- Python + Flask + Swagger + SQLAlchemy — potpuno standardni Python set;
- Vue.js za frontend;
- interakciju između komponenti i usluga odlučili smo raditi uz pomoć Celery preko AMQP.
Anticipirajući pitanja o izboru Pythona, pojasnit ću. Jezik je zauzeo svoju nišu u našoj tvrtki i oko njega se stvorila mala, ali ipak kultura. Stoga je odlučeno početi graditi uslugu baš na njemu. Tim više što brzina razvoja u takvim zadacima često igra ključnu ulogu.
Dakle, krenimo s našim upoznavanjem.
Tihi Bill — naplata
S ovim momkom poznajemo se već dugo. Uvijek je sjedio pored nas i nešto tiho računao. Ponekad nam je preusmjeravao korisničke zahtjeve, izdavao klijentima račune, upravljao uslugama. Običan radan momak. Istina, bilo je poteškoća. Bio je šutljiv, ponekad zamišljen i često — u svom svijetu.
Billing je prvi sustav s kojim smo pokušali ostvariti prijateljski odnos. I prva poteškoća naišla je tijekom obrade usluga.
Na primjer, prilikom kreiranja ili brisanja, zadatak pada u unutarnju queue billing sustava. Tako je implementiran sustav asinkronog rada s uslugama. Za obradu naših vrsta usluga morali smo "složiti" naše zadatke u tu queue. I ovdje smo se suočili s problemom: nedostatak dokumentacije.
Sudeći prema opisu softverskog API-ja, ovu zadaću je ipak moguće riješiti, ali nismo imali vremena za reverzno inženjerstvo, pa smo iznijeli logiku van i organizirali queue zadataka iznad RabbitMQ. Operacija nad uslugom inicira se od strane klijenta iz korisničkog sučelja, obavija se u "zadatak" Celery-ja na backendu i izvršava se na strani billing-a i OpenStack-a. Celery omogućuje prilično jednostavno upravljanje zadacima, organizaciju ponovnih izvršenja i praćenje stanja. Više o "celery"-ju može se pročitati, na primjer, .
Također, billing nije zaustavljao projekt kada su se novci potrošili. Razgovarajući s programerima, saznali smo da pri proračunu prema statistikama (a trebali smo implementirati upravo takvu logiku) postoji složena međusobna povezanost pravila zaustavljanja. No, ti modeli slabo odgovaraju našoj stvarnosti. Također smo implementirali putem zadataka na Celery-ju, prebacujući logiku upravljanja uslugama na backend.
Obje gore navedene poteškoće dovele su do toga da je kod malo narastao i da ćemo se u budućnosti morati posvetiti refaktoringu kako bismo iznijeli logiku upravljanja zadacima u zasebnu uslugu. Također moramo pohranjivati dio informacija o korisnicima i njihovim uslugama u vlastitim tablicama kako bismo podržali ovu logiku.
Još jedan problem — šutljivost.
Na dio zahtjeva prema API-ju Billy mlako odgovara "U redu". Tako je bilo, na primjer, kada smo vršili knjiženje obećanih uplata tijekom testiranja (o tome više kasnije). Zahtjevi su ispravno izvršavani i nismo vidjeli greške.
Morao sam proučiti logove dok sam radio sa sustavom putem sučelja. Isprva se pokazalo da sam billing izvodi takve zahtjeve, mijenjajući opseg na određenog korisnika, poput admina, proslijedivši ga u parametru su.
U cjelini, unatoč prazninama u dokumentaciji i malim greškama u API-ju, sve je prošlo dovoljno dobro. Logove je moguće pročitati čak i pri velikim opterećenjima, ako se razumije kako su strukturirani i što treba tražiti. Struktura baze podataka je kompleksna, ali sasvim logična i u nečemu čak i privlačna.
Dakle, da rezimiramo, glavni problemi s kojima smo se susreli tijekom interakcije vezani su uz specifičnosti implementacije određenog sustava:
- nedokumentirane "funkcije" koje su nas na ovaj ili onaj način pogodile;
- zatvoreni izvorni kodovi (billing je napisan u C++), kao posljedica — nemogućnost da se rješenje za problem 1 pronađe osim metodom "pokušaja i pogrešaka".
Srećom, proizvod ima dovoljno razvijen API i integrirali smo u svoj osobni račun sljedeće podsustave:
- modul tehničke podrške — zahtjevi iz osobnog računa se "proksiraju" u billing transparentno za klijente usluge;
- financijski modul — omogućuje izdavanje računa trenutnim klijentima, provođenje zaduženja i generiranje platnih dokumenata;
- modul za upravljanje uslugama — za njega smo morali implementirati svoj obradnik. Proširivost sustava nam je išla na ruku i "naučili" smo Billie novom tipu usluga.
Bilo je potrebno malo truda, ali mislim da ćemo se s Billijem snaći.
Šetnje po tungsten poljima — Tungsten Fabric
Tungsten polja, ispresijecana stotinama žica koje provode tisuće bitova informacija. Informacije se prikupljaju u "pakete", analiziraju se, gradeći složene rute, poput čarolije.
Ovo je područje drugog sustava s kojim smo se morali sprijateljiti — Tungsten Fabric (TF), bivši OpenContrail. Njegova je zadaća upravljanje mrežnom opremom, pružajući softversku apstrakciju nama, kao korisnicima. TF — SDN, uključuje složenu logiku upravljanja mrežnom opremom. O samoj tehnologiji postoji dobar članak, na primjer, .
Sustav je integriran s OpenStackom (o kojem ćemo govoriti u nastavku) putem Neutronovog dodatka.
Interakcija usluga OpenStack.
Ovaj sustav nam je predstavila ekipa iz operativnog odjela. Koristimo API sustava za upravljanje mrežnim okvirom naših usluga. Do sada nam nije uzrokovao ozbiljnije probleme ili neugodnosti, ali ne mogu govoriti u ime kolega iz OE. Međutim, bilo je i nekoliko neobičnih situacija tijekom suradnje.
Prvi je izgledao ovako: komande koje zahtijevaju ispis velikih količina podataka na konzolu instance pri povezivanju preko SSH jednostavno su "obješivale" vezu, dok je preko VNC sve radilo ispravno.
Za one koji nisu upoznati s problemom, to izgleda prilično smiješno: ls /root radi ispravno, dok top, na primjer, "smrzava" sustav. Na sreću, već smo se susreli s sličnim problemima. Riješeno je podešavanjem MTU-a na putu od compute čvorova do usmjerivača. Usput, to i nije problem TF-a.
Sljedeći problem čekao je iza ugla. U jedan "predivan" trenutak, čarolija usmjeravanja je nestala, tako jednostavno. TF je prestao upravljati usmjeravanjem na opremi.
Radili smo s Openstack s razine admina i nakon toga prelazili na razinu potrebnog korisnika. SDN, čini se, "presreće" opseg korisnika s kojim se izvršavaju radnje. Stvar je u tome što se taj isti admin račun koristi za povezivanje TF-a i OpenStacka. Tijekom prebacivanja na korisnički račun, "čarolija" je nestajala. Rješenje je bilo otvoriti odvojeni račun za rad sa sustavom. To je omogućilo rad bez narušavanja funkcionalnosti integracije.
Silicijski oblici života — OpenStack
Silicijsko biće neobičnog oblika živi nedaleko od wolframovih polja. Najviše nalikuje prekomjernom djetetu koje jednim zamahom može zgnječiti nas, ali ne pokazuje očitu agresiju. Ne izaziva strah, ali njegove dimenzije stvaraju zabrinutost. Kao i složenost onoga što se događa oko njega.
OpenStack — jezgra naše platforme.
OpenStack ima nekoliko podsustava, od kojih najviše koristimo Nova, Glance i Cinder. Svaki od njih ima svoj API. Nova je odgovorna za compute resurse i kreiranje instanci, Cinder za upravljanje volumenima i njihovim snimcima, dok je Glance usluga za slike koja upravlja predlošcima operativnih sustava i metapodacima vezanim uz njih.
Svaka usluga pokreće se u kontejneru, a posrednik poruka je "beli zec" — RabbitMQ.
Ovaj sustav nam je najviše donio iznenađujućih problema.
Prvi problem nije iznenadio kada smo pokušali povezati dodatni volumen s poslužiteljem. Cinder API kategorički je odbio izvršiti ovu radnju. Drugim riječima, ako vjerujemo OpenStacku, veza je uspostavljena, ali unutar virtualnog poslužitelja uređaj diska nedostaje.
Odlučili smo "ići naokolo" i zatražili istu radnju putem Nova API-ja. Rezultat — uređaj se ispravno povezuje i dostupan je unutar poslužitelja. Čini se da problem nastaje kada block-storage ne odgovara Cinderu.
Još jedna poteškoća čekala nas je pri radu s diskovima. Nije bilo moguće odvojiti sistemski volumen od poslužitelja.
Ponovno, sam OpenStack "jamči" da je veza uklonjena i da sada možemo ispravno raditi s volumenom zasebno. No, API kategorički nije želio izvesti operacije nad diskom.
Ovdje smo odlučili posebno se ne boriti, već promijeniti pogled na logiku rada usluge. Ako postoji instance, trebao bi postojati i sistemski volumen. Stoga korisnik trenutno ne može izbrisati ili isključiti sistemski "disk" bez brisanja "poslužitelja".
OpenStack je dovoljno složen kompleks sustava s vlastitom logikom interakcije i zamršenim API-jem. Pomoć nam pruža dovoljno detaljna dokumentacija i, naravno, metod probanja i grešaka (kuda bi bez njega).
Testno pokretanje
Testno pokretanje provodili smo u prosincu prošle godine. Glavni cilj bio je provjeriti u realnim uvjetima naš projekt s tehničke strane i s aspekta UX-a. Publiku smo pozivali selektivno, a testiranje je bilo zatvoreno. No, također smo ostavili mogućnost za traženje pristupa testiranju na našoj web stranici.
Sam test, naravno, nije prošao bez nezgoda, jer su tu naše avanture tek počele.
Prvo, malo smo pogrešno procijenili interes za projekt i morali smo brzo dodavati compute čvorove tijekom testa. Uobičajen slučaj za klaster, no tu su također bili i detalji. U dokumentaciji za određenu verziju TF-a navedena je točna verzija jezgre na kojoj je testirano djelovanje s vRouterom. Odlučili smo pokretati čvorove s novijim jezgrama. Kao rezultat — TF nije dobio rute s čvorova. Morali smo hitno vraćati jezgre.
Druga nezgoda povezana je s funkcionalnošću gumba "izmijeni lozinku" u korisničkom sučelju.
Odlučili smo koristiti JWT za organizaciju pristupa korisničkom sučelju kako bismo izbjegli rad s sesijama. S obzirom na to da su sustavi raznoliki i široko rasprostranjeni, upravljamo vlastitim tokenom u koji «umotavamo» sesije iz billing sustava i token iz OpenStack-a. Kada se password promijeni, token, naravno, «izgubi na važnosti», budući da su korisnički podaci već nevažeći i treba ih ponovno izdati.
Propustili smo ovaj trenutak, a resursa za brzo dopisivanje ovog dijela jednostavno nije bilo dovoljno. Morali smo izrezati funkcionalnost neposredno prije nego što smo otišli u testiranje.
Trenutno izlazimo iz sustava korisnika ako je password promijenjen.
Unatoč tim nijansama, testiranje je prošlo dobro. Tijekom nekoliko tjedana, oko 300 ljudi posjetilo nas je. Uspjeli smo pogledati proizvod očima korisnika, testirati ga u akciji i prikupiti kvalitetan feedback.
Nastavlja se
Za mnoge od nas ovo je prvi projekt ovakvog opsega. Izvukli smo nekoliko dragocjenih lekcija o tome kako raditi u timu, donositi arhitektonske i dizajnerske odluke. Kako integrirati složene sustave s ograničenim resursima i implementirati ih u produkciju.
Naravno, ima prostora za rad i na planu koda, kao i na razmaku između integracije sustava. Projekat je još mlad, ali puni smo ambicija da iz njega izgradimo pouzdanu i korisnu uslugu.
Već smo uspjeli nagovoriti sustave. Bill poslušno obračunava, izdaje račune i odgovara na korisničke upite iz svoje prostorije. «Čarolija» volframovih polja osigurava nam stabilnu vezu. I samo OpenStack ponekad pravi probleme, vičući nešto poput «’WSREP has not yet prepared node for application use». Ali to je sasvim druga priča...
Nedavno smo pokrenuli uslugu.
Sve detalje možete saznati na našem .
Razvojni tim CLO
Koristitne veze
OpenStack
Tungsten Fabric
Izvor: habr.com
