Pe măsură ce lucrezi în IT, începi să observi că sistemele au propriul lor caracter. Ele pot fi flexibile, silențioase, excentrice și aspre. Ele pot atrage sau respinge. Într-un fel sau altul, trebuie să „negociezi” cu ei, să manevrezi între „capcane” și să construiești lanțuri ale interacțiunii lor.
Așa că am avut onoarea de a construi o platformă cloud și pentru aceasta trebuia să „convingem” câteva subsisteme să lucreze cu noi. Din fericire, avem un „limbaj API”, mâini directe și mult entuziasm.
Acest articol nu va fi hardcore din punct de vedere tehnic, dar va descrie problemele pe care le-am întâlnit la construirea cloud-ului. Am decis să descriu drumul nostru sub forma unei fantezii tehnice ușoare despre cum am căutat un limbaj comun cu sisteme și ce a rezultat din el.
Bun venit la pisica.
Începutul unui drum
Cu ceva timp în urmă, echipa noastră a fost însărcinată cu lansarea unei platforme cloud pentru clienții noștri. Am avut suport de management, resurse, stivă hardware și libertate în alegerea tehnologiilor pentru implementarea părții software a serviciului.
Au existat și o serie de cerințe:
- serviciul are nevoie de un cont personal convenabil;
- platforma trebuie să fie integrată în sistemul de facturare existent;
- software și hardware: OpenStack + Tungsten Fabric (Open Contrail), pe care inginerii noștri au învățat să „gătească” destul de bine.
Vă vom spune altă dată despre cum a fost asamblată echipa, a fost dezvoltată interfața contului personal și s-au luat decizii de proiectare, dacă comunitatea Habra este interesată.
Instrumentele pe care am decis să le folosim:
- Python + Flask + Swagger + SQLAlchemy - un set Python complet standard;
- Vue.js pentru frontend;
- Am decis să facem interacțiunea între componente și servicii folosind Celery peste AMQP.
Anticipând întrebări despre alegerea Python, voi explica. Limba și-a găsit nișa în compania noastră și în jurul ei s-a dezvoltat o cultură mică, dar totuși. Prin urmare, s-a decis să se înceapă construirea serviciului pe acesta. Mai mult, viteza de dezvoltare în astfel de probleme este adesea decisivă.
Deci, să începem cunoștința noastră.
Silent Bill - facturare
Îl cunoaștem pe tipul ăsta de mult timp. Stătea mereu lângă mine și număra în tăcere ceva. Uneori, ne transmitea cererile utilizatorilor, emitea facturi pentru clienți și gestiona serviciile. Un tip obișnuit, muncitor. Adevărat, au fost dificultăți. El este tăcut, uneori gânditor și adesea pe propria sa minte.
Facturarea este primul sistem cu care am încercat să ne împrietenim. Iar prima dificultate pe care am întâlnit-o a fost la procesarea serviciilor.
De exemplu, atunci când este creată sau ștearsă, o sarcină intră în coada internă de facturare. Astfel, este implementat un sistem de lucru asincron cu servicii. Pentru a ne procesa tipurile de servicii, trebuia să ne „punem” sarcinile în această coadă. Și aici ne-am lovit de o problemă: lipsa documentației.
Judecând după descrierea API-ului software, este încă posibil să rezolvăm această problemă, dar nu am avut timp să facem inginerie inversă, așa că am scos logica afară și am organizat o coadă de activități deasupra RabbitMQ. O operațiune asupra unui serviciu este inițiată de client din contul său personal, se transformă într-o „sarcină” de țelină pe backend și se realizează pe partea de facturare și OpenStack. Țelina face destul de convenabil gestionarea sarcinilor, organizarea repetărilor și monitorizarea stării. Puteți citi mai multe despre „țelină”, de exemplu, .
De asemenea, facturarea nu a oprit un proiect care a rămas fără bani. Comunicând cu dezvoltatorii, am aflat că atunci când calculăm statisticile (și trebuie să implementăm exact acest tip de logică), există o interrelație complexă a regulilor de oprire. Dar aceste modele nu se potrivesc bine cu realitățile noastre. L-am implementat și prin sarcini pe țelină, ducând logica de gestionare a serviciilor în partea de backend.
Ambele probleme de mai sus au făcut ca codul să devină puțin umflat și în viitor va trebui să refactorăm pentru a muta logica pentru lucrul cu sarcini într-un serviciu separat. De asemenea, trebuie să stocăm unele informații despre utilizatori și serviciile acestora în tabelele noastre pentru a susține această logică.
O altă problemă este tăcerea.
Billy răspunde în tăcere „Ok” la unele solicitări API. Acesta a fost cazul, de exemplu, când am efectuat plăți pentru plățile promise în timpul testului (mai multe despre asta mai târziu). Solicitările au fost executate corect și nu am văzut erori.
A trebuit să studiez jurnalele în timp ce lucram cu sistemul prin interfața de utilizare. S-a dovedit că facturarea în sine efectuează solicitări similare, schimbând domeniul de aplicare la un anumit utilizator, de exemplu, admin, trecându-l în parametrul su.
În general, în ciuda lacunelor în documentație și a erorilor minore ale API, totul a mers destul de bine. Jurnalele pot fi citite chiar și sub sarcină grea dacă înțelegeți cum sunt structurate și ce să căutați. Structura bazei de date este ornamentată, dar destul de logică și, în anumite privințe, chiar atractivă.
Deci, pentru a rezuma, principalele probleme pe care le-am întâlnit în etapa de interacțiune sunt legate de caracteristicile de implementare ale unui anumit sistem:
- „caracteristici” nedocumentate care ne-au afectat într-un fel sau altul;
- sursă închisă (facturarea este scrisă în C++), ca rezultat - este imposibil să rezolvi problema 1 în alt mod decât „încercare și eroare”.
Din fericire, produsul are un API destul de extins și am integrat următoarele subsisteme în contul nostru personal:
- modul de asistență tehnică - solicitările din contul dvs. personal sunt „proxiate” la facturarea în mod transparent pentru clienții de servicii;
- modul financiar - vă permite să emiteți facturi către clienții actuali, să efectuați ștergeri și să generați documente de plată;
- modul de control al serviciului - pentru aceasta a trebuit să implementăm propriul nostru handler. Extensibilitatea sistemului a jucat în mâinile noastre și l-am „învățat” pe Billy un nou tip de serviciu.
A fost un pic o bătaie de cap, dar într-un fel sau altul, cred că Billy și cu mine ne vom înțelege.
Plimbare prin câmpuri de tungsten – Tungsten Fabric
Câmpuri de tungsten presărate cu sute de fire, trecând prin ele mii de biți de informații. Informațiile sunt colectate în „pachete”, analizate, construind rute complexe, ca prin magie.
Acesta este domeniul celui de-al doilea sistem cu care a trebuit să ne împrietenim – Tungsten Fabric (TF), fost OpenContrail. Sarcina sa este de a gestiona echipamentele de rețea, oferindu-ne o abstractizare software nouă ca utilizatori. TF - SDN, încapsulează logica complexă a lucrului cu echipamente de rețea. Există un articol bun despre tehnologie în sine, de exemplu, .
Sistemul este integrat cu OpenStack (discutat mai jos) prin intermediul pluginului Neutron.
Interacțiunea serviciilor OpenStack.
Băieții de la departamentul de operațiuni ne-au prezentat acest sistem. Utilizăm API-ul sistemului pentru a gestiona stiva de rețea a serviciilor noastre. Nu ne-a cauzat încă probleme sau inconveniente serioase (nu pot vorbi în numele băieților de la OE), dar au existat unele ciudățenii în interacțiune.
Prima arăta astfel: comenzile care necesitau scoaterea unei cantități mari de date către consola instanței la conectarea prin SSH pur și simplu „închideau” conexiunea, în timp ce prin VNC totul funcționa corect.
Pentru cei care nu sunt familiarizați cu problema, pare destul de amuzant: ls /root funcționează corect, în timp ce, de exemplu, top „îngheață” complet. Din fericire, am mai întâlnit probleme similare. S-a decis prin reglarea MTU-ului pe ruta de la nodurile de calcul la routere. Apropo, aceasta nu este o problemă TF.
Următoarea problemă era chiar după colț. Într-un moment „frumos”, magia rutării a dispărut, exact așa. TF a încetat să mai gestioneze rutarea pe echipament.
Am lucrat cu Openstack de la nivelul de administrator și apoi ne-am mutat la nivelul de utilizator necesar. SDN pare să „deturneze” domeniul de aplicare al utilizatorului de către care sunt efectuate acțiunile. Faptul este că același cont de administrator este folosit pentru a conecta TF și OpenStack. La pasul trecerii la utilizator, „magia” a dispărut. S-a decis crearea unui cont separat pentru a lucra cu sistemul. Acest lucru ne-a permis să lucrăm fără a întrerupe funcționalitatea de integrare.
Silicon Lifeforms - OpenStack
O creatură de silicon cu formă bizară trăiește lângă câmpurile de tungsten. Mai presus de toate, arată ca un copil prea mare care ne poate zdrobi dintr-o singură leagăn, dar nu există o agresivitate evidentă din partea lui. Nu provoacă frică, dar dimensiunea ei inspiră frică. La fel și complexitatea a ceea ce se întâmplă în jur.
OpenStack este nucleul platformei noastre.
OpenStack are mai multe subsisteme, dintre care în prezent folosim Nova, Glance și Cinder cel mai activ. Fiecare dintre ele are propriul API. Nova este responsabilă de resursele de calcul și de crearea instanțelor, Cinder este responsabil de gestionarea volumelor și a instantaneelor acestora, Glance este un serviciu de imagine care gestionează șabloanele de sistem de operare și metainformațiile despre acestea.
Fiecare serviciu rulează într-un container, iar brokerul de mesaje este „iepurele alb” - RabbitMQ.
Acest sistem ne-a dat cele mai neașteptate probleme.
Iar prima problemă nu a întârziat să apară când am încercat să conectăm un volum suplimentar la server. API-ul Cinder a refuzat categoric să îndeplinească această sarcină. Mai precis, dacă credeți că OpenStack în sine, conexiunea este stabilită, dar nu există niciun dispozitiv de disc în interiorul serverului virtual.
Am decis să facem un ocol și am solicitat aceeași acțiune de la API-ul Nova. Rezultatul este că dispozitivul se conectează corect și este accesibil în cadrul serverului. Se pare că problema apare atunci când blocul de stocare nu răspunde la Cinder.
O altă dificultate ne aștepta când lucram cu discuri. Volumul sistemului nu a putut fi deconectat de la server.
Din nou, OpenStack însuși „jură” că a distrus conexiunea și acum puteți lucra corect cu volumul separat. Dar API-ul categoric nu a vrut să efectueze operațiuni pe disc.
Aici am decis să nu ne luptăm în mod deosebit, ci să ne schimbăm viziunea asupra logicii serviciului. Dacă există o instanță, trebuie să existe și un volum de sistem. Prin urmare, utilizatorul nu poate încă elimina sau dezactiva „discul” de sistem fără a șterge „serverul”.
OpenStack este un set destul de complex de sisteme cu propria sa logică de interacțiune și API ornamentat. Suntem ajutați de documentație destul de detaliată și, bineînțeles, de încercări și erori (unde am fi fără ea).
Run test
Am efectuat un test de lansare în decembrie anul trecut. Sarcina principală a fost să testăm proiectul nostru în modul luptă din partea tehnică și din partea UX. Publicul a fost invitat selectiv și testarea a fost închisă. Cu toate acestea, am lăsat și opțiunea de a solicita acces la testare pe site-ul nostru.
Testul în sine, desigur, nu a fost lipsit de momentele sale amuzante, pentru că aici abia încep aventurile noastre.
În primul rând, am evaluat oarecum incorect interesul pentru proiect și a trebuit să adăugăm rapid noduri de calcul chiar în timpul testului. Un caz obișnuit pentru un cluster, dar au existat și aici câteva nuanțe. Documentația pentru o anumită versiune de TF indică versiunea specifică a nucleului pe care a fost testată lucrul cu vRouter. Am decis să lansăm noduri cu nuclee mai recente. Ca urmare, TF nu a primit rute de la noduri. A trebuit să dau imediat înapoi sâmburii.
O altă curiozitate este legată de funcționalitatea butonului „schimbați parola” din contul personal.
Am decis să folosim JWT pentru a organiza accesul la contul nostru personal pentru a nu lucra cu sesiuni. Deoarece sistemele sunt diverse și împrăștiate pe scară largă, ne gestionăm propriul token, în care „închegem” sesiunile din facturare și un token din OpenStack. Când parola este schimbată, simbolul, desigur, „se defectează”, deoarece datele utilizatorului nu mai sunt valide și trebuie reemis.
Am pierdut din vedere acest punct și pur și simplu nu au existat suficiente resurse pentru a finaliza rapid această piesă. A trebuit să decupăm funcționalitatea chiar înainte de a lansa testul.
În prezent, deconectam utilizatorul dacă parola a fost schimbată.
În ciuda acestor nuanțe, testarea a mers bine. În câteva săptămâni, aproximativ 300 de oameni au trecut pe aici. Am putut să privim produsul prin ochii utilizatorilor, să-l testăm în acțiune și să colectăm feedback de înaltă calitate.
Va urma
Pentru mulți dintre noi, acesta este primul proiect de această amploare. Am învățat o serie de lecții valoroase despre cum să lucrăm în echipă și să luăm decizii de arhitectură și design. Cum să integrezi sisteme complexe cu resurse reduse și să le introduci în producție.
Desigur, există ceva de lucrat atât în ceea ce privește codul, cât și la interfețele integrării sistemului. Proiectul este destul de tânăr, dar suntem plini de ambiții de a-l crește într-un serviciu de încredere și convenabil.
Am reușit deja să convingem sistemele. Bill se ocupă cu grijă de numărare, de facturare și de solicitările utilizatorilor în dulapul său. „Magia” câmpurilor de tungsten ne oferă o comunicare stabilă. Și numai OpenStack devine uneori capricios, strigând ceva de genul „'WSREP nu a pregătit încă nodul pentru utilizarea aplicației”. Dar asta e cu totul alta poveste...
Am lansat recent serviciul.
Puteți afla toate detaliile pe site-ul nostru .
Echipa de dezvoltare CLO
Link-uri utile
OpenStack
Țesătură de wolfram
Sursa: www.habr.com