Considerazioni sulla progettazione per i cloud privati di soluzione Azure VMware generazione 2

Questo articolo illustra le considerazioni di progettazione principali per i cloud privati di soluzione Azure VMware generazione 2 (Gen 2). Illustra le funzionalità offerte da questa generazione agli ambienti cloud privati basati su VMware, consentendo l'accesso alle applicazioni sia dall'infrastruttura locale che dalle risorse basate su Azure. Prima di configurare il cloud privato di soluzione Azure VMware Gen 2, è necessario esaminare diverse considerazioni. Questo articolo fornisce soluzioni per i casi d'uso che possono verificarsi quando si usa il tipo di cloud privato.

Limitazioni

La funzionalità seguente è limitata durante questo periodo di tempo. Queste limitazioni verranno rimosse in futuro:

• Non è possibile eliminare il gruppo di risorse, che contiene il cloud privato. Prima di eliminare il gruppo di risorse, è necessario eliminare il cloud privato.
• È possibile distribuire solo 1 cloud privato per ogni rete virtuale Azure.
• È possibile creare solo 1 cloud privato per gruppo di risorse. Non sono supportati più cloud privati in un singolo gruppo di risorse.
• Il cloud privato e la rete virtuale per il cloud privato devono trovarsi nello stesso gruppo di risorse.
• Non è possibile spostare il cloud privato da un gruppo di risorse a un altro dopo la creazione del cloud privato.
• Non è possibile spostare il cloud privato da un tenant a un altro dopo la creazione del cloud privato.
• Se è necessario ExpressRoute FastPath o Global Rete virtuale Peering per il cloud privato AVS, creare un caso di supporto tramite il portale di Azure.
• Gli endpoint del servizio non supportano la connettività diretta dai carichi di lavoro di soluzione Azure VMware.
• Private Endpoints quando è stato eseguito il peering globale tra aree connesse a soluzione Azure VMware non è supportato.
• vCloud Director che utilizza Private Endpoints è supportato. Tuttavia, vCloud Director che utilizza endpoint pubblici non è supportato.
• I cluster estesi vSAN non sono supportati.
• IP pubblico fino a VMware NSX Microsoft Edge per la configurazione di Internet non è supportato. È possibile trovare le opzioni Internet supportate nelle opzioni di connettività Internet.
• Durante la manutenzione non pianificata , ad esempio un errore hardware dell'host, in uno dei primi quattro host del Data Center (SDDC), è possibile che si verifichi un'interruzione temporanea della connettività di rete North-South per alcuni carichi di lavoro, durando fino a 30 secondi. La connettività Nord-Sud indica il traffico tra workload VMware AVS e gli endpoint esterni oltre l'Edge di NSX-T Tier-0 (T0), come i servizi Azure o gli ambienti on-premises. Questa limitazione è stata rimossa in aree Azure specifiche. Verificare se l'area è interessata da questa limitazione controllando Azure supporto tecnico.  
• I gruppi di sicurezza di rete associati alla rete virtuale host del cloud privato devono essere creati nello stesso gruppo di risorse del cloud privato e della relativa rete virtuale.
• Gruppo di risorse incrociate e riferimenti tra sottoscrizioni dalle reti virtuali dei clienti alla rete virtuale soluzione Azure VMware non sono supportate per impostazione predefinita. Sono inclusi i tipi di risorse, ad esempio route definite dall'utente (UDR), piani di protezione DDoS e altre risorse di rete collegate. Se una rete virtuale del cliente è associata a uno di questi riferimenti che si trovano in un gruppo di risorse o una sottoscrizione diversa rispetto alla rete virtuale soluzione Azure VMware, la programmazione di rete (ad esempio la propagazione dei segmenti NSX) potrebbe non riuscire. Per evitare problemi, i clienti devono assicurarsi che la rete virtuale soluzione Azure VMware non sia connessa alle risorse in un altro gruppo di risorse o in un'altra sottoscrizione. Prima di continuare, rimuovere tali connessioni, ad esempio piani di protezione DDoS, dalla rete virtuale.
  • Per mantenere il riferimento tra gruppi di risorse, creare un'assegnazione di ruolo dal gruppo di risorse o dalla sottoscrizione interessati e assegnare il ruolo "AVS on Fleet VIS Role" all'applicazione "AzS VIS Prod App". L'assegnazione di ruolo consente di usare il riferimento e di fare in modo che venga applicato correttamente al cloud privato di soluzione Azure VMware.
