Affidabilità in soluzione Azure VMware

soluzione Azure VMware Gen 1 supporta le zone di disponibilità tramite cluster allungati, che distribuiscono gli host ESXi tra due zone di disponibilità all'interno di una regione. Microsoft seleziona le zone da usare. Il cluster funziona in una configurazione attiva-attiva attraverso le due zone e vSAN si estende anche su più zone. È possibile stabilire se ogni carico di lavoro viene distribuito in una o due zone.

Un nodo testimone viene distribuito automaticamente in una terza zona di disponibilità per fornire il quorum per scenari split-brain. Microsoft gestisce automaticamente il nodo testimone.

Un cluster standard è un cluster che non è esteso tra le zone. In un cluster standard, il cluster e tutti gli host ESXi sono considerati non locali o regionali. I cluster non di zona possono essere inseriti in qualsiasi zona di disponibilità all'interno dell'area e Microsoft seleziona la zona. Se una zona di disponibilità nell'area riscontra un'interruzione, i cluster e gli host non di zona potrebbero trovarsi nella zona interessata e potrebbero verificarsi tempi di inattività.

soluzione Azure VMware Gen 2 supporta distribuzioni a zone di cloud privati. Quando si configura un cloud privato di zona, ognuno dei relativi cluster e tutti gli host ESXi vengono distribuiti in una singola zona di disponibilità selezionata.

Un cloud privato di zona non protegge da errori della zona di disponibilità. È possibile distribuire più cloud privati in zone di disponibilità separate per una maggiore resilienza, ma si è responsabili della distribuzione e della configurazione di ogni cloud privato in modo indipendente.

Se non si seleziona una zona di disponibilità, il cloud privato, i relativi cluster e tutti gli host ESXi sono considerati non locali o regionali. I cluster non di zona possono essere inseriti in qualsiasi zona di disponibilità all'interno dell'area e Microsoft seleziona la zona. Se si verifica un'interruzione di una zona di disponibilità nell'area, i cluster non di zona nella zona interessata potrebbero riscontrare tempi di inattività.

• Region support: I cluster estesi sono disponibili solo in aree Azure che supportano la configurazione estesa del cluster. Controllare la tabella di mapping tra zona di disponibilità della regione di Azure e tipo di host per il supporto della regione corrente.

• Host minimi: Distribuire almeno sei host in due zone di disponibilità (tre host per ogni zona) per abilitare la configurazione estesa del cluster. Quando si aumenta o si diminuisce il numero di host, è necessario ridimensionare a coppie in modo che ogni zona abbia un numero uguale di host.

• SKU host: I tipi di host AV36, AV36P e AV52 supportano cluster estesi. Lo SKU AV64 non supporta i cluster stretch.

• supporto Region: È possibile distribuire cloud privati di zona in aree che supportano sia soluzione Azure VMware Gen 2 che zone di disponibilità.

Considerazioni

Ogni zona di disponibilità in un'area può supportare tipi di host specifici. Per un elenco dettagliato dei tipi di host disponibili in ogni zona, vedere tabella di mapping tra zona di disponibilità della regione Azure e tipo di host.

• Distribuire un nuovo cluster: Quando si crea un nuovo cloud privato soluzione Azure VMware in un'area supportata, è possibile configurarlo come cluster esteso durante la distribuzione. Questa configurazione distribuisce automaticamente gli host tra due zone di disponibilità. Per ulteriori informazioni, vedere Distribuire cluster vSAN estesi.

• Cluster esistenti: Non è possibile convertire un cluster standard in un cluster esteso e non è possibile convertire un cluster esteso in un cluster standard. È invece necessario distribuire un nuovo cluster ed eseguire la migrazione dei carichi di lavoro.

• Distribuire un nuovo cluster: Quando si crea un nuovo cloud privato soluzione Azure VMware in un'area supportata, è possibile selezionarne la zona di disponibilità.

• Cluster esistenti: Non è possibile modificare la configurazione della zona di disponibilità di un cluster esistente. È invece necessario distribuire un nuovo cluster ed eseguire la migrazione dei carichi di lavoro.

Questa sezione descrive cosa aspettarsi quando il cluster è esteso e tutte le zone di disponibilità sono funzionanti.

• Operazione tra zone: Le macchine virtuali possono essere eseguite in host in entrambe le zone di disponibilità. È possibile controllare il posizionamento delle macchine virtuali usando le regole di affinità e anti-affinità di vSphere Distributed Resource Scheduler (DRS) per ottimizzare i requisiti di prestazioni o disponibilità.

• Replica dei dati tra zone: vSAN replica i dati in modo sincrono tra zone di disponibilità. Entrambe le zone confermano ogni operazione di scrittura prima del completamento per garantire l'integrità coerente dei dati.

Questa sezione descrive cosa aspettarsi quando il cluster viene distribuito in un cloud privato di zona e tutte le zone di disponibilità sono operative.

