Condividi tramite

Resilienza delle macchine virtuali per Azure locale

Dopo aver esaminato e implementato le considerazioni di progettazione per la resilienza dell'infrastruttura a livello di piattaforma, è essenziale comprendere in che modo le macchine virtuali e le applicazioni sono resilienti agli errori. Questa comprensione consente di consentire loro di rilevare, resistere e recuperare da errori entro un periodo di tempo accettabile. La resilienza è fondamentale per mantenere le operazioni continue per le applicazioni business critical.

Per impostazione predefinita, tutte le macchine virtuali (VM) in Locale di Azure sono progettate per la disponibilità elevata. Se un nodo fisico nel cluster ha esito negativo, le macchine virtuali interessate vengono riavviate automaticamente e continuano a funzionare sui nodi rimanenti, purché sia disponibile una capacità di calcolo sufficiente per le macchine virtuali. Anche con queste avanzate funzionalità di tolleranza di errore e resilienza a livello di piattaforma, è essenziale che le applicazioni distribuite all'interno delle macchine virtuali seguano principi ben architettati.

Le applicazioni ben architettate integrano l'affidabilità nel codice, nell'infrastruttura e nelle operazioni. Ad esempio, la distribuzione di più istanze di servizi dell'applicazione all'interno di due o più macchine virtuali locali di Azure è essenziale per eliminare singoli punti di errore all'interno del livello dell'applicazione. L'integrazione di resilienza aggiuntiva a questo livello riduce il rischio di tempi di inattività in caso di errore di una singola macchina virtuale o istanza dell'applicazione. Per altre informazioni, vedere Resilienza del carico di lavoro. Inoltre, una progettazione affidabile delle applicazioni deve includere strategie complete di continuità aziendale e ripristino di emergenza, tra cui la normale convalida del failover di ripristino di emergenza e i test di backup e ripristino dei dati per garantire che le procedure di ripristino di emergenza funzionino come previsto.

Per ridurre il rischio di interruzioni del servizio o perdita di dati che le funzionalità di ridondanza di una singola istanza locale di Azure non possono attenuare, è essenziale implementare una combinazione di strategie di backup complete insieme a tecnologie di replica continua dei dati.

  • Le strategie di backup proteggono da scenari quali danneggiamento dei dati, eliminazione accidentale o dannosa e eventi imprevisti irreversibili. Facilitano il ripristino dei dati in uno stato precedente, se necessario.

  • Le tecnologie di replica dei dati consentono di gestire copie sincronizzate dei dati delle macchine virtuali tra più istanze locali di Azure e aree di Azure. Questa procedura può ridurre al minimo i tempi di inattività e abilitare un rapido failover del carico di lavoro in caso di errore hardware o di sistema. Insieme, questi approcci forniscono una solida rete di sicurezza progettata per proteggere i dati e sostenere la continuità operativa e aziendale durante interruzioni impreviste.

Per altre informazioni e suggerimenti per migliorare la resilienza del carico di lavoro e delle applicazioni, vedere Principi di progettazione di Azure Well-Architected Framework (WAF) - Affidabilità.

Considerazioni sul percorso di archiviazione (volumi)

Le istanze locali di Azure distribuite usando l'opzione Crea volumi di carico di lavoro e volumi di infrastruttura necessari (scelta consigliata) creano volumi condivisi cluster "UserStorage_X", uno per nodo fisico nel cluster e una risorsa percorso di archiviazione associata creata in Azure per ogni volume. Le risorse del carico di lavoro, ad esempio le macchine virtuali locali di Azure e i cluster del server Azure Kubernetes abilitati per Arc, usano la risorsa percorso di archiviazione in Azure per archiviare le immagini delle macchine virtuali. Ad esempio, un CSV con il percorso del file system locale di C:\ClusterStorage\UserStorage_1\ ha una risorsa di percorso di archiviazione creata in Azure che rappresenta il volume condiviso del cluster (CSV) per consentire ai dischi rigidi virtuali (VHD) delle macchine virtuali locali di Azure di essere posizionati su un volume di destinazione specifico. Per altre informazioni, vedere Informazioni sui percorsi di archiviazione.

