Eseguire la migrazione al summit per l'innovazione:
Informazioni su come la migrazione e la modernizzazione in Azure possono migliorare le prestazioni, la resilienza e la sicurezza dell'azienda, consentendo di adottare completamente l'intelligenza artificiale.Iscriviti subito
Questo browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Questo articolo illustra come implementare un cluster esteso vSAN per un cloud privato soluzione Azure VMware.
Prerequisiti
Seguire il processo Richiedi quota host per ottenere la quota riservata per il numero di nodi richiesto. Fornire i dettagli seguenti per facilitare il processo:
Nome azienda
Punto di contatto: posta elettronica
ID sottoscrizione: è necessaria una nuova sottoscrizione separata
Tipo di cloud privato: "Cluster esteso"
Area richiesta: Stati Uniti orientali, Regno Unito meridionale, Europa occidentale, Germania centro-occidentale o Australia orientale
Numero di nodi nel primo cluster esteso: minimo 6, massimo 16 - in multipli di due
Piano di espansione stimato
Distribuire un cloud privato del cluster esteso
Quando vengono ricevuti i dettagli di supporto della richiesta, la quota è riservata a un ambiente cluster esteso nell'area richiesta. La sottoscrizione viene abilitata per distribuire un cluster esteso SDDC tramite il portale di Azure. Un messaggio di posta elettronica di conferma viene inviato al punto di contatto designato entro due giorni lavorativi in cui si dovrebbe essere in grado di distribuire automaticamente un cloud privato del cluster esteso tramite il portale di Azure. Assicurarsi di selezionare Host in due zone di disponibilità per assicurarsi che un cluster esteso venga distribuito nell'area desiderata.
Dopo aver creato il cloud privato, è possibile eseguire il peering di entrambe le zone di disponibilità (AZ) al circuito ExpressRoute locale con Copertura globale che consente di connettere il data center locale al cloud privato. Il peering di entrambe le reti AZ garantisce che un errore az non comporti una perdita di connettività al cloud privato. Poiché una chiave di autenticazione ExpressRoute è valida per una sola connessione, ripetere la procedura Creare una chiave di autenticazione ExpressRoute nel processo del circuito ExpressRoute locale per generare un'altra autorizzazione.
Ripetere quindi il processo per eseguire il peering di ExpressRoute Global Reach di due zone di disponibilità nel circuito ExpressRoute locale.
Criteri di archiviazione supportati
I criteri SPBM seguenti sono supportati con errori primari da tollerare (PFTT) di "mirroring del sito doppio" e errori secondari da tollerare (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