{"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 realizzata 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 Karamychev, il responsabile del team di amministrazione dei sistemi. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Negli ultimi dodici mesi abbiamo lanciato molti nuovi prodotti. Abbiamo cercato di garantire che i servizi API fossero facilmente scalabili, resilienti e pronti a gestire un rapido aumento del carico degli utenti. La nostra piattaforma \u00e8 costruita su OpenStack e voglio raccontarvi quali problemi di resilienza dei componenti abbiamo dovuto affrontare per ottenere un sistema robusto. Penso che sar\u00e0 interessante per chi sviluppa anche prodotti su OpenStack.<\/p>\n

La resilienza complessiva della piattaforma \u00e8 composta dalla robustezza dei suoi componenti. Quindi, passeremo gradualmente attraverso tutti i livelli in cui abbiamo individuato rischi e li abbiamo mitigati.<\/p>\n

Puoi vedere la versione video di questa storia, originata da un intervento alla conferenza Uptime Day 4, organizzata da ITSumma<\/a><\/noindex>, su YouTube-Channel Uptime Community<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Resilienza dell'architettura fisica<\/h2>\n

\nLa parte pubblica del cloud MCS si basa attualmente su due data center di livello Tier III, con una connessione in fibra ottica dedicata e riservata a livello fisico tramite percorsi diversi, con una capacit\u00e0 di 200 Gbit\/s. Il livello Tier III assicura il necessario livello di resilienza dell'infrastruttura fisica. <\/p>\n

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

Ad esempio, di recente, durante dei lavori in un pozzetto vicino a uno dei data center, un escavatore ha colpito un tubo, all'interno del quale si trovavano sia il cavo in fibra ottica principale che quello di riserva. Il nostro canale resiliente con il data center \u00e8 risultato vulnerabile in un singolo punto, nel pozzetto. Pertanto, abbiamo perso parte dell'infrastruttura. Abbiamo tratto delle conclusioni e intrapreso una serie di azioni, tra cui la posa di ulteriore fibra ottica in un pozzetto adiacente.<\/p><\/blockquote>\n

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

In caso di guasto del fornitore, 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 assorbe tutto il carico.<\/p>\n

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

Cosa usiamo per la resilienza a livello applicativo<\/h2>\n

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

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

HAProxy<\/b> \u2014 un bilanciatore di carico ad alta intensit\u00e0, che consente di impostare regole molto flessibili per il bilanciamento del traffico a 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>(di seguito semplicemente worker) \u2014 nei servizi OpenStack, \u00e8 un demone infrastrutturale che consente di trasmettere comandi API all'infrastruttura. Ad esempio, la creazione di un disco avviene proprio nel worker, mentre la richiesta di creazione \u00e8 nell'API application. <\/p>\n

Architettura standard di OpenStack Application<\/h2>\n

\nLa maggior parte dei servizi sviluppati per OpenStack cerca di seguire un'unica par\u00f2di. Il servizio in genere consiste di 2 parti: API e worker (esecutori backend). Di norma, l'API \u00e8 un'applicazione WSGI in python, che viene eseguita come processo autonomo (demone) o tramite un server web come Nginx o Apache. L'API gestisce la richiesta dell'utente e trasmette ulteriori istruzioni all'applicazione worker. La trasmissione avviene tramite un broker di messaggi, di solito RabbitMQ, mentre gli altri sono poco supportati. Quando i messaggi raggiungono il broker, vengono elaborati dai worker e, se necessario, restituiscono una risposta. <\/p>\n

Questa particolare architettura implica punti di guasto isolati: RabbitMQ e il database. Tuttavia, RabbitMQ \u00e8 isolato all'interno di un singolo servizio e, idealmente, pu\u00f2 essere dedicato a ciascun servizio. Pertanto, noi di MCS separiamo al massimo questi servizi, creando un database e un RabbitMQ separati per ogni progetto. Questo approccio \u00e8 vantaggioso perch\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 applicazioni worker non \u00e8 limitato, quindi l'API pu\u00f2 facilmente scalare orizzontalmente attraverso i bilanciatori per aumentare le prestazioni e la tolleranza agli errori.<\/p>\n

In alcuni servizi \u00e8 necessaria una coordinazione interna \u2014 quando si verificano operazioni complesse e sequenziali tra API e worker. In questo caso, si utilizza un centro di coordinazione unificato, un sistema cluster come Redis, Memcache, etcd, che permette a un worker di comunicare a un altro che questo compito \u00e8 assegnato a lui (\"tu, per favore, non occuparcene\"). Noi utilizziamo etcd. Di norma, i worker interagiscono attivamente con il database, scrivendo e leggendo informazioni. Come database utilizziamo mariadb, che si trova in un cluster multimaster.\n<\/p><\/blockquote>\n

\nQuesto classico servizio singolo \u00e8 organizzato in modo convenzionale per OpenStack. Pu\u00f2 essere visto come un sistema chiuso, per il quale sono chiari i metodi di scalabilit\u00e0 e tolleranza agli errori. Ad esempio, per garantire la tolleranza agli errori, \u00e8 sufficiente mettere un bilanciatore davanti all'API. La scalabilit\u00e0 dei worker \u00e8 ottenuta aumentando il loro numero. <\/p>\n

Il punto debole di tutto lo schema \u00e8 rappresentato da RabbitMQ e MariaDB. La loro architettura merita un articolo a parte. In questo articolo voglio concentrarmi sulla tolleranza agli errori dell'API.<\/p>\n

\"Come
\nArchitettura Openstack Application. Bilanciamento e tolleranza agli errori della piattaforma cloud<\/i><\/p>\n

Rendiamo il bilanciatore HAProxy tollerante agli errori con ExaBGP<\/h2>\n

\nPer garantire che le nostre API siano scalabili, veloci e tolleranti agli errori, abbiamo posto un bilanciatore davanti a loro. Abbiamo scelto HAProxy. A mio avviso, possiede tutte le caratteristiche necessarie per il nostro compito: bilanciamento a pi\u00f9 livelli OSI, interfaccia di gestione, flessibilit\u00e0 e scalabilit\u00e0, ampia gamma di metodi di bilanciamento, supporto per le tabelle di sessione.<\/p>\n

Il primo problema da risolvere \u00e8 la tolleranza agli errori del bilanciatore stesso. L'installazione di un bilanciatore crea anch'essa un punto di guasto: se il bilanciatore si guasta, il servizio crolla. Per evitare ci\u00f2, abbiamo utilizzato HAProxy insieme a ExaBGP.<\/p>\n

ExaBGP consente l'implementazione di un meccanismo di monitoraggio 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 ciascuno dei server creiamo un'interfaccia loopback.<\/li>\n
  3. Su tutti e tre i server configuriamo lo stesso indirizzo IP pubblico per questa interfaccia.<\/li>\n
  4. L'indirizzo IP pubblico viene annunciato su Internet tramite ExaBGP. <\/li>\n<\/ol>\n

    \nLa tolleranza agli errori \u00e8 raggiunta 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, in base alla propria metrica, il pi\u00f9 prioritario (di solito \u00e8 sempre lo stesso) e il traffico va solo su uno dei server. <\/p>\n

    In caso di problemi con HAProxy o di guasto di un server, ExaBGP smette di annunciare il percorso e il traffico si sposta gradualmente su un altro server. <\/p>\n

    Cos\u00ec abbiamo ottenuto la tolleranza agli errori del bilanciatore.<\/p>\n

    \"Come
    \nTolleranza agli errori dei bilanciatori HAProxy<\/i><\/p>\n

    Lo schema risultante non \u00e8 ideale: abbiamo imparato a riservare HAProxy, ma non a distribuire il carico all'interno dei servizi. Pertanto, abbiamo leggermente ampliato questo schema: siamo passati a un bilanciamento tra pi\u00f9 indirizzi IP pubblici.<\/p>\n

    Bilanciamento basato su DNS pi\u00f9 BGP<\/h2>\n

    \nRimane irrisolto il problema della distribuzione del carico davanti ai nostri HAProxy. Tuttavia, questo pu\u00f2 essere risolto piuttosto semplicemente, come abbiamo fatto noi.<\/p>\n

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

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

    Tuttavia, poich\u00e9 non gestiamo le priorit\u00e0 di selezione del server durante l'annuncio degli indirizzi IP pubblici, finch\u00e9 non si tratta di bilanciamento. Di solito, verr\u00e0 selezionato solo un server in base alla anzianit\u00e0 dell'indirizzo IP, mentre gli altri due rimarranno inattivi poich\u00e9 non sono specificate metriche in BGP.<\/p>\n

    Abbiamo iniziato a pubblicare le rotte 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 minima. Cos\u00ec, finch\u00e9 tutti e tre i bilanciatori sono operativi, le richieste al primo indirizzo IP vanno al primo bilanciatore, le richieste al secondo al secondo, e al terzo al terzo.<\/p>\n

    Cosa succede nel momento in cui uno dei bilanciatori si guasta? In caso di guasto di uno qualsiasi dei bilanciatori, l'indirizzo principale viene comunque annunciato dagli altri due, e il traffico tra di loro viene ridistribuito. In questo modo, restituiamo all'utente attraverso DNS diversi indirizzi IP. Attraverso il bilanciamento DNS e metriche diverse otteniamo una distribuzione uniforme del carico su tutti e tre i bilanciatori, senza compromettere 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 in caso di uscita di un server, basata sulla cessazione dell'annuncio delle rotte. Ma HAProxy pu\u00f2 disattivarsi per altri motivi oltre al guasto del server: errori di amministrazione, malfunzionamenti interni del servizio. Vogliamo rimuovere il bilanciatore guasto dal carico anche in questi casi, e ci serve un altro meccanismo. <\/p>\n

    Pertanto, ampliando lo schema precedente, abbiamo implementato un heartbeat tra ExaBGP e HAProxy. Questa \u00e8 un'implementazione software dell'interazione tra ExaBGP e HAProxy, in cui ExaBGP utilizza script personalizzati per controllare lo stato delle applicazioni.<\/p>\n

    Per questo, nel file di configurazione di ExaBGP, \u00e8 necessario impostare un health checker che possa verificare lo stato di HAProxy. Nel nostro caso, abbiamo impostato il backend di health in HAProxy, mentre dal lato di ExaBGP controlliamo con una semplice richiesta GET. Se l'annuncio smette di avvenire, HAProxy probabilmente non funziona, e non \u00e8 necessario annunciarlo. <\/p>\n

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

    HAProxy Peers: sincronizzazione delle sessioni <\/h2>\n

    \nLa prossima cosa da fare \u00e8 sincronizzare le sessioni. Quando si lavora attraverso bilanciatori distribuiti, \u00e8 difficile organizzare la conservazione delle informazioni sulle sessioni dei clienti. Ma HAProxy \u00e8 uno dei pochi bilanciatori in grado di farlo grazie alla funzionalit\u00e0 Peers, che consente di trasmettere tra diversi processi HAProxy le tabelle delle sessioni. <\/p>\n

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

    In HAProxy, per mantenere le sessioni del cliente, si utilizzano stick-tables. Queste memorizzano l'indirizzo IP originale del cliente, l'indirizzo del target scelto (backend) e alcune informazioni di servizio. Di solito, le stick-table vengono utilizzate per salvare la coppia source-IP + destination-IP, il che \u00e8 particolarmente utile per le applicazioni che non possono trasmettere il contesto della sessione dell'utente quando cambiano bilanciatore, come nel caso del bilanciamento RoundRobin.<\/p>\n

    Se si insegna alla stick-table a muoversi tra i diversi processi di HAProxy (tra i quali avviene il bilanciamento), i nostri bilanciatori potranno lavorare con un unico pool di stick-table. Questo abiliter\u00e0 uno switching senza soluzione di continuit\u00e0 della rete del cliente in caso di guasto di uno dei bilanciatori, e la gestione delle sessioni dei clienti continuer\u00e0 sugli stessi backend precedentemente selezionati.<\/p>\n

    Per un corretto funzionamento deve essere risolto il problema dell'indirizzo IP di origine 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 ottiene solo in determinate condizioni. Cio\u00e8, i timeout TCP devono essere sufficientemente grandi o il passaggio deve essere abbastanza veloce, affinch\u00e9 la sessione TCP non venga interrotta. Tuttavia, questo consente uno switching senza soluzione di continuit\u00e0. <\/p>\n

    Nella nostra IaaS, abbiamo un servizio costruito con la stessa tecnologia. \u00c8 Load Balancer come servizio per OpenStack<\/a><\/noindex>, chiamato Octavia. Si basa su due processi HAProxy e supporta inizialmente i peers. In questo servizio, si sono dimostrati molto efficaci.<\/p>\n

    Nell'immagine \u00e8 schematicamente rappresentato il movimento delle tabelle dei peers tra tre istanze HAProxy, con una configurazione proposta su come impostarlo:<\/p>\n

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

    Se implementerete uno schema simile, \u00e8 necessario testare attentamente il suo funzionamento. Non \u00e8 garantito che funzioni allo stesso modo nel 100% dei casi. Ma, almeno, non perderete le stick-table quando \u00e8 necessario ricordare l'IP del cliente.<\/p>\n

    Limitazione del numero di richieste simultanee da un singolo cliente<\/h2>\n

    \nQualsiasi servizio reso pubblico, compresi i nostri API, pu\u00f2 essere soggetto a picchi di richieste. Le cause possono variare, dagli errori degli utenti agli attacchi mirati. Periodicamente subiamo attacchi DDoS per indirizzo IP. I clienti spesso commettono errori nei loro script, causando mini-DDoS.<\/p>\n

    In ogni caso, \u00e8 necessario prevedere una protezione aggiuntiva. Una soluzione ovvia \u00e8 limitare il numero di richieste alle API e risparmiare tempo di elaborazione per le richieste dannose.<\/p>\n

    Per implementare tali limitazioni utilizziamo i rate limits, organizzati su HAProxy, tramite le stick tables. I limiti vengono configurati in modo semplice e consentono di limitare l'utente nel numero di richieste alle API. L'algoritmo memorizza l'indirizzo 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 sulle API per ogni servizio e stabilito un limite di circa 10 volte superiore a questo valore. Continuiamo a monitorare attentamente la situazione, tenendo il polso della situazione.<\/p>\n

    Come si presenta in pratica? Abbiamo clienti che utilizzano costantemente le nostre API per il ridimensionamento automatico. Creano circa duecento- trecento macchine virtuali al mattino e le eliminano in serata. Per OpenStack, creare una macchina virtuale, specialmente con i servizi PaaS, richiede almeno 1000 richieste API, poich\u00e9 l'interazione tra i servizi avviene anch'essa tramite API. <\/p>\n

    Tali flussi di lavoro generano un carico significativo. Abbiamo valutato questo carico, raccolto i picchi giornalieri, incrementati dieci volte, e questo \u00e8 diventato il nostro rate limit. Rimaniamo vigili. Spesso osserviamo bot e scanner che cercano di capire se abbiamo degli script CGA che possono essere eseguiti, e li blocchiamo attivamente.<\/p>\n

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

    \nImplementiamo la resilienza anche a livello di processi di distribuzione del codice. Durante i deploy possono verificarsi errori, ma possiamo minimizzare il loro impatto sulla disponibilit\u00e0 dei servizi.<\/p>\n

    Aggiorniamo costantemente i nostri servizi e dobbiamo garantire un processo di aggiornamento della base di codice senza effetti per gli utenti. Questa sfida \u00e8 stata risolta utilizzando le funzionalit\u00e0 di gestione di HAProxy e implementando il Graceful Shutdown nei nostri servizi.<\/p>\n

    Per affrontare questa problematica, \u00e8 necessario garantire la gestione del bilanciatore e una corretta disattivazione dei servizi:<\/p>\n