Architettura : soluzione Azure VMware in una zona di destinazione Azure

Questo articolo illustra come soluzione Azure VMware si integra nella zona di destinazione Azure e nell'architettura aziendale. Individuare le decisioni della piattaforma per la rete, la sicurezza, l'identità e l'integrazione che influiscono sui costi e sulle operazioni.

soluzione Azure VMware esegue l'ambiente VMware esistente nell'infrastruttura di Azure dedicata. Usando soluzione Azure VMware, i team possono continuare a usare strumenti e processi VMware familiari e integrarsi con i servizi di Azure in modo nativo. Queste linee guida sono incentrate sulle decisioni della piattaforma applicabili a ogni carico di lavoro soluzione Azure VMware, non alla progettazione di una singola applicazione. Usalo prima di richiedere un'implementazione, perché alcune scelte iniziali relative a rete, indirizzamento, gestione delle identità e integrazione influiscono su costi, sicurezza e operazioni per gli anni a venire.

Raccomandazione: Decidere come soluzione Azure VMware si integra con la zona di destinazione esistente, tra cui dove si trovano i cloud privati nella gerarchia dei gruppi di gestione, come si connettono alle reti Azure e locali e quali servizi aziendali si estendono ai carichi di lavoro.

1. Zona di destinazione della piattaforma

La zona di destinazione della piattaforma fornisce le basi condivise su cui si basa ogni carico di lavoro, ad esempio rete, identità e monitoraggio. soluzione Azure VMware dipende da questa base e il lavoro di configurazione dipende dalla generazione scelta. Gen 2 richiede meno impianti idraulici di piattaforma perché si trova all'interno della rete virtuale. Pianificare gli elementi seguenti prima di richiedere una distribuzione.

1.1 Azure connettività di rete virtuale

Decidere in che modo il cloud privato raggiunge le reti virtuali Azure e i data center locali. La landing zone della piattaforma deve garantire questa connettività e l'impegno richiesto dipende dalla generazione selezionata.

• Requisiti di generazione 2: Gen 2 si connette in modo nativo. Un cloud privato di seconda generazione viene distribuito all'interno di una rete virtuale di Azure, quindi può raggiungere le altre reti di Azure tramite peering standard tra reti virtuali, senza dover creare alcuna connettività aggiuntiva. Questo è il motivo principale per cui Gen 2 semplifica la progettazione di rete.

• Requisiti di generazione 1: Gen 1 usa una connessione ExpressRoute gestita. Un cloud privato di generazione 1 si connette alle reti virtuali Azure tramite una connessione ExpressRoute gestita da Microsoft appartenente al servizio soluzione Azure VMware. Considerare questo aspetto come una decisione di progettazione separata rispetto a ExpressRoute usata per il traffico locale. Per molti carichi di lavoro di seconda generazione, lo SKU a prestazioni elevate è sufficiente. Per i carichi di lavoro con requisiti di velocità effettiva molto elevati, usare lo SKU Prestazioni Ultra con FastPath abilitato e creare un secondo circuito ExpressRoute per la connettività di archiviazione esterna. Un singolo gateway supporta fino a quattro connessioni cloud private da un'unica posizione.

Usare la seconda generazione per le nuove distribuzioni di cloud privato, se possibile. Usare gen 1 quando si estende un ambiente di soluzione Azure VMware Gen 1 esistente o nelle aree in cui la generazione 2 non è disponibile.

1.2 Connettività locale

Molte organizzazioni eseguono soluzione Azure VMware in un modello ibrido in cui alcune applicazioni, utenti o dati rimangono nei data center. Pianificare questo percorso in anticipo, perché influisce sia sulla migrazione che sulle operazioni quotidiane.

VMware HCX Network Extension supporta l'estensione di una singola rete tra cloud privati locali e soluzione Azure VMware, in modo da poter condividere gli intervalli IP e conservare gli indirizzi IP quando si passa a Azure. L'estensione di rete introduce i propri vincoli e limiti di scalabilità. Usarlo per i carichi di lavoro in cui la conservazione ip è importante, ma non si presuppone che sia necessaria per ogni carico di lavoro.

• Gen 2: La seconda generazione si connette in locale tramite il proprio gateway. Con la seconda generazione, il data center viene connesso al cloud privato allo stesso modo in cui si connette qualsiasi rete virtuale Azure all'ambiente locale, usando una connessione ExpressRoute standard o una VPN da sito a sito tramite il gateway di rete virtuale. La connettività ibrida esistente spesso copre già questo problema.

