Host di riserva hot vs host di riserva cold?

Abbiamo diversi host in cui abbiamo un host hot spare identico, che è patchato e aggiornato, quindi è molto vicino avere lo stesso software e la stessa configurazione. In caso di guasto, il cavo di rete viene commutato e il server DHCP viene aggiornato con il nuovo indirizzo MAC. Questo è il caso migliore, poiché di solito ce ne sono alcuni che richiedono modifiche.

Penso che sia uno spreco di energia elettrica avere un host di riserva caldo e una perdita di tempo per mantenerlo, e poiché sono necessarie modifiche alla configurazione in caso di failover, vorrei chiedere quanto segue:

Gli host hot spare sono vecchia scuola e ora ci sono modi migliori?

Invece di avere un host hot spare, avrebbe senso trasformarlo in un cold spare, prendere i dischi rigidi e metterli nell'host primario e cambiare il RAID da 1 a 1 + 1. In caso di guasto, tutto ciò che dovrei fare è cambiare i cavi di rete, aggiornare il server DHCP, prendere i dischi rigidi e inserirli nella riserva fredda e accenderli. Il vantaggio, a mio avviso, è che i dischi 2x2 sono sempre sincronizzati, quindi solo un host da mantenere e non sono necessarie modifiche alla configurazione in caso di failover.

È una buona idea?

Sobrique spiega come l'intervento manuale fa sì che la soluzione proposta sia super -ottimale e ewwhite parla della probabilità di guasto di vari componenti . Entrambe le IMO danno ottimi punti e dovrebbero essere fortemente considerate.

C'è tuttavia un problema che nessuno sembra aver commentato finora, il che mi sorprende un po '. Proponi di:

