Ripristino di emergenza su scala aziendale per la soluzione Azure VMware

Questo scenario su scala aziendale consente di migliorare la continuità aziendale e il ripristino di emergenza.This enterprise-scale scenario helps improve business continuity and disaster recovery (BCDR). soluzione Azure VMware fornisce cloud privati che contengono cluster VMware vSphere creati da un'infrastruttura bare metal dedicata di Azure. La soluzione offre almeno tre host ESXi, fino a un massimo di 16 host per cluster. Tutti i cloud privati con provisioning hanno il server VMware vCenter, VMware vSAN, VMware vSphere e VMware NSX-T Data Center. Per informazioni sul contratto di servizio (SLA) per soluzione Azure VMware, vedere Contratto di servizio per soluzione Azure VMware.

Sia che si disponga di un soluzione Azure VMware locale, è consigliabile prendere in considerazione vari fattori bcdr per prepararsi a un'emergenza. Un solido piano BCDR mira a proteggere un'azienda dalla perdita di dati, dalla perdita finanziaria e dai tempi di inattività in caso di evento di interruzione. L'albero delle decisioni seguente mostra varie opzioni BCDR disponibili per soluzione Azure VMware.

Considerazioni sulla progettazione della continuità aziendale

• I criteri di archiviazione vSAN di VMware nella soluzione Azure VMware vengono implementati tenendo presente la disponibilità di archiviazione. Quando il cluster ha tra tre e cinque host, il numero di errori dell'host che possono essere tollerati senza perdita di dati è uguale a uno. Quando il cluster ha tra i 6 e i 16 host, il numero di errori tollerati negli host prima che si verifichi una perdita di dati è pari a due. I criteri di archiviazione vSAN di VMware possono essere applicati per ogni macchina virtuale. Anche se questi criteri sono l'impostazione predefinita, è possibile modificare i criteri in base ai requisiti personalizzati. Per altre informazioni, vedere Concetti di archiviazione della soluzione Azure VMware.

• La disponibilità elevata di vSphere è abilitata per impostazione predefinita in soluzione Azure VMware. I criteri di ammissione a disponibilità elevata riservano capacità di calcolo e memoria per un singolo nodo. Questa prenotazione garantisce capacità sufficiente per riavviare i carichi di lavoro in un altro nodo in un cluster soluzione Azure VMware.

• Disponibilità elevata con cluster esteso: con soluzione Azure VMware, gli host ESXi distribuiti in un cluster vSphere standard si trovano tradizionalmente in una singola zona di disponibilità di Azure e sono protetti dalla disponibilità elevata di vSphere. Tuttavia, i carichi di lavoro non sono protetti da un errore della zona di disponibilità. Per proteggersi da errori, un singolo cluster vSAN può estendersi su due zone di disponibilità separate, denominate cluster esteso vSAN. Per altre informazioni, vedere Distribuire cluster estesi vSAN.

• Scegliere una soluzione di backup convalidata per le macchine virtuali VMware vSphere, ad esempio Microsoft Backup di Azure Server o una soluzione di backup partner.

• Per informazioni sulle funzionalità supportate nelle soluzioni di backup dei partner, vedere la rispettiva documentazione dei partner.

  Nota

  soluzione Azure VMware le configurazioni del server vCenter del cloud privato e HCX Manager (se abilitato) sono in base a una pianificazione giornaliera del backup e la configurazione NSX è in base alla pianificazione del backup oraria. I backup vengono conservati per un minimo di tre giorni.

• soluzione Azure VMware componenti come vCenter Server, NSX-T Manager o HCX Manager sono servizi gestiti per cui Azure gestisce il backup. Per eseguire il ripristino da un backup, creare una richiesta di supporto di Azure.

Raccomandazioni per la progettazione della continuità aziendale

• Usare Backup di Azure Server per eseguire il backup del cloud privato soluzione Azure VMware. Per altre informazioni, vedere Eseguire il backup di macchine virtuali VMware vSphere con Backup di Azure. Le topologie di distribuzione supportate includono MARS Agent e Data Protection Manager. Ogni topologia di distribuzione ha una propria matrice di supporto, vincoli e limitazioni.