• Gen 1: Gen 1 usa Copertura globale di ExpressRoute. Con Gen 1, si connette l'ambiente locale al cloud privato con ExpressRoute Global Reach, che esegue il peering tra il circuito ExpressRoute locale e il circuito gestito da soluzione Azure VMware direttamente all'edge della rete Microsoft. Questo percorso offre una bassa latenza ed evita il routing tramite Azure reti virtuali. Nelle aree geografiche in cui Global Reach non è disponibile a causa delle normative locali, è necessario creare una soluzione di routing con macchine virtuali di Azure, il che comporta costi aggiuntivi e una maggiore complessità operativa.

1.3 Spazio indirizzi di rete

La connettività funziona solo se si riservano gli indirizzi corretti in anticipo. Le sovrapposizioni degli indirizzi e i ritardi delle quote sono le cause più comuni di implementazioni lente o non riuscite.

• Blocco di indirizzi del cloud privato: Riservare un blocco /22 dedicato per ogni cloud privato. Ogni cloud privato necessita di un proprio blocco di indirizzi /22 per le funzioni di gestione, ad esempio il server vCenter e vMotion, la tecnologia che sposta le macchine virtuali in esecuzione tra gli host. Azure effettua automaticamente il provisioning di queste subnet di gestione all'interno del blocco. Il blocco non deve sovrapporsi ad alcun intervallo già usato in locale o in Azure e deve provenire dallo spazio indirizzi privato (RFC 1918).

• Subnet gen 2: gen 2 chiede anche di riservare due subnet /24 aggiuntive per la gestione e il traffico di migrazione di VMware HCX, oltre a /22. Le macchine virtuali sono connesse a segmenti di rete che si trovano al di fuori del blocco di gestione, quindi occorre identificare almeno un segmento che non si sovrapponga per i carichi di lavoro iniziali, per poi espandere da lì. Vedere soluzione Azure VMware considerazioni sulla progettazione del cloud privato di seconda generazione.

1.4 Architettura delle identità

Riutilizzare i servizi di gestione delle identità esistenti. La maggior parte delle distribuzioni esegue l'autenticazione tramite Active Directory e Microsoft Entra ID. Configurare l'autenticazione di soluzione Azure VMware in modo che punti ai controller di dominio corretti, come si fa per altri carichi di lavoro di Azure, usando Active Directory Sites and Services. Distribuire i controller di dominio nella sottoscrizione di identità Azure e non fare affidamento sui controller di dominio locali per soluzione Azure VMware.

1.5 Architettura di monitoraggio

Inviare i log e le metriche di soluzione Azure VMware ad Monitoraggio di Azure e Log Analytics. Allineare la distribuzione Log Analytics alle responsabilità amministrative di VMware. Per un singolo team della piattaforma che gestisce sia Azure che VMware, un'area di lavoro condivisa Log Analytics migliora la visibilità. Dove l'amministrazione di VMware è delegata a team specializzati, un'area di lavoro dedicata Log Analytics supporta l'autonomia. Crea avvisi e dashboard sulle metriche più importanti per le operazioni e abilita il monitoraggio dei guest per le macchine virtuali in esecuzione in soluzione Azure VMware tramite Azure Arc. L'inoltro di volumi elevati di log comporta costi di ingestione in Log Analytics, quindi raccogli solo i dati su cui i team intervengono. Assicurarsi che Microsoft Sentinel sia attivato nelle aree di lavoro di Log Analytics con log di sicurezza, ad esempio log di identità e log del firewall NSX.

2. Zone di destinazione dell'applicazione

Posizionare ogni soluzione Azure VMware cloud privato in una zona di destinazione dell'applicazione, indipendentemente dal modello operativo o dalla struttura di proprietà. Non raggruppare un cloud privato soluzione Azure VMware nel gruppo di gestione "Piattaforma" come risorsa di piattaforma centralizzata. È una risorsa del carico di lavoro e dovresti governarla e gestirla in questo modo.

Se si distribuiscono più carichi di lavoro dell'applicazione nello stesso cloud privato, è comunque consigliabile considerarlo come risorsa del carico di lavoro. Mantieni l'isolamento dei carichi di lavoro per gli altri componenti dell'applicazione nelle rispettive sottoscrizioni della landing zone dell'applicazione, come se fossero autonomi. Ad esempio, è possibile scegliere di condividere le applicazioni X e Y nello stesso cloud privato VMware per motivi di efficienza dei costi. Distribuire database SQL e altre risorse appartenenti all'applicazione X nella zona di destinazione dell'applicazione X e l'applicazione Y nella propria zona di destinazione. Non posizionare altre risorse dell'applicazione nella stessa sottoscrizione di un soluzione Azure VMware cloud privato, a meno che non sia dedicato a un singolo carico di lavoro.

