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.
soluzione Azure VMware fornisce cloud privati che contengono cluster VMware vSphere creati da un'infrastruttura bare metal dedicata Azure. soluzione Azure VMware è disponibile in Azure Commercial e Azure per enti pubblici. La distribuzione iniziale minima è costituita da tre host, con l'opzione per aggiungere altri host, fino a un massimo di 16 host per cluster. Tutti i cloud privati provisionati hanno VMware vCenter Server, VMware vSAN, VMware vSphere e VMware NSX. Di conseguenza, è possibile eseguire la migrazione dei carichi di lavoro dagli ambienti locali, distribuire nuove macchine virtuali e usare Azure servizi dai cloud privati. Per informazioni sugli accordi di livello di servizio, vedere la pagina Azure service-level agreements.
soluzione Azure VMware è una soluzione convalidata da VMware con convalida e test continui di miglioramenti e aggiornamenti. Microsoft gestisce e gestisce l'infrastruttura e il software del cloud privato, consentendo di concentrarsi sullo sviluppo e l'esecuzione di carichi di lavoro nei cloud privati per offrire valore aziendale.
Il diagramma mostra l'adiacenza tra cloud privati e reti virtuali in Azure, servizi Azure e ambienti locali. L'accesso alla rete dai cloud privati ai servizi Azure o alle reti virtuali offre un'integrazione degli endpoint di servizio di Azure guidata dall'SLA. Copertura globale di ExpressRoute connette l'ambiente locale al cloud privato soluzione Azure VMware.
soluzione Azure VMware tipi di cloud privato
soluzione Azure VMware offre due diverse generazioni di cloud privato:
soluzione Azure VMware Generation 1 offre cluster VMware vSphere costruiti da host bare metal dedicati distribuiti nelle strutture di data center Azure. I circuiti Microsoft gestiti ExpressRoute forniscono connettività tra gli host VMware vSphere e le risorse native Azure distribuite nelle reti virtuali.
soluzione Azure VMware Generation 2 fornisce cluster VMware vSphere creati su host Azure bare metal dedicati. soluzione Azure VMware generazione 2 offre un'architettura di rete aggiornata in cui gli host VMware vSphere sono collegati direttamente alle reti virtuali Azure. Questa offerta è supportata solo nello SKU AV64.
Host, cluster e cloud privati
soluzione Azure VMware cluster si basano su un'infrastruttura iperconvergente. La tabella seguente illustra le specifiche di CPU, memoria, disco e rete dell'host.
| Tipo di host | CPU (Core/GHz) | RAM (GB) | Architettura vSAN | Livello di cache vSAN (TB, raw**) | Livello di capacità vSAN (TB, raw**) | Disponibilità regionale |
|---|---|---|---|---|---|---|
| AV36 | CPU Dual Intel Xeon Gold 6140 (microarchitettura Skylake) con 18 core/CPU a 2,3 GHz, 36 core fisici totali (72 core logici con hyperthreading) | 576 | OSA | 3.2 (NVMe) | 15.20 (SSD) | Aree selezionate (*) |
| AV36P | Doppio CPU Intel Xeon Gold 6240 (microarchitettura Cascade Lake) con 18 core per CPU a 2,6 GHz / 3,9 GHz in modalità Turbo, per un totale di 36 core fisici (72 core logici con hyperthreading) | 768 | OSA | 1,5 (cache Intel) | 19.20 (NVMe) | Aree selezionate (*) |
| AV48 | CPU Dual Intel Xeon Gold 6442Y (microarchitettura Sapphire Rapids) dotati di 24 core/CPU a 2,6 GHz / 4,0 GHz Turbo, per un totale di 48 core fisici (96 core logici con hyperthreading) | 1,024 | ESA | N/A | 25.6 (NVMe) | Aree selezionate (*) |
| AV52 | CPU Dual Intel Xeon Platinum 8270 (microarchitettura Cascade Lake) con 26 core/CPU a 2,7 GHz / 4,0 GHz Turbo, 52 core fisici totali (104 core logici con hyperthreading) | 1,536 | OSA | 1,5 (cache Intel) | 38.40 (NVMe) | Aree selezionate (*) |
| AV64 | Due CPU Intel Xeon Platinum 8370C (microarchitettura Ice Lake) con 32 unità centrali di elaborazione per CPU a 2,8 GHz / 3,5 GHz Turbo, per un totale di 64 core fisici (128 core logici con hyperthreading) | 1,024 | OSA/ESA | 3.84 (NVMe) / N/A* | 15.36 (NVMe) / 19.25 (NVMe)* | Aree selezionate (**) |
Un cluster soluzione Azure VMware richiede un numero minimo di tre host. È possibile usare host dello stesso tipo solo in un singolo cloud privato soluzione Azure VMware. Gli host usati per compilare o ridimensionare i cluster provengono da un pool isolato di host. Questi host hanno superato i test hardware e tutti i dati sono stati eliminati in modo sicuro prima di essere aggiunti a un cluster.
Tutti i tipi di host precedenti hanno una velocità effettiva dell'interfaccia di rete da 100 Gbps.
*I dettagli sono disponibili tramite il calcolatore prezzi Azure.
**Prerequisito AV64: è necessario un cloud privato soluzione Azure VMware distribuito con AV36, AV36P, AV48 o AV52 prima di aggiungere AV64.
Raw è basato sul Sistema Internazionale di Unità (SI) riportato dai produttori di dischi. Esempio: 1 TB raw = 100000000000000 byte. Lo spazio calcolato da un computer in formato binario (1 TB binario = 1099511627776 byte binari) è uguale a 931,3 gigabyte convertiti dal decimale non elaborato.
L'ESA si applica alle distribuzioni AV64 Gen 2.
È possibile distribuire cloud privati nuovi o ridimensionati tramite il portale di Azure o interfaccia della riga di comando di Azure.
Estensione del cloud privato di soluzione Azure VMware con nodo di dimensioni AV64
AV64 è uno SKU host soluzione Azure VMware, disponibile per espandere il cloud privato soluzione Azure VMware creato con lo SKU AV36, AV36P o AV52 esistente. Per distribuire DIRETTAMENTE AV64, fare riferimento a soluzione Azure VMware in un Rete virtuale di Azure. Usare la documentazione Microsoft per verificare la disponibilità dello SKU AV64 nell'area.
Prerequisito per l'espansione AV64 in AV36, AV36P e AV52
Vedere i prerequisiti seguenti per la distribuzione del cluster AV64.
Viene creato un cloud privato della soluzione VMware Azure usando AV36, AV36P, AV48 o AV52 in AV64 supportato region/AZ.
Sono necessari uno o tre blocchi di indirizzi /23 (contigui o non contigui) /25 per la gestione del cluster AV64.
Supporto per gli scenari dei clienti
Customer con il cloud privato soluzione Azure VMware esistente: quando un cliente ha distribuito un cloud privato soluzione Azure VMware, può ridimensionare il cloud privato aggiungendo un cluster di nodi vCenter AV64 separato a tale cloud privato. In questo scenario, i clienti devono seguire questa procedura:
- Ottenere un'approvazione della quota AV64 da Microsoft con almeno tre nodi. Aggiungere altri dettagli sul cloud privato soluzione Azure VMware che si prevede di estendere usando AV64.
- Usare un flusso di lavoro del cluster aggiuntivo soluzione Azure VMware esistente con host AV64 per espanderlo.
Customer prevede di creare un nuovo cloud privato soluzione Azure VMware: quando un cliente vuole un nuovo cloud privato soluzione Azure VMware che può usare SKU AV64, ma solo per l'espansione. In questo caso, il cliente soddisfa i prerequisiti di avere un cloud privato soluzione Azure VMware creato con AV36, AV36P o SKU AV52. Il cliente deve acquistare almeno tre nodi di AV36, AV36P o AV52 SKU prima di espandersi usando AV64. Per questo scenario, seguire questa procedura:
- Ottieni l'approvazione della quota per AV36, AV36P, AV52 e AV64 da Microsoft, con un minimo di tre nodi ciascuno.
- Creare un cloud privato soluzione Azure VMware usando AV36, AV36P o AV52 SKU.
- Usare un flusso di lavoro esistente di soluzione Azure VMware per aggiungere un cluster con host AV64 per espandere.
Cluster estesi del cloud privato soluzione Azure VMware: lo SKU AV64 non è supportato dai cluster estesi del cloud privato soluzione Azure VMware. Ciò significa che un'espansione basata su AV64 non è possibile per un cloud privato di cluster estesi soluzione Azure VMware.
Note
Tutto il traffico proveniente da un host AV64 verso una rete del cliente utilizzerà l'indirizzo IP dell'interfaccia di rete VMKernel 1.
Compatibilità VMotion avanzata (EVC) con estensione AV64
L'aggiunta di nodi AV64 a un cloud privato soluzione Azure VMware crea un ambiente eterogeneo, che comporta problemi Enhanced vMotion Compatibility (EVC) tra cluster AV64 e cluster SKU di base con SKU AV36, AV36P o AV52. I cluster AV64 usano la modalità Icelake EVC a causa delle CPU Intel Icelake, mentre i cluster AV36, AV36P e AV52, basati su CPU Intel meno recenti, non hanno la modalità EVC esplicita abilitata. I dettagli sulle generazioni di CPU per ogni SKU sono disponibili in precedenza.
L'eterogeneità delle modalità EVC tra cluster presenta sfide per le operazioni live vMotion, come definito da Broadcom, in base allo scenario specifico e alla direzione della migrazione. La sezione seguente fornisce un riepilogo dell'esperienza utente durante l'esecuzione di vMotion live tra AV64 e i cluster di base.
VMotion al cluster AV64 dal cluster SKU di base: questa operazione funziona correttamente perché la macchina virtuale è spostata tramite vMotion dal cluster in modalità EVC inferiore al cluster in modalità EVC superiore.
vMotion verso il cluster SKU di base dal cluster AV64 – due scenari
Se la macchina virtuale è stata precedentemente spostata dal cluster di base e non è stata riavviata, allora il vMotion live riesce.
Se la macchina virtuale è stata creata nel cluster AV64 o in un ciclo di alimentazione, anche se in precedenza è stata eseguita la vMotion dal cluster SKU di base, live vMotion avrà esito negativo con un errore di compatibilità EVC.
I clienti possono evitare problemi live vMotion tra cluster SKU di base e AV64 impostando la modalità EVC a livello di macchina virtuale in modo che corrisponda a un cluster di base inferiore OVC o spegnendo la macchina virtuale e eseguendo una vMotion a freddo.
Progettazione e raccomandazioni per il dominio di guasto vSAN del cluster AV64
I cluster host soluzione Azure VMware tradizionali non dispongono di una configurazione vSAN FD esplicita. Il motivo è la logica di allocazione host garantisce, all'interno dei cluster, che nessun host si trovi nello stesso dominio di errore fisico all'interno di un'area Azure. Questa funzionalità offre intrinsecamente resilienza e disponibilità elevata per l'archiviazione, che dovrebbe essere implementata dalla configurazione FD vSAN. Altre informazioni su vSAN FD sono disponibili nella documentazione di VMware.
I cluster host soluzione Azure VMware AV64 hanno una configurazione esplicita del dominio di errore vSAN (FD). soluzione Azure VMware piano di controllo configura sette domini di errore vSAN per i cluster AV64. Gli host vengono bilanciati in modo uniforme tra i sette domini di dominio man mano che gli utenti aumentano le prestazioni degli host in un cluster da tre nodi a 16 nodi. Alcune aree Azure supportano ancora un massimo di cinque domini di dominio come parte della versione iniziale dello SKU AV64. Per ulteriori informazioni, vedere la tabella di correlazione della zona di disponibilità della regione Azure ai tipi di host.
Raccomandazione per le dimensioni del cluster
La dimensione minima di cluster supportata di soluzione Azure VMware per i nodi vSphere è tre. La ridondanza dei dati vSAN viene gestita assicurando che le dimensioni minime del cluster di tre host si trovino in domini di dominio vSAN diversi. In un cluster vSAN con tre host, ciascuno in un diverso FD, nel caso in cui un FD fallisca (ad esempio, se il switch superiore del rack ha un guasto), i dati vSAN sarebbero protetti. Le operazioni come la creazione di oggetti (nuova macchina virtuale, VMDK e altri) hanno esito negativo. Lo stesso vale per tutte le attività di manutenzione in cui un host ESXi viene inserito in modalità di manutenzione e/o riavviato. Per evitare scenari come questi, è consigliabile distribuire cluster vSAN con almeno quattro host ESXi.
Flusso di lavoro di rimozione host AV64 e procedure consigliate
A causa della configurazione del dominio di errore VSAN del cluster AV64 e della necessità di host bilanciati in tutti i domini di dominio, la rimozione dell'host dal cluster AV64 differisce dai cluster host soluzione Azure VMware tradizionali con altri SKU.
Attualmente, un utente può selezionare uno o più host da rimuovere dal cluster usando il portale o l'API. Una condizione è che un cluster deve avere almeno tre host. Tuttavia, un cluster AV64 si comporta in modo diverso in determinati scenari quando AV64 usa FDS vSAN. Qualsiasi richiesta di rimozione dell'host viene verificata in caso di potenziale squilibrio di VSAN FD. Se una richiesta di rimozione host crea uno squilibrio, la richiesta viene rifiutata con la risposta http 409-Conflict. Il codice di stato della risposta http 409-Conflict indica un conflitto di richieste con lo stato corrente della risorsa di destinazione (host).
I tre scenari seguenti illustrano esempi di istanze che in genere eseguono errori e illustrano metodi diversi che possono essere usati per rimuovere gli host senza creare uno squilibrio del dominio di errore vSAN (FD).
La rimozione di un host crea uno sbilanciamento nel vSAN FD con una differenza nel numero di host tra il FD più popolato e quello meno popolato superiore a uno. Nell'esempio seguente gli utenti devono rimuovere uno degli host da FD 1 prima di rimuovere gli host da altri domini di dominio.
Più richieste di rimozione host vengono effettuate contemporaneamente e alcune rimozioni host creano uno squilibrio. In questo scenario, il piano di controllo soluzione Azure VMware rimuove solo gli host, che non creano squilibri. Nell'esempio seguente gli utenti non possono accettare entrambi gli host dagli stessi domini di dominio, a meno che non riducono le dimensioni del cluster a quattro o inferiori.
La rimozione di un host selezionato causa meno di tre domini di dominio vSAN attivi. Questo scenario non dovrebbe verificarsi dato che tutte le aree AV64 hanno cinque o sette domini di errore. Durante l'aggiunta di host, il piano di controllo soluzione Azure VMware si occupa dell'aggiunta uniforme di host da tutti e sette i domini di dominio. Nell'esempio seguente gli utenti possono rimuovere uno degli host da FD 1, ma non da FD 2 o 3.
Come identificare l'host che può essere rimosso senza causare uno squilibrio di VSAN FD: un utente può passare all'interfaccia client vSphere per ottenere lo stato corrente degli FD e degli host vSAN associati a ognuno di essi. Ciò consente di identificare gli host (in base agli esempi precedenti) che possono essere rimossi senza influire sul bilanciamento fd di vSAN ed evitare eventuali errori nell'operazione di rimozione.
Configurazione RAID supportata da AV64
Questa tabella fornisce l'elenco dei requisiti di configurazione RAID supportati e host nei cluster AV64. Le politiche RAID-6 FTT2 e RAID-1 FTT3 sono supportate con lo SKU AV64 in alcune regioni. In Azure aree attualmente vincolate a cinque domini di dominio, Microsoft consente ai clienti di usare i criteri di archiviazione VSAN RAID-5 FTT1 per i cluster AV64 con sei o più nodi per soddisfare il contratto di servizio . Per ulteriori informazioni, consultare la tabella di mappatura del tipo di host alla zona di disponibilità dell'area di Azure.
| Configurazione RAID | Tolleranza errori (FTT) | Numero minimo di host richiesti |
|---|---|---|
| RAID-1 (Mirroring) Impostazione predefinita. | 1 | 3 |
| RAID-5 (Codifica di cancellazione) | 1 | 4 |
| RAID-1 (specchiatura) | 2 | 5 |
| RAID-6 (Codifica di cancellazione) | 2 | 6 |
| RAID-1 (specchiatura) | 3 | 7 |
Storage
soluzione Azure VMware supporta l'espansione della capacità dell'archivio dati oltre a quanto incluso in vSAN usando i servizi di archiviazione Azure, consentendo di espandere la capacità dell'archivio dati senza ridimensionare i cluster. Per altre informazioni, vedere Opzioni di espansione della capacità dell'archivio dati.
Networking
soluzione Azure VMware offre un ambiente cloud privato accessibile da siti locali e risorse basate su Azure. Servizi come Azure ExpressRoute, connessioni VPN o rete WAN virtuale di Azure fornire la connettività. Tuttavia, per abilitare questi servizi sono necessari specifici intervalli di indirizzi di rete e porte del firewall.
Quando si distribuisce un cloud privato, vengono create reti private per la gestione, il provisioning e vMotion. Queste reti private vengono usate per accedere al server VMware vCenter e a VMware NSX Manager e alla macchina virtuale vMotion o alla distribuzione.
Per connettere i cloud privati agli ambienti locali viene usato il servizio Copertura globale di ExpressRoute. Collega i circuiti direttamente a livello di Microsoft Edge. La connessione richiede una rete virtuale (vNet) con un circuito ExpressRoute in locale nella sottoscrizione. Il motivo è che i gateway di rete virtuale (gateway ExpressRoute) non possono transitare il traffico, il che significa che è possibile collegare due circuiti allo stesso gateway, ma non invia il traffico da un circuito all'altro.
Ogni ambiente soluzione Azure VMware è una propria regione ExpressRoute (con il proprio dispositivo MSEE virtuale), consentendo di connettere Global Reach alla posizione di peering locale. Consente di connettere più istanze di soluzione Azure VMware in un'area alla stessa posizione di peering.
Note
Per le posizioni in cui ExpressRoute Global Reach non è abilitato, ad esempio a causa delle normative locali, è necessario creare una soluzione di routing utilizzando macchine virtuali IaaS di Azure. Per alcuni esempi, vedere Azure Cloud Adoption Framework - Topologia di rete e connettività per soluzione Azure VMware.
Le macchine virtuali distribuite nel cloud privato sono accessibili a Internet tramite la funzionalità rete WAN virtuale di Azure IP pubblico. Per impostazione predefinita, l'accesso a Internet è disabilitato per i nuovi cloud privati.
Per altre informazioni, vedere Architettura di rete.
Accesso e sicurezza
soluzione Azure VMware cloud privati usano il controllo degli accessi in base al ruolo vSphere per una maggiore sicurezza. È possibile integrare le funzionalità LDAP di vSphere SSO con Microsoft Entra ID. Per altre informazioni, vedere la pagina Architettura di accesso e identità.
Per impostazione predefinita, la crittografia dei dati inattivi della rete vSAN è abilitata e viene usata per fornire la sicurezza dell'archivio dati della rete vSAN. Per altre informazioni, vedere Architettura di archiviazione.
Residenza dei dati e dati dei clienti
soluzione Azure VMware non archivia i dati dei clienti.
Versioni del software VMware
La tabella seguente elenca le versioni software usate nelle nuove distribuzioni di soluzione Azure VMware cloud privati.
| Software | Version | Numero di build |
|---|---|---|
| VMware vCenter Server | 8.0 U3e | 24674346 |
| VMware ESXi | 8.0 U3f + Hot Patch (correzione bug VAIO) | 24797835 |
| VMware vSAN | 8.0 U3 | 24797835 |
| Server di controllo VMware vSAN | 8.0 U3 | 24797835 |
| Formato su disco VMware vSAN | 20 | N/A |
| Architettura di archiviazione VMware vSAN | Gen 1: OSA, Gen2: ESA | N/A |
| VMware NSX | 4.2.3.2 | 25077145 |
| VMware HCX | 4.11.3 | 24972695 |
| VMware Live Site Recovery | 9.0.2.1 | 24401761 |
| Replica di VMware vSphere | 9.0.2.1 | 24383568 |
Se il numero di build elencato non corrisponde al numero di build elencato nelle note sulla versione, è perché è stata applicata una patch personalizzata per i provider di servizi cloud.
La versione corrente del software in esecuzione viene applicata ai nuovi cluster aggiunti a un cloud privato esistente, se la versione del server vCenter la supporta.
Manutenzione del ciclo di vita di software e host
Gli aggiornamenti regolari del soluzione Azure VMware cloud privato e del software VMware assicurano che i set di sicurezza, stabilità e funzionalità più recenti siano in esecuzione nei cloud privati. Per altre informazioni, vedere Manutenzione host e gestione del ciclo di vita.
Monitoraggio del cloud privato
Dopo aver distribuito soluzione Azure VMware nella sottoscrizione, i log Monitoraggio di Azure vengono generati automaticamente.
Nel cloud privato è possibile:
- Raccogliere i log presenti in ogni macchina virtuale.
- Scaricare e installare l'agente MMA sulle macchine virtuali Linux e Windows.
- Abilitare l'estensione di diagnostica Azure.
- Creare ed eseguire nuove query.
- Eseguire le stesse query eseguite in genere nelle macchine virtuali.
I modelli di monitoraggio all'interno del soluzione Azure VMware sono simili alle macchine virtuali Azure all'interno della piattaforma IaaS. Per altre informazioni e procedure, vedere Monitoraggio di macchine virtuali Azure con Monitoraggio di Azure.
Comunicazione ai clienti
È possibile trovare problemi di servizio, manutenzione pianificata, avvisi di integrità e avvisi di sicurezza pubblicati tramite Servizio nel portale di Azure. È possibile eseguire azioni tempestive quando si configurano gli avvisi del log attività per queste notifiche. Per altre informazioni, vedere Creare avvisi di integrità dei servizi tramite il portale di Azure.
matrice di responsabilità soluzione Azure VMware - Microsoft vs cliente
soluzione Azure VMware implementa un modello di responsabilità condivisa che definisce ruoli e responsabilità distinti delle due parti coinvolte nell'offerta: cliente e Microsoft. Le responsabilità del ruolo condiviso sono illustrate in modo più dettagliato nelle due tabelle seguenti.
La tabella di matrice di responsabilità condivisa descrive le attività principali che i clienti e Microsoft ciascuno gestisce nell'ambito della distribuzione e della gestione sia per il cloud privato che per i carichi di lavoro delle applicazioni dei clienti.
La tabella seguente fornisce un elenco dettagliato di ruoli e responsabilità tra il cliente e Microsoft, che include le attività e le definizioni più frequenti. Per ulteriori domande, contattare Microsoft.
| Role | Task/details |
|---|---|
| Microsoft - soluzione Azure VMware | Infrastruttura fisica
(facoltativo) VMware HCX viene implementato con un profilo di calcolo completamente configurato nel cloud come modulo supplementare (facoltativo) VMware SRM distribuisce, aggiorna e aumenta/riduce le prestazioni Supporto - Piattaforme cloud private e VMware HCX |
| Customer | Richiedere l'offerta host soluzione Azure VMware con Microsoft Pianificare e creare una richiesta di cloud privati nel portale di Azure con:
Aggiungere o eliminare le richieste di host al cluster dal portale Distribuire/gestire il ciclo di vita delle soluzioni partner (di terze parti) |
| Ecosistema partner | Supporto per il prodotto/soluzione. Per riferimento, di seguito sono riportati alcuni dei soluzione Azure VMware soluzione/prodotto partner supportati:
|
Passaggi successivi
Il passaggio successivo consiste nell'apprendere i concetti chiave relativi all'architettura del cloud privato.