Quando si distribuiscono applicazioni ben architettate che usano più macchine virtuali locali di Azure per migliorare la resilienza del carico di lavoro, laddove possibile, posizionare i dischi rigidi virtuali di ogni macchina virtuale in percorsi di archiviazione separati per ottimizzare la ridondanza. Ad esempio, quando si effettua il provisioning di più macchine virtuali locali di Azure che eseguono istanze dello stesso servizio, l'uso di percorsi di archiviazione diversi per ogni VHD delle macchine virtuali consente di ridurre il rischio di tutte le macchine virtuali usando un singolo percorso di archiviazione (volume).

Il percorso di archiviazione usato dalle macchine virtuali locali di Azure viene configurato quando si creano i dischi rigidi virtuali. Quando si usa l'infrastruttura come codice (IaC) per effettuare il provisioning dei carichi di lavoro, la logica di posizionamento per i dischi rigidi virtuali usa una logica di allocazione round robin per la selezione del percorso di archiviazione. Per le istanze locali di Azure a più nodi, ogni percorso di archiviazione viene mappato a un volume diverso per impostazione predefinita. Di conseguenza, ogni VHD delle macchine virtuali viene distribuito tra percorsi di archiviazione diversi (volumi), che aumenta la resilienza del carico di lavoro, in particolare per gli scenari in cui un singolo volume è temporaneamente offline o non disponibile. Per un controllo di provisioning più granulare, specificare il parametro --storage-path-id quando si utilizza l'interfaccia della riga di comando di Azure per l'implementazione del carico di lavoro, permettendo di indicare percorsi di archiviazione dedicati durante il provisioning di dischi rigidi virtuali per Azure VMs locali.

Strumenti di backup

Microsoft Azure Backup Server

Microsoft Azure Backup Server (MABS), un'evoluzione di System Center Data Protection Manager, è una soluzione di backup Microsoft che è possibile usare per proteggere le macchine virtuali locali di Azure. MABS offre un approccio ibrido per il backup, offrendo conservazione a breve termine nell'archiviazione su disco locale per ripristini operativi veloci e conservazione a lungo termine tramite l'integrazione con i servizi di Backup di Azure, consentendo di archiviare i backup fuori sede in un insieme di credenziali di Servizi di ripristino di Azure.

Se si usa MABS, è possibile proteggere le macchine virtuali usando due approcci: backup di macchine virtuali a livello di host e backup di macchine virtuali a livello di guest.

  • Backup di macchine virtuali a livello di host: installare l'agente di backup in ogni host locale di Azure (ogni nodo del cluster) e eseguire il backup di intere macchine virtuali a livello di hypervisor. Questo approccio acquisisce l'intera macchina virtuale, inclusi tutti i dischi virtuali. Non richiede un agente all'interno di ogni macchina virtuale ed è indipendente dal sistema operativo guest. I backup a livello di host consentono ripristini completi delle macchine virtuali, in cui è possibile ripristinare un'intera macchina virtuale nello stesso cluster o in un cluster diverso. Tuttavia, i backup a livello di host non sono integrati con l'applicazione. Ad esempio, non troncano i log SQL o garantiscono ripristini coerenti con l'applicazione oltre a quanto fornito dal servizio Copia Shadow del volume.

    Annotazioni

    • Il ripristino di una macchina virtuale locale di Azure in un cluster diverso ripristina la macchina virtuale come macchina virtuale non gestita. Ciò significa che tutti i servizi all'interno della macchina virtuale iniziano a funzionare, ma la macchina virtuale non può essere gestita da Azure fino a quando non viene registrata nel nuovo cluster locale di Azure e riconnessa alla risorsa esistente in Azure.
    • La riconnessione indica che la risorsa di Azure viene aggiornata con il nuovo gruppo di risorse (facoltativo, è anche possibile mantenerlo nello stesso gruppo di risorse), la posizione personalizzata, il percorso di archiviazione e la rete logica della macchina virtuale.
    • Se si ripristina la macchina virtuale sul posto nello stesso cluster, la registrazione e la riconnessione non sono necessarie. La connessione di Azure della VM viene ripristinata e continua a essere gestita da Azure, a condizione che rientri nella finestra di riconnessione di 45 giorni di Azure Arc.

  • Backup VM a livello guest: installare gli agenti di backup nel sistema operativo guest della VM. Questo approccio consente backup coerenti con l'applicazione per le applicazioni compatibili con VSS in esecuzione all'interno del sistema operativo, assicurando che i dati dell'applicazione vengano acquisiti in uno stato coerente. Ad esempio, è possibile eseguire facilmente il backup di database SQL con fedeltà completa e ripristinare singoli elementi, ad esempio un singolo database o un file specifico. Il compromesso è la gestibilità: è necessario gestire gli agenti in ogni macchina virtuale e il backup copre solo ciò che si trova all'interno della macchina virtuale. Per ripristinare l'intera macchina virtuale, in genere si ricompila e quindi si ripristinano i dati all'interno.

  • Usare entrambi: molte organizzazioni usano una combinazione di entrambi gli approcci. Usare i backup a livello di guest per applicazioni critiche che richiedono il ripristino temporizzato o a livello di elemento, ad esempio il ripristino di un singolo database o di un file senza eseguire il rollback dell'intera macchina virtuale. Usare i backup a livello di host per il ripristino rapido di intere macchine virtuali o per il ripristino da scenari di errore host.

