[actech78]

Originariamente inviato da Tasslehoff

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

Ciao!

Ti ringrazio per l'esaustiva risposta... in queste ultime settimana l'azienda ha acquistato un server identico al primo, con medesimo sistema operativo (win server 2008 R2 foundation) almeno per evitare che non fosse più prodotto nei medesimi componenti.

Rimane il dilemma di cosa fare in caso di blocco del primo server, premetto che anche se per pochi minuti dovesse mancare un flusso di dati non succederebbe un disastro, quindi una soluzione economica sicuramente è la migliore. Per quanto riguarda il Ghost (o simili) sicuramente possiamo farlo visto che al momento una copia immagine del sistema manca, ci sono solo backup singoli (con l'app nativa di win) dei vari documenti, database ecc..

La soluzione failover cluster potrebbe fare al caso mio? Non ho ben chiaro il suo funzionamento ma il SO supporta tale funzione, leggendo un pò in Internet mi pare di aver capito che è necessario un NAS/SAN dedicato da collegare ai due server 1+2 (quindi presumo che entrambi i server debbano avere almeno 2 porte ethernet giusto?), quindi mi ritroverei un ip virtuale dei due server, entrambe le macchine sarebbero connesse al NAS/SAN direttamente tramite una porta ETH dedicata, mentre l'altra porta ETH andrebbe allo switch/LAN con altro indirizzo IP è corretto ?

Se l'installazione non dovesse essere complessa potrei tantare in questo modo, vorrei solo capire se va bene per le nostre esigenze ed eventualmente che NAS/SAN acquistare, un'altra cosa che non mi è chiara è cosa dovrei installare nel 2° server, una copia perfetta del 1° ?

Scusate le domande banali