• Distribuire il server di Backup di Azure nella stessa area di Azure in cui si trova il cloud privato della soluzione Azure VMware. Questo metodo di distribuzione riduce i costi del traffico, semplifica l'amministrazione e mantiene la topologia primaria/secondaria. Vedere la guida alla selezione delle aree di Azure per le procedure consigliate per la distribuzione dell'area di Azure.

• Backup di Azure può essere distribuito come macchina virtuale IaaS (Infrastructure as a Service) di Azure o all'interno del cloud privato soluzione Azure VMware. È consigliabile distribuirlo all'esterno del cloud privato soluzione Azure VMware. Distribuire Il backup in una rete virtuale di Azure e assicurarsi che questa rete virtuale sia connessa allo stesso ExpressRoute connesso al cloud privato soluzione Azure VMware. L'esecuzione del server di backup all'esterno di soluzione Azure VMware cloud privato consente di ridurre il consumo di vSAN, poiché vSAN è una risorsa di capacità limitata all'interno del cloud privato soluzione Azure VMware.

  Backup di Azure Server distribuito come macchina virtuale IaaS di Azure.

  

  Backup di Azure Server distribuito come macchina virtuale soluzione Azure VMware.

  

• Usare l'elenco di controllo dei requisiti di prestazioni dell'applicazione per ottenere la capacità e il tipo di disco corretti, ad esempio HDD, SSD o Ultra. Si consideri lo SKU della macchina virtuale IaaS di Azure che supporta il tipo di disco e la capacità per le operazioni di backup.

• Usare Backup di Azure Server Capacity Planner per determinare il numero di server, archiviazione e requisiti di I/O al secondo per ognuno di essi. Quando si specifica il valore "Dimensioni totali del carico di lavoro (GB)*" in Capacity Planner, usare il valore mediano tra "spazio di archiviazione usato" e "archiviazione allocata" di tutte le macchine virtuali in vCenter di cui si vuole eseguire il backup.

• Usare i pool di archiviazione con Backup di Azure Server per operazioni di I/O al secondo del disco avanzate.Use storage pools with Backup di Azure Server for enhanced disk IOPS/throughput. Usare l'archiviazione a livelli nel server di backup per operazioni avanzate. Impostare DisableWriteAutoTiering config value (Valore di configurazione DisableWriteAutoTiering ) su 1 nel volume maBS in modo che l'intero livello di prestazioni sia disponibile per archiviare i metadati ReFS.

• Identificare il numero di processi di backup paralleli e operazioni di ripristino da eseguire nel server Backup di Azure. Attualmente sono supportati otto processi di backup paralleli. Misurare la quantità di tempo impiegato per eseguire il backup e il ripristino di carichi di lavoro cruciali in più esecuzioni. Verificare che i tempi di backup e ripristino soddisfino i requisiti RPO e RTO per Backup di Azure server. Assicurarsi che l'archivio dati vSAN avS disponga di capacità sufficiente per contenere il backup ripristinato.

• Aggiungere le eccezioni antivirus necessarie per Backup di Azure file e cartelle del server, come documentato qui se un software Antivirus/Antimalware viene eseguito in Backup di Azure Server. Quando si usa l'agente protezione DPM in qualsiasi macchina virtuale soluzione Azure VMware per il backup dell'applicazione (ad esempio, SQL, Sharepoint e così via), disabilitare il monitoraggio in tempo reale delle dpmra.exe.

• Configurare le regole appropriate del gruppo di sicurezza di rete (gruppo di sicurezza di rete) nella subnet che ospita Backup di Azure Server per consentire la comunicazione di rete dall'agente protezione DPM in esecuzione nella macchina virtuale protetta in soluzione Azure VMware. L'agente protezione DPM comunica con Backup di Azure Server su qualsiasi porta dinamica compresa tra 1024 e 65535.

• Attualmente, Backup di Azure Server non supporta il ripristino tra aree per soluzione Azure VMware cloud privato. Fare riferimento alla sezione Soluzioni di backup dei partner e ripristino di emergenza quando è necessario il ripristino tra aree soluzione Azure VMware.

Considerazioni sulla progettazione del ripristino di emergenza

