Integrare soluzione Azure VMware in un'architettura hub-spoke

  • Articolo

Questo articolo fornisce suggerimenti per l'integrazione di una distribuzione di soluzione Azure VMware in un'architettura hub-spoke esistente o nuova in Azure.

Lo scenario hub-spoke presuppone un ambiente cloud ibrido con carichi di lavoro in:

  • Azure nativo con i servizi IaaS o PaaS
  • Soluzione Azure VMware
  • vSphere locale

Architettura

L'hub è un Rete virtuale di Azure che funge da punto centrale di connettività al cloud locale e soluzione Azure VMware privato. Gli spoke sono reti virtuali con peering con l'hub per abilitare la comunicazione tra reti virtuali.

Il traffico tra il data center locale, soluzione Azure VMware cloud privato e l'hub passa attraverso le connessioni di Azure ExpressRoute. Le reti virtuali spoke in genere contengono carichi di lavoro basati su IaaS, ma possono avere servizi PaaS come ambiente del servizio app, con integrazione diretta con Rete virtuale o altri servizi PaaS con collegamento privato di Azure abilitato.

Importante

È possibile usare un gateway ExpressRoute esistente per connettersi alla soluzione Azure VMware, purché non si superi il limite di quattro circuiti ExpressRoute per rete virtuale. Tuttavia, per accedere alla soluzione Azure VMware dall'ambiente locale tramite ExpressRoute è necessario avere Copertura globale ExpressRoute, in quanto il gateway ExpressRoute non fornisce il routing transitivo tra i circuiti connessi.

Il diagramma mostra un esempio di distribuzione hub-spoke in Azure connessa all'ambiente locale e soluzione Azure VMware tramite Copertura globale di ExpressRoute.

Diagramma che mostra la distribuzione dell'integrazione di hub e spoke soluzione Azure VMware.

L'architettura include i componenti principali seguenti:

  • Sito locale: data center locali del cliente connessi ad Azure tramite una connessione ExpressRoute.

  • soluzione Azure VMware cloud privato: soluzione Azure VMware data center software-defined formato da uno o più cluster vSphere, ognuno con un massimo di 16 host.

  • Gateway ExpressRoute: abilita la comunicazione tra soluzione Azure VMware cloud privato, servizi condivisi nella rete virtuale hub e carichi di lavoro in esecuzione su reti virtuali spoke tramite un Connessione ExpressRoute.

  • Copertura globale di ExpressRoute: abilita la connettività tra l'ambiente locale e soluzione Azure VMware cloud privato. La connettività tra soluzione Azure VMware e l'infrastruttura di Azure è solo tramite Copertura globale di ExpressRoute.

  • Considerazioni sulla VPN da sito a sito: Connessione ivity to soluzione Azure VMware private cloud using Azure S2S VPN is supported as as the minimum network requirements for VMware HCX(Considerazioni sulla VPN da sito a sito): Connessione ivity to soluzione Azure VMware private cloud using Azure S2S VPN is supported as the minimum network requirements for VMware HCX.

  • Rete virtuale hub: funge da punto centrale di connettività alla rete locale e soluzione Azure VMware cloud privato.

  • Rete virtuale spoke

    • IaaS Spoke: ospita carichi di lavoro basati su IaaS di Azure, inclusi i set di disponibilità delle macchine virtuali e i set di scalabilità di macchine virtuali e i componenti di rete corrispondenti.

    • PaaS Spoke: ospita i servizi PaaS di Azure usando l'indirizzamento privato grazie a endpoint privato e collegamento privato.

  • Firewall di Azure: Funge da pezzo centrale per segmentare il traffico tra gli spoke e soluzione Azure VMware.

  • gateway applicazione: Espone e protegge le app Web eseguite in Azure IaaS/PaaS o soluzione Azure VMware macchine virtuali (VM). Si integra con altri servizi come Gestione API.

Considerazioni sulla rete e sulla sicurezza

Le connessioni ExpressRoute consentono il flusso del traffico tra l'infrastruttura di rete locale, soluzione Azure VMware e l'infrastruttura di rete di Azure. soluzione Azure VMware usi Copertura globale di ExpressRoute per implementare questa connettività.

Poiché un gateway ExpressRoute non fornisce il routing transitivo tra i circuiti connessi, anche la connettività locale deve usare Copertura globale di ExpressRoute per comunicare tra l'ambiente vSphere locale e soluzione Azure VMware.

  • Da locale a soluzione Azure VMware flusso del traffico

    Diagramma che mostra il flusso del traffico da locale a soluzione Azure VMware.

  • soluzione Azure VMware al flusso del traffico della rete virtuale dell'hub

    Diagramma che mostra il flusso del traffico di rete virtuale hub soluzione Azure VMware.

Per altre informazioni sui concetti relativi alla rete e alla connettività soluzione Azure VMware, vedere la documentazione del prodotto soluzione Azure VMware.

Segmentazione del traffico

Firewall di Azure è la parte centrale della topologia Hub-Spoke, distribuita nella rete virtuale hub. Usare Firewall di Azure o un'altra appliance virtuale di rete supporto tecnico di Azure ed per stabilire regole di traffico e segmentare la comunicazione tra i diversi spoke e i carichi di lavoro soluzione Azure VMware.

