Settimana scorsa ho avuto un’interessante scambio di opinioni con un cliente: possiede due sedi distinte, a 5 km una dall’altra, già connesse in fibra e con due san che replicano tra di loro le lun. Direte voi: è perfetto per attivare Site Recovery Manager. E infatti è quello che avevo già proposto come secondo step dopo l’avvio del cluster ESX di produzione.
Beh, il cliente obiettava che avendo attivo il protocollo SMLT di Nortel, lo stesso indirizzo ip è attivabile in punti diversi della rete. Perciò basterebbe mettere alcuni nodi del cluster nella sede secondaria, avere le lun in mirroring e avremmo un cluster geografico senza bisogno di SRM.
Effettivamente un’argomentazione simile a prima vista è difficile da obiettare, non trovate? Nonostante ciò SRM ha ancora dei vantaggi che risultano più comprensibili ipotizzando un fail completo del sito primario:
- le VM ripartono nell’ordine che decidiamo (quindi prima i domain controller ad esempio, poi il resto)
- si può concatenare l’avvio di alcune VM al corretto avvio di altre (per esempio non avvio i web server se prima il cluster SQL non è funzionante)
- posso arrestare alcune VM che già giravano nel sito DR per fare spazio alle VM in recovery
- posso avere specifici resource pool di DR, diversi da quelli di produzione, per gestire ad esempio potenze di calcolo differenti tra i due siti
- possiamo usare la “test bubble” per simulare il failover
- il report di simulazione mi da l’esito ma anche i tempi di ogni operazione. In questo modo posso sapere in anticipo quanto disservizio posso aspettarmi da ogni singola VM, e nel caso correggerlo
Quindi alla fine, a mio avviso, l’unico contro potrebbe essere il prezzo (21117 dollari per processore sono parecchi). Ma se un cliente possiede due sedi, ognuna dotata di datacenter comprensivo di SAN in fibra con replica geografica, forse il budget non è poi così striminzito…