• Operazione tra zone: Le macchine virtuali vengono eseguite negli host all'interno della zona di disponibilità del cluster.

• Replica dei dati tra zone: Nessun dato viene replicato in un'altra zona.

Questa sezione descrive cosa aspettarsi quando il cluster è configurato come "stretched" e si verifica un'interruzione in una zona di disponibilità.

• Rilevamento e risposta: soluzione Azure VMware gestisce la risposta a livello di infrastruttura in caso di guasti nella zona. vSphere HA rileva automaticamente gli errori della zona e avvia le procedure di riavvio della macchina virtuale, se necessario.

• Notification: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Azure Integrità risorse per monitorare l'integrità di una singola risorsa ed è possibile configurare Integrità risorse avvisi per segnalare eventuali problemi. È anche possibile usare integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità Servizi per notificare i problemi.

• Richieste attive: Tutte le macchine virtuali in esecuzione nella zona di disponibilità guasta vengono riavviate sugli host nella zona di disponibilità sana. Le richieste e le connessioni attive alle macchine virtuali interessate terminano e i client sono responsabili della ripetizione dei tentativi.

• Tempo di inattività previsto: Il tempo di riavvio delle macchine virtuali non riuscite nella zona integra è in genere di pochi minuti, a seconda della configurazione e delle procedure di avvio della macchina virtuale. Il cluster esteso rimane operativo con capacità ridotta.

  Se la zona di disponibilità non riuscita contiene il nodo testimone, il nodo testimone diventa non raggiungibile. Finché le repliche di dati sufficienti rimangono disponibili, gli host dati e i carichi di lavoro in esecuzione continuano a funzionare senza perdita immediata di dati. Tuttavia, vSAN perde la consapevolezza del quorum in questo stato. La perdita del quorum impedisce di prendere decisioni di posizionamento e ripristino in modo sicuro. Blocca anche determinate operazioni, ad esempio l'alimentazione della macchina virtuale dopo gli errori, il ribilanciamento e le riparazioni.

• Perdita di dati prevista: Poiché vSAN usa la replica sincrona tra le zone, non è prevista alcuna perdita di dati durante un errore di zona.

• Ridistribuzione: vSphere DRS ridistribuisce automaticamente i carichi di lavoro delle macchine virtuali nella zona di disponibilità integra. Il routing del traffico di rete tramite VMware NSX si adatta automaticamente al nuovo posizionamento della macchina virtuale.

Questa sezione descrive cosa aspettarsi quando il cluster viene distribuito in un cloud privato di zona e si verifica un'interruzione della zona di disponibilità.

• Rilevamento e risposta: È necessario rilevare la perdita di una zona di disponibilità. Se necessario, è possibile avviare un failover in un cluster secondario precedentemente creato in un'altra zona di disponibilità.

• Notification: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Azure Integrità risorse per monitorare l'integrità di una singola risorsa ed è possibile configurare Integrità risorse avvisi per segnalare eventuali problemi. È anche possibile usare integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità Servizi per notificare i problemi.

• Richieste attive: Le richieste e le connessioni attive alle macchine virtuali interessate terminano e i client sono responsabili della ripetizione dei tentativi.

• Tempo di inattività previsto: Quando una zona non è disponibile, il cluster e i relativi carichi di lavoro non sono disponibili fino al ripristino della zona di disponibilità.

• Perdita di dati prevista: I dati nella zona interessata non sono disponibili fino al ripristino della zona.

• Ridistribuzione: Se necessario, si è responsabili del passaggio del traffico ad altri cluster in zone funzionanti.

Quando la zona di disponibilità viene ripristinata, vSphere DRS può facoltativamente ridistribuire le macchine virtuali nella zona ripristinata in base alla configurazione e alle regole di affinità drs. È anche possibile controllare manualmente il posizionamento delle macchine virtuali usando le operazioni vMotion.

Quando la zona di disponibilità viene ripristinata, i cluster e gli host nella zona sono nuovamente disponibili. L'utente è responsabile delle procedure di ripristino della zona e della sincronizzazione dei dati richiesta dai carichi di lavoro.

Per prepararsi agli errori di zona, testare la resilienza dell'applicazione per i riavvii delle macchine virtuali e le modifiche al percorso di rete, soprattutto quando sono stati estesi cluster o si distribuiscono applicazioni in cluster separati in zone diverse.

Poiché soluzione Azure VMware gestisce la risposta dell'infrastruttura agli errori della zona, è necessario testare principalmente la risposta dell'applicazione ai riavvii della macchina virtuale.

L'utente è responsabile di qualsiasi risposta dell'infrastruttura agli errori della zona, ad esempio il failover in un altro cluster situato in una zona o in un'area geografica diversa. Assicurarsi di testare accuratamente i processi di risposta.

I cluster che configuri come cluster estesi hanno un SLA di disponibilità dell'infrastruttura con carico di lavoro più elevato.