Disaster Recovery per SBS 2008

[panella.e]

nella mia azienda stiamo facendo un upgrade del server per passare da SBS 2003 a SBS 2008 con sostituzione anche dell'HW.
Questo server sarà controller di dominio, server di Exchange (50 utenti) e proxy internet, altri servizi e archiviazione dati sono ospitati su altre macchine. Vorremmo premunirci di un disaster recovery in modo che in caso di guasto si possa ripartire nel minor tempo possibile. In passato abbiamo adottato diverse soluzioni con macchine ridondate identiche e sincronizzate fra loro con un software della Dell ma che in realtà non hanno mai funzionato bene nel momento del bisogno, quindi adesso che stiamo affrontando questa spesa vorremmo colmare questa lacuna al meglio, cosa mi potete consigliare in merito?

[Tasslehoff]

L'unica soluzione di disaster recovery realmente funzionante su Windows è il ghost, imho non c'è verso, vista l'architettura di windows, l'uso che fa dei filesystem e il modo in cui il software interagisce con l'OS (es chiavi di registro, servizi e quant'altro) imho rende necessario il ghost.
Inoltre Windows rende agevole questa operazione grazie alla tecnologia VSS.

Per farlo a caldo le soluzioni imho sono due:
1) blasonata e costosa: Acronis True Image Echo, con quale scheduli ghost a caldo pianificando per bene (es ghost full settimanale e differenziale giorno per giorno).
Costo: circa 2500 euro per server
2) economica, funzionale e leggera: Drive Snapshot, fai lo stesso, scheduli tramite lo schedulatore interno di windows e crei snapshot su storage logale (es una lun ad-hoc) o su condivisioni cifs/samba.
Costo: 89 euro per server.

Io ho appena testato Drive Snapshot su un server Lotus Domino (os Win2000 server) con 140GB di db di posta e oltre 200 utenze attive che accedono via POP, IMAP, Webmail, client Notes e connessioni SMTP che vanno e vengono a vagonate.
Snapshot fatto a caldo senza fermare nulla, ripristinato su virtual machine vmware: OS e Domino sono partiti senza colpo ferire, perfetti!
Tieni conto che il test con Domino è ancora più significativo vista l'architettura del servizio stesso, che tiene tutto quello che concerne un db (documenti, form, agenti, html, pagine, allegati, configurazione etc etc) dentro un singolo file nsf, nel mio caso senza nemmeno usare alcuna logica transazionale

Se invece stai pensando a soluzioni di business continuity legate ai servizi onestamente non credo di essere di grande aiuto, passi per un cluster Windows di failover (quello si fa in un attimo con il servizio Cluster Manager), ma per quanto riguarda Exchange onestamente non ti posso dire nulla; aborrisco quel servizio, è una vita che cerca di riprodurre (senza riuscirci) features che Lotus Domino ha da una vita (es repliche o clustering, che su Domino si attiva in 5 minuti 5 ).

[panella.e]

ma invece un recovery immediato o meglio un server completamente ridondato che in caso di failover del primario sia già costantemente sincronizzato e in grado di essere operativo già da subito, senza necessità di dover ricorrere a ripristini di backup precedenti?
In passato abbiamo avuto doubletake ma non ha mai funzionato ed è stato un vero buco nell'acqua, anche se l'idea non era male

[Tasslehoff]

Originariamente inviato da panella.e

ma invece un recovery immediato o meglio un server completamente ridondato che in caso di failover del primario sia già costantemente sincronizzato e in grado di essere operativo già da subito, senza necessità di dover ricorrere a ripristini di backup precedenti?
In passato abbiamo avuto doubletake ma non ha mai funzionato ed è stato un vero buco nell'acqua, anche se l'idea non era male

Come dicevo prima potresti fare un cluster di failover, attivo-passivo per intenderci.

Non conosco Exchange, però se si potesse definire in modo preciso e ben delineato il path dei database e della configurazione potresti tenere questi dati sulla lun di un san e mettere il servizio in ascolto sull'ip di un alias.
A questo punto potresti configurare il server gemello (il nodo passivo) allo stesso identico modo e metterli in cluster; il nodo passivo continuerebbe a monitorare il funzionamento del nodo attivo mediante una interfaccia di rete di heartbeat, nel caso non dovesse rispondere dovrebbe attivare l'alias, montare la lun della san contenente i dati di Exchange e far partire il servizio.

Quella del cluster attivo-passivo è una configurazione piuttosto standard e molto diffusa, però non conoscendo Exchange non ti posso dire come configurarla nel dettaglio, anzi a dire il vero non ho molta esperienza di cluster con Windows, tutti quelli che ho amministrato e configurato erano tutti cluster RedHat; il principio cmq è lo stesso che ti ho descritto sopra.

Se invece volessi implementare un cluster di load balancing dovresti configurare un cluster applicativo Exchange, o cmq fare in modo che i due nodi si tengano costantemente sincronizzati.
A una conferenza in cui si confrontavano Lotus Domino e MS Exchange ho sentito parlare di repliche tra server Exchange, ma si trattava di una cosa piuttosto complessa ed estremamente grezza rispetto alla replica di database usata da Lotus Domino, per non parlare del clustering.

A quanto ne so il tuo è un problema abbastanza diffuso, conosco diverse persone che si sono trovate nella medesima situazione, gente partita con Exchange invogliata da Outlook e dalla licenza inclusa con SBS, che poi però se n'è pentita quando si è resa conto che si tratta di un servizio pensato male, realizzato peggio e che non ha nemmeno la metà delle features della concorrenza, mentre l'altra metà l'ha recuperata con 10 anni di ritardo
Io a tutte queste persone ho sempre ripetuto che sarebbe stato meglio investire i soldi della licenza di SBS in una licenza Lotus Domino (installabile anche su una distribuzione free tipo CentOS o OpenSuse, IBM inoltre non è schizzinosa sul supporto e lo fornisce anche se non si rispettano esattamente i requisiti del software), si sarebbero ritrovati con un sistema molto più facilmente gestibile e con molte più funzionalità, sicurezza, integrazione etc etc...