• Le distribuzioni del cloud privato di seconda generazione potrebbero non riuscire se i criteri di Azure applicano regole rigorose per i gruppi di sicurezza di rete o le tabelle di route (ad esempio, convenzioni di denominazione specifiche). Questi vincoli di policy possono bloccare la creazione necessaria del gruppo di sicurezza di rete e della tabella di routing di soluzione Azure VMware durante la distribuzione. È necessario rimuovere questi criteri dalla rete virtuale soluzione Azure VMware prima di distribuire il cloud privato. Dopo aver distribuito il cloud privato, questi criteri possono essere aggiunti di nuovo al cloud privato soluzione Azure VMware.
• Se si usa DNS privato per il cloud privato di soluzione Azure VMware Gen 2, l'uso di Custom DNS nella rete virtuale in cui viene distribuito un cloud privato di soluzione Azure VMware Gen 2 non è supportato. Un DNS personalizzato interrompe le operazioni del ciclo di vita, ad esempio il ridimensionamento, gli aggiornamenti e l'applicazione di patch.
• Se si sta eliminando il cloud privato e alcune risorse create da soluzione Azure VMware non vengono rimosse, è possibile riprovare l'eliminazione del cloud privato di soluzione Azure VMware usando l'interfaccia della riga di comando di Azure.
• soluzione Azure VMware Gen 2 usa un proxy HTTP per distinguere tra il traffico di rete del cliente e quello di gestione. Alcuni endpoint servizio cloud VMware potrebbero non seguire lo stesso percorso di rete o le stesse regole proxy del traffico generale gestito da vCenter. Gli esempi includono: "scapi.vmware" e "apigw.vmware". Il proxy VAMI controlla l'accesso Internet in uscita generale (VCSA) dell'appliance server vCenter, ma non tutte le interazioni degli endpoint di servizio passano attraverso questo proxy. Alcune interazioni provengono direttamente dal browser dell'utente o dai componenti di integrazione, che seguono invece le impostazioni proxy della workstation o avviano le connessioni in modo indipendente. Di conseguenza, il traffico verso gli endpoint del servizio cloud VMware può ignorare completamente il proxy VCSA.
• Le migrazioni RAV e bulk di HCX in Generazione 2 possono riscontrare prestazioni più lente a causa di stalli durante le fasi di sincronizzazione di base e sincronizzazione online. I clienti devono pianificare finestre di migrazione più lunghe e pianificare le onde di conseguenza per il momento. Per carichi di lavoro adatti, vMotion offre un'opzione più rapida e a basso sovraccarico quando le condizioni di host e di rete consentono.
• Peering dell'hub virtuale (WAN virtuale): per stabilire una connessione di peering tra una rete virtuale Gen-2 e un hub virtuale (WAN virtuale), l'hub virtuale deve trovarsi nella stessa area geografica della rete virtuale Gen-2. Se è necessario eseguire il peering con un hub virtuale in un'area diversa, è necessario creare un caso di supporto tramite il portale di Azure.
• /32 destinazione della route da una rete virtuale (VNET) con peering: se si annunciano route /32 da NSX (ad esempio route HCX MON o route del server di inoltro DNS) e si deve accedere a tale destinazione /32 da una rete virtuale con peering, è necessario aprire una richiesta di supporto nel portale di Azure. La connettività alla destinazione /32 funziona correttamente dall'interno della rete virtuale locale.
• Annuncio della subnet di sincronizzazione peer della rete virtuale e associazione UDR (Route Table) Azure: soluzione Azure VMware Gen 2 usa due architetture interne. L'architettura attuale sincronizza sia subnet specifiche sia lo spazio di indirizzi Azure più ampio per le route dei segmenti o delle subnet NSX con le reti virtuali Azure con peering. Di conseguenza, con l'architettura corrente di Gen 2, potrebbe essere necessario configurare le tabelle di route di Azure (UDR) con route della subnet dei segmenti NSX più specifiche, anziché utilizzare route generiche dello spazio degli indirizzi per i segmenti del carico di lavoro di soluzione Azure VMware.