La configurazione di MABS prevede la distribuzione del software del server MABS su una macchina virtuale dedicata nel cluster, la configurazione del suo archivio locale, l'installazione degli agenti di protezione sugli host locali Azure e/o sui guest, e poi la creazione dei gruppi di protezione con le macchine virtuali che si desidera proteggere. I gruppi protezione dati definiscono il backup (ad esempio, macchine virtuali specifiche), la pianificazione dei backup e i criteri di conservazione a breve termine e a lungo termine su disco locale o Azure. Per altre informazioni sull'installazione di MABS per macchine virtuali locali di Azure, vedere Eseguire il backup di macchine virtuali locali di Azure con il server di Backup di Azure.

Attribute Backup di macchine virtuali a livello di host Backup a livello guest delle macchine virtuali
Richiede un agente nel sistema operativo guest NO Yes
Richiede l'agente in tutti i nodi del cluster Yes NO
Indipendente dal sistema operativo guest Yes NO
Sensibilità alle applicazioni NO Yes
Backup L'intera macchina virtuale e i dischi Applicazioni e file (backup coerenti a livello di applicazione compatibili con VSS)
Ripristina Intera macchina virtuale Dati dell'app e singoli file
Ripristinare la macchina virtuale nello stesso cluster Yes Non applicabile
Ripristinare una macchina virtuale in un cluster alternativo Yes Non applicabile

Soluzioni di backup dei partner

Oltre a MABS, un mercato maturo dei fornitori di backup e ripristino dei partner offre soluzioni affidabili per gli ambienti locali di Azure. Queste soluzioni offrono spesso un set completo di funzionalità avanzate, supporto della piattaforma più ampio e modelli di licenza o costi diversi che potrebbero risultare interessanti a seconda di requisiti organizzativi specifici.

CloudCasa di Catalogic

CloudCasa offre backup, ripristino di emergenza e migrazione nativi di Kubernetes per AKS su cluster abilitati per Azure Local e Arc. Protegge le risorse del cluster e i volumi permanenti, con la possibilità di eseguire ripristini granulari, incluso il ripristino a livello di file. I backup possono essere archiviati in Archiviazione BLOB di Azure, in altri storage a oggetti o in un file system di rete (NFS). CloudCasa supporta i ripristini nello stesso sito, in un cluster locale di Azure secondario o nel servizio Azure AKS per il disaster recovery.

Cohesity DataProtect

Cohesity DataProtect, parte della piattaforma Data Cloud, protegge le macchine virtuali con una singola piattaforma di sicurezza dei dati. Combina backup, replica e ripristino di emergenza con snapshot immutabili illimitati, ripristini granulari di file/vm/database, ripristino istantaneo su larga scala e rilevamento anomalie e classificazione dei dati integrata per velocizzare il ripristino dopo gli eventi informatici. Per Azure Local, Cohesity offre un'integrazione approfondita con la piattaforma. Questa integrazione include l'individuazione automatica delle macchine virtuali, la protezione basata su criteri, molte opzioni di ripristino e i backup incrementali con Microsoft Resilient Change Tracking (RCT).