rendere [l'attuale host hot spare] un cold spare, prendere i dischi rigidi e metterli nell'host primario e cambiare il RAID da 1 a 1 + 1.

Questo non ti protegge da tutto ciò che il sistema operativo fa sul disco.

Ti protegge davvero solo dai guasti del disco, che spostandoti dai mirror (RAID 1) ai mirror dei mirror (RAID 1 + 1) riduci notevolmente l'impatto di per cominciare. È possibile ottenere lo stesso risultato aumentando il numero di dischi in ciascun set di mirror (passare da RAID 1 a 2 dischi a RAID 1 a 4 dischi, ad esempio), oltre a migliorare molto probabilmente le prestazioni di lettura durante le normali operazioni.

Bene, diamo un'occhiata ad alcuni modi in cui questo potrebbe fallire .

• Supponiamo che tu stia installando aggiornamenti di sistema e che qualcosa non riesca a metà del processo; forse c'è un guasto all'alimentazione e all'UPS , o forse hai un incidente strano e colpisci un bug del kernel paralizzante (Linux è abbastanza affidabile in questi giorni, ma c'è ancora il rischio).
• Forse un aggiornamento introduce un problema che non hai riscontrato durante il test (esegui test degli aggiornamenti di sistema, giusto?) Che richiede un failover sul sistema secondario mentre ripari il primario
• Forse un bug nel codice del file system provoca scritture spurie e non valide sul disco.
• Forse un amministratore malizioso (o addirittura malizioso) lo fa rm -rf ../*o rm -rf /*invece di rm -rf ./*.
• Forse un bug nel tuo software provoca un grave danneggiamento del contenuto del database.
• Forse un virus riesce a intrufolarsi.

Forse, forse, forse ... (e sono sicuro che ci sono molti altri modi in cui il tuo approccio proposto potrebbe fallire.) Tuttavia, alla fine questo si riduce al tuo "vantaggio" i due set sono sempre in sincronia. A volte non vuoi che siano perfettamente sincronizzati.

A seconda di ciò che è esattamente accaduto, è quando si desidera che uno standby caldo o freddo sia pronto per essere acceso e ripetuto o backup adeguati. In entrambi i casi, i mirror RAID dei mirror (o mirror RAID) non ti aiutano se la modalità di errore comporta molto altro a parte l'errore del dispositivo di archiviazione hardware (crash del disco). Qualcosa come il raidzN di ZFS può probabilmente fare un po 'meglio per alcuni aspetti, ma per niente migliore in altri.

Per me, questo renderebbe il tuo approccio proposto un no-go dall'inizio se l'intento è una sorta di failover di emergenza.

Sì, è un po 'vecchia scuola. L'hardware moderno non fallisce così spesso. Concentrati sul rendere le tue applicazioni più altamente disponibili (non sempre possibile) o sugli elementi necessari per rendere i tuoi host più resilienti ...

Per gli host:

• Acquista hardware migliore.
• Assicurati di avere contratti di supporto.
• REGISTRA i contratti di supporto dei tuoi server (i pezzi di ricambio vengono stoccati localmente in base ai dati di registrazione!)
• Utilizzare alimentatori ridondanti, RAID (hardware?), Ventole ridondanti.
• Se il server non è in grado di supportare le funzionalità ridondanti sopra indicate, tenere a portata di mano uno chassis o componenti di ricambio per poter effettuare l'autoriparazione in caso di guasto.

In ordine decrescente di frequenza degli errori, vedo: dischi, RAM, alimentatori, ventole il più delle volte ... A volte scheda di sistema o CPU. Ma questi ultimi due sono i punti in cui dovrebbe entrare il tuo contratto di supporto.

È piuttosto inefficiente, non da ultimo a causa della dipendenza dall'intervento manuale per effettuare il passaggio.

Ho lavorato in luoghi che gestiscono un sito DR caldo - letteralmente, server identici a quelli primari, pronti a partire immediatamente. Tuttavia, la commutazione DR è un processo automatizzato: non stiamo parlando di cavi, un po 'di armeggi e di commutazione, ma un processo quando premiamo il pulsante capovolge tutto da un sito all'altro.

Questo approccio è terribilmente costoso, ma è una decisione aziendale - rischio accettabile rispetto al denaro necessario per raggiungere l'obiettivo. Di norma, esiste una curva esponenziale sull'obiettivo del tempo di recupero: più si avvicina allo zero, più costa.

Ma questa è la tua domanda, davvero. Qual è l'obiettivo del tempo di recupero e qual è il modo più efficace per raggiungerlo. Attendere l'avvio di un server richiederà alcuni minuti. Quanto tempo impiega qualcuno a eseguire le regolazioni e le "attività di ripristino" quando viene visualizzato alle 4 del mattino?

E quanto dura un'interruzione accettabile?

Suggerirei che se stai facendo un 'recupero a caldo' vuoi pensare al clustering. Puoi essere abbastanza economico sul clustering con un buon uso di VMWare - "failover" su una VM - anche da un fisico - significa che non stai eseguendo hardware ridondante. (Bene, N + 1 anziché 2N).

Se l'RTO è abbastanza lungo, spegnere la scatola. È possibile che l'RTO sia sufficiente e che una ricostruzione a freddo dal backup sia corretta.

Il fatto che si tratti della vecchia scuola non rende necessariamente un cattivo uso una cattiva idea.

La tua preoccupazione principale dovrebbe essere la logica, quali sono i rischi che corri e in che modo eseguirli con un hot spare li mitiga. Perché nella mia percezione il tuo hot spare risolve solo i guasti hardware, che non è raro, né l'unico rischio operativo che corri, né il più probabile. La seconda preoccupazione è che le strategie alternative offrono una maggiore riduzione del rischio o risparmi significativi.

L'esecuzione di un hot spare con più passaggi manuali di failover richiederà molto tempo ed è probabile che vada storto, ma mi sembra anche un failover automatizzato con le suite di cluster HA che si trasformano in importanti cluster *.

Un'altra cosa è che lo standby a caldo o freddo nella stessa posizione non garantisce la continuità aziendale in caso di disastro locale.

Il concetto di avere una riserva calda o anche fredda dipende dal modo in cui le applicazioni sono costruite in primo luogo.

Quello che voglio dire è che se l'applicazione è stata costruita in modo tale che il carico di dati e servizi sia distribuito su più macchine, allora il concetto di ogni singola macchina che abbatte il sistema dovrebbe sparire. In quella situazione non è necessario un hot spare. Invece hai bisogno di una capacità in eccesso sufficiente per gestire quando una singola macchina / componente muore.

Ad esempio, un'applicazione Web standard richiede generalmente un server Web e un server di database. Per i server Web, basta caricare il saldo 2 o più. Se uno muore, niente di grosso. Il database di solito è più difficile in quanto deve essere progettato per essere multi-master con tutti i dati sincronizzati tra le macchine partecipanti. Quindi, invece di un singolo server DB, si ottengono 2 (o più) che soddisfano entrambi le esigenze dei dati. I grandi fornitori di servizi come Google, Amazon, Facebook, ecc. Hanno seguito questa strada. I tempi di sviluppo sono più costosi, ma paga dividendi se è necessario ridimensionarli.

Ora, se la tua applicazione non è strutturata in questo modo o è semplicemente proibitivo adattarla in modo retrò all'app, allora probabilmente vorrai un hot spare.