Beispielarchitekturen für Azure VMware-Lösung

Wenn Sie eine Azure VMware Solution-Zielzone einrichten, müssen Sie zunächst Netzwerkfunktionen entwerfen und implementieren. Azure-Netzwerkprodukte und -dienste unterstützen mehrere Netzwerkszenarien. In diesem Artikel werden die vier häufigsten Netzwerkszenarien beschrieben.

• Szenario 1: Ein gesicherter virtueller WAN-Hub mit Routingabsicht
• Szenario 2: Eine virtuelle Netzwerk-Appliance (NVA) in Azure Virtual Network prüft den gesamten Netzwerkdatenverkehr.
• Szenario 3: Ausgehender Datenverkehr aus Azure VMware Solution mit oder ohne NSX-T oder NVAs
• Szenario 4: Nicht-Microsoft-Firewalllösungen in einem virtuellen Hubnetzwerk mit Azure Route Server

Um eine geeignete Architektur auszuwählen und ihre Dienste zu strukturieren, bewerten Sie die Arbeitslasten, die Governance und die Anforderungen Ihrer Organisation.

Szenarioüberlegungen

Lesen Sie die folgenden Überlegungen und wichtigsten Anforderungen, bevor Sie Ihr Azure VMware Solution-Bereitstellungsszenario auswählen.

• Anforderungen für den Internetverkehr, der in Azure VMware Solution-Anwendungen eintritt

• Überlegungen zu Pfaden für Internetdatenverkehr, der Azure VMware Solution-Anwendungen verlässt

• Netzwerk-L2-Erweiterung für Migrationen

• NVA-Verwendung in der aktuellen Architektur

• Azure VMware Solution-Konnektivität mit einem Standard-Hub-VNet oder Azure Virtual WAN-Hub

• Azure ExpressRoute-Konnektivität von lokalen Rechenzentren zu Azure VMware-Lösung

• Verwendung der globalen ExpressRoute-Reichweite

• Anforderungen an die Datenverkehrsuntersuchung für:

  • Internetzugriff auf Azure VMware-Lösungsanwendungen
  • Azure VMware-Lösungszugriff auf das Internet
  • Azure VMware-Lösungszugriff auf lokale Rechenzentren
  • Azure VMware Solution-Zugriff auf Virtual Network
  • Datenverkehr in der privaten Azure VMware Solution-Cloud

Die folgende Tabelle enthält Empfehlungen und Überlegungen, die auf den Azure VMware Solution-Anforderungen zur Untersuchung des Datenverkehrs für die einzelnen Szenarios basieren.