Cohesity estende il supporto sfruttando i flussi di lavoro e il connettore Hyper-V maturi, offrendo un modello operativo coerente man mano che i clienti spostano i carichi di lavoro Hyper-V in Locale di Azure.

Cohesity NetBackup

Cohesity NetBackup offre protezione dei dati resilienti per Azure locale, consentendo alle organizzazioni di proteggere le macchine virtuali e le applicazioni locali di Azure usando la stessa piattaforma di livello aziendale su cui si basano in ambienti ibridi e multi-cloud.

NetBackup usa l'integrazione avanzata Hyper-V e Microsoft Resilient Change Tracking (RCT) per fornire backup incrementali e basati su criteri per i carichi di lavoro locali di Azure. L'acquisizione efficiente delle modifiche a livello di blocco riduce al minimo l'utilizzo delle finestre di backup e della rete. Il supporto locale di Azure è documentato nella tabella di compatibilità del software per NetBackup 11.x sotto le voci Hyper-V e Azure Local.

CommVault

Commvault Cloud offre una protezione unificata dei dati di livello aziendale per gli ambienti locali di Azure, consentendo il backup sicuro, il ripristino e la protezione ransomware tra macchine virtuali, database e dati non strutturati. Grazie all'automazione intelligente e ai flussi di lavoro basati su criteri, Commvault semplifica la conformità, migliora la resilienza e offre una protezione scalabile dal perimetro al cloud, mantenendo al contempo il controllo completo dei dati all'interno dell'area locale di Azure.

Rubrik

Rubrik Security Cloud offre protezione dei dati e sicurezza complete per le macchine virtuali distribuite in ambienti locali di Azure. Rubrik esegue un primo set completo e per sempre incrementale di backup, garantendo la protezione dei dati con copie non modificabili, air-gapped e controllate dall'accesso. Tramite un piano di controllo SaaS unificato, le organizzazioni possono gestire i dati dagli ambienti locali di Azure, offrendo una singola visualizzazione in asset di dati critici. Questa integrazione consente anche il monitoraggio continuo delle minacce, la ricerca delle minacce, il rilevamento delle anomalie e facilita il ripristino rapido del cyber recovery, consentendo un rapido ripristino delle macchine virtuali e delle applicazioni a uno stato pulito dopo un attacco.

Veeam

Veeam Backup & Replication supporta il backup e la replica delle macchine virtuali locali di Azure. Con Veeam Backup and Replication è possibile eseguire la migrazione dei carichi di lavoro da piattaforme diverse o da Hyper-V a Locale di Azure. È possibile eseguire il ripristino multipiattaforma usando il ripristino istantaneo della macchina virtuale. È anche possibile replicare i carichi di lavoro da versioni precedenti di Hyper-V in Locale di Azure.

Frequenza di backup, conservazione e test di ripristino

Anche con la tolleranza di errore hardware e Storage Spaces Direct che mantiene più copie dei dati, è essenziale implementare e testare regolarmente i processi di backup dei dati. La ridondanza dell'archiviazione protegge da errori dell'infrastruttura, ma non impedisce il danneggiamento, l'eliminazione o le emergenze a livello di sito. I backup regolari assicurano di poter ripristinare dati o intere macchine virtuali a un punto precedente nel tempo, se necessario.

  • Frequenza e conservazione dei backup: assicurarsi che la frequenza di backup sia allineata all'obiettivo del punto di ripristino (RPO), che definisce la quantità massima accettabile di perdita di dati per l'organizzazione. A seconda dell'importanza di una macchina virtuale per l'azienda, pianificare backup notturni o più backup al giorno, se necessario, usando backup incrementali. Implementare inoltre criteri di conservazione allineati ai requisiti aziendali e di conformità ( ad esempio, conservare i backup giornalieri per due settimane, backup mensili per sei mesi, backup annuali per sette anni). Backup di Azure, tramite il server di Backup di Microsoft Azure (MABS), può facilitare la conservazione locale a breve termine e la conservazione basata sul cloud a lungo termine.

  • Test dei ripristini: un backup è valido solo per la possibilità di ripristinarlo, quindi è importante testare regolarmente il ripristino di macchine virtuali e dati dai backup. Eseguire periodicamente un test di recupero completo della macchina virtuale in una rete isolata o in un cluster lab per garantire che il processo sia uniforme e tempestivo. Questa procedura fa parte della strategia di ripristino di emergenza per garantire che i backup facciano il loro scopo in un'effettiva emergenza.

