Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Dok radite u IT-u, počinjete da primjećujete da sistemi imaju svoj karakter. Mogu biti fleksibilni, tihi, ekscentrični i strogi. Mogu privući ili odbiti. Na ovaj ili onaj način, sa njima morate „pregovarati“, manevrisati između „zamki“ i graditi lance njihove interakcije.

Tako smo imali čast da izgradimo platformu u oblaku, a za to smo morali da „ubedimo“ nekoliko podsistema da rade sa nama. Srećom, imamo „API jezik“, direktne ruke i puno entuzijazma.

Ovaj članak neće biti tehnički hardcore, ali će opisati probleme na koje smo naišli prilikom izgradnje oblaka. Odlučio sam da opišem naš put u obliku lagane tehničke fantazije o tome kako smo tražili zajednički jezik sa sistemima i šta je iz toga proizašlo.

Dobrodošli u mačku.

Početak putovanja

Prije nekog vremena, naš tim je dobio zadatak da pokrene cloud platformu za naše klijente. Imali smo podršku menadžmenta, resurse, hardverski stog i slobodu u izboru tehnologija za implementaciju softverskog dijela usluge.

Postojao je i niz zahtjeva:

  • za uslugu je potreban zgodan lični račun;
  • platforma mora biti integrisana u postojeći sistem naplate;
  • softver i hardver: OpenStack + Tungsten Fabric (Open Contrail), koji su naši inženjeri naučili da "kuvaju" prilično dobro.

Reći ćemo vam drugi put o tome kako je sastavljen tim, razvijen interfejs ličnog naloga i donešene su dizajnerske odluke, ako je Habra zajednica zainteresovana.
Alati koje smo odlučili koristiti:

  • Python + Flask + Swagger + SQLAlchemy - potpuno standardni Python set;
  • Vue.js za frontend;
  • Odlučili smo da napravimo interakciju između komponenti i usluga koristeći Celery preko AMQP-a.

Očekujući pitanja o odabiru Pythona, objasnit ću. Jezik je našao svoju nišu u našoj kompaniji i oko njega se razvila mala, ali ipak kultura. Stoga je odlučeno da se na njemu počne graditi servis. Štaviše, brzina razvoja takvih problema često je odlučujuća.

Dakle, počnimo naše upoznavanje.

Tihi račun - naplata

Poznajemo ovog momka dugo vremena. Uvijek je sjedio pored mene i nečujno nešto brojao. Ponekad nam je prosljeđivao zahtjeve korisnika, izdavao račune klijentima i upravljao uslugama. Običan vredan momak. Istina, bilo je poteškoća. On je ćutljiv, ponekad zamišljen i često samostalan.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Naplata je prvi sistem sa kojim smo pokušali da se sprijateljimo. I prva poteškoća na koju smo naišli bila je prilikom obrade usluga.

Na primjer, kada se kreira ili izbriše, zadatak ide u interni red naplate. Tako je implementiran sistem asinhronog rada sa servisima. Da bismo obrađivali naše tipove usluga, morali smo da "stavimo" naše zadatke u ovaj red čekanja. I tu smo naišli na problem: nedostatak dokumentacije.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Sudeći po opisu softverskog API-ja, ovaj problem je još uvijek moguće riješiti, ali nismo imali vremena za obrnuti inženjering, pa smo logiku iznijeli van i organizirali red zadataka na vrhu RabbitMQ-a. Operaciju na servisu pokreće klijent sa svog ličnog naloga, pretvara se u Celery „zadatak“ na backend-u i izvodi se na strani naplate i OpenStack-a. Celer ga čini prilično zgodnim za upravljanje zadacima, organiziranje ponavljanja i praćenje statusa. Možete pročitati više o "celeru", npr. ovdje.

Takođe, naplata nije zaustavila projekat koji je ostao bez novca. U komunikaciji sa programerima, otkrili smo da prilikom izračunavanja statistike (a moramo implementirati upravo ovakvu logiku) postoji složena međusobna povezanost pravila zaustavljanja. Ali ovi modeli se ne uklapaju dobro u našu stvarnost. Također smo ga implementirali kroz zadatke na Celeryju, prevodeći logiku upravljanja uslugama na pozadinu.

Oba gore navedena problema dovela su do toga da je kod postao malo naduvan i u budućnosti ćemo morati da ga refaktoriramo kako bismo logiku za rad sa zadacima prebacili u poseban servis. Također moramo pohraniti neke informacije o korisnicima i njihovim uslugama u našim tabelama kako bismo podržali ovu logiku.

Drugi problem je tišina.