Integrazioni non supportate

Le integrazioni proprietarie e di terze parti seguenti non sono disponibili:

• Ripristino di emergenza Zerto

Subnet delegate e gruppi di sicurezza di rete per la seconda generazione

Quando viene distribuito un cloud privato di soluzione Azure VMware Gen 2, Azure crea automaticamente diverse subnet delegate all'interno della rete virtuale host del cloud privato. Queste subnet vengono usate per isolare e proteggere i componenti di gestione del cloud privato.

I clienti possono gestire l'accesso a queste subnet usando gruppi di sicurezza di rete (NSG) visibili nel portale di Azure o tramite interfaccia della riga di comando di Azure/PowerShell. Oltre ai gruppi di sicurezza di rete gestibili dal cliente, AVS applica gruppi di sicurezza di rete aggiuntivi gestiti dal sistema alle interfacce di gestione critiche. Questi gruppi di sicurezza di rete gestiti dal sistema non sono visibili o modificabili dai clienti ed esistono per garantire che il cloud privato rimanga sicuro per impostazione predefinita.

Come parte del comportamento di sicurezza predefinito:

• L'accesso a Internet è disabilitato per il cloud privato, a meno che il cliente non lo consenta in modo esplicito.
• Solo il traffico di gestione richiesto è autorizzato a raggiungere i servizi della piattaforma.

Questa progettazione mantiene l'ambiente AVS sicuro e separato per impostazione predefinita, consentendo comunque ai clienti di gestire e regolare l'accesso alla rete in base alle proprie esigenze.

Considerazioni su routing e subnet

soluzione Azure VMware cloud privato di seconda generazione forniscono un ambiente cloud privato VMware accessibile agli utenti e alle applicazioni da ambienti o risorse locali e basati su Azure. La connettività viene distribuita tramite rete Azure standard. Per abilitare questi servizi sono necessari intervalli di indirizzi di rete e porte del firewall specifici. Questa sezione illustra come configurare la rete in modo che funzioni con soluzione Azure VMware.

Il cloud privato si connette alla rete virtuale Azure usando la rete Azure standard. I cloud privati della soluzione Azure VMware Gen 2 richiedono almeno un blocco di indirizzi di rete CIDR /22 per le subnet. Questa rete integra le reti locali, quindi il blocco di indirizzi non deve sovrapporsi ai blocchi di indirizzi usati in altre reti virtuali presenti nella sottoscrizione e nelle reti locali. Il provisioning delle reti di gestione, vMotion e di replica viene effettuato automaticamente all'interno di questo blocco di indirizzi come subnet all'interno della rete virtuale.

Evitare di usare lo schema IP seguente riservato per l'utilizzo di VMware NSX:

• 169.254.0.0/24: usato per la rete di transito interna
• 169.254.2.0/23 - usato per la rete di transito inter-VRF
• 100.64.0.0/16: usato per connettere internamente i gateway T1 e T0
• 100.73.x.x: usato dalla rete di gestione di Microsoft

Il blocco di indirizzi di rete CIDR di esempio /22 10.31.0.0/22 è suddiviso nelle subnet seguenti:

Programmazione di route NSX su Rete virtuale di Azure

Le route NSX Gen-2 di soluzione Azure VMware vengono integrate in Azure usando lo spazio di indirizzi e assegnandolo come IP secondari nella subnet "avs-network-infra-gw" creata dal sistema, consentendo una connettività fluida tra Azure e i carichi di lavoro dei clienti AVS. Quando NSX Tier-0 annuncia una route in base alle impostazioni utente, ad esempio la creazione di segmenti, l'aggiunta di route statiche o l'uso di macchine virtuali MON di HCX, il piano di controllo soluzione Azure VMware controlla se il prefisso di route esiste nello spazio degli indirizzi della rete virtuale. In caso contrario, crea lo spazio di indirizzi e aggiunge il prefisso di instradamento come indirizzi IP secondari nella subnet "avs-network-infra-gw". Per le rotte /32 annunciate da Tier-0, come le rotte MON di HCX, gli indirizzi IP secondari non vengono configurati, ma il piano dati viene configurato internamente per garantire la connettività alle destinazioni /32 su soluzione Azure VMware.