Szenario	Anforderungen an die Verkehrsinspektion	Empfohlenes Lösungsdesign	Überlegungen
1	- Aus dem Internet - Zum Internet	Verwenden Sie einen geschützten Virtual WAN-Hub mit Standardgatewayweitergabe. Verwenden Sie das Azure-Anwendungsgateway für HTTP- oder HTTPS-Datenverkehr. Verwenden Sie Azure Firewall für Nicht-HTTP- oder HTTPS-Datenverkehr. Bereitstellen Sie einen gesicherten virtuellen WAN-Hub mit Routingziel.	Diese Option verwendet die globale Reichweite, die nicht für die lokale Filterung wirksam ist, da sie die virtuellen WAN-Hubs umgeht.
2	- Aus dem Internet - Zum Internet – Lokales Rechenzentrum (eingehend) - Zum virtuellen Netzwerk	Verwenden Sie Nicht-Microsoft-Firewall-NVA-Lösungen in Ihrem virtuellen Hubnetzwerk mit Route Server. Verwenden Sie Global Reach nicht. Verwenden Sie das Anwendungsgateway für HTTP- oder HTTPS-Datenverkehr. Verwenden Sie ein Nicht-Microsoft-Firewall-NVA in Azure für Nicht-HTTP- oder HTTPS-Datenverkehr.	Wählen Sie diese Option aus, wenn Sie Ihr vorhandenes NVA verwenden möchten und alle Datenverkehrsüberprüfungen in Ihrem virtuellen Hubnetzwerk zentralisieren möchten.
3	- Aus dem Internet - Zum Internet – Lokales Rechenzentrum (eingehend) - Zum virtuellen Netzwerk – Innerhalb der Azure VMware-Lösung	Verwenden Sie NSX-T Data Center oder eine Nicht-Microsoft NVA-Firewall in Azure VMware Solution. Verwenden Sie das Anwendungsgateway für HTTPS-Datenverkehr. Verwenden Sie azure Firewall für nicht-HTTPS-Datenverkehr. Stellen Sie den gesicherten virtuellen WAN-Hub bereit, und aktivieren Sie eine öffentliche IP-Adresse in der Azure VMware-Lösung.	Wählen Sie diese Option aus, wenn Sie den Datenverkehr aus zwei oder mehr privaten Azure VMware Solution-Clouds überprüfen müssen. Verwenden Sie diese Option, um die NSX-T-eigenen Funktionen zu nutzen. Sie können diese Option auch mit NVAs kombinieren, die auf Azure VMware Solution ausgeführt werden.
4	- Aus dem Internet - Zum Internet – Lokales Rechenzentrum (eingehend) - Zum virtuellen Netzwerk	Verwenden Sie Nicht-Microsoft-Firewalllösungen in einem virtuellen Hubnetzwerk mit Route Server. Verwenden Sie das Anwendungsgateway für HTTP- oder HTTPS-Datenverkehr. Verwenden Sie eine NVA-Firewall eines Drittanbieters, die nicht von Microsoft stammt, in Azure für Nicht-HTTP- oder -HTTPS-Datenverkehr. Verwenden Sie eine lokale NVA-Firewall von einem Nicht-Microsoft-Anbieter. Bereitstellen von Nicht-Microsoft-Firewalllösungen in einem virtuellen Hubnetzwerk mit Route Server.	Wählen Sie diese Option aus, um die Route 0.0.0.0/0 von einem NVA in Ihrem virtuellen Azure Hub-Netzwerk zu Azure VMware Solution anzukündigen.

Berücksichtigen Sie die folgenden wichtigen Punkte zu den Netzwerkszenarien:

• Alle Szenarien weisen ähnliche Eingangsmuster über das Anwendungsgateway und die Azure-Firewall auf.

• Sie können L4 to L7 Load Balancer-Lösungen in Azure VMware Solution verwenden.

• Sie können die NSX-T verteilte Firewall für jedes dieser Szenarien verwenden.

In den folgenden Abschnitten werden Architekturmuster für private Azure VMware Solution-Clouds beschrieben. Weitere Informationen finden Sie unter Azure VMware Solution – Netzwerk- und Interkonnektivitätskonzepte.

Szenario 1: Ein gesicherter virtueller WAN-Hub mit Routingabsicht

Dieses Szenario umfasst die folgenden Architekturkomponenten und Überlegungen.

Wann dieses Szenario verwendet werden soll

Verwenden Sie dieses Szenario, wenn:

• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure VMware Solution und lokalen Rechenzentren.

• Sie benötigen eine Datenverkehrsüberprüfung zwischen Azure VMware Solution-Workloads und dem Internet.

• Sie müssen den eingehenden öffentlichen Datenverkehr zu Azure VMware Solution-Workloads sichern.

Berücksichtigen Sie auch diese anderen Faktoren:

• In diesem Szenario können Sie die öffentlichen IP-Adressen besitzen. Weitere Informationen finden Sie unter Benutzerdefiniertes IP-Adresspräfix.

• Sie können bei Bedarf öffentliche eingehende L4- oder L7-Dienste hinzufügen.

• Möglicherweise haben Sie bereits ExpressRoute-Konnektivität zwischen lokalen Rechenzentren und Azure, oder auch nicht.

Überblick

Das folgende Diagramm bietet eine allgemeine Übersicht über Szenario 1.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Komponenten

Dieses Szenario besteht aus den folgenden Komponenten:

• Azure Firewall in einem gesicherten virtuellen WAN-Hub für Firewalls

• Application Gateway für L7-Lastenausgleich und Azure Web Application Firewall

• L4-DNAT (Destination Network Address Translation) mit Azure Firewall zum Übersetzen und Filtern des eingehenden Netzwerkdatenverkehrs

