Mentre lavori nel settore IT, inizi a notare che i sistemi hanno il loro carattere. Possono essere flessibili, silenziosi, eccentrici e severi. Possono attrarre o respingere. In un modo o nell'altro, devi "negoziare" con loro, manovrare tra le "insidie" e costruire catene della loro interazione.
Quindi abbiamo avuto l'onore di costruire una piattaforma cloud e per questo abbiamo dovuto "convincere" un paio di sottosistemi a lavorare con noi. Per fortuna abbiamo un “linguaggio API”, mani dirette e tanto entusiasmo.
Questo articolo non sarà tecnicamente hardcore, ma descriverà i problemi che abbiamo riscontrato durante la creazione del cloud. Ho deciso di descrivere il nostro percorso sotto forma di una leggera fantasia tecnica su come abbiamo cercato un linguaggio comune con i sistemi e cosa ne è venuto fuori.
Benvenuto al gatto.
Inizio di un viaggio
Qualche tempo fa, al nostro team è stato assegnato il compito di lanciare una piattaforma cloud per i nostri clienti. Avevamo supporto gestionale, risorse, stack hardware e libertà nella scelta delle tecnologie per implementare la parte software del servizio.
C'erano anche una serie di requisiti:
- il servizio necessita di un comodo conto personale;
- la piattaforma deve essere integrata nel sistema di fatturazione esistente;
- software e hardware: OpenStack + Tungsten Fabric (Open Contrail), che i nostri ingegneri hanno imparato a “cucinare” piuttosto bene.
Se la comunità Habra è interessata, vi racconteremo un'altra volta come è stato assemblato il team, come è stata sviluppata l'interfaccia dell'account personale e come sono state prese le decisioni di progettazione.
Gli strumenti che abbiamo deciso di utilizzare:
- Python + Flask + Swagger + SQLAlchemy: un set Python completamente standard;
- Vue.js per il frontend;
- Abbiamo deciso di eseguire l'interazione tra componenti e servizi utilizzando Celery su AMQP.
Anticipando domande sulla scelta di Python, spiegherò. La lingua ha trovato la sua nicchia nella nostra azienda e attorno ad essa si è sviluppata una piccola, ma pur sempre, cultura. Pertanto, si è deciso di iniziare a costruire il servizio su di esso. Inoltre, la velocità di sviluppo di tali problemi è spesso decisiva.
Quindi, iniziamo la nostra conoscenza.
Silent Bill - fatturazione
Conosciamo questo ragazzo da molto tempo. Si sedeva sempre accanto a me e contava qualcosa in silenzio. A volte ci inoltrava le richieste degli utenti, emetteva fatture clienti e gestiva servizi. Un normale ragazzo che lavora sodo. È vero, c'erano difficoltà. È silenzioso, a volte pensieroso e spesso pensieroso.
La fatturazione è il primo sistema con cui abbiamo provato a fare amicizia. E la prima difficoltà che abbiamo riscontrato è stata durante l'elaborazione dei servizi.
Ad esempio, quando viene creata o eliminata, un'attività viene inserita nella coda di fatturazione interna. Pertanto, viene implementato un sistema di lavoro asincrono con i servizi. Per elaborare i nostri tipi di servizio, dovevamo "mettere" le nostre attività in questa coda. E qui ci siamo imbattuti in un problema: la mancanza di documentazione.
A giudicare dalla descrizione dell'API del software, è ancora possibile risolvere questo problema, ma non abbiamo avuto il tempo di eseguire il reverse engineering, quindi abbiamo preso la logica all'esterno e organizzato una coda di attività sopra RabbitMQ. Un'operazione su un servizio viene avviata dal cliente dal suo account personale, si trasforma in un "compito" di Celery sul backend e viene eseguita sul lato fatturazione e OpenStack. Celery rende abbastanza comodo gestire le attività, organizzare le ripetizioni e monitorare lo stato. Puoi leggere di più sul "sedano", ad esempio, .
Inoltre, la fatturazione non ha fermato un progetto che aveva finito i soldi. Comunicando con gli sviluppatori, abbiamo scoperto che quando si calcolano le statistiche (e dobbiamo implementare esattamente questo tipo di logica), esiste una complessa interrelazione tra le regole di arresto. Ma questi modelli non si adattano bene alle nostre realtà. Lo abbiamo implementato anche tramite task su Celery, portando la logica di gestione del servizio sul lato backend.
Entrambi i problemi di cui sopra hanno portato il codice a diventare un po' gonfio e in futuro dovremo effettuare il refactoring per spostare la logica per lavorare con le attività in un servizio separato. Dobbiamo anche memorizzare alcune informazioni sugli utenti e sui loro servizi nelle nostre tabelle per supportare questa logica.
Un altro problema è il silenzio.
Billy risponde silenziosamente "Ok" ad alcune richieste API. Questo è stato il caso, ad esempio, quando abbiamo effettuato i pagamenti promessi durante il test (ne parleremo più avanti). Le richieste sono state eseguite correttamente e non abbiamo riscontrato alcun errore.
Ho dovuto studiare i registri mentre lavoravo con il sistema tramite l'interfaccia utente. Si è scoperto che la fatturazione stessa esegue richieste simili, modificando l'ambito su un utente specifico, ad esempio admin, passandolo nel parametro su.
In generale, nonostante le lacune nella documentazione e piccoli difetti API, tutto è andato abbastanza bene. I registri possono essere letti anche in condizioni di carico pesante se si capisce come sono strutturati e cosa cercare. La struttura del database è elaborata, ma abbastanza logica e per certi versi anche attraente.
Quindi, riassumendo, i principali problemi che abbiamo riscontrato nella fase di interazione sono legati alle caratteristiche di implementazione di un sistema specifico:
- "caratteristiche" non documentate che ci hanno influenzato in un modo o nell'altro;
- closed source (la fatturazione è scritta in C++), di conseguenza è impossibile risolvere il problema 1 in altro modo se non "tentativi ed errori".
Fortunatamente il prodotto dispone di un'API abbastanza estesa e abbiamo integrato i seguenti sottosistemi nel nostro account personale:
- modulo di supporto tecnico: le richieste dal tuo account personale vengono "procurate" alla fatturazione in modo trasparente per i clienti del servizio;
- modulo finanziario: consente di emettere fatture ai clienti attuali, effettuare cancellazioni e generare documenti di pagamento;
- modulo di controllo del servizio: per questo abbiamo dovuto implementare il nostro gestore. L’espandibilità del sistema ha giocato nelle nostre mani e abbiamo “insegnato” a Billy un nuovo tipo di servizio.
È stata un po' una seccatura, ma in un modo o nell'altro, penso che io e Billy andremo d'accordo.
Camminando attraverso i campi di tungsteno – Tessuto di tungsteno
Campi di tungsteno punteggiati da centinaia di fili, che passano attraverso di essi migliaia di bit di informazioni. Le informazioni vengono raccolte in “pacchetti”, analizzate, costruendo percorsi complessi, come per magia.
Questo è il dominio del secondo sistema con cui abbiamo dovuto fare amicizia: Tungsten Fabric (TF), precedentemente OpenContrail. Il suo compito è gestire le apparecchiature di rete, fornendo a noi utenti un'astrazione software. TF - SDN, incapsula la complessa logica di lavoro con le apparecchiature di rete. C'è un buon articolo sulla tecnologia stessa, ad esempio, .
Il sistema è integrato con OpenStack (discusso di seguito) tramite il plugin Neutron.
Interazione dei servizi OpenStack.
I ragazzi del reparto operativo ci hanno fatto conoscere questo sistema. Utilizziamo l'API del sistema per gestire lo stack di rete dei nostri servizi. Non ci ha ancora causato problemi o inconvenienti seri (non posso parlare per i ragazzi dell'OE), ma ci sono state alcune stranezze nell'interazione.
Il primo assomigliava a questo: i comandi che richiedevano l'output di una grande quantità di dati sulla console dell'istanza durante la connessione tramite SSH semplicemente "bloccavano" la connessione, mentre tramite VNC tutto funzionava correttamente.
Per coloro che non hanno familiarità con il problema, sembra piuttosto divertente: ls /root funziona correttamente, mentre, ad esempio, top “si blocca” completamente. Fortunatamente, abbiamo già riscontrato problemi simili in precedenza. È stato deciso sintonizzando la MTU sul percorso dai nodi di calcolo ai router. A proposito, questo non è un problema di TF.
Il problema successivo era proprio dietro l’angolo. In un momento “bellissimo”, la magia del routing è scomparsa, proprio così. TF ha smesso di gestire il routing sull'apparecchiatura.
Abbiamo lavorato con Openstack dal livello di amministratore e successivamente siamo passati al livello di utente richiesto. Sembra che SDN “dirotti” l'ambito dell'utente da cui vengono eseguite le azioni. Il fatto è che per connettere TF e OpenStack viene utilizzato lo stesso account amministratore. Nella fase di passaggio all'utente, la "magia" è scomparsa. Si è deciso di creare un account separato per lavorare con il sistema. Ciò ci ha permesso di lavorare senza interrompere la funzionalità di integrazione.
Forme di vita in silicio - OpenStack
Una creatura di silicone dalla forma bizzarra vive vicino ai campi di tungsteno. Soprattutto, sembra un bambino troppo cresciuto che può schiacciarci con un'altalena, ma non c'è alcuna evidente aggressività da parte sua. Non provoca paura, ma le sue dimensioni ispirano paura. Così come la complessità di ciò che accade intorno.
OpenStack è il cuore della nostra piattaforma.
OpenStack ha diversi sottosistemi, di cui attualmente utilizziamo più attivamente Nova, Glance e Cinder. Ognuno di loro ha la propria API. Nova è responsabile delle risorse di calcolo e della creazione di istanze, Cinder è responsabile della gestione dei volumi e dei relativi snapshot, Glance è un servizio di immagine che gestisce i modelli del sistema operativo e le metainformazioni su di essi.
Ogni servizio viene eseguito in un contenitore e il broker dei messaggi è il "coniglio bianco" - RabbitMQ.
Questo sistema ci ha dato i guai più inaspettati.
E il primo problema non si è fatto attendere quando abbiamo provato a connettere un volume aggiuntivo al server. L'API Cinder si è rifiutata categoricamente di eseguire questa attività. Più precisamente, se credi a OpenStack stesso, la connessione viene stabilita, ma non è presente alcun dispositivo disco all'interno del server virtuale.
Abbiamo deciso di fare una deviazione e abbiamo richiesto la stessa azione all'API Nova. Il risultato è che il dispositivo si connette correttamente ed è accessibile all'interno del server. Sembra che il problema si verifichi quando lo storage a blocchi non risponde a Cinder.
Un'altra difficoltà ci aspettava quando lavoravamo con i dischi. Impossibile disconnettere il volume di sistema dal server.
Ancora una volta, OpenStack stesso "giura" di aver distrutto la connessione e ora puoi lavorare correttamente con il volume separatamente. Ma l'API categoricamente non voleva eseguire operazioni sul disco.
Qui abbiamo deciso di non combattere particolarmente, ma di cambiare la nostra visione della logica del servizio. Se è presente un'istanza, deve essere presente anche un volume di sistema. Pertanto, l'utente non può ancora rimuovere o disabilitare il “disco” di sistema senza eliminare il “server”.
OpenStack è un insieme di sistemi piuttosto complesso con una propria logica di interazione e API elaborate. Siamo aiutati da una documentazione abbastanza dettagliata e, ovviamente, da tentativi ed errori (dove saremmo senza di essa).
Prova
Abbiamo effettuato un lancio di prova nel dicembre dello scorso anno. Il compito principale era testare il nostro progetto in modalità combattimento dal lato tecnico e dal lato UX. Il pubblico è stato invitato in modo selettivo e la prova è stata chiusa. Tuttavia, abbiamo anche lasciato la possibilità di richiedere l'accesso ai test sul nostro sito web.
Il test stesso, ovviamente, non è stato privo di momenti divertenti, perché è qui che le nostre avventure sono appena iniziate.
In primo luogo, abbiamo valutato in modo un po’ errato l’interesse per il progetto e abbiamo dovuto aggiungere rapidamente nodi di calcolo proprio durante il test. Un caso comune per un cluster, ma anche qui c'erano alcune sfumature. La documentazione per una versione specifica di TF indica la versione specifica del kernel su cui è stato testato il funzionamento con vRouter. Abbiamo deciso di lanciare nodi con kernel più recenti. Di conseguenza, TF non ha ricevuto rotte dai nodi. Ho dovuto ripristinare urgentemente i kernel.
Un'altra curiosità è legata alla funzionalità del pulsante “cambia password” nel tuo account personale.
Abbiamo deciso di utilizzare JWT per organizzare l'accesso al nostro account personale in modo da non lavorare con le sessioni. Poiché i sistemi sono diversi e ampiamente sparsi, gestiamo il nostro token, in cui "racchiudiamo" le sessioni dalla fatturazione e un token da OpenStack. Quando la password viene modificata, il token, ovviamente, "va male", poiché i dati dell'utente non sono più validi e devono essere riemessi.
Abbiamo perso di vista questo punto e semplicemente non c’erano abbastanza risorse per finire rapidamente questo pezzo. Abbiamo dovuto eliminare la funzionalità subito prima di lanciare il test.
Attualmente disconnettiamo l'utente se la password è stata modificata.
Nonostante queste sfumature, i test sono andati bene. In un paio di settimane sono passate circa 300 persone. Abbiamo potuto guardare il prodotto attraverso gli occhi degli utenti, testarlo in azione e raccogliere feedback di alta qualità.
essere continuato
Per molti di noi, questo è il primo progetto di questa portata. Abbiamo imparato una serie di lezioni preziose su come lavorare in squadra e prendere decisioni sull'architettura e sul design. Come integrare sistemi complessi con poche risorse e metterli in produzione.
Naturalmente c'è qualcosa su cui lavorare sia in termini di codice che a livello di interfacce di integrazione del sistema. Il progetto è piuttosto giovane, ma siamo pieni di ambizioni per trasformarlo in un servizio affidabile e conveniente.
Siamo già riusciti a persuadere i sistemi. Bill gestisce diligentemente il conteggio, la fatturazione e le richieste degli utenti nel suo armadio. La “magia” dei campi di tungsteno ci fornisce una comunicazione stabile. E solo OpenStack a volte diventa capriccioso, gridando qualcosa come "'WSREP non ha ancora preparato il nodo per l'uso dell'applicazione". Ma questa è una storia completamente diversa...
Recentemente abbiamo lanciato il servizio.
Puoi scoprire tutti i dettagli sul ns .
Gruppo di sviluppo CLO
Link utili
OpenStack
Tessuto di tungsteno
Fonte: habr.com