Oltre all'aggiornamento dello spazio di indirizzamento e della subnet per le route NSX, vi sono meccanismi interni di cui i clienti devono essere consapevoli, soprattutto per quanto riguarda i limiti di scalabilità supportati quando vengono utilizzate maschere di sottorete meno restrittive. Per altre informazioni sull'aspetto della scalabilità, vedere architettura Route per soluzione Azure VMware Gen 2

Considerazioni sull'associazione Azure route table (UDR)

soluzione Azure VMware Gen-2 include due architetture interne, con lievi variazioni. Alcuni dei cloud privati di prima generazione usano l'architettura interna iniziale. Questi vengono aggiornati all'architettura corrente tramite la manutenzione pianificata, coordinata con il cliente. Tuttavia, esiste una modifica del comportamento con l'architettura corrente, rispetto all'architettura iniziale, che può influire su alcune considerazioni sulla progettazione di rete, come descritto di seguito.

Cloud privato di prima generazione 2:

• La rete virtuale di Azure dispone di due subnet gateway di base denominate "avs-nsx-gw" e non include la subnet "avs-network-infra-gw", come avviene nell'architettura corrente.
• Tutte le subnet del segmento NSX AVS vengono configurate nella subnet "avs-nsx-gw" come indirizzi IPv4 aggiuntivi per connettere Azure ai carichi di lavoro NSX.
• La tabella di routing (UDR) o l'NSG di Azure per il traffico da AVS alla rete virtuale di Azure e oltre (ad esempio verso l'ambiente on-premises) devono essere applicati alla subnet "avs-nsx-gw".

Cloud privato di seconda generazione corrente:

Assicurarsi di prendere nota di questa modifica nel comportamento.

• La rete virtuale di Azure comprenderà un'ulteriore subnet con prefisso "avs-network-infra-gw", insieme a due subnet gateway di base denominate "avs-nsx-gw", come nell'architettura iniziale.
• Tutte le subnet dei segmenti NSX di AVS sono ora configurate in questa sottorete come indirizzi IPv4 secondari per connettere Azure ai carichi di lavoro NSX. Ciò non modifica la connettività di rete dei clienti.
• Il peering VNET propaga sia lo spazio di indirizzi sia le subnet alla VNET connessa tramite peering, a differenza dell'architettura iniziale o della sincronizzazione VNET nativa di Azure, in cui viene sincronizzato solo lo spazio di indirizzi.

Considerazioni sulla progettazione dovute alle modifiche apportate all'architettura interna di seconda generazione

• I clienti riscontrano route effettive aggiuntive per le subnet AVS all'interno della VNET con peering a causa di una modifica del comportamento di sincronizzazione del peering VNET.
• Se un cliente usa una tabella di route Azure (UDR) per inviare il traffico da locale ad AVS tramite un firewall o un'appliance virtuale di rete, è necessario aggiornare la route definita dall'utente per usare route subnet NSX specifiche anziché l'intervallo di indirizzi supernet più ampio usato in precedenza. Ciò è necessario per evitare che il traffico destinato ad AVS segua route di subnet VNET più specifiche, bypassando il firewall previsto, a causa del criterio della corrispondenza con il prefisso più lungo nel comportamento del routing di Azure. In caso contrario, questo può causare un routing asimmetrico, causando potenzialmente problemi di connettività.
• Tuttavia, la tabella di routing (UDR) o il gruppo di sicurezza di rete (NSG) di Azure per il traffico da AVS alla rete virtuale di Azure e oltre (ad esempio in sede) continuerebbe a essere applicato alle subnet "avs-nsx-gw", non a "avs-network-infra-gw". I clienti non devono usare la tabella di route (UDR) nella subnet "avs-network-infra-gw", anche se le subnet dei segmenti NSX sono configurate come indirizzi IP secondari.

Passaggi successivi

• Iniziare a configurare l'entità servizio della soluzione Azure VMware come prerequisito. Per scoprire come, vedere la guida introduttiva Abilitazione dell'entità servizio della soluzione Azure VMware.

• Seguire un'esercitazione per Creare un Azure VMware Gen 2 Private Cloud