• Ausgehendes Internet über die Azure Firewall in Ihrem virtuellen WAN-Hub

• EXR, VPN oder SD-WAN für die Konnektivität zwischen lokalen Rechenzentren und Azure VMware-Lösung

Laden Sie eine Visio-Datei dieser Architektur herunter.

Überlegungen

• Azure Firewall im geschützten Virtual WAN Hub kündigt die Route 0.0.0.0/0 in Azure VMware Solution an. Diese Route wird auch lokal über Global Reach angekündigt. Sie können SD-WAN oder VPN verwenden, um einen lokalen Routenfilter zu implementieren, der das Lernen von 0.0.0.0/0 Routen verhindert.

• Bestehende VPN-, ExpressRoute- oder VNet-Verbindungen mit dem geschützten Virtual WAN-Hub, die keine Ankündigung von 0.0.0.0/0 benötigen, erhalten die Ankündigung trotzdem. Um diese Aktion zu verhindern, können Sie eine der folgenden Aktionen ausführen:

  • Verwenden Sie ein lokales Edgegerät, um die Route 0.0.0.0/0 herauszufiltern.

  • Deaktivieren Sie die Weitergabe von 0.0.0.0/0 für spezifische Verbindungen.

    1. Trennen Sie die ExpressRoute-, VPN- oder virtuellen Netzwerkverbindungen.
    2. Aktivieren Sie die Weitergabe von 0.0.0.0/0.
    3. Deaktivieren Sie die Weitergabe von 0.0.0.0/0 für diese spezifischen Verbindungen.
    4. Verbinden Sie diese Verbindungen erneut.

• Sie können Application Gateway in einem mit dem Virtual WAN-Hub verbundenen virtuellen Spoke-Netzwerk hosten.

Ermöglichen Sie der Azure VMware-Lösung, den lokalen Datenverkehr über die Azure Firewall zu überprüfen.

Führen Sie die folgenden Schritte aus, um die Azure VMware-Lösung zum Überprüfen des lokalen Datenverkehrs über die Azure-Firewall zu aktivieren:

1. Entfernen Sie die Global Reach-Verbindung zwischen Azure VMware Solution und lokal.
2. Öffnen Sie einen Supportfall mit dem Microsoft-Support, um ExpressRoute-zu-ExpressRoute-Transitkonnektivität über eine Azure Firewall-Appliance im Hub zu aktivieren, die mit privaten Routingrichtlinien konfiguriert ist.

Szenario 2: Ein NVA in Virtual Network überprüft den gesamten Netzwerkdatenverkehr

Dieses Szenario umfasst die folgenden Architekturkomponenten und Überlegungen.

Wann dieses Szenario verwendet werden soll

Verwenden Sie dieses Szenario, wenn:

• Sie müssen Ihre nicht-Microsoft-Firewall-NVAs in einem virtuellen Hubnetzwerk verwenden, um den gesamten Datenverkehr zu prüfen, und Sie können Global Reach aus geopolitischen Gründen oder anderen Gründen nicht nutzen.

  • Sie haben Konnektivität zwischen lokalen Rechenzentren und Azure VMware-Lösung.
  • Sie verfügen über eine Verbindung zwischen virtuellem Netzwerk und Azure VMware-Lösung.
  • Sie benötigen Internetzugriff über die Azure VMware-Lösung.
  • Sie benötigen Internetzugriff auf Azure VMware Solution.

• Sie benötigen eine differenzierte Kontrolle über Firewalls, die sich außerhalb der privaten Azure VMware Solution-Cloud befinden.

• Sie benötigen mehrere öffentliche IP-Adressen für eingehende Dienste und benötigen einen Block vordefinierter IP-Adressen in Azure. In diesem Szenario besitzen Sie keine öffentlichen IP-Adressen.

In diesem Szenario wird davon ausgegangen, dass Sie über ExpressRoute-Konnektivität zwischen lokalen Rechenzentren und Azure verfügen.

Überblick

Das folgende Diagramm bietet eine allgemeine Übersicht über Szenario 2.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Dieses Szenario besteht aus den folgenden Komponenten:

