Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La soluzione Azure VMware offre cloud privati che contengono cluster VMware vSphere creati da un'infrastruttura bare metal dedicata di Azure. È possibile eseguire la migrazione dei carichi di lavoro dagli ambienti locali, distribuire nuove macchine virtuali (VM) e usare i servizi di Azure dai cloud privati. È possibile usare una combinazione di funzionalità VMware e native di Azure per abilitare la disponibilità elevata e la resilienza dei carichi di lavoro.
Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.
Questo articolo descrive come rendere resiliente la soluzione Azure VMware a potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità e interruzioni dell'area. Descrive anche come usare i backup per eseguire il ripristino da altri tipi di problemi ed evidenzia alcune informazioni chiave sul contratto di servizio della soluzione Azure VMware.
Raccomandazioni per la distribuzione di produzione
Le distribuzioni di soluzioni Azure VMware richiedono un'attenta pianificazione in un'ampia gamma di aree e spesso richiedono più servizi di Azure. Per indicazioni dettagliate, vedere Carichi di lavoro della soluzione Azure VMware in Well-Architected Framework.
Panoramica dell'architettura di affidabilità
La soluzione Azure VMware usa un'infrastruttura iperconvergente con cluster VMware vSphere.
Quando si distribuisce la soluzione Azure VMware, si distribuisce un cloud privato con uno o più cluster. Ogni cluster contiene host ESXi che forniscono risorse di calcolo, archiviazione tramite vSAN e rete tramite VMware NSX. Esistono due generazioni di soluzioni Azure VMware:
- Gen 1 usa hardware bare metal specializzato per i nodi e usa approcci di rete dedicati. Per altre informazioni sui concetti chiave, vedere Concetti relativi al cloud privato e ai cluster della soluzione Azure VMware.
- Gen 2 usa i tipi di macchine virtuali standard di Azure e le reti virtuali di Azure. Questa architettura semplifica l'architettura di rete, migliora la velocità di trasferimento dei dati, riduce la latenza per i carichi di lavoro e migliora le prestazioni quando si accede ad altri servizi di Azure.
Tolleranza di errore
La soluzione Azure VMware offre diversi meccanismi per gestire gli errori a livello di infrastruttura e applicazione:
vSphere High Availability (HA): vSphere HA monitora gli host e le macchine virtuali ESXi. In caso di errore di un host, le macchine virtuali interessate vengono riavviate automaticamente in host integri. La funzione vSphere HA è abilitata per impostazione predefinita e riserva capacità di calcolo e di memoria per un guasto di un singolo nodo.
Tolleranza di errore vSAN: i criteri di archiviazione vSAN proteggono da errori temporanei a livello di archiviazione mantenendo più copie dei dati tra host. Se un percorso di archiviazione o un disco riscontra problemi temporanei, vSAN gestisce automaticamente il failover in percorsi di archiviazione integri.
Ridondanza della rete: La soluzione Azure VMware offre percorsi di rete ridondanti e più schede di rete VMkernel per gestire gli errori temporanei a livello di rete.
Resilienza a errori temporanei
Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.
Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.
Per le applicazioni in esecuzione in macchine virtuali della soluzione Azure VMware, implementare procedure standard di gestione degli errori temporanei:
- Configurare le politiche di ripetizione appropriate con backoff esponenziale
- Usare i modelli di interruttore per le chiamate di servizio esterne
- Monitorare l'integrità dell'applicazione e implementare una degradazione graduale
- Progettare applicazioni senza stato, se possibile, per ridurre l'impatto dei riavvii delle macchine virtuali
Resilienza ai guasti delle zone di disponibilità
Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.
La soluzione Azure VMware Gen 1 supporta le zone di disponibilità tramite cluster estesi, che distribuiscono gli host ESXi tra due zone di disponibilità all'interno di un'area. 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 il nodo testimone automaticamente.
Un cluster standard è uno 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à.
La soluzione Azure VMware Gen 2 supporta distribuzioni di 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 potrebbero trovarsi nella zona interessata e potrebbero verificarsi tempi di inattività.
Per visualizzare informazioni sul supporto della zona di disponibilità per altre generazioni, selezionare la generazione appropriata all'inizio di questa pagina.
Requisiti
Supporto per l'area: I cluster estesi sono disponibili in aree di Azure selezionate che supportano la configurazione del cluster estesa. Controllare la tabella di mapping della zona di disponibilità della regione Azure per i tipi di host per supportare la regione corrente.
Host minimi: Distribuire almeno sei host in due zone di disponibilità (tre host per zona) per abilitare la configurazione del cluster estesa. Quando si effettua uno scaling verso l'interno o verso l'esterno, è necessario procedere a coppie in modo che il numero di host sia uguale in ogni zona.
SKU host: I cluster estesi sono supportati con i tipi di host AV36, AV36P e AV52. Lo SKU AV64 non è supportato con cluster estesi.
Supporto per l'area: È possibile distribuire cloud privati di zona in aree che supportano sia Azure VMware Solution Gen 2 che supportano le 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 ciascuna zona region availability di Azure, consultare la tabella di mappatura per i tipi di host.
Costo
Si comportano costi per ogni nodo del cluster, indipendentemente dalla configurazione della zona di disponibilità del cluster. Per informazioni dettagliate sui prezzi, vedere Prezzi della soluzione Azure VMware.
Configurare il supporto delle zone di disponibilità
Distribuire un nuovo cluster: Quando si crea un nuovo cloud privato della 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, né 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 della 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.
Comportamento quando tutte le zone sono integre
Questa sezione descrive cosa aspettarsi quando il cluster è esteso e tutte le zone di disponibilità sono funzionanti.
Operazione tra aree: Le macchine virtuali possono essere eseguite in host in entrambe le zone di disponibilità. Il posizionamento delle macchine virtuali può essere controllato usando l'affinità drS vSphere e le regole anti-affinità per ottimizzare i requisiti di prestazioni o disponibilità.
Replica dei dati tra aree: vSAN replica i dati in modo sincrono tra zone di disponibilità. Ogni operazione di scrittura viene confermata da entrambe le zone prima del completamento, garantendo un'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 aree: Le macchine virtuali vengono eseguite negli host all'interno della zona di disponibilità del cluster.
Replica dei dati tra aree: Nessun dato viene replicato in un'altra zona.
Comportamento durante un errore di 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: La soluzione Azure VMware gestisce la risposta a livello di infrastruttura agli errori della zona. vSphere HA rileva automaticamente gli errori della zona e avvia le procedure di riavvio della macchina virtuale, se necessario.
- Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità risorse di Azure per monitorare l'integrità di una singola risorsa ed è possibile configurare gli avvisi di Integrità risorse per notificare i 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à dei servizi per notificare i problemi.
Richieste attive: Tutte le macchine virtuali in esecuzione nella zona di disponibilità non riuscita vengono riavviate negli host nella zona di disponibilità sopravvissuta. Le richieste attive e le connessioni alle macchine virtuali interessate vengono terminate 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, che impedisce di prendere decisioni di posizionamento e ripristino in modo sicuro e fa sì che determinate operazioni vengano bloccate, ad esempio l'accensione 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à sopravvissuta. 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 creato in un'altra zona di disponibilità.
- Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità risorse di Azure per monitorare l'integrità di una singola risorsa ed è possibile configurare gli avvisi di Integrità risorse per notificare i 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à dei servizi per notificare i problemi.
Richieste attive: Le richieste attive e le connessioni alle macchine virtuali interessate vengono terminate 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 in buona salute.
Ripristino della zona
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.
Verifica dei guasti di zona
È possibile simulare gli errori di zona in base a:
Uso di vSphere per inserire gli host in modalità di manutenzione per simulare errori a livello di zona.
La verifica che i sistemi di backup e monitoraggio funzionino continuativamente durante i malfunzionamenti simulati.
- Test della resilienza dell'applicazione per i riavvii delle macchine virtuali e modifiche del percorso di rete, soprattutto quando si dispone di cluster estesi o si distribuiscono applicazioni in cluster separati in zone diverse.
Poiché la 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.
Resilienza agli errori a livello di area
Ogni cluster della soluzione Azure VMware viene distribuito all'interno di una singola area di Azure. Se l'area non è più disponibile, il cloud privato e tutte le risorse all'interno diventano non disponibili.
Tuttavia, è anche possibile progettare soluzioni personalizzate in più aree che combinano approcci diversi o si integrano con l'infrastruttura esistente per soddisfare requisiti aziendali specifici e obiettivi di ripristino.
Soluzioni personalizzate in più aree per la resilienza
Per ottenere la resilienza in più aree con la soluzione Azure VMware, è necessario distribuire cloud privati separati in più aree e implementare il failover e altre soluzioni di ripristino di emergenza.
Sono disponibili diverse opzioni che supportano requisiti diversi. Per altre informazioni, vedere Soluzioni di backup e ripristino di emergenza di terze parti per Azure VMware: limitazioni, compatibilità e problemi noti.
Backup e ripristino
La soluzione Azure VMware esegue automaticamente il backup dei componenti di gestione (vCenter Server, NSX Manager e HCX Manager, se abilitato). Per eseguire il ripristino da questi backup di gestione, creare una richiesta di supporto di Azure.
Per i carichi di lavoro delle macchine virtuali, la soluzione Azure VMware supporta più approcci di backup. Per informazioni dettagliate, vedere Soluzioni di backup per le macchine virtuali della soluzione Azure VMware.
Resilienza alla manutenzione del servizio
Azure esegue la manutenzione automatica della piattaforma per applicare gli aggiornamenti della sicurezza, distribuire nuove funzionalità e migliorare l'affidabilità del servizio.
Per informazioni sull'effetto che la manutenzione può avere sui componenti della soluzione Azure VMware e per comprendere i componenti responsabili della gestione e di quelli che Microsoft gestisce, vedere Procedure consigliate per la manutenzione del cloud privato della soluzione Azure VMware.
È possibile configurare le finestre di manutenzione per il cluster per ridurre la probabilità di manutenzione che influisce sui carichi di lavoro di produzione. Per altre informazioni, vedere Pianificare la manutenzione self-service per la soluzione Azure VMware (anteprima pubblica).
Contratto di servizio
Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere Contratti di servizio per Servizi online.
La soluzione Azure VMware offre contratti di servizio di disponibilità diversi per l'infrastruttura del carico di lavoro e per le operazioni di gestione.
I cluster configurati come cluster estesi hanno un livello di disponibilità SLA dell'infrastruttura del carico di lavoro superiore.
Tuttavia, per qualificarsi per i contratti di servizio di disponibilità, è necessario configurare il cluster in modi specifici. Per informazioni dettagliate, vedere il testo del contratto di servizio.