Billy tiho odgovara "OK" na neke API zahtjeve. To je bio slučaj, na primjer, kada smo izvršili plaćanja obećanih plaćanja tokom testa (više o tome kasnije). Zahtjevi su izvršeni korektno i nismo vidjeli nikakve greške.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Morao sam da proučavam dnevnike dok sam radio sa sistemom preko korisničkog interfejsa. Pokazalo 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.

Generalno, uprkos 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 tražiti. Struktura baze podataka je kitnjasta, ali sasvim logična i na neki način čak i atraktivna.

Dakle, da rezimiramo, glavni problemi na koje smo naišli u fazi interakcije odnose se na karakteristike implementacije određenog sistema:

  • nedokumentovane “karakteristike” koje su uticale na nas na ovaj ili onaj način;
  • zatvorenog koda (naplata je napisana u C++), kao rezultat - nemoguće je riješiti problem 1 na bilo koji drugi način osim "pokušajem i greškom".

Na sreću, proizvod ima prilično opsežan API i integrirali smo sljedeće podsisteme u naš lični račun:

  • modul tehničke podrške - zahtjevi sa vašeg ličnog računa se „proksiraju“ na transparentno naplatu za klijente usluge;
  • finansijski modul - omogućava vam da ispostavljate račune trenutnim klijentima, vršite otpise i generišete dokumente za plaćanje;
  • servisni kontrolni modul - za to smo morali implementirati vlastiti rukovatelj. Proširivost sistema nam je išla na ruku i Bilija smo „naučili“ novoj vrsti usluge.
    Bilo je to malo muke, ali na ovaj ili onaj način, mislim da ćemo se Bili i ja slagati.

Šetnja po poljima volframa – Tungsten Fabric

Polja volframa prošarana stotinama žica, prolazeći kroz njih hiljade bitova informacija. Informacije se skupljaju u „pakete“, raščlanjuju, grade složene rute, kao magijom.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Ovo je domen drugog sistema sa kojim smo morali da se sprijateljimo - Tungsten Fabric (TF), ranije OpenContrail. Njegov zadatak je da upravlja mrežnom opremom, pružajući apstrakciju softvera nama kao korisnicima. TF - SDN, obuhvata složenu logiku rada sa mrežnom opremom. Postoji dobar članak o samoj tehnologiji, npr. ovdje.

Sistem je integrisan sa OpenStack-om (o kome se govori u nastavku) preko Neutron dodatka.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom
Interakcija OpenStack servisa.

Momci iz operativnog odjela su nas upoznali sa ovim sistemom. Koristimo sistemski API za upravljanje mrežnim stogom naših usluga. To nam još nije izazvalo ozbiljne probleme ili neugodnosti (ne mogu govoriti u ime momaka iz OE), ali je bilo nekih neobičnosti u interakciji.

Prvi je izgledao ovako: komande koje su zahtijevale izlaz velike količine podataka na konzolu instance pri povezivanju preko SSH-a jednostavno su „opustile“ vezu, dok je preko VNC-a sve funkcionisalo kako treba.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Za one koji nisu upoznati s problemom, to izgleda prilično smiješno: ls /root radi ispravno, dok se, na primjer, top potpuno "zamrzne". Srećom, već smo se susreli sa sličnim problemima. Odlučeno je podešavanjem MTU-a na ruti od računarskih čvorova do rutera. Inače, ovo nije TF problem.

Sljedeći problem je bio iza ugla. U jednom „lijepom“ trenutku nestala je magija rutiranja, tek tako. TF je prestao upravljati usmjeravanjem na opremi.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Sa Openstack-om smo radili od administratorskog nivoa i nakon toga prešli na potreban korisnički nivo. Čini se da SDN “otima” opseg korisnika koji izvršavaju radnje. Činjenica je da se isti administratorski račun koristi za povezivanje TF-a i OpenStack-a. U koraku prelaska na korisnika, “magija” je nestala. Odlučeno je da se kreira poseban nalog za rad sa sistemom. To nam je omogućilo da radimo bez narušavanja funkcionalnosti integracije.

Silicijumski oblici života - OpenStack

Silikonsko stvorenje bizarnog oblika živi u blizini volframovih polja. Najviše od svega liči na preraslo dijete koje nas jednim zamahom može zgnječiti, ali od njega nema očigledne agresije. Ne izaziva strah, ali njegova veličina izaziva strah. Kao i kompleksnost onoga što se dešava okolo.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

OpenStack je srž naše platforme.

OpenStack ima nekoliko podsistema, od kojih trenutno najaktivnije koristimo Novu, Glance i Cinder. Svaki od njih ima svoj API. Nova je odgovorna za računarske resurse i kreiranje instanci, Cinder je odgovoran za upravljanje volumenima i njihovim snimcima, Glance je usluga slika koja upravlja predlošcima OS-a i metainformacijama o njima.

Svaki servis radi u kontejneru, a posrednik poruka je “bijeli zec” - RabbitMQ.

