{"id":52389,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions"},"modified":"2020-02-18T14:00:05","modified_gmt":"2020-02-18T11:00:05","slug":"kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Come viene implementata un'architettura web resiliente nella piattaforma Mail.ru Cloud Solutions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n
\nCiao, Habr! Sono Artem Karamyshev, il responsabile del team di amministrazione di sistema. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Negli ultimi anno abbiamo lanciato molti nuovi prodotti. Volevamo assicurarci che i servizi API potessero scalare facilmente, fossero fault-tolerant e pronti a una rapida crescita del carico degli utenti. La nostra piattaforma \u00e8 basata su OpenStack e voglio raccontare quali problemi di tolleranza ai guasti dei componenti abbiamo dovuto affrontare per ottenere un sistema resistente. Penso che questo possa interessare chi sta sviluppando prodotti su OpenStack.<\/p>\n

La tolleranza ai guasti della piattaforma deriva dalla robustezza dei suoi componenti. Quindi passeremo gradualmente attraverso tutti i livelli in cui abbiamo identificato rischi e li abbiamo affrontati.<\/p>\n

Puoi guardare la versione video di questa storia, che ha avuto origine da una presentazione alla conferenza Uptime Day 4, organizzata da ITSumma<\/a><\/noindex>, su canale YouTube della Uptime Community<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Tolleranza ai guasti dell'architettura fisica<\/h2>\n

\nLa parte pubblica della nuvola MCS \u00e8 attualmente basata in due data center di livello Tier III, tra i quali \u00e8 presente una fibra ottica scura dedicata, riservata a livello fisico attraverso diverse rotte, con una capacit\u00e0 di 200 Gbit\/s. Il livello Tier III garantisce il necessario livello di tolleranza ai guasti per l'infrastruttura fisica. <\/p>\n

La fibra ottica scura \u00e8 riservata sia a livello fisico che logico. Il processo di riservazione dei canali \u00e8 stato iterativo, ci sono stati problemi e stiamo continuamente migliorando la connessione tra i data center. <\/p>\n

Ad esempio, recentemente durante i lavori in una fossa vicino a uno dei data center, un escavatore ha colpito un tubo che conteneva sia il cavo ottico principale sia quello di riserva. Il nostro canale di comunicazione a prova di guasto con il data center si \u00e8 rivelato vulnerabile in un solo punto, nella fossa. Di conseguenza, abbiamo perso parte dell'infrastruttura. Abbiamo tratto delle conclusioni e abbiamo intrapreso diverse azioni, tra cui l'installazione di ulteriore fibra ottica attraverso una fossa vicina.<\/p><\/blockquote>\n

\nNei data center ci sono punti di presenza dei provider di telecomunicazioni, a cui trasmettiamo i nostri prefissi tramite BGP. Per ogni direzione di rete viene scelta la migliore metrica, che consente di garantire ai vari clienti la migliore qualit\u00e0 di connessione. Se la connessione tramite un provider si interrompe, ristrutturiamo il nostro instradamento attraverso i provider disponibili.<\/p>\n

In caso di guasto di un provider, passiamo automaticamente al successivo. In caso di guasto di uno dei data center, abbiamo una copia speculare dei nostri servizi nel secondo data center, che prende in carico tutto il carico.<\/p>\n

\"Come
\nAffidabilit\u00e0 dell'infrastruttura fisica<\/i><\/p>\n

Cosa utilizziamo per l'affidabilit\u00e0 a livello di applicazioni<\/h2>\n

\nIl nostro servizio \u00e8 costruito su una serie di componenti open source. <\/p>\n

ExaBGP<\/b> \u2014 un servizio che implementa diverse funzionalit\u00e0 utilizzando il protocollo di instradamento dinamico basato su BGP. Lo utilizziamo attivamente per annunciare i nostri indirizzi IP pubblici, attraverso i quali gli utenti accedono all'API.<\/p>\n

HAProxy<\/b> \u2014 un bilanciatore di carico ad alta intensit\u00e0, che consente di configurare regole di bilanciamento del traffico molto flessibili su diversi livelli del modello OSI. Lo utilizziamo per il bilanciamento davanti a tutti i servizi: database, broker di messaggi, servizi API, servizi web, i nostri progetti interni \u2014 tutto \u00e8 gestito da HAProxy.<\/p>\n

API application<\/b> \u2014 un'applicazione web scritta in Python, tramite la quale l'utente gestisce la propria infrastruttura, il proprio servizio.<\/p>\n

Worker application <\/b>(d'ora in poi semplicemente worker) \u2014 nei servizi OpenStack \u00e8 un demone di infrastruttura che consente di trasmettere comandi API all'infrastruttura. Ad esempio, la creazione di un disco avviene proprio nel worker, mentre la richiesta di creazione avviene nell'API application. <\/p>\n

Architettura standard dell'OpenStack Application<\/h2>\n

\nLa maggior parte dei servizi sviluppati per OpenStack cerca di seguire un'unica concezione. Un servizio di solito \u00e8 composto da 2 parti: API e worker (esecutori di backend). In genere, l'API \u00e8 un'applicazione WSGI in Python, che pu\u00f2 essere eseguita come processo autonomo (daemon), oppure utilizzando un server web gi\u00e0 configurato come Nginx o Apache. L'API gestisce la richiesta dell'utente e trasmette successivamente le istruzioni all'applicazione worker. La trasmissione avviene tramite un broker di messaggi, generalmente RabbitMQ, mentre le altre opzioni sono poco supportate. Quando i messaggi raggiungono il broker, vengono elaborati dai worker e, in caso di necessit\u00e0, restituiscono una risposta. <\/p>\n

Questa concezione implica isolati punti di guasto comuni: RabbitMQ e il database. Tuttavia, RabbitMQ \u00e8 isolato all'interno di un singolo servizio e, in teoria, pu\u00f2 essere dedicato a ciascun servizio. Per questo motivo, in MCS cerchiamo di separare al massimo questi servizi, creando per ogni progetto un database e un RabbitMQ distinti. Questo approccio \u00e8 vantaggioso poich\u00e9 in caso di guasti in alcuni punti vulnerabili, non si interrompe l'intero servizio, ma solo una sua parte.<\/p>\n

Il numero di worker application non \u00e8 limitato, quindi l'API pu\u00f2 scalare facilmente orizzontalmente dietro ai bilanciatori, al fine di aumentare le prestazioni e la resilienza.<\/p>\n

In alcuni servizi \u00e8 necessaria una coordinazione all'interno del servizio, quando si verificano operazioni sequenziali complesse tra API e worker. In questo caso, viene utilizzato un centro di coordinazione unico, un sistema di clustering come Redis, Memcache, etcd, che consente a un worker di comunicare a un altro che questo compito \u00e8 assegnato a lui (\u00abtu, per favore, non prenderlo\u00bb). Noi utilizziamo etcd. Di solito, i worker comunicano attivamente con il database, scrivendo e leggendo informazioni. Come database utilizziamo MariaDB, che \u00e8 mantenuto in un cluster multimaster.\n<\/p><\/blockquote>\n

\nUn servizio classico singolo \u00e8 organizzato in modo consolidato per OpenStack. Pu\u00f2 essere visto come un sistema chiuso, per il quale sono abbastanza evidenti i metodi di scaling e resilienza. Ad esempio, per la resilienza dell'API \u00e8 sufficiente posizionare un bilanciatore davanti ad essa. Lo scaling dei worker si ottiene aumentando il loro numero. <\/p>\n

Il punto debole dell'intero sistema sono RabbitMQ e MariaDB. La loro architettura merita un articolo dedicato. In questo articolo voglio concentrarmi sull'affidabilit\u00e0 dell'API.<\/p>\n

\"Come
\nArchitettura Openstack Application. Bilanciamento e affidabilit\u00e0 della piattaforma cloud.<\/i><\/p>\n

Rendiamo il bilanciatore HAProxy affidabile con ExaBGP.<\/h2>\n

\nPer garantire che le nostre API siano scalabili, veloci e affidabili, abbiamo inserito un bilanciatore. Abbiamo scelto HAProxy. A mio avviso, possiede tutte le caratteristiche necessarie per il nostro compito: bilanciamento su pi\u00f9 livelli OSI, interfaccia di gestione, flessibilit\u00e0 e scalabilit\u00e0, un grande numero di metodi di bilanciamento, supporto per le tabelle di sessione.<\/p>\n

Il primo problema da risolvere \u00e8 stata l'affidabilit\u00e0 del bilanciatore stesso. L'installazione di un bilanciatore crea comunque un punto di guasto: se il bilanciatore si blocca, il servizio va gi\u00f9. Per evitare questo problema, abbiamo utilizzato HAProxy insieme a ExaBGP.<\/p>\n

ExaBGP consente di implementare un meccanismo di verifica dello stato del servizio. Abbiamo utilizzato questo meccanismo per controllare il funzionamento di HAProxy e, in caso di problemi, disattivare il servizio HAProxy dal BGP. <\/p>\n

Schema ExaBGP+HAProxy.<\/b><\/p>\n

    \n
  1. Installiamo il software necessario, ExaBGP e HAProxy, su tre server. <\/li>\n
  2. Su ciascun server creiamo un'interfaccia loopback.<\/li>\n
  3. Su tutti e tre i server impostiamo lo stesso indirizzo IP pubblico su questa interfaccia.<\/li>\n
  4. L'indirizzo IP pubblico viene annunciato su Internet tramite ExaBGP. <\/li>\n<\/ol>\n

    \nL'affidabilit\u00e0 si ottiene annunciando lo stesso indirizzo IP da tutti e tre i server. Dal punto di vista della rete, lo stesso indirizzo \u00e8 accessibile da tre diversi next hop. Il router vede tre percorsi identici e seleziona quello pi\u00f9 priorizzato secondo la sua metrica (che di solito \u00e8 lo stesso percorso), e il traffico viene instradato solo su uno dei server. <\/p>\n

    In caso di problemi con il funzionamento di HAProxy o di guasto del server, ExaBGP smette di annunciare il percorso, e il traffico viene immediatamente reindirizzato a un altro server. <\/p>\n

    In questo modo abbiamo raggiunto l'affidabilit\u00e0 del bilanciatore.<\/p>\n

    \"Come
    \nAffidabilit\u00e0 dei bilanciatori HAProxy.<\/i><\/p>\n

    Lo schema non \u00e8 risultato ideale: abbiamo imparato a riservare HAProxy, ma non a distribuire il carico all'interno dei servizi. Pertanto, abbiamo espanso un po' questa architettura: siamo passati al bilanciamento tra pi\u00f9 indirizzi IP pubblici.<\/p>\n

    Bilanciamento basato su DNS e BGP<\/h2>\n

    \nRimane irrisolto il problema del bilanciamento del carico davanti ai nostri HAProxy. Tuttavia, \u00e8 possibile risolverlo in modo piuttosto semplice, come abbiamo fatto noi.<\/p>\n

    Per bilanciare tre server sono necessari 3 indirizzi IP pubblici e il buon vecchio DNS. Ognuno di questi indirizzi \u00e8 definito sull'interfaccia loopback di ciascun HAProxy e viene annunciato su Internet. <\/p>\n

    In OpenStack, per la gestione delle risorse, viene utilizzato un catalogo dei servizi, in cui \u00e8 definito l'endpoint API di ciascun servizio. In questo catalogo, indichiamo il nome di dominio \u2014 public.infra.mail.ru, che viene risolto tramite DNS tramite tre indirizzi IP diversi. Di conseguenza, otteniamo una distribuzione del carico tra i tre indirizzi tramite DNS. <\/p>\n

    Ma poich\u00e9, nell'annuncio degli indirizzi IP pubblici, non gestiamo le priorit\u00e0 di selezione del server, al momento non si tratta di bilanciamento. Di solito, viene selezionato solo un server in base all'anzianit\u00e0 dell'indirizzo IP, mentre gli altri due rimarranno inattivi, poich\u00e9 non sono state specificate metriche in BGP.<\/p>\n

    Abbiamo iniziato a trasmettere percorsi tramite ExaBGP con metriche diverse. Ogni bilanciatore annuncia tutti e tre gli indirizzi IP pubblici, ma uno di essi, principale per quel bilanciatore, viene annunciato con la metrica pi\u00f9 bassa. Quindi, finch\u00e9 tutti e tre i bilanciatori sono attivi, le richieste al primo indirizzo IP vanno al primo bilanciatore, quelle al secondo al secondo, e quelle al terzo al terzo.<\/p>\n

    Cosa succede nel momento in cui uno dei bilanciatori fallisce? In caso di guasto di un bilanciatore, il suo indirizzo principale viene ancora annunciato dagli altri due, e il traffico tra di loro viene ridistribuito. In questo modo, forniamo all'utente tramite DNS immediatamente pi\u00f9 indirizzi IP. Attraverso il bilanciamento via DNS e la metrica diversa, otteniamo una distribuzione uniforme del carico su tutti e tre i bilanciatori, senza perdere la resilienza.<\/p>\n

    \"Come
    \nBilanciamento HAProxy basato su DNS + BGP<\/i><\/p>\n

    Interazione tra ExaBGP e HAProxy<\/h2>\n

    \nQuindi, abbiamo implementato la resilienza nel caso di un guasto del server, sulla base dell'interruzione dell'annuncio dei percorsi. Ma HAProxy pu\u00f2 disattivarsi anche per altri motivi, oltre al guasto del server: errori di amministrazione, guasti all'interno del servizio. Vogliamo rimuovere il bilanciatore rotto dal carico anche in questi casi, e serve un altro meccanismo. <\/p>\n

    Pertanto, espandendo la precedente configurazione, abbiamo realizzato un heartbeat tra ExaBGP e HAProxy. Questa \u00e8 un'implementazione software dell'interazione tra ExaBGP e HAProxy, dove ExaBGP utilizza script personalizzati per controllare lo stato delle applicazioni.<\/p>\n

    A tal fine, nel file di configurazione di ExaBGP \u00e8 necessario impostare un health checker in grado di verificare lo stato di HAProxy. Nel nostro caso, abbiamo configurato un health backend in HAProxy e, da parte di ExaBGP, verifichiamo con una semplice richiesta GET. Se l'annuncio smette di avvenire, HAProxy probabilmente non funziona e non deve essere annunciato. <\/p>\n

    \"Come
    \nControllo dello stato di HAProxy<\/i><\/p>\n

    Peer di HAProxy: sincronizzazione delle sessioni <\/h2>\n

    \nLa successiva operazione da effettuare \u00e8 stata sincronizzare le sessioni. Lavorando attraverso bilanciatori distribuiti, \u00e8 difficile organizzare la conservazione delle informazioni sulle sessioni dei clienti. Ma HAProxy \u00e8 uno dei pochi bilanciatori che pu\u00f2 farlo grazie alla funzionalit\u00e0 Peers, che consente il passaggio delle tabelle di sessioni tra i vari processi di HAProxy. <\/p>\n

    Esistono diversi metodi di bilanciamento: semplici, come round-robin<\/a><\/noindex>, e avanzati, in cui la sessione del cliente viene memorizzata, e ogni volta il cliente viene indirizzato allo stesso server di prima. Volevamo implementare la seconda opzione.<\/p>\n

    In HAProxy, per mantenere le sessioni del cliente, viene utilizzato il meccanismo delle stick-tables. Queste memorizzano l'indirizzo IP originale del cliente, l'indirizzo target selezionato (backend) e alcune informazioni di servizio. Di solito, le stick-tables vengono utilizzate per memorizzare la coppia source-IP + destination-IP, il che \u00e8 particolarmente utile per le applicazioni che non possono trasmettere il contesto della sessione utente quando si passa a un altro bilanciatore, ad esempio, in modalit\u00e0 bilanciamento RoundRobin.<\/p>\n

    Se la stick-table viene addestrata a spostarsi tra i diversi processi di HAProxy (tra cui avviene il bilanciamento), i nostri bilanciatori potranno lavorare con un unico pool di stick-tables. Questo consentir\u00e0 un passaggio senza soluzione di continuit\u00e0 della rete del cliente in caso di caduta di uno dei bilanciatori, e il lavoro con le sessioni dei clienti continuer\u00e0 sugli stessi backend selezionati in precedenza.<\/p>\n

    Per un funzionamento corretto, deve essere risolta la questione dell'indirizzo IP sorgente del bilanciatore da cui \u00e8 stata stabilita la sessione. Nel nostro caso, si tratta di un indirizzo dinamico sull'interfaccia loopback. <\/p>\n

    Il corretto funzionamento dei peers si realizza solo in determinate condizioni. In altre parole, i timeout TCP devono essere sufficientemente lunghi oppure il passaggio deve avvenire abbastanza rapidamente affinch\u00e9 la sessione TCP non si interrompa. Tuttavia, ci\u00f2 consente uno switch senza interruzioni. <\/p>\n

    Nel nostro IaaS abbiamo un servizio costruito con la stessa tecnologia. Questo \u00e8 Load Balancer come servizio per OpenStack<\/a><\/noindex>, chiamato Octavia. \u00c8 basato su due processi HAProxy, supporta nativamente i peers. In questo servizio, si sono rivelati molto efficaci.<\/p>\n

    Nell'immagine \u00e8 rappresentato schematicamente il trasferimento delle tabelle dei peers tra tre istanze di HAProxy, \u00e8 fornita una configurazione su come impostarla:<\/p>\n

    \"Come
    \nHAProxy Peers (sincronizzazione delle sessioni)<\/i><\/p>\n

    Se intendi implementare uno schema simile, \u00e8 necessario testarne il funzionamento con attenzione. Non \u00e8 garantito che funzioni allo stesso modo nel 100% dei casi. Tuttavia, perlomeno, non perderai le tabelle stick quando \u00e8 necessario ricordare l'IP sorgente del cliente.<\/p>\n

    Limitazione del numero di richieste simultanee da parte dello stesso cliente<\/h2>\n

    \nQualsiasi servizio accessibile pubblicamente, compresi i nostri API, pu\u00f2 essere soggetto a ondate di richieste. Le cause possono essere completamente diverse, da errori degli utenti a attacchi mirati. Siamo periodicamente soggetti a attacchi DDoS per indirizzi IP. I clienti spesso commettono errori nei loro script, creando mini-DDoS.<\/p>\n

    In ogni caso, \u00e8 necessario prevedere una protezione aggiuntiva. Una soluzione ovvia \u00e8 limitare il numero di richieste agli API per non sprecare tempo di elaborazione su richieste dannose.<\/p>\n

    Per implementare tali limitazioni utilizziamo i rate limits, organizzati sulla base di HAProxy, tramite le stesse tabelle stick. I limiti sono facili da configurare e consentono di limitare l'utente per numero di richieste agli API. L'algoritmo memorizza l'IP sorgente da cui vengono effettuate le richieste e limita il numero di richieste simultanee da un singolo utente. Naturalmente, abbiamo calcolato il profilo medio del carico sugli API per ciascun servizio e abbiamo impostato un limite di circa 10 volte superiore a questo valore. Continuiamo a monitorare attentamente la situazione, mantenendo un occhio sempre vigile.<\/p>\n

    Come appare nella pratica? Abbiamo clienti che utilizzano costantemente le nostre API per l'auto-scalabilit\u00e0. Creano circa duecento-trecento macchine virtuali al mattino e le cancellano verso sera. Per OpenStack, creare una macchina virtuale, insieme ai servizi PaaS, richiede almeno 1000 richieste API, poich\u00e9 l'interazione tra i servizi avviene anch'essa tramite API. <\/p>\n

    Questi spostamenti di carico causano un notevole sovraccarico. Abbiamo valutato questo sovraccarico, raccolto i picchi giornalieri, aumentati di dieci volte, ed \u00e8 diventato il nostro rate limit. Teniamo la mano sul polso. Spesso vediamo bot e scanner che cercano di capire se abbiamo script CGA che possono essere eseguiti e li blocchiamo attivamente.<\/p>\n

    Come aggiornare la base di codice senza che gli utenti se ne accorgano<\/h2>\n

    \nImplementiamo la tolleranza ai guasti anche a livello di processi di deployment del codice. Durante i rilasci possono verificarsi errori, ma il loro impatto sulla disponibilit\u00e0 dei servizi pu\u00f2 essere minimizzato.<\/p>\n

    Aggiorniamo continuamente i nostri servizi e dobbiamo garantire il processo di aggiornamento della base di codice senza effetti sugli utenti. Siamo riusciti a risolvere questo problema utilizzando le funzionalit\u00e0 di gestione di HAProxy e implementando il Graceful Shutdown nei nostri servizi.<\/p>\n

    Per affrontare questa sfida, era necessario garantire il controllo del bilanciatore e lo 'shutdown corretto' dei servizi:<\/p>\n