Carichi di lavoro esposti a Internet vs. carichi di lavoro interni. Come procedura consigliata, distribuire cloud privati separati per carichi di lavoro interni e con connessione Internet. Questa separazione rafforza i limiti di sicurezza e semplifica la governance. Riduce anche il rischio di esposizione imprevista. I carichi di lavoro con connessione Internet e i carichi di lavoro solo interni comportano rischi diversi, quindi non devono condividere lo stesso cloud privato. Combinate i carichi di lavoro solo come eccezione per motivi di costo. Le organizzazioni con vincoli di costo possono ospitare entrambi i tipi di carico di lavoro in un cloud privato. Quando si esegue questa eccezione, applicare controlli di sicurezza e segmentazione di rete avanzata tra i gruppi di carico di lavoro. Questa scelta riduce i costi ed è consigliabile considerarla come un'eccezione anziché la progettazione preferita.

3. Integrazione aziendale

L'esecuzione di carichi di lavoro VMware in soluzione Azure VMware consente ai team di accedere direttamente ai servizi di Azure. Poiché la seconda generazione si trova all'interno della rete virtuale, soluzione Azure VMware i carichi di lavoro raggiungono questi servizi tramite la rete Azure senza riprogettare le applicazioni. Decidi subito quali servizi aziendali si estenderanno ai carichi di lavoro di soluzione Azure VMware, in modo che gli strumenti di sicurezza, gestione dei dati, IA e operativi li coprano fin dal primo giorno.

3.1 Sicurezza e conformità

soluzione Azure VMware deve integrarsi con le stesse funzionalità di sicurezza, governance e conformità che proteggono il resto del tuo ambiente cloud. L'estensione di processi di conformità e operazioni di sicurezza esistenti a soluzione Azure VMware consente di mantenere controlli coerenti, migliorare la visibilità tra gli ambienti e ridurre il carico operativo della gestione di piattaforme di sicurezza separate.

• Microsoft Defender per il cloud e Defender for Endpoint: Usare Azure Arc per integrare le macchine virtuali di soluzione Azure VMware in Defender per il cloud. Dopo aver abilitato Arc, è possibile distribuire Defender per endpoint in macchine virtuali soluzione Azure VMware allo stesso modo delle macchine virtuali Azure.

• Microsoft Sentinel: inoltrare i dati dei log di sicurezza da NSX, vCenter e ESXi a un'area di lavoro Log Analytics e usare le regole di analisi di Sentinel per rilevare le minacce nei carichi di lavoro Azure e VMware. Se si usa già Sentinel, estendendolo a soluzione Azure VMware evita di introdurre una soluzione SIEM separata.

• Microsoft Purview: se i carichi di lavoro soluzione Azure VMware sono soggetti ai requisiti di governance dei dati, eseguire l'integrazione con Purview Data Map con i servizi di database ospitati da VMware.

3.2 Integrazione con i servizi Azure

soluzione Azure VMware consente alle organizzazioni di adottare servizi di intelligenza artificiale e piattaforme dati moderne senza richiedere la modernizzazione immediata delle applicazioni. Connettendo i carichi di lavoro ospitati da VMware a Azure servizi di intelligenza artificiale, dati e integrazione, le organizzazioni possono accelerare l'innovazione, migliorare le informazioni aziendali e modernizzarli in base ai requisiti operativi e aziendali.

• Microsoft Foundry: le applicazioni ospitate soluzione Azure VMware possono connettersi ai modelli di intelligenza artificiale distribuiti tramite Foundry sul percorso a bassa latenza tra soluzione Azure VMware e Azure reti virtuali.

• Microsoft Fabric: Connetti i database ospitati in soluzione Azure VMware a Microsoft Fabric per la predisposizione all'IA, l'analisi e la business intelligence, mantenendo il livello dati in VMware. Vedere Dati per intelligenza artificiale e analisi - Linee guida per impostare la strategia dei dati dell'organizzazione per intelligenza artificiale e analisi.

• Integration Services: Usare servizi come Gestione API di Azure (GESTIONE API) e bus di servizio di Azure per esporre le API ospitate da VMware in modo sicuro, disaccoppiare i componenti con la messaggistica e integrare carichi di lavoro soluzione Azure VMware con applicazioni native di Azure.

• Servizio app: Modernizzare componenti dell'applicazione specifici spostando app Web o API in Servizio app di Azure mantenendo al tempo stesso livelli dipendenti in soluzione Azure VMware. Usa l'integrazione con la rete virtuale in modo che App Service possa raggiungere back-end ospitati in soluzione Azure VMware con bassa latenza.