• Allineare i requisiti aziendali con gli obiettivi del tempo di ripristino (RTO), la capacità e gli obiettivi del punto di ripristino (RPO) per le applicazioni. Pianificare e progettare di conseguenza per raggiungere questi obiettivi usando la tecnologia di replica più appropriata. Ad esempio, replicare in modo nativo i database SQL usando il gruppo di disponibilità SQL AlwaysOn o usare uno strumento di ripristino di emergenza, ad esempio VMware Site Gestione ripristino.

• Determinare il sito di ripristino di emergenza di destinazione per il cloud privato soluzione Azure VMware protetto. Questo sito influenza gli strumenti di ripristino di emergenza adatti per l'ambiente. Ad esempio, se si vuole ripristinare soluzione Azure VMware carichi di lavoro nelle macchine virtuali IaaS native di Azure, è possibile prendere in considerazione Azure Site Recovery o Zerto.

• Determinare quale subset di soluzione Azure VMware carichi di lavoro richiede la protezione se si verifica un evento di ripristino di emergenza. Prendere in considerazione la categorizzazione dei carichi di lavoro in base alla priorità: P0 per i carichi di lavoro critici per l'azienda e P1, P2, P3 per altri carichi di lavoro importanti ma non come critici per il funzionamento dell'azienda. Il piano di continuità aziendale del cliente definisce i livelli di priorità, che consentono di controllare i costi associati all'implementazione del ripristino di emergenza.

• Nella maggior parte dei casi, gli ambienti non di produzione, ad esempio sviluppo, test o UAT, non devono eseguire il failover in un sito secondario. È consigliabile eseguire la luce pilota nel sito secondario con capacità ridotta per i carichi di lavoro critici e di produzione per risparmiare sui costi. Per una maggiore capacità, è possibile aumentare il numero di istanze per aggiungere host ESXi al cluster durante l'evento di ripristino di emergenza.

• Per le distribuzioni di luce pilota in particolare, assicurarsi di aver protetto tutte le quote host necessarie nel sito secondario, in modo che non sia necessario attendere la capacità necessaria durante il ridimensionamento completo. Vedere Richiedere la quota dell'host per soluzione Azure VMware.

• Configurare i ruoli di dominio funzionali, ad esempio i controller di dominio di Active Directory, nell'ambiente secondario.

• Le soluzioni di partner come JetStream e Zerto sono disponibili a livello generale e convalidate in soluzione Azure VMware. Supportano la maggior parte degli scenari di ripristino di emergenza e possono offrire un ripristino più rapido con RPO quasi zero.

• VMware Site Gestione ripristino, Jetstream e Zerto supportano la migrazione da posizioni di terze parti a soluzione Azure VMware.

• VMware HCX è anche una soluzione di ripristino di emergenza conveniente. Tuttavia, non è consigliabile per carichi di lavoro di produzione di grandi dimensioni a causa dell'orchestrazione manuale.

• Per il ripristino di emergenza tra soluzione Azure VMware cloud privati in aree di Azure diverse, è necessario abilitare Copertura globale di ExpressRoute tra entrambi i circuiti ExpressRoute back-end. Questi circuiti creano connettività cloud privato da primaria a secondaria quando necessario per soluzioni come VMware SRM e VMware HCX.

• Per il ripristino di emergenza tra soluzione Azure VMware cloud privati nella stessa area di Azure, è necessario abilitare soluzione Azure VMware Interconnessione. Crea un collegamento di routing tra le reti di gestione e carico di lavoro dei cloud privati soluzione Azure VMware per la comunicazione tra i cloud. Assicurarsi che lo spazio indirizzi IP indirizzato in ogni cloud privato sia univoco e non si sovrapponga.

