Architettura del ripristino di emergenza da VMware ad Azure - Modernizzato
Questo articolo descrive l'architettura e i processi usati per implementare il ripristino di emergenza con replica, failover e ripristino di macchine virtuali (VM) VMware tra un sito VMware locale e Azure usando l’esperienza di protezione di macchine virtuali o fisiche da VMware modernizzata.
Nota
Assicurarsi di creare un nuovo insieme di credenziali di Servizi di ripristino per configurare l'appliance di replica ASR. Non usare un insieme di credenziali esistente.
Per informazioni sull'architettura di Azure Site Recovery nell'architettura classica, vedere questo articolo.
Componenti dell'architettura
La tabella e l'immagine seguenti offrono una visualizzazione generale dei componenti usati per il ripristino di emergenza di macchine virtuali o fisiche da VMware ad Azure.
| Componente | Requisito | Dettagli |
|---|---|---|
| Azure | Una sottoscrizione di Azure, un account di Archiviazione di Azure per la cache, Managed Disks e rete di Azure. | I dati replicati da macchine virtuali locali vengono archiviati nell'archiviazione di Azure. Le macchine virtuali di Azure vengono create con i dati replicati durante l'esecuzione di un failover dal sito locale ad Azure. Le VM di Azure si connettono alla rete virtuale di Azure quando vengono create. |
| Appliance di replica di Azure Site Recovery | Si tratta dell'unità base predefinita dell'intera infrastruttura locale di Azure Site Recovery. Tutti i componenti nell'appliance si coordinano con l'appliance di replica. Questo servizio supervisiona tutte le attività end-to-end di Site Recovery, tra cui il monitoraggio dell'integrità dei computer protetti, la replica dei dati, gli aggiornamenti automatici e così via. |
L'appliance ospita vari componenti cruciali, ad esempio: Server proxy: questo componente funge da canale proxy tra l'agente di mobilità e i servizi di Site Recovery nel cloud. Garantisce che non sia necessaria alcun altra connettività Internet dai carichi di lavoro di produzione per generare punti di ripristino. Elementi individuati: questo componente raccoglie informazioni su vCenter e si coordina con il servizio di gestione di Azure Site Recovery nel cloud. Server di riprotezione: questo componente si coordina tra Azure e i computer locali durante le operazioni di riprotezione e failback. Server di elaborazione: questo componente viene usato per la memorizzazione nella cache e la compressione dei dati prima dell'invio ad Azure. Altre informazioni sull'appliance di replica e su come usare più appliance di replica. Agente del servizio di ripristino: questo componente viene usato per la configurazione/registrazione con i servizi di Site Recovery e per il monitoraggio dell'integrità di tutti i componenti. Provider di Site Recovery: questo componente viene usato per facilitare la riprotezione. Si identifica tra la riprotezione della posizione alternativa e la riprotezione della posizione originale per un computer di origine. Servizio di replica: questo componente viene usato per la replica dei dati dal percorso di origine ad Azure. |
| Server VMware | Le macchine virtuali VMware sono ospitate in server vSphere ESXi locali. È consigliabile usare un server vCenter per gestire gli host. | Durante la distribuzione di Site Recovery, aggiungere i server VMware all'insieme di credenziali di Servizi di ripristino. |
| Computer replicati | Il servizio Mobility viene installato in ogni macchina virtuale VMware da replicare. | È consigliabile consentire l'installazione automatica del servizio Mobility. In alternativa, è possibile installare manualmente il servizio. |
Configurare la connettività di rete in uscita
Affinché Site Recovery funzioni come previsto, è necessario modificare la connettività di rete in uscita per consentire all'ambiente di replicare.
Nota
Site Recovery non supporta l'uso di un proxy di autenticazione per controllare la connettività di rete.
Connettività in uscita per gli URL
Se si usa un proxy firewall basato su URL per controllare la connettività in uscita, consentire l'accesso a questi URL:
| URL | Dettagli |
|---|---|
portal.azure.com |
Passare al portale di Azure. |
*.windows.net *.msftauth.net*.msauth.net*.microsoft.com*.live.com *.office.com |
Per accedere alla sottoscrizione di Azure. |
*.microsoftonline.com |
Creare app Microsoft Entra affinché l'appliance comunichi con Azure Site Recovery. |
management.azure.com |
Creare app Microsoft Entra affinché l'appliance comunichi con il servizio Azure Site Recovery. |
*.services.visualstudio.com |
Caricare i log delle app usati per il monitoraggio interno. |
*.vault.azure.net |
Gestire i segreti in Azure Key Vault. Nota: assicurarsi che i computer da replicare abbiano accesso a questo. |
aka.ms |
Consentire l'accesso ai collegamenti "noti anche come". Usato per gli aggiornamenti dell'appliance di Azure Site Recovery. |
download.microsoft.com/download |
Consentire i download dal download Microsoft. |
*.servicebus.windows.net |
Comunicazione tra l'appliance e il servizio Azure Site Recovery. |
*.discoverysrv.windowsazure.com |
Connettersi agli URL del servizio di individuazione di Azure Site Recovery. |
*.hypervrecoverymanager.windowsazure.com |
Connettersi agli URL del microservizio di Azure Site Recovery. |
*.blob.core.windows.net |
Caricare i dati nell'archiviazione di Azure, che viene usata per creare dischi di destinazione. |
*.backup.windowsazure.com |
URL del servizio protezione: un microservizio usato da Azure Site Recovery per l'elaborazione e la creazione di dischi replicati in Azure. |
*.prod.migration.windowsazure.com |
Per scoprire la proprietà locale. |
Processo di replica
Quando si abilita la replica per una macchina virtuale, viene avviata la replica iniziale nell'archiviazione di Azure con i criteri di replica specificati. Nota quanto segue:
- Per le macchine virtuali VMware, la replica è a livello di blocco, quasi continua, e usa l'agente del servizio Mobility in esecuzione nella macchina virtuale.
- Vengono applicate tutte le impostazioni dei criteri di replica:
- Soglia RPO. Questa impostazione non influisce sulla replica. È utile con il monitoraggio. Viene generato un evento e, facoltativamente, viene inviato un messaggio di posta elettronica, se l'obiettivo RPO corrente supera la soglia specificata.
- Conservazione del punto di ripristino. Questa impostazione specifica quanto indietro nel tempo si vuole andare quando si verifica un'interruzione. La conservazione massima è di 15 giorni.
- Snapshot coerenti con l'app. È possibile acquisire snapshot coerenti con l'app a intervalli compresi tra 1 e 12 ore, a seconda delle esigenze dell'app. Si tratta di snapshot BLOB di Azure standard. L'agente di mobilità in esecuzione in una macchina virtuale richiede uno snapshot VSS conforme a questa impostazione e fa riferimento a quel momento come punto coerente con l'applicazione nel flusso di replica.
Nota
Un periodo di conservazione dei punti di ripristino elevato può influire sul costo di archiviazione perché potrebbe essere necessario salvare più punti di ripristino.
Il traffico viene replicato negli endpoint pubblici di archiviazione di Azure, tramite Internet. In alternativa, è possibile usare Azure ExpressRoute con il peering Microsoft. La replica del traffico tramite una rete privata virtuale da sito a sito (VPN) da un sito locale ad Azure è supportata solo quando si usano endpoint privati.
L'operazione di replica iniziale garantisce che interi dati nel computer al momento dell'abilitazione della replica vengano inviati ad Azure. Al termine della replica iniziale, viene avviata la replica differenziale in Azure. Le modifiche rilevate per un computer vengono inviate al server di elaborazione.
Le comunicazioni avvengono nel modo seguente:
- Le macchine virtuali comunicano con appliance locali sulla porta HTTPS 443 in ingresso, per la gestione delle repliche.
- Le macchine virtuali inviano i dati di replica all'appliance sulla porta HTTPS 9443 in ingresso. La porta può essere modificata.
- L’appliance riceve i dati della replica, li ottimizza e li crittografa, quindi li invia ad Archiviazione di Azure attraverso la porta 443 in uscita.
I log dei dati di replica vengono prima inseriti in un account di archiviazione della cache in Azure. Questi log vengono elaborati e i dati vengono archiviati in un disco gestito di Azure denominato asrseeddisk. I punti di ripristino vengono creati su questo disco.
Processo di risincronizzazione
- In alcuni casi, durante la replica iniziale o durante il trasferimento delle modifiche differenziali, possono verificarsi problemi di connettività di rete tra il computer di origine e il server di elaborazione o tra i server di elaborazione in Azure. Uno di questi può causare errori temporanei nel trasferimento dei dati in Azure.
- Per evitare problemi di integrità dei dati e ridurre al minimo i costi di trasferimento dei dati, Site Recovery contrassegna un computer per la risincronizzazione.
- Un computer può anche essere contrassegnato per la risincronizzazione in situazioni come le seguenti per mantenere la coerenza tra il computer di origine e i dati archiviati in Azure
- Se una macchina subisce l'arresto forzato
- Se un computer subisce modifiche di configurazione come il dimensionamento del disco (modifica delle dimensioni del disco da 2 TB a 4 TB)
- La risincronizzazione invia solo i dati differenziali ad Azure. Il trasferimento dei dati tra l'ambiente locale e Azure viene ridotto a icona calcolando i checksum dei dati tra il computer di origine e i dati archiviati in Azure.
- Per impostazione predefinita, la risincronizzazione è pianificata per l'esecuzione automatica al di fuori degli orari lavorativi. Se non si vuole attendere la risincronizzazione predefinita al di fuori degli orari di lavoro, è possibile risincronizzare una macchina virtuale manualmente, A questo scopo, nel portale di Azure selezionare la macchina virtuale >Risincronizza.
- Se la risincronizzazione predefinita ha esito negativo al di fuori dell'orario di ufficio e viene richiesto un intervento manuale, viene generato un errore nel computer specifico nel portale di Azure. È possibile risolvere l'errore e attivare manualmente la risincronizzazione.
- Al termine della risincronizzazione, la replica delle modifiche differenziali riprenderà.
Criteri di replica
Quando si abilita la replica delle macchine virtuali di Azure, per impostazione predefinita Site Recovery crea nuovi criteri di replica con le impostazioni predefinite riepilogate nella tabella.
| Impostazione criteri | Dettagli | Predefinita |
|---|---|---|
| Conservazione del punto di ripristino | Specifica per quanto tempo Site Recovery conserva i punti di ripristino | 1 giorno |
| Frequenza snapshot coerenti con l'applicazione | Specifica con quale frequenza Site Recovery accetta uno snapshot coerente con l'app | Disabilitata |
Gestione dei criteri di replica
È possibile gestire e modificare le impostazioni predefinite dei criteri di replica nei modi seguenti:
- È possibile modificare le impostazioni quando si abilita la replica.
- È possibile creare o modificare nuovi criteri di replica durante il tentativo di abilitare la replica.
Coerenza tra più macchine virtuali
Se si vuole che le macchine virtuali vengano replicate insieme e abbiano punti di ripristino condivisi coerenti con l'arresto anomalo del sistema e coerenti con l'app in caso di failover, è possibile raccoglierle in un gruppo di replica. La coerenza tra più macchine virtuali influisce sulle prestazioni dei carichi di lavoro e deve essere usata solo per le macchine virtuali 4 che eseguono carichi di lavoro per cui la coerenza fra tutte le macchine è fondamentale.
Snapshot e punti di ripristino
I punti di ripristino vengono creati da snapshot dei dischi delle macchine virtuali acquisiti in un momento specifico. Quando si effettua il failover di una macchina virtuale, si usa un punto di ripristino per ripristinare la VM nella posizione di destinazione.
Prima di effettuare il failover è importante assicurarsi che la macchina virtuale venga avviata senza danneggiamenti o perdita di dati e che i dati della VM siano coerenti per il sistema operativo e per le app in esecuzione su di essa. Tutto questo dipende dal tipo di snapshot acquisiti.
Site Recovery acquisisce snapshot nel modo seguente:
- Site Recovery acquisisce snapshot dei dati coerenti con l'arresto anomalo del sistema per impostazione predefinita, oltre a snapshot coerenti con l'app se si specifica una frequenza.
- Dagli snapshot vengono creati punti di ripristino che vengono archiviati in base alle impostazioni di conservazione dei criteri di replica.
Coerenza
La tabella seguente illustra i vari tipi di coerenza.
Coerenza con l'arresto anomalo del sistema
| Descrizione | Dettagli | Consiglio |
|---|---|---|
| Uno snapshot coerente con l'arresto anomalo del sistema acquisisce i dati contenuti nel disco al momento dell'acquisizione dello snapshot. Non include alcun dato in memoria. Contiene l'equivalente dei dati su disco che sarebbero presenti se si verificasse un arresto anomalo della macchina virtuale o se il cavo di alimentazione del server venisse scollegato nell'istante esatto dell'acquisizione dello snapshot. Uno snapshot coerente con l'arresto anomalo del sistema non garantisce la coerenza dei dati per il sistema operativo o per le app in esecuzione nella macchina virtuale. |
Per impostazione predefinita, Site Recovery crea punti di ripristino coerenti con l'arresto anomalo del sistema ogni cinque minuti. Questa impostazione non può essere modificata. |
Attualmente, la maggior parte delle app può essere ripristinata correttamente da punti coerenti con l'arresto anomalo del sistema. I punti di ripristino coerenti con l'arresto anomalo del sistema sono in genere sufficienti per la replica di sistemi operativi e app come i server DHCP e i server di stampa. |
Coerenza con l'app
| Descrizione | Dettagli | Consiglio |
|---|---|---|
| I punti di ripristino coerenti con l'app vengono creati dagli snapshot coerenti con l'app. Uno snapshot coerente con l'app contiene tutte le informazioni contenute in uno snapshot coerente con l'arresto anomalo del sistema, oltre a tutti i dati in memoria e le transazioni in corso. |
Gli snapshot coerenti con l'app usano il servizio Copia Shadow del volume: 1) Azure Site Recovery usa il metodo di backup di sola copia (VSS_BT_COPY) che non modifica il tempo di backup del log delle transazioni di Microsoft SQL e il numero di sequenza 2) Quando viene avviato uno snapshot, VSS esegue un'operazione COW (Copy-On-Write) nel volume. 3) Prima di eseguire l'operazione di copia su scrittura, il servizio informa ogni app presente nella macchina virtuale che dovrà scaricare i dati residenti in memoria su disco. 4) Il servizio Copia Shadow del volume consente quindi all'app di backup/ripristino di emergenza (in questo caso Site Recovery) di leggere i dati dello snapshot e di procedere. |
Gli snapshot vengono acquisiti in base alla frequenza specificata. Questa frequenza deve essere sempre inferiore a quella impostata per la conservazione dei punti di ripristino. Ad esempio, se i punti di ripristino vengono conservati in base all'impostazione predefinita di 24 ore, la frequenza deve essere impostata su un periodo inferiore a 24 ore. Gli snapshot coerenti con l'app sono più complessi e il loro completamento richiede più tempo rispetto agli snapshot coerenti con l'arresto anomalo del sistema. Influiscono sulle prestazioni delle app in esecuzione su una macchina virtuale abilitata per la replica. |
Processo di failover e failback
Dopo aver configurato la replica e aver eseguito un'analisi di ripristino di emergenza (failover di test) per verificare che funzioni tutto come previsto, è possibile eseguire il failover e il failback in base alle esigenze.
È possibile eseguire il failover di una singola macchina virtuale o creare piani di ripristino per eseguire contemporaneamente il failover di più macchine virtuali. Rispetto al failover di una singola macchina virtuale, un piano di ripristino offre i vantaggi seguenti:
- È possibile modellare le dipendenze di un'app includendo tutte le macchine virtuali dell'app in un solo piano di ripristino.
- È possibile aggiungere script e runbook di Azure e sospendere il failover per eseguire operazioni manuali.
Dopo aver attivato il failover iniziale, è necessario eseguirne il commit per iniziare ad accedere al carico di lavoro dalla macchina virtuale di Azure.
Quando il sito locale primario è di nuovo disponibile, è possibile eseguire le attività preliminari al failback. Se è necessario eseguire il failback di grandi volumi di traffico, configurare una nuova appliance di replica di Azure Site Recovery.
- Fase 1: riproteggere le macchine virtuali di Azure in modo da eseguirne di nuovo la replica da Azure alle macchine virtuali VMware locali.
- Fase 2: eseguire un failover nel sito locale.
- Fase 3: al termine del failback dei carichi di lavoro, riabilitare la replica per le macchine virtuali locali.
Passaggi successivi
Seguire questa esercitazione per abilitare la replica da VMware ad Azure.