Dok radite u IT-u, počinjete primjećivati da sustavi imaju svoj karakter. Mogu biti fleksibilni, tihi, ekscentrični i strogi. Mogu privući ili odbiti. Na ovaj ili onaj način, morate "pregovarati" s njima, manevrirati između "zamki" i graditi lance njihove interakcije.
Tako smo imali čast izgraditi platformu u oblaku, a za to smo trebali "nagovoriti" nekoliko podsustava da rade s nama. Srećom, imamo „API jezik“, izravne ruke i puno entuzijazma.
Ovaj članak neće biti tehnički hardcore, ali će opisati probleme na koje smo naišli tijekom izgradnje oblaka. Odlučio sam opisati naš put u obliku lagane tehničke fantazije o tome kako smo tražili zajednički jezik sa sustavima i što je iz toga ispalo.
Dobrodošli u mačku.
Početak putovanje
Naš tim je prije nekog vremena dobio zadatak pokrenuti cloud platformu za naše klijente. Imali smo podršku menadžmenta, resurse, sklop hardvera i slobodu u odabiru tehnologija za implementaciju softverskog dijela usluge.
Postojali su i brojni zahtjevi:
- usluga treba prikladan osobni račun;
- platforma mora biti integrirana u postojeći sustav naplate;
- softver i hardver: OpenStack + Tungsten Fabric (Open Contrail), koji su naši inženjeri naučili prilično dobro "kuhati".
Reći ćemo vam drugi put o tome kako je sastavljen tim, razvijeno sučelje osobnog računa i donesene odluke o dizajnu, ako Habrinu zajednicu zanima.
Alati koje smo odlučili koristiti:
- Python + Flask + Swagger + SQLAlchemy - potpuno standardni Python set;
- Vue.js za sučelje;
- Odlučili smo napraviti interakciju između komponenti i usluga koristeći Celery preko AMQP-a.
Predviđajući pitanja o odabiru Pythona, objasnit ću. Jezik je našao svoju nišu u našoj tvrtki i oko njega se razvila mala, ali ipak kultura. Stoga je odlučeno da se na njemu počne graditi usluga. Štoviše, brzina razvoja kod takvih problema često je presudna.
Dakle, započnimo naše upoznavanje.
Silent Bill - naplata
Ovog tipa poznajemo dugo. Uvijek je sjedio pored mene i šutke nešto brojao. Ponekad nam je prosljeđivao zahtjeve korisnika, izdavao račune klijentima i upravljao uslugama. Običan vrijedan momak. Istina, bilo je poteškoća. Šutljiv je, ponekad zamišljen, a često sam po sebi.
Billing je prvi sustav s kojim smo se pokušali sprijateljiti. A prva poteškoća s kojom smo se susreli bila je prilikom obrade usluga.
Na primjer, kada se izradi ili izbriše, zadatak ide u interni red čekanja za naplatu. Dakle, implementiran je sustav asinkronog rada s uslugama. Da bismo obradili naše vrste usluga, morali smo "staviti" svoje zadatke u ovaj red čekanja. I tu smo naišli na problem: nedostatak dokumentacije.
Sudeći prema opisu softverskog API-ja, još uvijek je moguće riješiti ovaj problem, ali nismo imali vremena za obrnuti inženjering, pa smo logiku iznijeli van i organizirali red čekanja zadataka na vrhu RabbitMQ-a. Operaciju na usluzi pokreće klijent sa svog osobnog računa, pretvara se u Celery "zadatak" na pozadini i izvodi se na strani naplate i OpenStacka. Celery čini vrlo praktičnim upravljanje zadacima, organiziranje ponavljanja i praćenje statusa. Više o “celeru” možete pročitati npr. .
Također, naplata nije zaustavila projekt koji je ostao bez novca. Komunicirajući s programerima, saznali smo da kod izračunavanja statistike (a upravo takvu logiku moramo implementirati) postoji složen međuodnos pravila zaustavljanja. Ali ti se modeli ne uklapaju dobro u našu stvarnost. Također smo ga implementirali kroz zadatke na Celeryju, prebacujući logiku upravljanja uslugom na pozadinsku stranu.
Oba gore navedena problema dovela su do toga da je kod postao malo napuhan i u budućnosti ćemo morati refaktorirati kako bismo logiku za rad sa zadacima premjestili u zasebnu uslugu. Također moramo pohraniti neke informacije o korisnicima i njihovim uslugama u našim tablicama kako bismo podržali ovu logiku.
Drugi problem je šutnja.
Billy tiho odgovara "U redu" na neke API zahtjeve. To je bio slučaj, na primjer, kada smo izvršili plaćanja obećanih plaćanja tijekom testa (više o tome kasnije). Zahtjevi su izvršeni ispravno i nismo vidjeli nikakve greške.
Morao sam proučavati zapisnike dok sam radio sa sustavom preko korisničkog sučelja. Ispostavilo se da sama naplata izvršava slične zahtjeve, mijenjajući opseg na određenog korisnika, na primjer, administratora, prosljeđujući ga u parametru su.
Općenito, unatoč prazninama u dokumentaciji i manjim nedostacima API-ja, sve je prošlo prilično dobro. Dnevnici se mogu čitati čak i pod velikim opterećenjem ako razumijete kako su strukturirani i što trebate tražiti. Struktura baze podataka je kićena, ali sasvim logična i na neki način čak i atraktivna.
Dakle, da rezimiramo, glavni problemi s kojima smo se susreli u fazi interakcije povezani su sa značajkama implementacije određenog sustava:
- nedokumentirane "osobine" koje su na nas utjecale na ovaj ili onaj način;
- zatvoreni izvor (naplata je napisana u C++), kao rezultat - nemoguće je riješiti problem 1 na bilo koji drugi način osim "pokušaja i pogrešaka".
Srećom, proizvod ima prilično opsežan API i integrirali smo sljedeće podsustave u naš osobni račun:
- modul za tehničku podršku - zahtjevi s vašeg osobnog računa "preusmjereni su" na transparentnu naplatu za klijente usluga;
- financijski modul - omogućuje izdavanje računa postojećim klijentima, otpis i generiranje dokumenata za plaćanje;
- servisni kontrolni modul - za ovo smo morali implementirati vlastiti rukovatelj. Proširivost sustava išla nam je na ruku i Billyja smo "naučili" novu vrstu usluge.
Bilo je malo gnjavaže, ali na ovaj ili onaj način, mislim da ćemo se Billy i ja slagati.
Šetnja poljima volframa – Tungsten Fabric
Volframova polja prošarana stotinama žica, kroz koje prolaze tisuće bitova informacija. Informacije se prikupljaju u "pakete", analiziraju, grade složene rute, kao čarolijom.
To je domena drugog sustava s kojim smo se morali sprijateljiti - Tungsten Fabric (TF), nekadašnji OpenContrail. Njegov zadatak je upravljanje mrežnom opremom, pružajući softversku apstrakciju nama kao korisnicima. TF - SDN, sažima složenu logiku rada s mrežnom opremom. Postoji dobar članak o samoj tehnologiji, npr. .
Sustav je integriran s OpenStackom (o čemu se govori u nastavku) putem dodatka Neutron.
Interakcija OpenStack servisa.
Dečki iz operativnog odjela upoznali su nas s tim sustavom. Koristimo API sustava za upravljanje mrežnim skupom naših usluga. Još nam nije uzrokovao ozbiljne probleme ili neugodnosti (ne mogu govoriti u ime momaka iz OE), ali je bilo nekih neobičnosti u interakciji.
Prvi je izgledao ovako: naredbe koje su zahtijevale ispis velike količine podataka na konzolu instance pri povezivanju preko SSH-a jednostavno su “zakačile” vezu, dok je preko VNC-a sve radilo ispravno.
Za one koji nisu upoznati s problemom, izgleda prilično smiješno: ls /root radi ispravno, dok se, primjerice, top potpuno "smrzne". Srećom, već smo se susretali sa sličnim problemima. Odlučeno je podešavanjem MTU-a na ruti od računalnih čvorova do usmjerivača. Usput, ovo nije TF problem.
Sljedeći problem bio je odmah iza ugla. U jednom “lijepom” trenutku, čarolija rutiranja je nestala, samo tako. TF je prestao upravljati usmjeravanjem na opremi.
S Openstackom smo radili od administrativne razine i nakon toga prešli na potrebnu korisničku razinu. Čini se da SDN "otima" opseg korisnika koji izvodi radnje. Činjenica je da se isti administratorski račun koristi za povezivanje TF-a i OpenStacka. U koraku prelaska na korisnika, “čarolija” je nestala. Odlučeno je stvoriti zaseban račun za rad sa sustavom. To nam je omogućilo rad bez prekidanja funkcionalnosti integracije.
Silikonski oblici života - OpenStack
Silikonsko stvorenje bizarnog oblika živi u blizini polja volframa. Prije svega, izgleda kao preraslo dijete koje nas jednim zamahom može zgaziti, ali iz njegove strane nema očite agresije. Ne izaziva strah, ali svojom veličinom izaziva strah. Kao i složenost onoga što se događa okolo.
OpenStack je srž naše platforme.
OpenStack ima nekoliko podsustava od kojih trenutno najaktivnije koristimo Nova, Glance i Cinder. Svaki od njih ima svoj API. Nova je odgovorna za računalne resurse i stvaranje instanci, Cinder je odgovoran za upravljanje volumenima i njihovim snimkama, Glance je slikovni servis koji upravlja OS predlošcima i metainformacijama na njima.
Svaka usluga radi u spremniku, a posrednik poruka je “bijeli zec” - RabbitMQ.
Ovaj sustav nam je zadao najneočekivanije probleme.
I prvi problem nije dugo čekao kada smo pokušali spojiti dodatni volumen na poslužitelj. Cinder API glatko je odbio izvršiti ovaj zadatak. Točnije, ako je vjerovati samom OpenStacku, veza je uspostavljena, ali unutar virtualnog poslužitelja nema diska.
Odlučili smo krenuti zaobilaznim putem i zatražili istu radnju od Nova API-ja. Rezultat je da se uređaj ispravno povezuje i da mu se može pristupiti unutar poslužitelja. Čini se da se problem javlja kada blok-pohrana ne reagira na Cinder.
Kod rada s diskovima čekala nas je još jedna poteškoća. Sistemski volumen nije se mogao odspojiti s poslužitelja.
Opet, sam OpenStack se "kune" da je uništio vezu i sada možete ispravno raditi s volumenom zasebno. Ali API kategorički nije želio izvoditi operacije na disku.
Tu smo se odlučili ne svađati posebno, nego promijeniti pogled na logiku servisa. Ako postoji instanca, mora postojati i volumen sustava. Stoga korisnik još ne može ukloniti ili onemogućiti "disk" sustava bez brisanja "poslužitelja".
OpenStack je prilično složen skup sustava s vlastitom logikom interakcije i kićenim API-jem. Pomaže nam prilično detaljna dokumentacija i, naravno, pokušaj i pogreška (gdje bismo bez toga).
Probni test
Probno smo lansiranje izveli u prosincu prošle godine. Glavni zadatak bio je testirati naš projekt u borbenom modu s tehničke i UX strane. Publika je selektivno pozvana i testiranje je zatvoreno. Međutim, također smo ostavili mogućnost da zatražite pristup testiranju na našoj web stranici.
Sam test, naravno, nije bio bez smiješnih trenutaka, jer tu naše avanture tek počinju.
Prvo, donekle smo krivo procijenili interes za projekt i morali smo brzo dodavati računalne čvorove tijekom testa. Uobičajen slučaj za klaster, ali i ovdje je bilo nekih nijansi. Dokumentacija za određenu verziju TF-a ukazuje na određenu verziju kernela na kojoj je testiran rad s vRouterom. Odlučili smo pokrenuti čvorove s novijim jezgrama. Kao rezultat toga, TF nije primio rute od čvorova. Morao sam hitno vratiti kernele.
Još jedna zanimljivost vezana je uz funkcionalnost gumba “promijeni lozinku” na vašem osobnom računu.
Odlučili smo koristiti JWT za organiziranje pristupa našem osobnom računu kako ne bismo radili sa sesijama. Budući da su sustavi raznoliki i široko raštrkani, upravljamo vlastitim tokenom, u koji "omatamo" sesije iz naplate i token iz OpenStacka. Kada se lozinka promijeni, token se, naravno, “pokvari”, budući da korisnički podaci više nisu valjani i treba ih ponovno izdati.
Izgubili smo ovu točku iz vida i jednostavno nije bilo dovoljno resursa da brzo završimo ovaj dio. Morali smo izrezati funkcionalnost neposredno prije pokretanja testa.
Trenutno odjavljujemo korisnika ako je lozinka promijenjena.
Unatoč ovim nijansama, testiranje je prošlo dobro. U par tjedana svratilo je oko 300 ljudi. Uspjeli smo pogledati proizvod očima korisnika, isprobati ga na djelu i prikupiti povratne informacije visoke kvalitete.
Da bi se nastavila
Mnogima od nas ovo je prvi projekt ovakvih razmjera. Naučili smo niz vrijednih lekcija o tome kako raditi kao tim i donositi arhitektonske i dizajnerske odluke. Kako integrirati složene sustave s malo resursa i uvesti ih u proizvodnju.
Naravno, postoji nešto na čemu treba raditi iu smislu koda i na sučeljima integracije sustava. Projekt je prilično mlad, ali puni smo ambicija prerasti u pouzdanu i praktičnu uslugu.
Već smo uspjeli uvjeriti sustave. Bill savjesno rješava brojanje, naplatu i zahtjeve korisnika u svom ormaru. “Čarolija” volframovih polja osigurava nam stabilnu komunikaciju. I samo OpenStack ponekad postaje hirovit, vičući nešto poput "'WSREP još nije pripremio čvor za korištenje aplikacije." Ali to je sasvim druga priča...
Nedavno smo pokrenuli uslugu.
Sve detalje možete saznati na našem .
CLO razvojni tim
korisni linkovi
OpenStack
Tkanina od volframa
Izvor: www.habr.com