Replica continua di macchine virtuali critiche per l'azienda

Mentre i backup proteggono i dati e abilitano il ripristino temporizzato, non offrono funzionalità di failover immediato. Il ripristino da un backup può richiedere molto tempo, spesso richiedendo ore. Per le macchine virtuali aziendali o cruciali, in cui anche un tempo di inattività o una perdita di dati minima non è accettabile, le tecnologie di replica continua forniscono un meccanismo per gestire una copia up-to-date delle macchine virtuali in una posizione secondaria. Queste tecnologie consentono un failover rapido e una perdita minima di dati in caso di emergenza. Due tecnologie di replica continua supportate da Azure Local sono Azure Site Recovery e Hyper-V Replica.

Usare Azure Site Recovery per replicare macchine virtuali locali di Azure in Azure

Azure Site Recovery è la soluzione di ripristino di emergenza basata sul cloud di Microsoft progettata per replicare macchine virtuali locali in Azure. Azure Site Recovery facilita la replica di macchine virtuali locali di Azure in Azure, garantendo la protezione dei carichi di lavoro critici per l'azienda. Questo servizio trasmette continuamente le modifiche dalle macchine virtuali locali ad Azure. Di conseguenza, in caso di interruzione significativa nel sito o nel cluster locale, è possibile eseguire il failover della macchina virtuale in Azure per mantenere la continuità operativa.

Punti chiave su Azure Site Recovery per Azure Local:Key points about Azure Site Recovery for Azure Local:

  • Distribuzione:

    • Distribuzione automatizzata: azure locale ha creato un'estensione per Azure Site Recovery per la distribuzione automatizzata. L'estensione Azure Site Recovery può rilevare tutti i nodi del cluster e distribuire Azure Site Recovery in tutti i nodi automaticamente e configurarli con i criteri di replica. Per altre informazioni, vedere Proteggere i carichi di lavoro delle macchine virtuali con Azure Site Recovery.
    • Distribuzione manuale: l'estensione Azure Site Recovery per Azure Local è in anteprima e applicabile solo agli ambienti di test. Per i clienti che necessitano di una soluzione pronta per la produzione, Azure Site Recovery può essere configurato manualmente nel cluster locale di Azure usando l'opzione Hyper-V per il ripristino di emergenza di Azure .

  • Replica frequente: Azure Site Recovery può raggiungere obiettivi del punto di ripristino (RPO) fino a 30 secondi.

  • Failover:

    • Una volta eseguita la replica, è possibile avviare un failover in Azure. Questo processo consente di visualizzare la macchina virtuale in Azure usando i dati replicati. È possibile testare questo processo usando un failover di test, che crea una copia in Azure in una rete isolata per la verifica senza arrestare le macchine virtuali locali.
    • Durante un'emergenza effettiva, se il sito primario è inattivo in modo imprevisto, si esegue un failover non pianificato anche se la macchina virtuale di origine non è in esecuzione.
    • Per scenari come la manutenzione hardware o la sostituzione, è possibile avviare un failover pianificato. Questo failover arresta normalmente la macchina virtuale in modo che possa eseguire il commit della memoria su disco per garantire una perdita di dati pari a zero.
    • Dopo il failover, la macchina virtuale viene eseguita in Azure.

  • Failback:

    • Quando si riduce l'emergenza e il cluster è operativo, Azure Site Recovery può invertire la direzione della replica e replicare le modifiche apportate durante il funzionamento in Azure nel cluster locale di Azure. Dopo la replica inversa, è possibile eseguire il failback della macchina virtuale, consentendo alle operazioni di tornare all'ambiente locale.

    • Per un failback riuscito, l'ambiente locale deve essere in buone condizioni operative. Se il cluster non è disponibile, è possibile registrare un altro cluster locale di Azure nel sito di Azure Site Recovery Hyper-V e eseguire il failback della macchina virtuale in un nodo in un cluster alternativo.

      Annotazioni

      • Il failback di una macchina virtuale locale di Azure in un cluster alternativo esegue il failback della macchina virtuale come macchina virtuale non gestita. Ciò significa che tutti i servizi all'interno della macchina virtuale iniziano a funzionare, ma la macchina virtuale non può essere gestita da Azure fino a quando non viene registrata nel nuovo cluster locale di Azure e riconnessa alla risorsa esistente in Azure.
      • La riconnessione indica che la risorsa di Azure viene aggiornata con il nuovo gruppo di risorse (facoltativo, è anche possibile mantenerlo nello stesso gruppo di risorse), la posizione personalizzata, il percorso di archiviazione e la rete logica della macchina virtuale.
      • Se la macchina virtuale viene sottoposta a failback nello stesso cluster, la registrazione e la riconnessione non sono necessarie. La connessione di Azure della VM viene ripristinata e continua a essere gestita da Azure, a condizione che rientri nella finestra di riconnessione di 45 giorni di Azure Arc.