• Nicht-Microsoft-Firewall-NVAs, die in einem virtuellen Netzwerk zur Überprüfung des Datenverkehrs und anderer Netzwerkfunktionen gehostet werden.

• Route Server, um den Datenverkehr zwischen Azure VMware Solution, lokalen Rechenzentren und virtuellen Netzwerken weiterzuleiten.

• Application Gateway zum Bereitstellen des L7 HTTP- oder HTTPS-Lastenausgleichs.

In diesem Szenario müssen Sie expressRoute Global Reach deaktivieren. Die Nicht-Microsoft-NVAs bieten ausgehenden Internetzugriff auf Azure VMware Solution.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Überlegungen

• Konfigurieren Sie ExpressRoute Global Reach für dieses Szenario nicht, da der Datenverkehr der Azure VMware Solution direkt zwischen Microsoft Enterprise Edge (MSEE) ExpressRoute-Routern fließt. Der Datenverkehr überspringt das virtuelle Hubnetzwerk.

• Stellen Sie den Route Server in Ihrem virtuellen Hubnetzwerk bereit. Route Server muss eine BGP-Peerverbindung (Border Gateway Protocol) mit den NVAs im virtuellen Transitnetzwerk haben. Konfigurieren Sie Route Server so, dass die Branch-to-Branch-Konnektivität zulässig ist.

• Verwenden Sie benutzerdefinierte Routingtabellen und benutzerdefinierte Routen, um den Datenverkehr in beide Richtungen zwischen Azure VMware Solution und dem Lastenausgleich der Nicht-Microsoft-Firewall-NVAs weiterzuleiten. Dieses Setup unterstützt alle Hochverfügbarkeitsmodi, einschließlich Aktiv/Aktiv und Aktiv/Standby, und trägt zur Sicherstellung der Routingsymmetrie bei.

• Wenn Sie Hochverfügbarkeit für NVAs benötigen, lesen Sie Ihre NVA-Herstellerdokumentation und stellen Sie hochverfügbare NVAs bereit.

Szenario 3: Ausgehender Datenverkehr aus Azure VMware Solution mit oder ohne NSX-T oder NVAs

Dieses Szenario umfasst die folgenden Architekturkomponenten und Überlegungen.

Wann dieses Szenario verwendet werden soll

Verwenden Sie dieses Szenario, wenn:

• Sie verwenden die native NSX-T Data Center-Plattform, daher benötigen Sie eine PaaS-Bereitstellung (Platform-as-a-Service) für Azure VMware Solution.

• Sie benötigen ein BYOL-NVA (Bring-Your-Own-License) innerhalb von Azure VMware Solution für die Überprüfung des Datenverkehrs.

• Sie benötigen eingehende HTTP-, HTTPS- oder L4-Dienste.

Optional ist bereits ExpressRoute-Konnektivität zwischen den lokalen Rechenzentren und Azure gegeben. Sämtlicher Datenverkehr von Azure VMware Solution zu Virtual Network, von Azure VMware Solution zum Internet und von Azure VMware Solution zu lokalen Rechenzentren wird über die NSX-T Data Center Tier-0- oder Tier-1-Gateways oder die NVAs geleitet.

Überblick

Das folgende Diagramm bietet eine allgemeine Übersicht über Szenario 3.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Dieses Szenario besteht aus den folgenden Komponenten:

• Eine NSX Distributed Firewall oder ein NVA hinter Tier-1 in Azure VMware Solution.
• Application Gateway zum Bereitstellen des L7-Lastenausgleichs.
• L4-DNAT über Azure Firewall.
• Internet-Breakout von Azure VMware Solution.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Überlegungen

• Aktivieren Sie den Internetzugriff im Azure-Portal. In diesem Szenario kann sich eine ausgehende IP-Adresse ändern und ist nicht deterministisch. Öffentliche IP-Adressen befinden sich außerhalb der NVA. Das NVA in Azure VMware Solution umfasst nach wie vor private IP-Adressen und bestimmt nicht die ausgehende öffentliche IP-Adresse.

• Das NVA ist BYOL, was bedeutet, dass Sie eine Lizenz bereitstellen und Hochverfügbarkeit für das NVA implementieren.