Ovaj sistem nam je zadao najneočekivanije probleme.

I prvi problem nije dugo čekao kada smo pokušali da povežemo dodatni volumen na server. Cinder API je glatko odbio izvršiti ovaj zadatak. Tačnije, ako vjerujete samom OpenStack-u, veza je uspostavljena, ali nema disk uređaja unutar virtuelnog servera.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Odlučili smo da skrenemo i zatražili istu akciju od Nova API-ja. Rezultat je da se uređaj ispravno povezuje i da je dostupan unutar servera. Čini se da se problem javlja kada block-storage ne reaguje na Cinder.

Još jedna poteškoća čekala nas je pri radu sa diskovima. Sistemski volumen nije mogao biti prekinut sa serverom.

Opet, sam OpenStack se "kune" da je uništio vezu i sada možete ispravno raditi sa volumenom odvojeno. Ali API kategorički nije želio obavljati operacije na disku.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Ovdje smo odlučili da se ne svađamo posebno, već da promijenimo pogled na logiku servisa. Ako postoji instanca, mora postojati i sistemski volumen. Stoga korisnik još ne može ukloniti ili onemogućiti sistemski “disk” a da ne izbriše “server”.

OpenStack je prilično složen skup sistema sa sopstvenom logikom interakcije i ukrašenim API-jem. Pomaže nam prilično detaljna dokumentacija i, naravno, pokušaji i greške (gdje bismo bili bez nje).

Test run

Probno lansiranje izveli smo u decembru prošle godine. Glavni zadatak je bio da testiramo naš projekat u borbenom režimu sa tehničke strane i sa strane UX. Publika je pozvana selektivno i testiranje je zatvoreno. Međutim, također smo ostavili opciju da zatražimo pristup testiranju na našoj web stranici.

Sam test, naravno, nije prošao bez smiješnih momenata, jer tu naše avanture tek počinju.

Prvo, donekle smo pogrešno procenili interesovanje za projekat i morali smo da brzo dodamo računarske čvorove upravo tokom testa. Uobičajen slučaj za klaster, ali i ovdje je bilo nekih nijansi. Dokumentacija za određenu verziju TF-a označava specifičnu verziju kernela na kojoj je testiran rad sa vRouterom. Odlučili smo da pokrenemo čvorove sa novijim kernelima. Kao rezultat toga, TF nije primio rute od čvorova. Morao sam hitno da vratim jezgra.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Još jedna zanimljivost je vezana za funkcionalnost dugmeta „promeni lozinku“ na vašem ličnom nalogu.

Odlučili smo koristiti JWT da organiziramo pristup našem ličnom računu kako ne bismo radili sa sesijama. Pošto su sistemi raznoliki i široko rasuti, mi upravljamo sopstvenim tokenom, u koji „premotavamo“ sesije od naplate i tokena iz OpenStack-a. Kada se lozinka promijeni, token se, naravno, „pokvari“, pošto korisnički podaci više ne vrijede i treba ih ponovo izdati.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom

Izgubili smo ovu tačku iz vida i jednostavno nije bilo dovoljno resursa da brzo završimo ovaj komad. Morali smo isključiti funkcionalnost neposredno prije pokretanja testa.
Trenutno odjavljujemo korisnika ako je lozinka promijenjena.

Uprkos ovim nijansama, testiranje je prošlo dobro. Za nekoliko sedmica svratilo je oko 300 ljudi. Uspjeli smo pogledati proizvod očima korisnika, testirati ga na djelu i prikupiti visokokvalitetne povratne informacije.

Nastaviti

Mnogima od nas ovo je prvi projekat ovakvog obima. Naučili smo niz vrijednih lekcija o tome kako raditi kao tim i donositi arhitektonske i dizajnerske odluke. Kako integrisati složene sisteme sa malo resursa i uvesti ih u proizvodnju.

Naravno, ima na čemu raditi i u pogledu koda i na interfejsima sistemske integracije. Projekat je prilično mlad, ali smo puni ambicija da ga preraste u pouzdan i praktičan servis.

Već smo uspjeli uvjeriti sisteme. Bill poslušno upravlja brojanjem, naplatom i zahtjevima korisnika u svom ormaru. “Magija” volframovih polja nam omogućava stabilnu komunikaciju. I samo OpenStack ponekad postane hirovit, vičući nešto poput „'WSREP još nije pripremio čvor za upotrebu aplikacije.“ Ali to je sasvim druga priča...

Nedavno smo pokrenuli uslugu.
Sve detalje možete saznati na našoj stranici site.

Istorija stvaranja cloud servisa, začinjenog sajberpunkom
CLO razvojni tim

korisni linkovi

OpenStack

Tungsten Fabric

izvor: www.habr.com

Dodajte komentar