Per altre informazioni e per installare Azure Site Recovery, vedere Proteggere i carichi di lavoro delle macchine virtuali con Azure Site Recovery in Locale di Azure (anteprima).For more information and to install Azure Site Recovery, see Protect VM workloads with Azure Site Recovery on Azure Local (preview).

Usare Hyper-V Replica per la replica continua delle VM critiche per il business

Hyper-V Replica è una funzionalità integrata in Locale di Azure che consente la replica asincrona di macchine virtuali tra due host Hyper-V o cluster di failover. È possibile usare questa tecnologia per replicare le macchine virtuali tra due cluster locali di Azure separati, fornendo una soluzione di ripristino di emergenza locale.

Quando si abilita Hyper-V Replica per una macchina virtuale, viene creata una copia iniziale della macchina virtuale (inclusa la configurazione e i dischi rigidi virtuali) in un server o un cluster di replica designato. Hyper-V Replica tiene traccia delle modifiche apportate alla macchina virtuale primaria e le scrive nei file di log. Trasmette questi log al sito di replica, dove li applica alla macchina virtuale di replica in modo asincrono.

Punti chiave sull'uso della replica Hyper-V con Azure Local:

  • Distribuzione:

    • Distribuzione manuale: non è possibile configurare Hyper-V Replica tramite il portale di Azure. Usare PowerShell nei nodi locali di Azure per configurarlo. In alternativa, gli amministratori possono accedere in remoto al cluster locale di Azure da qualsiasi computer Windows Server all'interno della stessa rete e completare la configurazione tramite l'interfaccia utente di Gestione cluster di failover. Sono necessarie autorizzazioni appropriate per connettersi e gestire entrambi i cluster locali di Azure.

    • Configurazione: è possibile abilitare i cluster locali di Azure come server di replica, configurare metodi di autenticazione (in genere Kerberos all'interno di un dominio o basati su certificati per scenari non aggiunti a un dominio o tra domini), configurare le regole del firewall per consentire il traffico di replica e quindi abilitare la replica in base a ogni macchina virtuale. Le impostazioni per-VM includono la specifica del server di replica o del cluster, la selezione dei dischi rigidi virtuali da replicare, la scelta della frequenza di replica e la definizione del numero di punti di ripristino (istantanee temporali) da mantenere sul lato del server di replica. Hyper-V Replica supporta la replica, il failover di test, il failover, la replica inversa e il failback sia per scenari pianificati che non pianificati.

  • Frequenza di replica: è possibile configurare la frequenza di replica ogni 30 secondi, 5 minuti o 15 minuti.

  • Failover:

    • Una volta eseguita la replica, è possibile avviare un failover nel server di replica. Questa azione consente di visualizzare la macchina virtuale nel server di replica usando i dati replicati. È possibile testare questa azione usando un failover di test, che crea una macchina virtuale in una rete isolata per la verifica senza arrestare la macchina virtuale replicata.

    • Durante un'emergenza effettiva, se il sito primario è inattivo in modo imprevisto, è possibile eseguire un failover non pianificato anche se la macchina virtuale replicata non è in esecuzione.

      • Per scenari come la manutenzione hardware o la sostituzione, è possibile avviare un failover pianificato. Questo processo arresta normalmente la macchina virtuale replicata, assicurandosi che la memoria venga sottoposta a commit su disco per evitare perdite di dati.

    • Dopo il failover, la macchina virtuale viene eseguita nel server di replica.

      Annotazioni

      • Il failover di una VM locale di Azure su un cluster di replica esegue il failover della VM come VM non gestita. Ciò significa che tutti i servizi all'interno della macchina virtuale iniziano a funzionare, ma non è possibile gestire la macchina virtuale da Azure fino a quando non viene registrata nel nuovo cluster locale di Azure e riconnessa alla risorsa esistente in Azure.
      • La riconnessione indica che la risorsa di Azure viene aggiornata con il nuovo gruppo di risorse (facoltativo, è anche possibile mantenerlo nello stesso gruppo di risorse), la posizione personalizzata, il percorso di archiviazione e la rete logica della macchina virtuale.
      • La registrazione e la riconnessione potrebbero non essere necessarie se il failover è temporaneo e si prevede che la macchina virtuale venga sottoposta a failback al cluster originale dopo che l'emergenza è stata mitigata. Durante questo periodo, la macchina virtuale non è gestibile da Azure, ma i servizi sono operativi.

  • Failback:

    • Dopo aver risolto l'emergenza e il cluster è operativo, Hyper-V replica può invertire la direzione della replica e replicare le modifiche apportate durante il funzionamento nel server di replica nel cluster locale di Azure originale.

    • Dopo la replica inversa, è possibile eseguire il failback della macchina virtuale, consentendo alla macchina virtuale di tornare al cluster di origine.

      Annotazioni

      Dopo il failback della macchina virtuale al cluster di origine, la registrazione e la riconnessione non sono necessarie. La connettività di Azure della macchina virtuale viene ripristinata e questa continua a essere gestita da Azure, purché rientri nella finestra di riconnessione di 45 giorni di Azure Arc.

Per altre informazioni, vedere la procedura di distribuzione in Configurare Hyper-V Replica.

Funzionalità

Quando si abilita Hyper-V Replica per una macchina virtuale, viene creata una copia iniziale della macchina virtuale (inclusa la configurazione e i dischi rigidi virtuali) in un server o un cluster di replica designato. Hyper-V Replica tiene traccia delle modifiche apportate alla macchina virtuale primaria e le scrive nei file di log. Trasmette questi log al sito di replica e li applica alla macchina virtuale di replica in modo asincrono, in base a una frequenza di replica configurabile, ad esempio ogni 30 secondi, 5 minuti o 15 minuti.

La configurazione prevede l'abilitazione dei cluster locali di Azure come server di replica, la configurazione dei metodi di autenticazione (in genere Kerberos all'interno di un dominio o basato su certificati per scenari non aggiunti a un dominio o tra domini), la configurazione delle regole del firewall per consentire il traffico di replica e quindi l'abilitazione della replica in base a ogni macchina virtuale. Le impostazioni per VM includono la specifica del server di replica o del cluster, la selezione dei dischi rigidi virtuali (VHD) da replicare, la scelta della frequenza di replica e la definizione del numero di punti di ripristino (istantanee temporali) da mantenere sul lato del server replica. Hyper-V Replica supporta la replica, il failover di test, il failover, la replica inversa e il failback sia per scenari pianificati che non pianificati.

