A mesura que treballeu en TI, comenceu a notar que els sistemes tenen el seu propi caràcter. Poden ser flexibles, silenciosos, excèntrics i severs. Poden atreure o repel·lir. D'una manera o d'una altra, cal "negociar" amb ells, maniobrar entre "tranyes" i construir cadenes de la seva interacció.
Així que vam tenir l'honor de construir una plataforma al núvol, i per això vam haver de "convèncer" un parell de subsistemes perquè treballessin amb nosaltres. Afortunadament, tenim un “llenguatge API”, mans directes i molta il·lusió.
Aquest article no serà tècnicament dur, però descriurà els problemes que hem trobat durant la construcció del núvol. Vaig decidir descriure el nostre camí en forma d'una lleugera fantasia tècnica sobre com buscàvem un llenguatge comú amb sistemes i què en va sortir.
Benvingut al gat.
A partir d'un viatge
Fa un temps, el nostre equip va tenir l'encàrrec de llançar una plataforma al núvol per als nostres clients. Teníem suport de gestió, recursos, pila de maquinari i llibertat per triar tecnologies per implementar la part de programari del servei.
També hi havia una sèrie de requisits:
- el servei necessita un compte personal convenient;
- la plataforma ha d'estar integrada en el sistema de facturació existent;
- programari i maquinari: OpenStack + Tungsten Fabric (Open Contrail), que els nostres enginyers han après a "cuinar" força bé.
En una altra ocasió us explicarem com es va formar l'equip, es va desenvolupar la interfície del compte personal i es van prendre decisions de disseny, si la comunitat Habra està interessada.
Les eines que hem decidit utilitzar:
- Python + Flask + Swagger + SQLAlchemy: un conjunt de Python completament estàndard;
- Vue.js per a la interfície;
- Vam decidir fer la interacció entre components i serveis utilitzant Celery sobre AMQP.
Anticipant preguntes sobre l'elecció de Python, les explicaré. La llengua ha trobat el seu nínxol a la nostra empresa i al seu voltant s'ha desenvolupat una cultura petita, però encara. Per tant, es va decidir començar a construir-hi el servei. A més, la velocitat de desenvolupament d'aquests problemes sovint és decisiva.
Comencem, doncs, el nostre coneixement.
Silent Bill - facturació
Fa temps que coneixem aquest noi. Sempre s'asseia al meu costat i en silenci comptava alguna cosa. De vegades ens enviava les sol·licituds dels usuaris, emetia factures de clients i gestionava serveis. Un noi treballador normal. És cert que hi havia dificultats. És silenciós, de vegades pensatiu i sovint en la seva pròpia ment.
La facturació és el primer sistema amb el qual vam intentar fer amics. I la primera dificultat que vam trobar va ser a l'hora de processar els serveis.
Per exemple, quan es crea o s'elimina, una tasca passa a la cua de facturació interna. Així, s'implementa un sistema de treball asíncron amb serveis. Per processar els nostres tipus de servei, havíem de "posar" les nostres tasques a aquesta cua. I aquí ens vam trobar amb un problema: la manca de documentació.
A jutjar per la descripció de l'API del programari, encara és possible resoldre aquest problema, però no vam tenir temps de fer enginyeria inversa, així que vam treure la lògica i vam organitzar una cua de tasques a sobre de RabbitMQ. El client inicia una operació d'un servei des del seu compte personal, es converteix en una "tasca" d'Api al backend i es realitza al costat de facturació i OpenStack. L'api fa que sigui molt còmode gestionar tasques, organitzar repeticions i controlar l'estat. Podeu llegir més sobre "api", per exemple, .
A més, la facturació no va aturar un projecte que es va quedar sense diners. En comunicar-nos amb els desenvolupadors, vam descobrir que en calcular les estadístiques (i hem d'implementar exactament aquest tipus de lògica), hi ha una interrelació complexa de regles d'aturada. Però aquests models no encaixen bé amb les nostres realitats. També ho vam implementar mitjançant tasques a Celery, portant la lògica de gestió del servei al backend.
Ambdós problemes anteriors van fer que el codi s'esforcés una mica i en el futur haurem de refactoritzar per traslladar la lògica per treballar amb tasques a un servei independent. També hem d'emmagatzemar informació sobre els usuaris i els seus serveis a les nostres taules per donar suport a aquesta lògica.
Un altre problema és el silenci.
Billy en silenci respon "D'acord" a algunes sol·licituds de l'API. Aquest va ser el cas, per exemple, quan vam fer els pagaments dels pagaments promesos durant la prova (més informació més endavant). Les sol·licituds es van executar correctament i no vam veure cap error.
Vaig haver d'estudiar els registres mentre treballava amb el sistema mitjançant la interfície d'usuari. Va resultar que la facturació en si mateixa realitza sol·licituds similars, canviant l'abast a un usuari específic, per exemple, administrador, passant-ho al paràmetre su.
En general, malgrat els buits de la documentació i els errors menors de l'API, tot va anar força bé. Els registres es poden llegir fins i tot amb una càrrega pesada si enteneu com estan estructurats i què cal buscar. L'estructura de la base de dades és ornamentada, però força lògica i d'alguna manera fins i tot atractiva.
Així, per resumir, els principals problemes que hem trobat en l'etapa d'interacció estan relacionats amb les característiques d'implementació d'un sistema específic:
- "característiques" no documentades que ens van afectar d'una manera o altra;
- codi tancat (la facturació està escrita en C++), com a resultat, és impossible resoldre el problema 1 d'una altra manera que no sigui "assaig i error".
Afortunadament, el producte té una API força extensa i hem integrat els següents subsistemes al nostre compte personal:
- Mòdul de suport tècnic: les sol·licituds del vostre compte personal es "apropen" a la facturació de manera transparent per als clients del servei;
- mòdul financer: permet emetre factures als clients actuals, fer baixa i generar documents de pagament;
- mòdul de control de servei: per això hem hagut d'implementar el nostre propi controlador. L'expansió del sistema va jugar a les nostres mans i vam "ensenyar" a Billy un nou tipus de servei.
Va ser una mica de molèstia, però d'una manera o altra, crec que en Billy i jo ens entendrem.
Passejant pels camps de tungstè – Tungstè Tela
Camps de tungstè esquitxats de centenars de cables, passant milers de bits d'informació a través d'ells. La informació es recull en "paquets", s'analitza, construint rutes complexes, com per art de màgia.
Aquest és el domini del segon sistema amb el qual vam haver de fer amics: Tungsten Fabric (TF), abans OpenContrail. La seva tasca és gestionar els equips de xarxa, proporcionant-nos com a usuaris una abstracció de programari. TF - SDN, encapsula la complexa lògica de treballar amb equips de xarxa. Hi ha un bon article sobre la tecnologia en si, per exemple, .
El sistema està integrat amb OpenStack (que es comenta a continuació) mitjançant el connector Neutron.
Interacció dels serveis d'OpenStack.
Els nois del departament d'operacions ens van presentar aquest sistema. Utilitzem l'API del sistema per gestionar la pila de xarxa dels nostres serveis. Encara no ens ha causat cap problema o inconvenient greu (no puc parlar en nom dels nois de l'OE), però hi ha hagut algunes rareses en la interacció.
La primera tenia aquest aspecte: les ordres que requerien enviar una gran quantitat de dades a la consola de la instància quan es connectava mitjançant SSH simplement "penjaven" la connexió, mentre que mitjançant VNC tot funcionava correctament.
Per a aquells que no estan familiaritzats amb el problema, sembla bastant divertit: ls /root funciona correctament, mentre que, per exemple, la part superior es "congela" completament. Afortunadament, ens hem trobat amb problemes similars abans. Es va decidir ajustant la MTU a la ruta des dels nodes de càlcul fins als encaminadors. Per cert, això no és un problema de TF.
El següent problema estava a la volta de la cantonada. En un "bell" moment, la màgia de l'encaminament va desaparèixer, així mateix. TF ha deixat de gestionar l'encaminament a l'equip.
Vam treballar amb Openstack des del nivell d'administració i després vam passar al nivell d'usuari requerit. SDN sembla que "segresta" l'abast de l'usuari pel qual es realitzen les accions. El fet és que el mateix compte d'administrador s'utilitza per connectar TF i OpenStack. En el pas de canviar a l'usuari, la "màgia" va desaparèixer. Es va decidir crear un compte separat per treballar amb el sistema. Això ens va permetre treballar sense trencar la funcionalitat d'integració.
Silicon Lifeforms - OpenStack
Una criatura de silicona de forma estranya viu a prop dels camps de tungstè. Sobretot, sembla un nen massa gran que ens pot aixafar d'un sol cop, però no hi ha cap agressió evident que ve d'ell. No provoca por, però la seva mida inspira por. Igual que la complexitat del que passa al voltant.
OpenStack és el nucli de la nostra plataforma.
OpenStack té diversos subsistemes, dels quals actualment utilitzem Nova, Glance i Cinder de manera més activa. Cadascun d'ells té la seva pròpia API. Nova s'encarrega dels recursos informàtics i de la creació d'instàncies, Cinder s'encarrega de gestionar els volums i les seves instantànies, Glance és un servei d'imatge que gestiona les plantilles del sistema operatiu i la metainformació sobre elles.
Cada servei s'executa en un contenidor i l'agent de missatges és el "conill blanc" - RabbitMQ.
Aquest sistema ens va provocar els problemes més inesperats.
I el primer problema no es va fer esperar quan vam intentar connectar un volum addicional al servidor. L'API de Cinder es va negar rotundament a realitzar aquesta tasca. Més precisament, si creieu que OpenStack mateix, la connexió s'estableix, però no hi ha cap dispositiu de disc dins del servidor virtual.
Vam decidir fer una volta i vam demanar la mateixa acció a l'API de Nova. El resultat és que el dispositiu es connecta correctament i és accessible dins del servidor. Sembla que el problema es produeix quan l'emmagatzematge en bloc no respon a Cinder.
Una altra dificultat ens esperava quan treballàvem amb discs. El volum del sistema no s'ha pogut desconnectar del servidor.
De nou, el mateix OpenStack "jura" que ha destruït la connexió i ara podeu treballar correctament amb el volum per separat. Però l'API categòricament no volia realitzar operacions al disc.
Aquí vam decidir no lluitar especialment, sinó canviar la nostra visió de la lògica del servei. Si hi ha una instància, també hi ha d'haver un volum del sistema. Per tant, l'usuari encara no pot eliminar o desactivar el "disc" del sistema sense eliminar el "servidor".
OpenStack és un conjunt de sistemes força complex amb la seva pròpia lògica d'interacció i API ornamentada. Ens ajuda una documentació força detallada i, per descomptat, assaig i error (on estaríem sense ella).
Prova d'execució
Vam fer una prova de llançament el desembre de l'any passat. La tasca principal va ser provar el nostre projecte en mode combat des del vessant tècnic i des de l'UX. El públic va ser convidat selectivament i es va tancar la prova. Tanmateix, també hem deixat l'opció de sol·licitar accés a les proves al nostre lloc web.
La prova en si, és clar, no va estar exempta de moments divertits, perquè aquí és on les nostres aventures tot just comencen.
En primer lloc, vam avaluar una mica incorrectament l'interès pel projecte i vam haver d'afegir nodes de càlcul ràpidament durant la prova. Un cas comú per a un clúster, però aquí també hi havia alguns matisos. La documentació d'una versió específica de TF indica la versió específica del nucli en què es va provar el treball amb vRouter. Vam decidir llançar nodes amb nuclis més recents. Com a resultat, TF no va rebre rutes dels nodes. Vaig haver de revertir urgentment els nuclis.
Una altra curiositat està relacionada amb la funcionalitat del botó "canviar contrasenya" del vostre compte personal.
Vam decidir utilitzar JWT per organitzar l'accés al nostre compte personal per no treballar amb sessions. Com que els sistemes són diversos i àmpliament dispersos, gestionem el nostre propi testimoni, en el qual "emboliquem" sessions de facturació i un testimoni d'OpenStack. Quan es canvia la contrasenya, el testimoni, per descomptat, "va malament", ja que les dades de l'usuari ja no són vàlides i s'han de tornar a emetre.
Hem perdut aquest punt de vista i simplement no hi havia prou recursos per acabar ràpidament aquesta peça. Vam haver de tallar la funcionalitat just abans de llançar la prova.
Actualment tanquem la sessió de l'usuari si s'ha canviat la contrasenya.
Malgrat aquests matisos, les proves van anar bé. En un parell de setmanes, unes 300 persones van passar per aquí. Hem pogut mirar el producte a través dels ulls dels usuaris, provar-lo en acció i recollir comentaris d'alta qualitat.
Continuar
Per a molts de nosaltres, aquest és el primer projecte d'aquesta envergadura. Hem après una sèrie de lliçons valuoses sobre com treballar en equip i prendre decisions d'arquitectura i disseny. Com integrar sistemes complexos amb pocs recursos i posar-los en producció.
Per descomptat, hi ha alguna cosa per treballar tant pel que fa al codi com a les interfícies d'integració del sistema. El projecte és bastant jove, però estem plens d'ambicions per convertir-lo en un servei fiable i còmode.
Ja hem sabut persuadir els sistemes. Bill s'encarrega de manera diligent del recompte, la facturació i les sol·licituds dels usuaris al seu armari. La "màgia" dels camps de tungstè ens proporciona una comunicació estable. I només OpenStack de vegades es fa capritxoso, cridant alguna cosa com "'WSREP encara no ha preparat el node per utilitzar l'aplicació". Però aquesta és una història completament diferent...
Recentment hem posat en marxa el servei.
Podeu conèixer tots els detalls al nostre .
Equip de desenvolupament de CLO
links útils
OpenStack
Teixit de tungstè
Font: www.habr.com