• Contenitori: Ripiattaforma i servizi selezionati ai contenitori usando Servizio Azure Kubernetes (AKS) o App contenitore di Azure, mantenendo al tempo stesso altri componenti in soluzione Azure VMware. Ciò supporta la modernizzazione incrementale e può ridurre il sovraccarico operativo per i componenti dell'applicazione.

• Servizi di database di Azure: I carichi di lavoro di soluzione Azure VMware possono connettersi ad database SQL di Azure, Database di Azure per PostgreSQL, Cosmos DB e altri servizi di database gestiti per una modernizzazione incrementale del livello dati.

• Archiviazione di Azure: i carichi di lavoro in soluzione Azure VMware possono connettersi direttamente a File di Azure, Azure NetApp Files e Archiviazione BLOB di Azure per archiviare i dati dell'applicazione. Azure NetApp Files e Elastic SAN possono estendere la capacità del datastore del cloud privato oltre allo spazio di archiviazione di cui è già stato effettuato il provisioning in vSAN. La connessione agli account di archiviazione Azure può ridurre la domanda di archiviazione all'interno del cloud privato soluzione Azure VMware e ridurre al minimo i costi.

soluzione Azure VMware carichi di lavoro accedono ai servizi Azure tramite ExpressRoute (Gen 1) o la rete virtuale direttamente (Gen 2). Assicurarsi che la progettazione della rete fornisca una larghezza di banda adeguata e una bassa latenza per queste connessioni. Per l'accesso ad alte prestazioni ai servizi di Azure, i cloud privati di prima generazione soluzione Azure VMware possono richiedere più circuiti ExpressRoute.

3.3. Integrazione locale

Alcune applicazioni, punti di integrazione e endpoint utente rimangono in locale durante e dopo la migrazione. Progettare le operazioni ibride fin dall'inizio, in modo da eseguire i carichi di lavoro in modo coerente tra soluzione Azure VMware e il resto del patrimonio.

• Connettività locale: Usare la connettività stabilita nella zona di destinazione della piattaforma come percorso singolo tra il data center e soluzione Azure VMware. Per Gen 2, si tratta della configurazione standard di ExpressRoute o VPN tramite il gateway di rete virtuale. Per Gen 1, si tratta di ExpressRoute Global Reach.

• Gestione unificata: Gestire entrambe le proprietà da un'unica posizione. Usa VMware vSphere abilitato per Azure Arc per gestire insieme l'infrastruttura VMware locale e soluzione Azure VMware, per avere una vista coerente di inventario, criteri e sicurezza. Se si usano le operazioni VMware Aria per il monitoraggio, è possibile configurare una console per coprire sia l'ambiente locale che soluzione Azure VMware. Lo stesso vale per gli strumenti di gestione di backup e configurazione.

3.4 Integrazione del ciclo di vita

soluzione Azure VMware dovrebbe far parte dei processi operativi e di governance esistenti anziché essere gestiti come piattaforma separata. Integrare soluzione Azure VMware nelle procedure stabilite per la gestione dei servizi IT, la gestione degli asset, l'automazione e la gestione della configurazione. Migliora la coerenza operativa, riduce il sovraccarico amministrativo e semplifica le operazioni della piattaforma in corso.

• Integrazione con ITSM: Collega gli avvisi alla piattaforma ITSM. Integra Monitoraggio di Azure con ServiceNow o la tua piattaforma di gestione dei servizi IT, in modo che gli avvisi di soluzione Azure VMware creino automaticamente incidenti nei flussi di lavoro esistenti.

• Gestione degli asset: Tenere traccia degli asset soluzione Azure VMware nel database CMDB. Usare Azure Arc per registrare le macchine virtuali di soluzione Azure VMware nel database di gestione della configurazione insieme alle risorse di Azure e locali.

• Automazione della piattaforma e IaC: Automatizzare con l'infrastruttura come codice. Includi soluzione Azure VMware nella tua strategia di automazione della piattaforma, in modo da distribuire e modificare la soluzione allo stesso modo del resto dell'infrastruttura.

• Gestione delle immagini: Pianificare la gestione delle immagini. Vedere la documentazione del prodotto per le opzioni più recenti per condividere i modelli di macchina virtuale tra vCenter locale e soluzione Azure VMware vCenter. Potrebbe essere necessario gestire le immagini separatamente in ogni ambiente. Le librerie di contenuto sono utili all'interno di ciascun ambiente e la sincronizzazione tra ambienti potrebbe richiedere intervento manuale o automazione personalizzata.

Passo successivo