In questo articolo voglio mostrare quanto sia facile e gratuito creare uno schema di failover per un sito web (o qualsiasi altro servizio internet) utilizzando una combinazione di monitoraggio e un servizio DNS dinamico. Cioè, in caso di problemi con il sito principale (che vanno da un errore 'PHP Error' sulla pagina, fino alla mancanza di spazio o a un numero sospettosamente basso di ordini in un negozio online), i nuovi visitatori verranno indirizzati a un secondo (terzo e così via) server noto per funzionare, oppure su una pagina 'Mi dispiace', dove verrà gentilmente spiegato che 'c'è un problema, ne siamo già a conoscenza e stiamo già risolvendo, sarà sistemato a breve' (e in questo caso sarete effettivamente a conoscenza della situazione e potrete apportare le correzioni necessarie).
Vivere con o senza failover?
Fino a quando non si verifica un problema, non c'è una gran differenza. Ma quando accade, senza failover spesso succede quanto segue: cerchi di capire rapidamente qual è il problema, ma non riesci (i backup non si avviano, il software non funziona per qualche motivo come indicato nella documentazione, ecc.), e non c'è tempo, i server e i siti sono fuori servizio, i clienti chiamano, tutti sono tesi, cerchi di sistemare le cose in modo grossolano e disordinato 'con del nastro adesivo', poi in qualche modo sembra iniziare a funzionare con delle soluzioni temporanee. Pensi che dovrai prenderti il tempo per approfondire e sistemare tutto in modo ordinato, ma non c'è niente di più permanente del temporaneo.
Ora, come funziona nella versione elegante con il failover:
- Si verifica un errore
- L'errore viene rilevato automaticamente
- Viene inviata una notifica
- Si effettua il passaggio a uno dei server di riserva
- Il problema viene esaminato in modo calmo e senza panico, corretto e il server torna operativo.
In questo schema, di certo possono sorgere dei problemi, ma in ogni caso, la procedura è lineare, ogni fase qui è semplice e la cosa principale è che può essere testata separatamente, quindi la probabilità di errore di questo schema è molto più bassa, e tutte le azioni possono essere automatizzate ed eseguite rapidamente (a differenza del compito di trovare e correggere un'ignota e epica seccatura). Il tuo aereo è atterrato in un paese lontano, accendi il telefono e vedi su Telegram una notifica che il server è caduto, ma tutto va bene, è stato attivato il server di riserva, puoi continuare il tuo viaggio, non hai bisogno di volare indietro né di sistemare via SSH dal caffè più vicino con WiFi. Ti occuperai della situazione quando ti sarà più comodo.
Il futuro è già qui!
In passato, il principale problema che rendeva il failover spesso una soluzione inaccettabile era il costo associato. Era necessario acquistare costose attrezzature (e chiamare specialisti ancora più costosi). Oppure si doveva improvvisare qualcosa di complicato seguendo guide (ho visto anche un'opzione in cui due server erano collegati tramite un cavo null-modem e comunicavano heartbeat affinché, al momento giusto, il server secondario potesse rilevare e prendere il controllo). Ora ci sono modi più semplici e gratuiti. Se avete un sito con gattini, non avete scuse se non avete già implementato il failover per esso!
Inoltre, per uno schema di failover è necessario un ulteriore server (o forse più di uno) e in passato questo comportava spese enormi, mentre ora si può ottenere un VDS a basso costo.
Il sito più affidabile con gattini
Per illustrare praticamene la soluzione con okerr + DNS dinamico, abbiamo lanciato il nostro sito con gattini . In realtà, odiamo i gattini, quindi ce ne saranno pochi. Ci sono tre siti, ognuno appare all'incirca uguale (tutti basati su un modello), ma con diversi gattini per essere facilmente distinguibili e ognuno fornisce informazioni tecniche per mostrare come funziona il failover. La pagina si aggiorna automaticamente ogni minuto, ma è sempre possibile premere il tasto di ricarica nel browser.
Nelle informazioni tecniche c'è la riga "status=OK". A volte i server simulano problemi e riportano status=ERR. Il server principale "cade" per così dire ogni 20 minuti di ogni ora (0:20, 1:20, 2:20, ...). Il server secondario (backup) lo fa ogni 40 minuti. L'ultimo server (il server "scusate") è sempre attivo. A 0 minuti di ogni ora, il server principale e quello secondario "si ripristinano".
Se aprite il sito e lo lasciate aperto in una scheda, vedrete che non smette mai di funzionare (anche se ogni singolo server simula periodicamente un problema), e in caso di problemi con un server, semplicemente "salta" tra i server attivi. Cambierà l'immagine, il nome e l'indirizzo del server e il suo ruolo. A volte è possibile cogliere il momento in cui status=ERR (un problema è già presente, ma l'intero schema di failover non è ancora scattato), ma il successivo aggiornamento vi mostrerà la pagina di un sito funzionante.
Failover su okerr + DNS dinamico
Diamo un'occhiata a come è strutturato sotto il cofano. L'obiettivo del failover è quello di fare in modo che l'indirizzo cat.okerr.com punti sempre all'indirizzo IP del server attivo.
Dietro ognuno dei server che ospita il nostro sito di gatti in okerr c'è un indicatore che controlla il suo stato ogni minuto.
In questo screenshot vediamo come viene controllato il sito cat.okerr.com dal server alpha.okerr.com. La pagina dovrebbe contenere status=OK e come possiamo vedere in alto, lo stato dell'indicatore attualmente è OK. Quando il server si 'rompe', sarà ERR. (Questo è solo un esempio di indicatore, okerr è un monitoraggio, quindi è possibile attaccare qualsiasi tipo di indicatore, ad esempio controllare lo spazio disponibile su disco, il numero di nuovi ordini nel database e persino indicatori logici, ad esempio, di notte ci saranno alcuni criteri di errore e di giorno altri).
Nelle impostazioni del progetto abbiamo creato uno schema di failover con questi indicatori:
Nello schema ci sono tre indicatori (tre server), diversi per priorità. Il server principale per il sito è charlie; se non funziona (non avrà 'status=OK' o sarà semplicemente non disponibile), allora bravo, e in ultimo caso — alpha. Nella parte destra della pagina viene mostrato lo stato del record DNS su diversi server.
Per coloro che hanno notato che viene utilizzato il nome cat.he.okerr.com: utilizziamo uno schema un po' più complesso. Invece di modificare semplicemente il record DNS cat.okerr.com, modifichiamo cat.he.okerr.com (su un provider di Dynamic DNS ), e cat.okerr.com è un CNAME (alias) che non cambia, punta sempre a cat.he.okerr.com. A noi piace semplicemente di più Hurricane come DNS dinamico e ha chiavi per gestire un singolo record (e non l'intera zona), riteniamo che sia più sicuro. Puoi anche non specificare in okerr le password-chiavi per gestire l'intero dominio, ma solo per il sottodominio o il record.
Da caduta a ripresa
Passo dopo passo, come funziona questo schema:
- Si verifica (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, determinando quale indirizzo deve essere impostato (se necessario. Ad esempio, se il server principale è attivo e nel frattempo il server secondario è andato giù, non ci saranno modifiche).
- Questo indirizzo viene comunicato al servizio di dynamic DNS. Al termine di questa fase, sulla destra vedrete lo stato 'synced'.
- Very soon (in seconds), the record will reach your domain's DNS servers (for the cat site, this is ns1-ns5.he.net).
- A partire da questo momento, alcuni utenti accederanno già al nuovo server live. Ma non tutti i server DNS nel mondo hanno ancora aggiornato le loro registrazioni, e altrove potrebbe essere ancora memorizzata la registrazione precedente. Puoi vedere come i dati sui server DNS pubblici 'ballano', mostrando ora il nuovo, ora il vecchio valore. Aggiornando la pagina delle impostazioni del failover, okerr richiederà automaticamente nuovi dati dai server DNS.
- Dopo che i dati si sono stabilizzati, la vecchia registrazione memorizzata è scaduta ovunque: tutte le richieste, il 100%, vengono indirizzate al nuovo server.
Per accelerare il settimo passo (spesso il più lungo), è necessario impostare il TTL della registrazione DNS dinamica il più basso possibile. Di solito, i servizi consentono intervalli di 90-120 secondi. Questo è un compromesso ragionevole.
Inoltre
Tutto questo può essere configurato in una sera (se hai già un server di backup). Sia okerr che i servizi DNS dinamici sono gratuiti. Per ottenere in okerr più controlli e periodi di verifica più brevi, è necessario seguire un training (dalla pagina del profilo). Dopo aver completato il training, il livello aumenta immediatamente (20 controlli all'ora + 1 veloce, di 10 minuti). E se saranno pochi, scrivi a support@okerr.com, molto probabilmente sarà possibile aumentare (fino ad ora c'è sempre stata questa possibilità, non sono mai stato rifiutato, anzi, è stato lui a proporre). Non voglio promettere a tutti tutto in principio, non sono sicuro che ci siano risorse sufficienti per mantenere la parola. Ma per ora 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, è un monitoraggio (zabbix dal cloud), e il failover è una funzione aggiuntiva gradevole. Inoltre, dal sito puoi accedere alla demo senza registrazione.
Quando lo stato dell'indicatore cambia, viene inviata una notifica via email o Telegram. (Abbiamo osservato cosa sta succedendo e abbiamo capito che, sembra, Telegram è il messenger più affidabile. Grazie a RKN per il test di stress!) Con una corretta configurazione di okerr, ogni notifica è un segnale di "lascia tutto, dobbiamo riparare!", o "annullato!". Non ci dovrebbero essere allerta inutili da okerr (se ci sono, è necessario configurare diversamente). Ad esempio, per il nostro sito di gatti, il server alpha è l'ultimo e non simula mai un errore. Se cade, dobbiamo saperlo. Gli altri server, invece, simulano continuamente errori, quindi, per non ricevere allerta più volte all'ora, quegli indicatori hanno lo stato 'silenzioso'.
Ha senso anche creare un server di scuse (su qualsiasi hosting economico), che avrà o la vostra pagina di scuse (nel caso in cui tutti i server principali e di backup siano inattivi) o che reindirizzerà alla pagina di stato su okerr (ad esempio, la nostra ) o statuspage.io.
Fonte: habr.com
