Share via

Progettare cluster estesi vSAN

  • Articolo

Questo articolo illustra come progettare un cluster esteso vSAN per un cloud privato soluzione Azure VMware.

Background

L'infrastruttura globale di Azure è suddivisa in aree. Ogni area supporta i servizi per una determinata area geografica. All'interno di ogni area, Azure crea isole isolate e ridondanti dell'infrastruttura denominate zone di disponibilità (AZ). Un az funge da limite per la gestione delle risorse. Le risorse di calcolo e di altro tipo disponibili per un az sono limitate e possono essere esaurite dalle richieste dei clienti. Un az è progettato per essere resiliente in modo indipendente, ovvero gli errori in un az non influiscono su altre reti AZ.

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, non protegge i carichi di lavoro da un errore az di Azure. Per proteggersi da un errore az, è possibile abilitare un singolo cluster vSAN per estendersi su due zone di disponibilità separate, denominate cluster esteso vSAN.

I cluster estesi consentono la configurazione dei domini di errore vSAN tra due reti AZ per notificare al server vCenter che gli host risiedono in ogni zona di disponibilità (AZ). Ogni dominio di errore è denominato dopo l'AZ in cui si trova per aumentare la chiarezza. Quando si estende un cluster vSAN tra due reti AZ all'interno di un'area, in caso di arresto di un az, viene considerato come un evento a disponibilità elevata di vSphere e la macchina virtuale viene riavviata nell'altro az.

Vantaggi del cluster esteso:

  • Migliorare la disponibilità delle applicazioni.
  • Fornire una funzionalità RPO (Recovery Point Objective) zero per le applicazioni aziendali senza dover riprogettare o distribuire soluzioni di ripristino di emergenza costose.
  • Un cloud privato con cluster estesi è progettato per offrire una disponibilità del 99,99% a causa della resilienza agli errori az.
  • Consentire ai clienti di concentrarsi sui requisiti e sulle funzionalità principali dell'applicazione, anziché sulla disponibilità dell'infrastruttura.

Per proteggersi da scenari split brain e per misurare l'integrità del sito, viene creato un server di controllo vSAN gestito in un terzo az. Con una copia dei dati in ogni az, vSphere HA tenta di eseguire il ripristino da qualsiasi errore usando un semplice riavvio della macchina virtuale.

Il diagramma seguente illustra un cluster vSAN esteso tra due reti AZ.

Il diagramma mostra un cluster esteso vSAN gestito creato in una terza zona di disponibilità con i dati copiati in tutti e tre.

In sintesi, i cluster estesi semplificano le esigenze di protezione fornendo gli stessi controlli e funzionalità attendibili oltre alla scalabilità e alla flessibilità dell'infrastruttura di Azure.

È importante comprendere che i cloud privati del cluster esteso offrono solo un livello aggiuntivo di resilienza e non rispondono a tutti gli scenari di errore. Ad esempio, i cloud privati del cluster esteso:

  • Non proteggersi da errori a livello di area all'interno di Azure o da scenari di perdita di dati causati da problemi dell'applicazione o da criteri di archiviazione non pianificati correttamente.
  • Fornisce protezione da un singolo errore di zona, ma non è progettato per garantire la protezione da errori doppi o progressivi. Ad esempio:

    • Nonostante vari livelli di ridondanza integrati nell'infrastruttura, se un errore inter-AZ causa il partizionamento del sito secondario, vSphere HA avvia l'accensione delle macchine virtuali del carico di lavoro nel sito secondario.

      Il diagramma seguente illustra lo scenario di partizionamento del sito secondario.

      Il diagramma mostra la disponibilità elevata di vSphere che spegne le macchine virtuali del carico di lavoro nel sito secondario.

    • Se invece il partizionamento del sito secondario è in corso nell'errore del sito primario o ha generato un partizionamento completo, vSphere HA tenterà di riavviare le macchine virtuali del carico di lavoro nel sito secondario. Se vSphere HA ha tentato di riavviare le macchine virtuali del carico di lavoro nel sito secondario, le macchine virtuali del carico di lavoro vengono inserite in uno stato invece non predefinito.

      I diagrammi seguenti illustrano l'errore del sito preferito e gli scenari di partizionamento di rete completi.

      Diagramma che mostra la disponibilità elevata di vSphere che tenta di riavviare le macchine virtuali del carico di lavoro nel sito secondario quando si verifica un errore del sito preferito.

      Il diagramma mostra la disponibilità elevata di vSphere che tenta di riavviare le macchine virtuali del carico di lavoro nel sito secondario quando si verifica l'isolamento di rete completo.

Si noti che questi tipi di errori, anche se rari, non rientrano nell'ambito della protezione offerta da un cloud privato del cluster esteso. A causa di questi tipi di errori rari, una soluzione cluster estesa deve essere considerata come una soluzione a disponibilità elevata multi-AZ basata sulla disponibilità elevata di vSphere. È importante comprendere che una soluzione cluster estesa non è destinata a sostituire una strategia completa di ripristino di emergenza in più aree che può essere usata per garantire la disponibilità delle applicazioni. Il motivo è che una soluzione di ripristino di emergenza ha in genere piani di gestione e di controllo separati in aree di Azure separate. soluzione Azure VMware cluster estesi hanno un singolo piano di gestione e controllo esteso esteso tra due zone di disponibilità all'interno della stessa area di Azure. Ad esempio, un server vCenter, un cluster NSX Manager, una coppia di macchine virtuali NSX Edge.

Disponibilità dell'area cluster estesi

