View Single Post
Old 08-11-2012, 17:43   #2
Tasslehoff
Senior Member
 
L'Avatar di Tasslehoff
 
Iscritto dal: Nov 2001
Città: Kendermore
Messaggi: 6659
Partiamo dal presupposto che senza implementare qualche architettura clusterizzata in caso di disastro qualunque soluzione presuppone un tempo più o meno lungo di recovery.
La lunghezza del recovery può variare in base a parecchi fattori, se ad esempio ti limiti a fare un backup dei db ma non del sistema operativo e dei binari del dbms, in caso di disastro il tempo che ti servirà a ripristinare sarà: t(OS) + t(BIN) + t(restore)
dove t(OS) è il tempo necessario a reinstallare l'OS, t(BIN) è il tempo necessario a reinstallare il servizio, t(restore) è il tempo necessario a ripristinare il backup.

Affiancando al backup dei db un ghost del sistema operativo riduci t(OS) e t(BIN) ad un'unica operazione di ripristino del ghost (che generalmente si riduce principalmente a tempo macchina, mentre la reinstallazione presuppone anche una notevole quantità di tempo uomo per la riconfigurazione dell'OS e dei servizi), a cui farà seguito il restore del backup dei db.

Questo in linea generale per aver ben presente quello che puoi fare per migliorare l'attuale procedura di disaster recovery senza imbarcarti in architetture più complesse (e quindi più fragili a prescindere).

Se invece vuoi proprio uno switch a caldo da un nodo all'altro in caso di guasto ci sono soluzioni di clustering active-active o soluzionei active-passive.
Le prime hanno il vantaggio di non generare alcuna interruzione nel passaggio da un nodo all'altro, però sono generalmente più costose da implementare e devono essere usate correttamente anche dai servizi che utilizzano il db (es Oracle RAC).
Le seconde hanno il vantaggio di essere più economiche e più semplici da implementare, però nel passaggio dei servizi da un nodo all'altro richiedono un certo gap temporale per riassegnare le risorse e riattivare i servizi (gap che può essere di qualche secondo o minuto, resta il fatto che l'interruzione c'è e gli eventuali servizi che usano quelle risorse possono interrompersi o generare errori).

Questo per quanto riguarda l'architettura, una volta deciso che approccio seguire occorre dotarsi dell'hardware e del software necessario a mettere in pratica tutto questo, es storage condiviso (NAS o SAN), licenze etc etc.
In questo caso però preparatevi a mettere mano al portafogli
__________________
https://tasslehoff.burrfoot.it | Cloud? Enough is enough! | SPID… grazie ma no grazie
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say."
Tasslehoff è offline   Rispondi citando il messaggio o parte di esso