In questo articolo voglio mostrare quanto sia facile e gratuito creare uno schema di failover per un sito web (o un altro servizio online) utilizzando una combinazione di monitoraggio e un servizio di DNS dinamico. Cioè, in caso di problemi con il sito principale (dalla comparsa di un errore PHP sulla pagina, alla mancanza di spazio o a un numero sospettosamente basso di ordini in un negozio online), i nuovi visitatori verranno reindirizzati a un secondo (terzo, e così via) server che funziona, oppure a una pagina 'Spiacente', dove verrà gentilmente spiegato che 'c'è un problema, siamo già a conoscenza della situazione e stiamo già lavorando per risolverla, sarà sistemato a breve' (e in questo caso sarete già informati e in grado di intervenire).
Vivere con il failover o senza?
Finché non si verifica un problema, non c'è una grande differenza. Ma quando accade, senza un failover spesso succede quanto segue: cerchi di capire rapidamente qual è il problema, ma non ci riesci (i backup non si avviano, il software non funziona come descritto nella documentazione, ecc.), e il tempo scarseggia, i server e i siti sono giù, i clienti chiamano, tutti sono tesi, e cerchi di risolvere grossolanamente e provvisoriamente 'con un cerotto', poi sembra che parta con delle soluzioni affrettate e continua a funzionare. Pensi che dovrai approfondire la questione e rifare tutto con calma, ma non c'è nulla di più permanente del provvisorio.
Ora, come avviene nella versione ideale con il failover:
- Si verifica un errore
- L'errore viene rilevato automaticamente
- Viene inviata una notifica
- Si avvia il passaggio a uno dei server di riserva
- La problematica viene analizzata con calma e senza panico, corretta e il server viene reintegrato.
In questa configurazione, naturalmente, potrebbero sorgere dei problemi, ma in effetti è uno schema lineare; ogni fase è semplice e, soprattutto, può essere testata separatamente. Pertanto, la probabilità di un malfunzionamento di questo schema è molto più bassa e tutte le operazioni possono essere automatizzate ed eseguite rapidamente (a differenza del compito di trovare e correggere un'epica incognita). Il tuo aereo è atterrato in un paese lontano, accendi il telefono e vedi su Telegram una notifica che il server è andato giù, ma tutto va bene: si è attivato il server di riserva, puoi continuare il tuo viaggio senza dover tornare indietro o riparare via SSH dal caffè più vicino con WiFi. Te ne occuperai quando sarà più comodo.
Il futuro è già qui!
In passato, il principale problema che rendeva il failover spesso una soluzione inaccettabile era il costo. Occorreva acquistare hardware costoso (e assumere anche specialisti altrettanto costosi). Oppure si doveva assemblare un sistema complesso seguendo le guide (ho persino visto un caso in cui due server erano collegati tramite un cavo null-modem, e si scambiavano il heartbeat per far sapere al server di riserva quando prendere il controllo). Oggi ci sono soluzioni più semplici e gratuite. Se hai un sito con gattini, non hai scuse se non hai ancora implementato il failover!
Inoltre, per uno schema di failover è necessario un server (o forse più di uno) e in passato questo comportava costi elevati, mentre ora puoi prendere un VDS a poco prezzo.
Il sito più affidabile con gattini
Per illustrare praticamente la soluzione con okerr + dynamic dns, abbiamo lanciato il nostro sito con gattini . Non amiamo i gatti, quindi ce ne saranno quasi nessuno. Ci sono tre siti in totale, ognuno appare più o meno uguale (tutti utilizzano lo stesso template), ma con diversi gattini per facilitarne la distinzione, e ognuno fornisce informazioni tecniche per mostrare come funziona il failover. La pagina si aggiorna automaticamente ogni minuto, ma si può sempre premere il pulsante di ricarica nel browser.
Nelle informazioni tecniche c'è la scritta “status=OK”. A volte i server simulano problemi e mostrano status=ERR. Il server principale ‘cade’ per così dire ogni 20 minuti di ogni ora (0:20, 1:20, 2:20, …). Il server di backup ogni 40 minuti. L'ultimo server (“server di scuse”) è sempre attivo. Al minuto 0 di ogni ora, il server principale e quello di backup ‘si ristabiliscono’.
Se apri il sito e lo lasci aperto nella scheda, vedrai che non va mai giù (anche se ciascun server può simulare un problema di tanto in tanto). In caso di problemi con un server, il sito semplicemente “salta” tra i server attivi. Cambieranno l'immagine, il nome, l'indirizzo del server e il suo ruolo. A volte puoi beccare il momento in cui status=ERR (c'è già un problema, ma l'intero schema di failover non è ancora attivo), ma già il successivo aggiornamento ti mostrerà la pagina di un sito funzionante.
Failover su okerr + DNS dinamico
Vediamo come è strutturato sotto il cofano. L'obiettivo del failover è che l'indirizzo cat.okerr.com punti sempre all'IP del server attivo.
Dietro ciascuno dei server che ospitano il nostro sito di gatti in okerr c'è un indicatore che controlla il suo stato una volta al minuto.
In questa schermata vediamo come viene controllato il sito cat.okerr.com dal server alpha.okerr.com. La pagina deve contenere status=OK e, come possiamo vedere in alto, lo stato dell'indicatore è attualmente OK. Quando il server "si guasta", sarà ERR. (Questo è solo un esempio di indicatore; okerr è un servizio di monitoraggio, quindi possiamo applicare qualsiasi tipo di indicatore, come ad esempio controllare lo spazio libero su disco, il numero di nuovi ordini nel database, e anche indicatori logici, ad esempio, di notte ci saranno certi criteri di errore e di giorno altri).
Nelle impostazioni del progetto abbiamo creato uno schema di failover con questi indicatori:
Lo schema ha tre indicatori (tre server), diversi per priorità. Il server principale per il sito è charlie; se non funziona (non ci sarà "status=OK" o sarà semplicemente non disponibile), allora si passerà a bravo e, in ultima istanza, ad alpha. Nella parte destra della pagina viene mostrato lo stato del record DNS sui diversi server.
Per coloro che hanno notato che si utilizza il nome cat.he.okerr.com: utilizziamo uno schema leggermente più complesso. Invece di modificare semplicemente il record DNS di cat.okerr.com, modifichiamo cat.he.okerr.com (su un fornitore di Dynamic DNS) ), cat.okerr.com è un CNAME (alias) che non cambia, punta sempre a cat.he.okerr.com. A noi piace di più Hurricane come DNS dinamico, e ha chiavi per gestire una singola registrazione (e non l'intera zona), il che ci sembra più sicuro. Puoi anche non specificare le password-chiavi in okerr per gestire l'intero dominio, ma solo per il sottodominio o la registrazione.
Dalla caduta al rialzo
Passo dopo passo, come funziona questo schema:
- Si verifica (si simula) un problema sul server
- Il sensore okerr controlla lo stato di ciascun server ogni minuto e comunica al server principale del progetto in okerr
- L'indicatore del server corrispondente cambia stato da OK a ERR
- Quando cambia lo stato dell'indicatore, viene ricalcolato il failover, si calcola quale indirizzo deve essere impostato (se necessario. Ad esempio, se il server principale è attivo e nel frattempo è andato giù quello di riserva — non ci saranno modifiche)
- Questo indirizzo viene comunicato al servizio dynamic DNS. Una volta completato questo passaggio, a destra vedrai lo stato “synced”
- Molto presto (in pochi secondi) la registrazione arriverà ai server DNS del tuo dominio (per il sito sono ns1-ns5.he.net).
- A partire da questo momento, alcuni utenti inizieranno già a connettersi al nuovo server attivo. Tuttavia, non tutti i server DNS nel mondo hanno aggiornato le loro registrazioni, quindi in alcune posizioni potrebbero ancora restare cache delle vecchie registrazioni. È possibile osservare che i dati sui server DNS pubblici "ballano", mostrando sia il valore nuovo che quello vecchio. Aggiornando la pagina delle impostazioni failover, il sistema richiederà nuovi dati ai server DNS.
- Dopo che i dati si sono stabilizzati, la vecchia registrazione memorizzata in cache è scaduta ovunque: il 100% delle richieste viene ora indirizzato al nuovo server.
Per accelerare il settimo passo (spesso il più lungo), è necessario impostare il TTL della registrazione DNS dinamica il più basso possibile. Solitamente i servizi consentono intervalli di 90-120 secondi. Questo è un compromesso del tutto ragionevole.
Inoltre
Tutto questo può essere configurato in una sera (se hai già un server duplicato). Sia okerr che i servizi DNS dinamici sono gratuiti. Per ottenere più controlli in okerr e ridurre il tempo di verifica, è necessario seguire un corso di formazione (dalla pagina del profilo). Dopo aver completato il corso, si aumenta subito il livello (20 indicatori all'ora + 1 rapido, di 10 minuti). E se ciò non dovesse essere sufficiente, scrivi a support@okerr.com; molto probabilmente sarà possibile aumentare (fino ad ora c'è sempre stata la possibilità, non hanno mai rifiutato, al contrario, hanno anche offerto). Non voglio promettere a tutti tutto all'inizio, non sono sicuro che ci siano abbastanza risorse per mantenere la parola. Ma finora gli utenti sono pochi, quindi non ci sono problemi ad aumentare i limiti.
Cosa può fare okerr in generale — dai un'occhiata al sito . In generale, questo è un monitoraggio (Zabbix dal cloud), e il file manager è una funzione aggiuntiva gradevole. Inoltre, dal sito è possibile accedere alla demo senza registrazione.
Quando lo stato dell'indicatore cambia, viene inviata una notifica via email o Telegram. (Abbiamo controllato cosa succede e abbiamo capito che, a quanto pare, Telegram è il messenger più affidabile. Grazie al RKN per il test di stress!) Con la corretta configurazione di okerr, ogni notifica è o un segnale “abbandonate tutto, bisogna riparare!”, o “tutto a posto!”. Non ci devono essere allerte inutili da okerr (se ce ne sono, la configurazione deve essere rivista). Ad esempio, per il nostro sito di prova, il server alpha è l'ultimo e non simula mai un errore. Se si blocca, dobbiamo saperlo. Gli altri server simulano continuamente errori, quindi, per non ricevere allerte più volte all'ora, quegli indicatori hanno lo stato “silenzioso.”
Ha senso anche creare un server di scuse (su qualche hosting economico), che possa avere la vostra pagina di scuse (nel caso in cui tutti i server principali e di backup non funzionino) o indirizzarvi alla pagina di stato su okerr (ecco ad esempio la nostra ) o statuspage.io.
Fonte: habr.com