• Quando si usa il ripristino di emergenza, è possibile usare lo stesso spazio di indirizzi IP di origine nell'area primaria di Azure e nell'area secondaria di Azure. Tuttavia, richiede ulteriori sforzi di progettazione e progettazione.

  • Mantenere gli stessi indirizzi IP: le macchine virtuali nel sito secondario soluzione Azure VMware possono essere ripristinate usando lo stesso indirizzo IP di origine del sito primario. Per questo metodo, creare VLAN isolate o segmenti NSX-T nel sito secondario e assicurarsi che nessuna di queste VLAN o segmenti isolati sia connessa all'ambiente. Modificare le route di ripristino di emergenza in modo da riflettere che la subnet è stata spostata nel sito secondario e nella nuova posizione degli indirizzi IP. Anche se questo metodo funziona, crea anche un sovraccarico di progettazione quando si mira al ripristino di emergenza completamente automatizzato.

  • Usare indirizzi IP diversi: è anche possibile usare indirizzi IP diversi per le macchine virtuali ripristinate. Se la macchina virtuale viene spostata in un sito secondario, il piano di ripristino all'interno del sito VMware Gestione ripristino dettaglia la mappa IP personalizzata. Selezionare questa mappa per la modifica dell'indirizzo IP. Le macchine virtuali vengono visualizzate nei nuovi segmenti NSX-T e vengono assegnati nuovi indirizzi IP. Gli strumenti possono variare per diverse soluzioni di ripristino di emergenza.

• Fattori importanti per scenari di ripristino di emergenza parziali e completi:

  • VMware Site Gestione ripristino supporta il ripristino parziale, che recupera solo un subset di macchine virtuali e il ripristino di emergenza completo. Tra due siti soluzione Azure VMware nell'area 1 e nell'area 2, è possibile eseguire il failover di tutte o alcune delle macchine virtuali.

  • Il requisito di conservazione degli indirizzi IP di origine per le macchine virtuali ripristinate determina se è possibile un ripristino di emergenza parziale o completo.

  • Per mantenere l'indirizzo IP di origine durante l'esecuzione del ripristino di emergenza parziale in Site Gestione ripristino, il gateway subnet deve passare al sito secondario.

  Nota

  Il ripristino di emergenza attivo-standby non richiede l'estensione di livello 2.

Consigli per la progettazione del ripristino di emergenza

• Usare Gestione ripristino del sito VMware quando si usano soluzione Azure VMware sia nei siti primari che secondari. I siti primari e secondari sono noti anche come siti protetti e di ripristino, rispettivamente.

  Panoramica generale della replica vSphere continua.

  

  Esempio dettagliato della replica continua di vSphere tra siti primari e secondari.

  

• Per le applicazioni critiche per l'azienda, Zerto e JetStream sono disponibili come soluzioni di ripristino di emergenza per soluzione Azure VMware cloud privato. JetStream e Zerto sono basati sulla base della protezione continua dei dati (CDP), usando l'API VMware vSphere per il framework vaio (I/O filtering), che consente una perdita minima o vicina a nessuna perdita di dati. Consente anche un ripristino di emergenza conveniente usando risorse minime.

• Usare Azure Site Recovery o Zerto, se le macchine virtuali IaaS di Azure sono la destinazione di ripristino di emergenza per il cloud privato soluzione Azure VMware.

• Ridurre al minimo l'input manuale usando piani di ripristino automatizzati all'interno di ognuna delle rispettive soluzioni di ripristino di emergenza. Questi piani sono utili quando si lavora con VMware Site Gestione ripristino o soluzioni partner. Un piano di ripristino raccoglie i computer in gruppi di ripristino per il failover. Consente quindi di definire un processo di ripristino sistematico creando unità indipendenti che possono eseguire il failover.

• Configurare i test di fumo o le esercitazioni sul ripristino di emergenza almeno una volta all'anno per garantire che i piani di ripristino funzionino come previsto. Le funzionalità di orchestrazione dello strumento di ripristino di emergenza scelto determinano il livello di impegno necessario per l'esecuzione di queste esercitazioni.

• Usare coppie di aree geopolitiche come ambiente di ripristino di emergenza secondario. Alcuni dei vantaggi delle coppie a livello di area sono il ripristino delle aree con priorità, gli aggiornamenti sequenziali, l'isolamento fisico e la residenza dei dati.

• Mantenere gli spazi di indirizzi diversi per evitare la sovrapposizione degli indirizzi IP tra i due siti. Ad esempio, è possibile usare per l'area 192.168.0.0/16 1 e 10.0.0.0/16 per l'area 2.

• Usare la connettività Copertura globale di ExpressRoute tra i cloud privati primari e secondari in aree diverse. Vedere altre considerazioni e raccomandazioni sulla rete nell'area di progettazione corrispondente.

Passaggi successivi

Considerazioni e consigli per la distribuzione iniziale della soluzione Azure VMware e indicazioni per l'automazione operativa.