Il web moderno è quasi impensabile senza contenuti multimediali: quasi tutte le nonne hanno uno smartphone, tutti sono sui social network e i tempi di inattività nella manutenzione sono costosi per le aziende. Ecco una trascrizione della storia dell'azienda su come ha organizzato la consegna delle foto utilizzando una soluzione hardware, quali problemi di prestazioni ha riscontrato durante il processo, cosa li ha causati e come questi problemi sono stati risolti utilizzando una soluzione software basata su Nginx, garantendo allo stesso tempo la tolleranza agli errori a tutti i livelli (). Ringraziamo gli autori della storia di Oleg Efimova e Alexandra Dymova, che hanno condiviso la loro esperienza alla conferenza .
— Iniziamo con una piccola introduzione su come archiviamo e memorizziamo nella cache le foto. Abbiamo un livello in cui le memorizziamo e un livello in cui memorizziamo nella cache le foto. Allo stesso tempo, se vogliamo raggiungere un elevato tasso di trucchi e ridurre il carico sullo spazio di archiviazione, per noi è importante che ogni foto di un singolo utente si trovi su un server di caching. Altrimenti, dovremmo installare tante volte più dischi quanti sono i nostri server. La nostra percentuale di trick è intorno al 99%, ovvero stiamo riducendo il carico sul nostro storage di 100 volte e per fare questo, 10 anni fa, quando tutto questo veniva costruito, avevamo 50 server. Di conseguenza, per poter servire queste foto, avevamo bisogno essenzialmente di 50 domini esterni serviti da questi server.
Naturalmente è subito sorta la domanda: se uno dei nostri server si blocca e non è più disponibile, quale parte del traffico perdiamo? Abbiamo esaminato cosa c'era sul mercato e abbiamo deciso di acquistare un componente hardware in modo che risolvesse tutti i nostri problemi. La scelta è caduta sulla soluzione dell'azienda della rete F5 (che, tra l'altro, ha recentemente acquistato NGINX, Inc): BIG-IP Local Traffic Manager.
Cosa fa questo componente hardware (LTM): è un router di ferro che rende ridondante le sue porte esterne e consente di instradare il traffico in base alla topologia di rete, ad alcune impostazioni ed esegue controlli di integrità. Per noi era importante che questo componente hardware potesse essere programmato. Di conseguenza, potremmo descrivere la logica con cui le fotografie di un utente specifico sono state servite da una cache specifica. Che cosa sembra? C'è un componente hardware che esamina Internet su un dominio, un IP, esegue l'offload SSL, analizza le richieste http, seleziona un numero di cache da IRule, dove andare e lascia che il traffico vada lì. Allo stesso tempo, esegue controlli sanitari e, nel caso in cui qualche macchina non fosse disponibile, in quel momento abbiamo fatto in modo che il traffico andasse a un server di backup. Dal punto di vista della configurazione ci sono, ovviamente, alcune sfumature, ma in generale tutto è abbastanza semplice: registriamo una carta, corrisponde un certo numero al nostro IP sulla rete, diciamo che ascolteremo sulle porte 80 e 443, diciamo che se il server non è disponibile, allora è necessario inviare traffico a quello di backup, in questo caso il 35, e descriviamo un sacco di logica su come smontare questa architettura. L'unico problema era che il linguaggio in cui era programmato l'hardware era Tcl. Se qualcuno se lo ricorda... questo linguaggio è più di sola scrittura che un linguaggio conveniente per la programmazione:
Cosa abbiamo ottenuto? Abbiamo ricevuto un componente hardware che garantisce un'elevata disponibilità della nostra infrastruttura, instrada tutto il nostro traffico, offre benefici per la salute e funziona semplicemente. Inoltre funziona da parecchio tempo: negli ultimi 10 anni non ci sono state lamentele al riguardo. All’inizio del 2018 inviavamo già circa 80 foto al secondo. Si tratta di circa 80 gigabit di traffico da entrambi i nostri data center.
Tuttavia ...
All’inizio del 2018 abbiamo visto un brutto quadro nelle classifiche: il tempo necessario per inviare le foto era chiaramente aumentato. E ha smesso di soddisfarci. Il problema è che questo comportamento era visibile solo durante i picchi di traffico: per la nostra azienda si tratta della notte tra domenica e lunedì. Ma per il resto del tempo il sistema si è comportato come al solito, senza segni di cedimento.
Tuttavia il problema doveva essere risolto. Abbiamo identificato i possibili colli di bottiglia e abbiamo iniziato ad eliminarli. Naturalmente prima di tutto abbiamo ampliato gli uplink esterni, condotto un audit completo degli uplink interni e individuato tutti i possibili colli di bottiglia. Ma tutto ciò non ha dato un risultato evidente, il problema non è scomparso.
Un altro possibile collo di bottiglia era rappresentato dalle prestazioni delle cache fotografiche stesse. E abbiamo deciso che forse il problema dipende da loro. Bene, abbiamo ampliato le prestazioni, principalmente le porte di rete sulle cache delle foto. Ma ancora una volta non è stato riscontrato alcun miglioramento evidente. Alla fine, abbiamo prestato molta attenzione alle prestazioni dell'LTM stesso, e qui abbiamo visto un'immagine triste sui grafici: il carico su tutte le CPU inizia a funzionare senza intoppi, ma poi improvvisamente raggiunge un plateau. Allo stesso tempo, LTM smette di rispondere adeguatamente ai controlli di integrità e agli uplink e inizia a disattivarli in modo casuale, il che porta a un grave degrado delle prestazioni.
Cioè, abbiamo individuato la fonte del problema, individuato il collo di bottiglia. Resta da decidere cosa faremo.
La prima cosa più ovvia che potremmo fare è modernizzare in qualche modo la LTM stessa. Ma ci sono alcune sfumature qui, perché questo hardware è piuttosto unico, non andrai al supermercato più vicino e lo comprerai. Questo è un contratto separato, un contratto di licenza separato e richiederà molto tempo. La seconda opzione è iniziare a pensare con la propria testa, trovare la propria soluzione utilizzando i propri componenti, preferibilmente utilizzando un programma ad accesso aperto. Resta solo da decidere cosa sceglieremo esattamente per questo e quanto tempo dedicheremo alla risoluzione di questo problema, perché gli utenti non hanno ricevuto abbastanza foto. Pertanto, dobbiamo fare tutto questo molto, molto rapidamente, si potrebbe dire ieri.
Dato che il compito sembrava "fare qualcosa il più rapidamente possibile e utilizzando l'hardware di cui disponiamo", la prima cosa che abbiamo pensato è stata semplicemente quella di rimuovere alcune macchine non molto potenti dal fronte, mettere lì Nginx, con il quale sappiamo come fare. lavorare e provare a implementare la stessa logica utilizzata dall'hardware. Cioè, infatti, abbiamo abbandonato il nostro hardware, installato altri 4 server che dovevamo configurare, creato per loro domini esterni, simile a come avveniva 10 anni fa... Perdevamo un po' di disponibilità se queste macchine cadevano, ma ancor meno, hanno risolto localmente il problema dei nostri utenti.
Di conseguenza, la logica rimane la stessa: installiamo Nginx, può eseguire l'offload SSL, possiamo in qualche modo programmare la logica di routing, i controlli di integrità nelle configurazioni e semplicemente duplicare la logica che avevamo prima.
Sediamoci per scrivere le configurazioni. All'inizio sembrava che tutto fosse molto semplice, ma purtroppo è molto difficile trovare manuali per ogni compito. Sconsigliamo quindi di cercare semplicemente su Google “come configurare Nginx per le foto”: meglio fare riferimento alla documentazione ufficiale, che indicherà quali impostazioni toccare. Ma è meglio scegliere tu stesso il parametro specifico. Bene, allora è tutto semplice: descriviamo i server di cui disponiamo, descriviamo i certificati... Ma la cosa più interessante è proprio la logica di routing stessa.
All'inizio ci è sembrato che stessimo semplicemente descrivendo la nostra posizione, abbinando il numero della nostra cache di foto in essa contenuta, usando le nostre mani o un generatore per descrivere di quanti upstream abbiamo bisogno, in ogni upstream indichiamo il server a cui dovrebbe passare il traffico vai e un server di backup - se il server principale non è disponibile:
Ma, probabilmente, se tutto fosse così semplice, torneremmo semplicemente a casa e non diremmo nulla. Sfortunatamente, con le impostazioni predefinite di Nginx, che, in generale, sono state realizzate nel corso di molti anni di sviluppo e non sono del tutto adatte a questo caso... la configurazione assomiglia a questa: se qualche server upstream ha un errore di richiesta o un timeout, Nginx sempre sposta il traffico a quello successivo. Inoltre, dopo il primo guasto, entro 10 secondi verrà spento anche il server, sia per errore che per timeout, che non è nemmeno configurabile in alcun modo. Cioè, se rimuoviamo o reimpostiamo l'opzione di timeout nella direttiva upstream, anche se Nginx non elaborerà questa richiesta e risponderà con qualche errore non molto positivo, il server si spegnerà.
Per evitare ciò, abbiamo fatto due cose:
a) hanno proibito a Nginx di farlo manualmente e, sfortunatamente, l'unico modo per farlo è semplicemente impostare le impostazioni di massimo errore.
b) ci siamo ricordati che in altri progetti utilizziamo un modulo che ci consente di effettuare controlli sanitari di base - di conseguenza, abbiamo effettuato controlli sanitari abbastanza frequenti in modo che i tempi di inattività in caso di incidente fossero minimi.
Sfortunatamente, anche questo non è tutto, perché letteralmente le prime due settimane di funzionamento di questo schema hanno dimostrato che anche il controllo dello stato TCP è una cosa inaffidabile: sul server upstream potrebbe non essere Nginx, o Nginx in D-state, e in in questo caso il kernel accetterà la connessione, il controllo dello stato passerà, ma non funzionerà. Pertanto, lo abbiamo immediatamente sostituito con un http di controllo dello stato, ne abbiamo creato uno specifico che, se restituisce 200, tutto funziona in questo script. Puoi eseguire una logica aggiuntiva: ad esempio, nel caso dei server di memorizzazione nella cache, controlla che il file system sia montato correttamente:
E questo ci andrebbe bene, tranne per il fatto che in questo momento il circuito ripeteva completamente ciò che faceva l'hardware. Ma volevamo fare meglio. In precedenza, avevamo un server di backup e questo probabilmente non è molto buono, perché se hai un centinaio di server, quando diversi falliscono contemporaneamente, è improbabile che un server di backup possa far fronte al carico. Pertanto, abbiamo deciso di distribuire la prenotazione su tutti i server: abbiamo semplicemente creato un altro upstream separato, scritto lì tutti i server con determinati parametri in base al carico che possono servire, aggiunto gli stessi controlli di salute che avevamo prima :
Poiché è impossibile andare a un altro upstream all'interno di un upstream, era necessario assicurarsi che se l'upstream principale, in cui abbiamo semplicemente registrato la cache delle foto corretta e necessaria, non fosse disponibile, avremmo semplicemente passato attraverso la error_page al fallback, da dove siamo andati al backup a monte:
E aggiungendo letteralmente quattro server, questo è ciò che abbiamo ottenuto: abbiamo sostituito parte del carico, lo abbiamo rimosso da LTM su questi server, abbiamo implementato lì la stessa logica, utilizzando hardware e software standard, e abbiamo immediatamente ricevuto il bonus che questi server possono essere ridimensionati, perché possono essere semplicemente forniti quanto necessario. Ebbene, l'unico aspetto negativo è che abbiamo perso l'elevata disponibilità per gli utenti esterni. Ma in quel momento abbiamo dovuto sacrificare questo, perché era necessario risolvere subito il problema. Quindi, abbiamo rimosso parte del carico, a quel tempo era circa il 40%, LTM si sentiva bene e, letteralmente due settimane dopo l'inizio del problema, abbiamo iniziato a inviare non 45 richieste al secondo, ma 55. In effetti, siamo cresciuti del 20%: questo è chiaramente il traffico che non abbiamo fornito all'utente. E successivamente hanno iniziato a pensare a come risolvere il problema rimanente: garantire un'elevata accessibilità esterna.
Abbiamo avuto una pausa, durante la quale abbiamo discusso quale soluzione avremmo utilizzato per questo. Sono state avanzate proposte per garantire l'affidabilità utilizzando DNS, utilizzando alcuni script scritti in casa, protocolli di routing dinamico... c'erano molte opzioni, ma era già chiaro che per una consegna veramente affidabile delle foto, è necessario introdurre un altro livello che monitorerà questo . Abbiamo chiamato queste macchine registi fotografici. Il software a cui ci siamo affidati è stato Keepalived:
Per cominciare, in cosa consiste Keepalived? Il primo è il protocollo VRRP, ampiamente noto ai networker, situato sulle apparecchiature di rete che fornisce tolleranza agli errori per l'indirizzo IP esterno a cui si connettono i client. La seconda parte è IPVS, server virtuale IP, per il bilanciamento tra router fotografici e per garantire la tolleranza agli errori a questo livello. E terzo: controlli sanitari.
Cominciamo con la prima parte: VRRP: che aspetto ha? Esiste un determinato IP virtuale, che ha una voce nel DNS badoocdn.com, a cui si connettono i client. Ad un certo punto, abbiamo un indirizzo IP su un server. I pacchetti keepalived vengono eseguiti tra i server utilizzando il protocollo VRRP e se il master scompare dal radar - il server si è riavviato o qualcos'altro, il server di backup rileva automaticamente questo indirizzo IP - non sono necessarie azioni manuali. La differenza tra master e backup è principalmente la priorità: più è alta, maggiori sono le possibilità che la macchina diventi master. Un grande vantaggio è che non è necessario configurare gli indirizzi IP sul server stesso, è sufficiente descriverli nella configurazione e se gli indirizzi IP necessitano di regole di routing personalizzate, questo viene descritto direttamente nella configurazione, utilizzando il comando stessa sintassi descritta nel pacchetto VRRP. Non incontrerai cose sconosciute.
Come si presenta in pratica? Cosa succede se uno dei server fallisce? Non appena il master scompare, il nostro backup smette di ricevere pubblicità e diventa automaticamente master. Dopo un po ', abbiamo riparato il master, riavviato, aumentato Keepalived: gli annunci arrivano con una priorità più alta rispetto al backup e il backup torna automaticamente indietro, rimuove gli indirizzi IP, non è necessario eseguire azioni manuali.
In questo modo abbiamo garantito la tolleranza agli errori dell'indirizzo IP esterno. La parte successiva è bilanciare in qualche modo il traffico dall'indirizzo IP esterno ai router fotografici che lo stanno già terminando. Tutto è abbastanza chiaro con i protocolli di bilanciamento. Si tratta di un semplice round-robin o di cose leggermente più complesse, wrr, connessione a elenchi e così via. Questo è sostanzialmente descritto nella documentazione, non c'è niente di speciale. Ma il metodo di consegna... Qui daremo un'occhiata più da vicino al motivo per cui ne abbiamo scelto uno. Questi sono NAT, Direct Routing e TUN. Il fatto è che abbiamo immediatamente pianificato di fornire 100 gigabit di traffico dai siti. Se fai una stima, avrai bisogno di 10 schede gigabit, giusto? 10 schede Gigabit in un server vanno già oltre la portata, almeno, del nostro concetto di "attrezzatura standard". E poi ci siamo ricordati che non regaliamo solo traffico, regaliamo foto.
Cosa c'è di speciale? — Enorme differenza tra traffico in entrata e in uscita. Il traffico in entrata è molto piccolo, il traffico in uscita è molto grande:
Se guardi questi grafici, puoi vedere che in questo momento il regista riceve circa 200 MB al secondo, questa è una giornata molto normale. Restituiamo 4,500 MB al secondo, il nostro rapporto è di circa 1/22. È già chiaro che per fornire completamente il traffico in uscita a 22 server di lavoro, ne abbiamo bisogno solo uno che accetti questa connessione. È qui che ci viene in aiuto l’algoritmo di routing diretto.
Che cosa sembra? Il nostro direttore delle foto, secondo la sua tabella, trasmette le connessioni ai router fotografici. Ma i router fotografici inviano il traffico di ritorno direttamente a Internet, lo inviano al cliente, non torna indietro attraverso il photodirector, quindi, con un numero minimo di macchine, garantiamo la completa tolleranza agli errori e il pompaggio di tutto il traffico. Nelle configurazioni appare così: specifichiamo l'algoritmo, nel nostro caso è un semplice rr, forniamo il metodo di instradamento diretto e poi iniziamo a elencare tutti i real server, quanti ne abbiamo. Che determinerà questo traffico. Se abbiamo uno o due server in più, o più server, si presenta questa necessità: aggiungiamo semplicemente questa sezione alla configurazione e non ci preoccupiamo troppo. Dal lato dei real server, dal lato del router fotografico, questo metodo richiede la configurazione minima, è perfettamente descritto nella documentazione e non ci sono insidie.
La cosa particolarmente bella è che una soluzione del genere non implica una riprogettazione radicale della rete locale; questo per noi era importante; dovevamo risolverlo con costi minimi. Se guardi , poi vedremo come appare. Qui abbiamo un certo server virtuale, sulla porta 443, ascolta, accetta la connessione, tutti i server funzionanti sono elencati e puoi vedere che la connessione è, più o meno, la stessa. Se guardiamo le statistiche sullo stesso server virtuale, abbiamo pacchetti in entrata, connessioni in entrata, ma assolutamente nessuna in uscita. Le connessioni in uscita vanno direttamente al client. Ok, siamo riusciti a sbilanciarlo. Ora, cosa succede se uno dei nostri router fotografici si guasta? Dopotutto, il ferro è ferro. Potrebbe andare in panico nel kernel, potrebbe rompersi, l'alimentatore potrebbe bruciarsi. Nulla. Ecco perché sono necessari controlli sanitari. Possono essere semplici come controllare come è aperta la porta, o qualcosa di più complesso, fino ad alcuni script scritti in casa che controlleranno anche la logica aziendale.
Ci siamo fermati da qualche parte nel mezzo: abbiamo una richiesta https in una posizione specifica, viene chiamato lo script, se risponde con una 200esima risposta, crediamo che tutto vada bene con questo server, che sia vivo e possa essere acceso abbastanza facilmente.
Come si presenta, ancora una volta, nella pratica? Spegniamo il server per la manutenzione, ad esempio aggiornando il BIOS. Nei log abbiamo subito un timeout, vediamo la prima riga, poi dopo tre tentativi viene contrassegnata come “non riuscita” e viene semplicemente rimossa dall'elenco.
È anche possibile una seconda opzione di comportamento, quando VS è semplicemente impostato su zero, ma se la foto viene restituita, questo non funziona bene. Il server si avvia, Nginx si avvia lì, il controllo dello stato capisce immediatamente che la connessione funziona, che va tutto bene, e il server appare nel nostro elenco e il carico inizia immediatamente ad essere applicato ad esso. Non sono richieste azioni manuali da parte dell'amministratore di turno. Il server si è riavviato di notte: il dipartimento di monitoraggio non ci chiama di notte per questo. Ti informano che è successo questo, va tutto bene.
Quindi, in modo abbastanza semplice, con l'aiuto di un piccolo numero di server, abbiamo risolto il problema della tolleranza agli errori esterni.
Tutto ciò che resta da dire è che tutto ciò, ovviamente, deve essere monitorato. Separatamente, va notato che Keepalivede, come software scritto molto tempo fa, ha molti modi per monitorarlo, entrambi utilizzando controlli tramite DBus, SMTP, SNMP e Zabbix standard. Inoltre, lui stesso sa scrivere lettere per quasi ogni starnuto e, a dire il vero, a un certo punto abbiamo anche pensato di disattivarlo, perché scrive moltissime lettere per ogni cambio di traffico, accensione, per ogni connessione IP, e così via. Naturalmente, se ci sono molti server, puoi sopraffarti con queste lettere. Monitoriamo nginx sui router fotografici utilizzando metodi standard e il monitoraggio dell'hardware non è scomparso. Naturalmente consigliamo altre due cose: innanzitutto i controlli esterni e la disponibilità, perché anche se tutto funziona, infatti, forse gli utenti non ricevono le foto a causa di problemi con fornitori esterni o per qualcosa di più complesso. Vale sempre la pena tenere da qualche parte su un'altra rete, in Amazon o da qualche altra parte, una macchina separata in grado di eseguire il ping dei server dall'esterno, e vale anche la pena utilizzare il rilevamento delle anomalie, per coloro che sanno come eseguire il complicato apprendimento automatico, o il semplice monitoraggio , almeno per tenere traccia se le richieste sono diminuite drasticamente, o, al contrario, sono aumentate. Può anche essere utile.
Riassumiamo: abbiamo infatti sostituito la soluzione ferrea, che a un certo punto ha smesso di soddisfarci, con un sistema abbastanza semplice che fa tutto allo stesso modo, cioè prevede la terminazione del traffico HTTPS e un ulteriore routing intelligente con necessari controlli sanitari. Abbiamo aumentato la stabilità di questo sistema, cioè abbiamo ancora un'elevata disponibilità per ogni livello, in più abbiamo il vantaggio che è abbastanza facile scalare il tutto su ogni livello, perché si tratta di hardware standard con software standard, cioè , abbiamo semplificato la diagnosi dei possibili problemi.
Cosa abbiamo ottenuto? Abbiamo avuto un problema durante le vacanze di gennaio 2018. Nei primi sei mesi in cui abbiamo messo in funzione questo schema, lo abbiamo esteso a tutto il traffico per rimuovere tutto il traffico da LTM, siamo cresciuti solo nel traffico in un data center da 40 gigabit a 60 gigabit e allo stesso tempo per durante l’intero anno 2018 sono stati in grado di inviare quasi tre volte più foto al secondo.
Fonte: habr.com