Evan colpisce alcuni punti positivi, ma qui ci sono forse alcuni modi specifici per ottenere un tempo di recupero inferiore a 1 ora a fronte di guasti.
Piccola impresa probabilmente significa piccolo hardware, quindi potrebbe non essere un sacco di costi fare alcune cose semplici che in realtà aggiungono una quantità significativa di resilienza di fronte ai problemi. L'idea principale è avere l'hardware aggiuntivo pronto per l'uso.
Innanzitutto, mettiti comodo con il pensiero di un IP virtuale. Questo è l'indirizzo IP con cui gli utenti parleranno, ma può risiedere su qualsiasi server a cui lo dai. Questo è l'indirizzo IP che sei gli utenti e le applicazioni vorranno parlare. E sarà la più utile in definitiva per qualsiasi soluzione tu scelga. Avere un VIP significa che non dovresti dover riconfigurare nessuna delle applicazioni quando esegui il failover. Inoltre, tieni presente che avere hardware ridondante ha anche l'impatto di un sovraccarico amministrativo, facendo due aggiornamenti di configurazione invece di 1.
Se iniziamo con il tuo server proxy di routing / web, è probabilmente il più semplice poiché il loro non sarà uno stato reale che deve essere archiviato sulla scatola stessa. Quindi basta ottenere un duplicato della stessa scatola e configurarlo allo stesso modo. Terrei entrambi collegati al segmento LAN, e supponendo che tu sia internet su un'altra interfaccia, scamberei i cavi se il loro è un errore. Dal punto di vista del routing, imposti tutti i tuoi client lan per indirizzare l'indirizzo .1 (VIP) per la loro route predefinita e il server proxy fornisce al server A l'indirizzo .2 e al server B l'indirizzo .3. In questo modo possono entrambi essere gestiti per gli aggiornamenti di configurazione (vale per entrambi). E tutto ciò che devi fare per eseguire il failover è rimuovere l'assegnazione IP .1 da .2 e spostarla su .3, quindi spostare la connessione Internet sull'altra interfaccia. Non è molto complicato, facile da fare e da capire, e costa l'hardware aggiuntivo di una seconda scatola. Se riesci a ottenere ridondanza sul lato Internet, potresti aggiungere un po 'di complessità e ottenere il failover automatico usando qualcosa come VRRP.
Senza specifiche, è difficile da dire, ma il tuo server web potrebbe essere altrettanto semplice. Aggiungi un secondo server con configurazione identica, crea un vIP tra i due e sposta il VIP sul backup di fronte al fallimento. In genere non mi dispiace se lo stato della sessione viene perso in caso di failover (è un problema critico causare un failover). Quindi, se gli utenti devono accedere di nuovo, non è un grosso problema. Ancora una volta, vrrp può essere probabilmente utilizzato per il failover automatico.
Passando al tuo DB, questo è significativamente più complesso. La maggior parte dei DB ha una sorta di modello primario / secondario, in cui si esegue il backup del DB originale sul secondario, quindi si copiano tutti i registri delle transazioni o le modifiche del DB sul secondario. Ancora una volta, è possibile combinare questo con i VIP per le applicazioni / gli utenti che accedono effettivamente al DB. Tuttavia, il failover è più complicato. A seconda dell'errore del primario, potrebbe essere necessario mettere in funzione le unità per copiare e conservare i registri delle transazioni. Quindi porta l'attivo secondario. Se riesci a tollerare alcuni dati persi, puoi portare subito l'attivo secondario. Dopo il failover, il server B ora sei il principale e il tuo lavoro sarebbe ripristinare il server A e trasformarlo nel nuovo backup in modo che sia pronto per il fallimento quando il server b alla fine ha problemi.
I file server sono sempre la parte più difficile, poiché a differenza dei DB, è molto più difficile ottenere una funzionalità integrata del file system. Tuttavia, è possibile raggiungere un certo livello di resilienza disponendo di un secondo server e scrivere semplicemente uno script che scansiona il filesystem alla ricerca di modifiche e copia tutti i nuovi file su di te secondari. Fondamentalmente puoi eseguire rsync su un cron che credo per farlo. Ancora una volta, usi un VIP che dai agli utenti, che ti sposterai in caso di failover. Nel tuo script, ti consiglio caldamente di verificare che il sistema sia il proprietario del VIP prima di trasferire i file. Davvero davvero non vuoi che rsync venga eseguito nella direzione sbagliata e sovrascrivi le modifiche che stai facendo gli utenti. Questo potrebbe perdere alcuni file se il loro è un errore,
Non ho idea di cosa potresti fare sul tuo sistema telefonico ... dipende davvero dal venditore e da come è configurato. Il fornitore potrebbe avere una soluzione pronta all'uso per la resilienza.
Alcune ultime parole di avvertimento. Assicurati di testare accuratamente tutte le impostazioni che stai per seguire. Assicurati di sapere come eseguire il failover senza perdere tali informazioni critiche. Test test test per assicurarsi che funzionerà quando ne hai bisogno. Accertarsi di disporre di processi in grado di applicare correttamente le modifiche alla configurazione, gli aggiornamenti del software, ecc. Sia ai backup primari che a quelli di backup. La buona notizia è che probabilmente è possibile eseguire il failover controllato quando si desidera arrestare un server per l'aggiornamento, ecc. Non è un'impostazione attiva-attiva, quindi non si ha idea se il secondario funzionerà quando è necessario.
Lavoro nelle telecomunicazioni e le nostre apparecchiature sono estremamente ridondanti, incluso nella maggior parte dei casi la ridondanza geo-grafica. Il nostro punto di errore numero 1 è la ridondanza non viene testata dopo le modifiche e gli utenti apportano modifiche che non sanno come funziona il modello di ridondanza. Tuttavia, abbiamo l'ulteriore problema che tutte le nostre apparecchiature devono supportare il failover automatico in non più di alcuni secondi. Puoi tollerare un intervento manuale nei failover se devi essere attivo e funzionante entro 30-60 minuti. Devi solo essere preparato. In bocca al lupo.