Annotazioni

Per la replica da cluster a cluster locale di Azure, è necessario configurare il ruolo Broker di replica Hyper-V in ogni cluster. Questo broker coordina la replica e fornisce l'endpoint a livello di cluster per ricevere modifiche alle macchine virtuali.

Configurazione

È necessario configurare Hyper-V Replica usando PowerShell nei nodi locali di Azure oppure configurarlo in remoto tramite l'interfaccia utente di Gestione cluster di failover in qualsiasi computer Windows Server all'interno della stessa rete delle istanze locali di Azure. Sono necessarie le autorizzazioni appropriate per connettersi e amministrare entrambi i computer locali di Azure. Non è possibile configurare Hyper-V Replica dal portale di Azure.

Per altre informazioni, vedere la procedura di distribuzione in Configurare Hyper-V Replica.

Considerazioni sulla rete e sulle prestazioni

Durante il processo di replica, l'hardware e la rete usati influiscono sui servizi che si basano su di essi. A seconda della quantità di dati replicati tra i sistemi di origine e di destinazione, questo processo utilizza una grande quantità di risorse di sistema. Le prestazioni del tuo dispositivo sono influenzate fino al completamento di questo processo. È necessaria una larghezza di banda di rete adeguata tra i due cluster locali di Azure affinché la replica di Hyper-V funzioni in modo ottimale, soprattutto con intervalli di replica inferiori, ad esempio, 30 secondi. Analogamente, il cluster di destinazione necessita di operazioni di input/output di archiviazione sufficienti al secondo (IOPS) per mantenere il passo con il traffico di replica in ingresso. Per altre informazioni, vedere Funzionalità e ottimizzazione delle prestazioni di Hyper-V Replica (HVR).

