Architettura del ripristino di emergenza da server fisico ad Azure - Modernizzato
Questo articolo descrive l'architettura modernizzata e i processi usati per la replica, il failover e il ripristino di server fisici Windows e Linux tra un sito locale e Azure, usando il servizio Azure Site Recovery.
Per informazioni sui requisiti del server di configurazione nelle versioni classiche, vedere Architettura di ripristino di emergenza da server fisico ad Azure.
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.
Componenti dell'architettura
La tabella e l'immagine seguenti offrono una visualizzazione generale dei componenti usati per il ripristino di emergenza dal computer fisico 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 computer 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 connettività Internet aggiuntiva 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. |
| Computer replicati | Il servizio Mobility viene installato in ogni computer fisico 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: verificare che i computer da replicare abbiano accesso a questo URL. |
| aka.ms | Consentire l'accesso ai collegamenti aka.ms. 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 |
Processo di replica
Quando si abilita la replica per un sistema, viene avviata la replica iniziale nell'archiviazione di Azure con i criteri di replica specificati. Nota quanto segue:
- Per i computer fisici, la replica è a livello di blocco, quasi continua, e usa l'agente del servizio di mobilità in esecuzione nel sistema.
- 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 un computer fisico 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 VPN da sito a sito da un sito locale ad Azure non è supportata.
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:
- I computer comunicano con appliance locali sulla porta HTTPS 443 in ingresso, per la gestione delle repliche.
- L'appliance orchestra la replica con Azure attraverso la porta HTTPS 443 in uscita.
- I computer inviano i dati di replica al server di elaborazione sulla porta HTTPS 9443 in ingresso. La porta può essere modificata.
- Il server di elaborazione 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 failover e failback
Dopo aver configurato la replica ed eseguito un'esercitazione sul ripristino di emergenza (failover di test) per verificare che tutto funzioni come previsto, è possibile eseguire il failover in base alle esigenze.
Nota
Per i server fisici, il failback non è supportato
- È possibile eseguire il failover per un singolo computer o creare un piano di ripristino per eseguire il failover simultaneo di più server. Rispetto al failover di una singola macchina virtuale, un piano di ripristino offre i vantaggi seguenti:
- È possibile modellare le dipendenze di un'app includendo tutti i server 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.
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 un sistema manualmente. A questo scopo, nel portale di Azure selezionare il computer fisico >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 |
Snapshot e punti di ripristino
I punti di ripristino vengono creati da snapshot dei dischi dei computer acquisiti in un momento specifico. Quando si effettua il failover di un sistema, si usa un punto di ripristino per ripristinare il computer fisico come 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 del sistema 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 nel computer. |
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 di copia su scrittura (COW) 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 un sistema abilitato per la replica. |
Passaggi successivi
Seguire questa esercitazione per abilitare la replica da computer fisico e VMware ad Azure.