Con la virtualizzazione cambiano gli equilibri della programmazione e del bilanciamento delle risorse.
Come una partita a scacchi, gli uomini dell’IT devono ragionare di strategia, valutando bene le loro mosse. Con una premessa fondamentale: per garantire la continuità operativa agli utenti e al business anche le applicazioni virtualizzate devono essere ridondate.
Hyper-V Replica è una soluzione progettata da Microsoft che consente di controllare le modifiche apportate su una macchina virtuale, copiandole su un server secondario. Il problema è che questo avviene secondo intervalli di tempo prestabiliti. Quali sono i casi in cui vale la pena ospitare applicazioni in Hyper-V Replica, dunque?
Deduplicazione ridondata per garantire business continuity e controllo
Come si evince dal nome, Hyper-V Replica è progettato per replicare il contenuto di una macchina virtuale da un server primario a un altro server localizzato nel sito di disaster recovery. Al’insorgere di un evento disastroso, il carico di lavoro virtualizzato tramite un comando manuale viene spostato in linea sul sito ridondato.
Hyper-V Replica tiene traccia delle modifiche sul file del disco rigido virtuale della macchina virtuale a intervalli di tempo di 5 minuti in ambiente Windows Server 2012 e di 30 secondi, cinque minuti o 15 minuti in ambiente Windows Server 2012 R2. Il sistema non fornisce un’elevata disponibilità come Windows Failover Clustering ma assicura comunque che i dati virtualizzati siano disponibili attraverso la clonazione dei contenuti che risultano modificati.
Pro e contro dell’hosting applicativo utilizzando Hyper-V Replica
Il principale vantaggio di applicazioni ospitate in un ambiente Hyper-V Replica è quello di assicurare il recupero dei dati applicativi attraverso gli snapshot che fungono da copie coerenti delle applicazioni. Tuttavia, questo approccio non funziona con tutte le applicazioni.
In dettaglio, Hyper-V Replica crea delle copie di backup standard rispetto a uno storage virtuale, che aiuta a recuperare delle componenti rispetto al sistema operativo di una macchina virtuale. Ad esempio, se si applica un aggiornamento di Windows a una macchina virtuale primaria e questo aggiornamento genera anomalie in alcune componenti del sistema operativo, è possibile recuperare questi errori partendo da un punto di ripristino che Hyper-V Replica ha creato sullo storage virtuale.
Poiché la copia replicata di una macchina virtuale è sempre spenta, è possibile utilizzare le risorse del server ridondato per l’esecuzione di altre macchine virtuali. Come già accennato, il principale svantaggio di Hyper-V Replica è che può supportare solo una copia dei contenuti a intervalli periodici, dai 5 minuti al quarto d’ora.
Questo significa che se i dati non vengono replicati entro l’intervallo specificato e la macchina virtuale primaria si blocca, si ha una perdita dei dati applicativi. Snapshot coerenti con le applicazioni sono creati solo una volta ogni ora per poi essere inviati alla macchina di replica in base alle impostazioni precedentemente pianificate.
È possibile ospitare tutte le applicazioni di Hyper-V Replica?
La risposta a questa domanda dipende dalle caratteristiche dell’applicazione. Hyper-V Replica, infatti, non ha coscienza di che cosa ci sia in esecuzione all’interno di una macchina virtuale. Una VM (Virtual Machine) potrebbe essere impegnata con un’istanza di SQL o Exchange Server o con l’implementazione di un controller di dominio su una Directory attiva.
Decidere se ospitare un’applicazione in un ambiente Hyper-V Replica dipende dunque dalla tipologia di applicazione. Prendiamo in considerazione alcuni esempi per determinare quali tipi di applicazioni dovrebbe essere supportate da Hyper-V Replica.
Caso 1: un’applicazione dotata di un sistema incorporato per il recupero automatico dei dati persi
Se un’applicazione possiede queste caratteristiche, è una buona pratica escluderla da Hyper-V Replica, evitando un’inutile impegno a livello di memoria dello storage secondario. Considerando però il fatto che Hyper-V Replica fornisce anche delle copie di backup standard per il ripristino da errori del sistema operativo, si potrebbe attivare comunque Hyper-V Replica garntendo così una protezione aggiuntiva rispetto ad eventuali guasti del sistema operativo.
Caso 2: un’applicazione che non dispone di un meccanismo incorporato di replicazione dei dati e non include un sistema di ripristino dei dati in caso di errore
Questo è un caso in cui vale la pena prendere in considerazione Hyper-V Replica. Hyper-V Replica offre snapshot coerenti rispetto ai dati applicativi, permettendo recupero e ripristino. Esistono due tipi di applicazioni che rientrano in questa categoria: le applicazioni che integrano il servizio Volume Shadow Copy Service (VSS) e quelle che non lo integrano. Se un’applicazione è VSS-aware ed è ospitata in un ambiente Hyper-V Replica, la trascrizione dei dati applicativi effettuata dal sistema VSS e da Hyper-V Replica lavorano in sincrono per garantire che i dati non vengano persi. Se invece si esegue un’applicazione non VSS in un ambiente Hyper-V Replica che al suo interno non dispone di un proprio VSS writer, è possibile che i dati vengano persi. Se l’applicazione ha dei dati in memoria e non può impegnare i dati della memoria sul disco, si genererà uno snapshot incoerente dell’applicazione inviata al server di replica e, poiché la copia di backup non è coerente, questa non può essere utilizzata per recuperare dati delle applicazioni.
Come già spiegato, Hyper-V Replica non fa un distinguo su ciò che è in esecuzione all’interno di una macchina virtuale: si limita semplicemente a clonare i contenuti modificati sul server ridondato.
La decisione di realizzare un applicazione in un ambiente Hyper-V Replica dipende dal fatto che un’applicazione può comunicare con il sistema di scrittura dell’Hyper-V VSS. Le applicazioni devono intraprendere le azioni necessarie quando ci sono snapshot di copia coerenti con le applicazioni perché creati dall’Hyper-V VSS writer.
Se un’applicazione mantiene i dati in memoria e non capisce la tecnologia VSS, lo snapshot dell’applicazione risulterà incoerente e verrà inviato al server ridondato inutilmente, in quanto il recupero dei dati applicativi archiviati sarà inutile.
Caso 3: un’applicazione che comprende i failover pianificati e non pianificati di Hyper-V Replica
In questo caso l’applicazione può essere distribuita in modo sicuro in ambiente Hyper-V Replica. Ad esempio, SQL Server è supportato in Hyper-V Replica, ovviamente previa attivazione delle procedure spiegate da Microsoft. Allo stesso modo, i controller di dominio Active Directory che girano su Windows Server 2012 e le versioni successive si interfacciano con la tecnologia Hyper-V Replica e sono supportati per le diverse opzioni di failover.