• In der VMware-Dokumentation finden Sie NVA-Platzierungsoptionen und Informationen zum VMware-Grenzwert von acht virtuellen Netzwerkschnittstellenkarten auf einem virtuellen Computer. Weitere Informationen finden Sie unter Firewallintegration in Azure VMware Solution.

Szenario 4: Nicht von Microsoft stammende Firewalllösungen in einem virtuellen Hubnetzwerk mit Route Server

Dieses Szenario umfasst die folgenden Architekturkomponenten und Überlegungen.

Wann dieses Szenario verwendet werden soll

Verwenden Sie dieses Szenario, wenn:

• Sie möchten ausgehenden Internetdatenverkehr von Azure VMware Solution über Ihr Nicht-Microsoft-NVA in einem virtuellen Azure-Netzwerkhub aktivieren. Außerdem möchten Sie den Datenverkehr zwischen Azure VMware-Lösung und virtuellem Netzwerk prüfen.

• Sie möchten den Datenverkehr zwischen lokalen Rechenzentren und Azure über Ihr lokales Nicht-Microsoft-NVA überprüfen.

• Sie benötigen mehrere öffentliche IP-Adressen für eingehende Dienste und benötigen einen Block vordefinierter IP-Adressen in Azure. In diesem Szenario besitzen Sie keine öffentlichen IP-Adressen.

• Sie benötigen eine differenzierte Kontrolle über Firewalls außerhalb der privaten Azure VMware Solution-Cloud.

Überblick

Das folgende Diagramm bietet eine allgemeine Übersicht über Szenario 4.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Dieses Szenario besteht aus den folgenden Komponenten:

• Nicht-Microsoft-NVAs, die im Aktiv/Aktiv- oder Aktiv/Standbymodus konfiguriert sind und in einem virtuellen Netzwerk gehostet werden, um Firewall- sowie andere Netzwerkfunktionen auszuführen.

• Route Server zum Austausch von Routen zwischen Azure VMware Solution, lokalen Rechenzentren und virtuellen Netzwerken.

• Nicht-Microsoft-NVAs in Ihrem virtuellen Azure-Netzwerkhub, um ausgehendes Internet für Azure VMware Solution bereitzustellen.

• ExpressRoute für die Konnektivität zwischen lokalen Rechenzentren und Azure VMware-Lösung.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Überlegungen

• In diesem Szenario werden den NVAs im virtuellen Azure-Netzwerk ausgehende öffentliche IP-Adressen zugewiesen.

• Nicht-Microsoft-NVAs im virtuellen Netzwerkhub werden so konfiguriert, dass sie eine Peerverbindung mit dem Routendienst über BGP und Equal-Cost Multi-Path (ECMP)-Routing herstellen. Diese NVAs kündigen die Standardroute0.0.0.0/0 zu Azure VMware Solution an.

• Die Standardroute 0.0.0.0/0 wird auch lokal über Global Reach angekündigt. Implementieren Sie einen Routenfilter vor Ort, um das Lernen der Standardroute 0.0.0.0/0 zu verhindern.

• Datenverkehr zwischen Azure VMware Solution und Ihrem lokalen Netzwerk fließt über ExpressRoute Global Reach. Weitere Informationen finden Sie unter Peering lokaler Umgebungen mit Azure VMware Solution. Das lokale Nicht-Microsoft-NVA überprüft den Datenverkehr zwischen lokalen Systemen und Azure VMware Solution (anstatt der Nicht-Microsoft-NVAs im virtuellen Azure-Netzwerkhub).

• Sie können Application Gateway in einem virtuellen Spoke-Netzwerk hosten, das mit einem Hub verbunden ist oder sich im virtuellen Netzwerk des Hubs befindet.

Nächste Schritte

• Integrieren von Azure VMware Solution in eine Hub-and-Spoke-Architektur

• NSX-Netzwerkkomponenten mit Azure VMware Solution konfigurieren

• Im nächsten Artikel dieser Reihe erfahren Sie mehr über die Architekturprinzipien der Zielzone des Cloud Adoption Framework für Unternehmen, verschiedene Designüberlegungen und Best Practices für Azure VMware Solution:

  Sicherheit, Governance und Compliance für Azure VMware Solution