soluzione Azure VMware cluster estesi sono disponibili nelle aree seguenti:

  • Regno Unito meridionale (su AV36 e AV36P)
  • Europa occidentale (su AV36 e AV36P)
  • Germania occidentale (su AV36 e AV36P)
  • Australia orientale (su AV36P)
  • Stati Uniti orientali (su AV36P)

Archiviazione criteri supportati

I criteri SPBM seguenti sono supportati con un PFTT "Dual Site Mirroring" e SFTT di "RAID 1 (mirroring)" abilitato come criteri predefiniti per il cluster:

  • Impostazioni di tolleranza di emergenza del sito (PFTT):
    • Mirroring del sito doppio
    • Nessuno: mantenere i dati su preferiti
    • Nessuno: mantenere i dati su dati non posticipati
  • Errori locali da tollerare (SFTT):
    • 1 errore - RAID 1 (mirroring)
    • 1 errore: RAID 5 (codifica di cancellazione), richiede almeno quattro host in ogni az
    • 2 errori - RAID 1 (mirroring)
    • 2 errori: RAID 6 (codifica di cancellazione), richiede almeno sei host in ogni az
    • 3 errori - RAID 1 (mirroring)

Domande frequenti

Sono pianificate altre aree?

Attualmente sono supportate quattro aree per i cluster estesi.

Quale tipo di contratto di servizio offre soluzione Azure VMware con i cluster estesi?

Un cloud privato creato con un cluster esteso vSAN è progettato per offrire un impegno di disponibilità dell'infrastruttura del 99,99% quando esistono le condizioni seguenti:

  • Nel cluster vengono distribuiti almeno sei nodi (3 in ogni zona di disponibilità).
  • Quando i criteri di archiviazione delle macchine virtuali di PFTT "Mirroring dual-site" e sfTT pari a 1 vengono usati dalle macchine virtuali del carico di lavoro.
  • Per raggiungere gli obiettivi di disponibilità, è necessaria la conformità ai requisiti aggiuntivi acquisiti nei dettagli del contratto di servizio di soluzione Azure VMware.

È possibile scegliere la zona di disponibilità in cui viene distribuito un cloud privato?

No. Viene creato un cluster esteso tra due zone di disponibilità, mentre la terza zona viene usata per distribuire il nodo di controllo. Poiché tutte le zone vengono usate in modo efficace per la distribuzione di un ambiente cluster esteso, una scelta non viene fornita al cliente. Al momento della creazione del cloud privato, il cliente sceglie invece di distribuire gli host in più reti AZ.

Quali sono le limitazioni di cui tenere conto?

  • Dopo aver creato un cloud privato con un cluster esteso, non può essere modificato in un cloud privato del cluster standard. Analogamente, non è possibile modificare un cloud privato del cluster standard in un cloud privato del cluster esteso dopo la creazione.
  • L'aumento del numero di istanze e il ridimensionamento dei cluster estesi possono verificarsi solo in coppie. Un minimo di sei nodi e un massimo di 16 nodi sono supportati in un ambiente cluster esteso. Per altre informazioni, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.
  • Le macchine virtuali del carico di lavoro del cliente vengono riavviate con una priorità a disponibilità elevata media di vSphere. Le macchine virtuali di gestione hanno la priorità di riavvio più alta.
  • La soluzione si basa su vSphere HA e vSAN per i riavvii e la replica. L'obiettivo del tempo di ripristino (RTO) è determinato dalla quantità di tempo necessario per vSphere HA per riavviare una macchina virtuale nell'az sopravvissuto dopo l'errore di un singolo az.
  • Attualmente non è supportato in un ambiente cluster esteso:
    • Funzionalità rilasciate di recente, ad esempio l'indirizzo IP pubblico, fino a NSX Edge e all'archiviazione esterna, come gli archivi dati ANF.
    • Componenti aggiuntivi per il ripristino di emergenza, ad esempio VMware SRM, Zerto e JetStream.
  • Aprire un ticket di supporto dal portale di Azure per gli scenari seguenti (assicurarsi di selezionare Cluster estesi come tipo di problema):
    • Connessione un cloud privato a un cloud privato del cluster esteso.
    • Connessione due cloud privati di cluster estesi in una singola area.

Quali latenze è consigliabile prevedere tra le zone di disponibilità (AZs)?

I cluster estesi vSAN funzionano entro un tempo di round trip di 5 millisecondi (RTT) e 10 Gb/s o una larghezza di banda maggiore tra le reti AZ che ospitano le macchine virtuali del carico di lavoro. La distribuzione di cluster estesi soluzione Azure VMware segue questo principio guida. Si consideri che le informazioni durante la distribuzione di applicazioni (con SFTT di mirroring del sito doppio, che usa scritture sincrone) che presentano requisiti di latenza rigorosi.

È possibile combinare cluster estesi e standard nel cloud privato?

No. Una combinazione di cluster estesi e standard non è supportata all'interno dello stesso cloud privato. Quando si crea il cloud privato, viene selezionato un ambiente cluster esteso o standard. Una volta creato un cloud privato con un cluster esteso, si presuppone che tutti i cluster creati all'interno del cloud privato siano estesi in natura.

Quanto costa la soluzione?

I clienti vengono addebitati in base al numero di nodi distribuiti nel cloud privato.

Vengono addebitati i costi per il nodo di controllo e per il traffico inter-AZ?

No. I clienti non visualizzano un addebito per il nodo di controllo e il traffico inter-AZ. Il nodo di controllo è completamente gestito dal servizio e soluzione Azure VMware fornisce la gestione del ciclo di vita necessaria del nodo di controllo. Poiché l'intera soluzione è gestita dal servizio, il cliente deve identificare solo i criteri SPBM appropriati da impostare per le macchine virtuali del carico di lavoro. Il resto viene gestito tramite Microsoft.