Creare tabelle di route per indirizzare il traffico a Firewall di Azure. Per le reti virtuali spoke, creare una route che imposta la route predefinita sull'interfaccia interna del Firewall di Azure. In questo modo, quando un carico di lavoro nella Rete virtuale deve raggiungere lo spazio degli indirizzi soluzione Azure VMware, il firewall può valutarlo e applicare la regola di traffico corrispondente per consentire o rifiutarla.

Screenshot che mostra le tabelle di route per indirizzare il traffico alle Firewall di Azure.

Importante

Una route con prefisso indirizzo 0.0.0.0/0 nell'impostazione GatewaySubnet non è supportata.

Impostare le route per reti specifiche nella tabella di route corrispondente. Ad esempio, le route per raggiungere soluzione Azure VMware i prefissi IP di gestione e carichi di lavoro dai carichi di lavoro spoke e viceversa.

Screenshot che mostra le route impostate per reti specifiche nella tabella di route corrispondente.

Secondo livello di segmentazione del traffico usando i gruppi di sicurezza di rete all'interno degli spoke e dell'hub per creare criteri di traffico più granulari.

Nota

Traffico da locale a soluzione Azure VMware: il traffico tra carichi di lavoro locali, basati su vSphere o altri, è abilitato da Copertura globale, ma il traffico non passa attraverso Firewall di Azure nell'hub. In questo scenario è necessario implementare meccanismi di segmentazione del traffico, in locale o in soluzione Azure VMware.

Gateway applicazione

app Azure gateway V1 e V2 sono stati testati con app Web eseguite in macchine virtuali soluzione Azure VMware come pool back-end. gateway applicazione è attualmente l'unico metodo supportato per esporre le app Web in esecuzione in soluzione Azure VMware macchine virtuali a Internet. Può anche esporre le app agli utenti interni in modo sicuro.

Per altre informazioni, vedere l'articolo specifico soluzione Azure VMware su gateway applicazione.

Diagramma che mostra il secondo livello di segmentazione del traffico usando i gruppi di sicurezza di rete.

Jump box e Azure Bastion

Accedere soluzione Azure VMware ambiente con un jump box, ovvero una macchina virtuale Windows 10 o Windows Server distribuita nella subnet del servizio condiviso all'interno della rete virtuale hub.

Importante

Azure Bastion è il servizio consigliato per connettersi alla jump box per evitare di esporre la soluzione Azure VMware a Internet. Non è possibile usare Azure Bastion per connettersi alle macchine virtuali soluzione Azure VMware perché non sono oggetti IaaS di Azure.

Come procedura consigliata per la sicurezza, distribuire il servizio Microsoft Azure Bastion all'interno della rete virtuale hub. Azure Bastion offre accesso RDP e SSH facile alle macchine virtuali distribuite in Azure senza fornire indirizzi IP pubblici a tali risorse. Dopo aver effettuato il provisioning del servizio Azure Bastion, è possibile accedere alla macchina virtuale selezionata dal portale di Azure. Dopo aver stabilito la connessione, viene aperta una nuova scheda che mostra il jump box desktop e da tale desktop è possibile accedere al piano di gestione del cloud privato soluzione Azure VMware.

Importante

Non assegnare un indirizzo IP pubblico alla macchina virtuale jump box o esporre la porta 3389/TCP alla rete Internet pubblica.

Diagramma che mostra la rete virtuale dell'hub Bastion di Azure.

Considerazioni sulla risoluzione DNS di Azure

Per la risoluzione DNS di Azure sono disponibili due opzioni:

  • Usare i controller di dominio distribuiti nell'hub (descritto in Considerazioni sull'identità) come server dei nomi.

  • Distribuire e configurare una zona privata DNS di Azure.

L'approccio migliore consiste nel combinare sia per fornire una risoluzione dei nomi affidabile per soluzione Azure VMware, locale e Azure.

Raccomandazione di progettazione generale: usare il DNS integrato di Active Directory esistente distribuito in almeno due macchine virtuali di Azure nella rete virtuale hub e configurato nelle reti virtuali spoke per usare tali server DNS di Azure nelle impostazioni DNS.

È possibile usare DNS privato di Azure, in cui la zona DNS privato di Azure collega alla rete virtuale. I server DNS vengono usati come resolver ibridi con l'inoltro condizionale all'ambiente locale o soluzione Azure VMware l'esecuzione di DNS tramite l'infrastruttura di Azure DNS privato del cliente.

Per gestire automaticamente il ciclo di vita dei record DNS per le macchine virtuali distribuite all'interno delle reti virtuali spoke, abilitare la registrazione automatica. Se abilitata, il numero massimo di zone DNS private è solo uno. Se disabilitato, il numero massimo è 1000.

I server locali e soluzione Azure VMware possono essere configurati con server d'inoltro condizionale per risolvere le macchine virtuali in Azure per la zona DNS privato di Azure.

Considerazioni sull'identità

Ai fini dell'identità, l'approccio migliore consiste nel distribuire almeno un controller di dominio nell'hub. Usare due subnet del servizio condiviso in modalità distribuita nella zona o in un set di disponibilità di macchine virtuali. Per altre informazioni sull'estensione del dominio di Active Directory locale (AD) ad Azure, vedere Centro architetture di Azure.

Distribuire inoltre un altro controller di dominio sul lato soluzione Azure VMware per fungere da origine DNS e identità all'interno dell'ambiente vSphere.

Come procedura consigliata, integrare il dominio AD con Microsoft Entra ID.