Confrontare Azure Site Recovery e Hyper-V Replica

Quando si sceglie tra Azure Site Recovery e replica Hyper-V per le macchine virtuali locali di Azure, prendere in considerazione le differenze tra entrambe le soluzioni:

Attribute Azure Site Recovery (Ripristino del sito Azure) replica Hyper-V
Destinazioni di replica Da Azure locale ad Azure Da Azure Locale a Azure Locale
Macchine virtuali eseguite in modalità failover Macchine virtuali di Azure Macchine virtuali locali di Azure
Distribuzione Automatizzato in tutti i nodi, avviato dal portale di Azure e usa l'estensione Azure Site Recovery . Manuale, in ogni nodo, fuori banda e tramite strumenti locali (Hyper-V Manager).
Richiede il piano di controllo di Azure Yes NO
Fornisce piani di ripristino per il coordinamento delle sequenze di failover Yes NO
Richiede la valutazione di rete per la macchina virtuale di cui è stato eseguito il failover per continuare la manutenzione Yes Yes
Comporta costi di utilizzo di Azure Sì. Consulta Prezzi - Site Recovery. NO
Richiede la registrazione se la macchina virtuale viene ripristinata al suo sito originale dopo che l'emergenza è stata mitigata. NO No (È possibile eseguire temporaneamente il failover della macchina virtuale al sito di ripristino di emergenza e successivamente il failback al sito originale dopo la risoluzione dell'emergenza)
Richiede la registrazione se la macchina virtuale di cui è stato eseguito il failover deve risiedere in modo permanente nel sito di ripristino di emergenza No (le macchine virtuali di Azure non richiedono la registrazione) Yes

Usare Azure Site Recovery e replica Hyper-V: le organizzazioni con siti remoti con singoli cluster e hub più grandi con più cluster possono estendere Azure come sito di ripristino di emergenza. Usare Azure Site Recovery per siti remoti e replica Hyper-V per posizioni più grandi. Questa architettura consente ad alcune macchine virtuali di eseguire la replica in Azure, mentre altre vengono replicate in un sito secondario, garantendo flessibilità e strategie di ripristino di emergenza personalizzate per diverse esigenze operative.

Piani di ripristino e test

È essenziale disporre di un piano di ripristino in cui si documentino tutti i passaggi necessari per eseguire il failover dei carichi di lavoro, inclusa la sequenza (ad esempio, i controller di dominio devono essere attivati prima dei server applicazioni) e tutte le modifiche di rete necessarie ,ad esempio gli aggiornamenti DNS e il reindirizzamento degli utenti. Hyper-V Replica consente la creazione di piani di ripristino, consentendo la sequenziazione dei gruppi di macchine virtuali e l'inclusione di script come parte del processo di failover. Questi piani possono essere manuali o inseriti in script tramite PowerShell.

Testare regolarmente il piano di ripristino di emergenza tramite esercitazioni simulate. Eseguire un failover di test almeno una volta al mese per garantire la funzionalità e mantenere la competenza del personale. Inoltre, i test rivelano se gli obiettivi del tempo di ripristino (RTO) vengono soddisfatti, ad esempio il tempo necessario per l'avvio in Azure o nell'hardware secondario.

Per altre informazioni, vedere Strategie di architettura per la progettazione di una strategia di ripristino di emergenza.

Passaggi successivi

  • Last updated on