Freigeben über


Beispielarchitekturen für Azure VMware Solution

Um eine Azure VMware Solution Landezone einzurichten, müssen Sie zunächst Netzwerkfunktionen entwerfen und implementieren. Die Netzwerkprodukte und -dienste von Azure unterstützen eine Vielzahl von Netzwerkszenarien. Wählen Sie eine geeignete Architektur und einen Plan für die Strukturierung von Diensten für Ihre Anforderungen aus, indem Sie die Workloads, Governance und Anforderungen Ihrer Organisation bewerten.

Überprüfen Sie die folgenden Überlegungen und wichtigsten Anforderungen, bevor Sie Ihre Azure VMware Solution Bereitstellungsentscheidung treffen.

  • Anforderungen an den eingehenden Internetdatenverkehr über HTTP/S oder Nicht-HTTP/S in Azure VMware Solution-Anwendungen
  • Überlegungen zu ausgehenden Internetpfaden
  • L2-Erweiterung für Migrationen
  • NVA-Verwendung in der aktuellen Architektur
  • Azure VMware Solution-Konnektivität mit einem standardmäßigen Hub-VNet oder Virtual WAN-Hub
  • Private ExpressRoute-Konnektivität zwischen lokalen Rechenzentren und Azure VMware Solution (und die Frage, ob Sie ExpressRoute Global Reach aktivieren sollten)
  • Anforderungen an die Datenverkehrsuntersuchung für:
    • Eingehender Internetdatenverkehr in Azure VMware Solution-Anwendungen
    • Ausgehender Azure VMware Solution-Zugriff auf das Internet
    • Azure VMware Solution-Zugriff auf lokale Rechenzentren
    • Azure VMware Solution-Zugriff auf Azure Virtual Network
    • Datenverkehr innerhalb der privaten Azure VMware Solution-Cloud

In der folgenden Tabelle werden anhand der Anforderungen der VMware-Lösung zur Überprüfung des Datenverkehrs Empfehlungen und Überlegungen für die gängigsten Netzwerkszenarien gegeben.

Szenario Anforderungen bezüglich der Untersuchung von Datenverkehr Empfohlenes Lösungsdesign Überlegungen
1 – Internet Eingang
- Internet (ausgehend)
Verwenden Sie den geschützten Virtual WAN-Hub mit standardmäßiger Gatewayweitergabe.

Verwenden Sie für HTTP/S-Datenverkehr das Azure Application Gateway. Verwenden Sie Azure Firewall für nicht-HTTP/S-Datenverkehr.

Stellen Sie einen geschützten Virtual WAN-Hub bereit, und aktivieren Sie eine öffentliche IP-Adresse in Azure VMware Solution.
Diese Lösung funktioniert nicht für die lokale Filterung. Global Reach umgeht Virtual WAN-Hubs.
2 – Internet Eingang
– Internet Ausgang
- Lokales Rechenzentrum (eingehend)
- Azure Virtual Network (eingehend)
Verwenden Sie Firewall-NVA-Lösungen von Drittanbietern in Ihrem virtuellen Netzwerk des Hubs mit Azure Route Server.

Deaktivieren Sie Global Reach.

Verwenden Sie für HTTP/S-Datenverkehr das Azure Application Gateway. Verwenden Sie für nicht-HTTP/S-Datenverkehr eine Firewall von Drittanbietern in Azure.
Wählen Sie diese Option aus, wenn Sie Ihre vorhandene NVA verwenden möchten und alle Datenverkehrsüberprüfungen in Ihrem virtuellen Hubnetzwerk zentralisieren möchten.
3 – Internet Eingang
– Internet Ausgang
- Lokales Rechenzentrum (eingehend)
- Azure Virtual Network (eingehend)
Innerhalb von Azure VMware Solution
Verwenden Sie NSX-T Data Center oder eine NVA-Firewall eines Drittanbieters in Azure VMware Solution.

Verwenden Sie Azure Application Gateway für HTTP/S oder Azure Firewall für Nicht-HTTP/S-Datenverkehr.

Stellen Sie den geschützten Virtual WAN-Hub bereit, und aktivieren Sie eine öffentliche IP-Adresse in Azure VMware Solution.
Verwenden Sie diese Option, wenn Sie Datenverkehr von zwei oder mehr privaten Azure VMware Solution-Clouds untersuchen müssen.

Mit dieser Option können Sie NATIVE FEATURES VON XAML-T verwenden. Sie können diese Option auch mit NVAs kombinieren, die auf Azure VMware Solution zwischen L1 und L0 ausgeführt werden.
4 – Internet Eingang
– Internet Ausgang
– Zu lokalem Rechenzentrum
– Azure Virtual Network

Verwenden Sie Firewall-Lösungen von Drittanbietern in einem virtuellen Netzwerk des Hubs mit Azure Route Server.

Verwenden Sie für HTTP- und HTTPS-Datenverkehr Azure Application Gateway. Verwenden Sie für Nicht-HTTP/S-Datenverkehr eine Firewall-NVA von Drittanbietern in Azure.

Verwenden Sie eine lokale Firewall-NVA von Drittanbietern.

Stellen Sie Firewall-Lösungen von Drittanbietern in einem virtuellen Hub-Netzwerk mit Azure Route Server bereit.
Wählen Sie diese Option aus, um die 0.0.0.0/0 Route von einem NVA in Ihrem virtuellen Azure Hub-Netzwerk an eine Azure VMware Solution anzukündigen.

Wichtige Punkte zu den Netzwerkszenarien:

  • Alle Szenarien haben ähnliche Eingangsmuster über Application Gateway und Azure Firewall.
  • Sie können L4-L7-Lastenausgleichs-NVAs in Azure VMware Solution verwenden.
  • Sie können die NSX-T Data Center-Firewall in jedem dieser Szenarien verwenden.

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

Geschützter Virtual WAN-Hub mit standardmäßiger Routenweitergabe

Dieses Szenario umfasst das folgende Kundenprofil und diese Architekturkomponenten und Überlegungen:

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

  • Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure VMware Solution und Azure Virtual Network.
  • 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 und dem Internet.

In diesem Szenario nutzen Sie Azure VMware Solution als PaaS-Angebot (Platform-as-a-Service). In diesem Szenario befinden sich die öffentlichen IP-Adressen nicht in Ihrem Besitz. Fügen Sie bei Bedarf öffentliche eingehende L4- und L7-Dienste hinzu. Optional ist bereits ExpressRoute-Konnektivität zwischen den lokalen Rechenzentren und Azure gegeben.

Allgemeine Übersicht

Das folgende Diagramm bietet einen allgemeinen Überblick über das Szenario.

Diagramm der Übersicht von Szenario 1 mit geschützter Virtual WAN-Hub mit standardmäßiger Routenweitergabe.

Komponenten der Architektur

Implementieren Sie dieses Szenario mit folgenden Komponenten:

  • Azure Firewall im geschützten Virtual WAN-Hub für Firewalls.
  • Azure Application Gateway für einen L7-Lastenausgleich
  • L4-DNAT (Destination Network Address Translation) mit Azure Firewall zum Übersetzen und Filtern des eingehenden Netzwerkdatenverkehrs
  • Ausgehender Internetzugang über Azure Firewall in Ihrem Virtual WAN-Hub.
  • EXR, VPN oder SD-WAN für Konnektivität zwischen lokalen Rechenzentren und Azure VMware Solution.

Diagramm für Szenario 1: Geschützter Virtual WAN-Hub mit Standardroutenweitergabe.

Überlegungen

Wenn Sie keine Ankündigung der Standardroute 0.0.0.0/0 von Azure VMware Solution erhalten möchten, weil sie mit Ihrer bestehenden Umgebung in Konflikt steht, müssen Sie weitere Maßnahmen ergreifen.

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. Implementieren Sie einen lokalen Routenfilter, um das Lernen der Route 0.0.0.0/0 zu verhindern. Vermeiden Sie dieses Problem mithilfe von SD-WAN oder VPN.

Wenn Sie derzeit eine Verbindung zu einer Hub-and-Spoke-Topologie auf der Basis eines virtuellen Netzwerks über ein ExpressRoute-Gateway herstellen, anstatt eine direkte Verbindung herzustellen, wird die Standardroute 0.0.0.0/0 vom virtuellen WAN-Hub zu diesem Gateway weitergeleitet und hat Vorrang vor der in Ihr virtuelles Netzwerk integrierten Internet-Systemroute. Vermeiden Sie dieses Problem, indem Sie in Ihrem virtuellen Netzwerk eine 0.0.0.0/0 benutzerdefinierte Route implementieren, die die erlernte Standardroute außer Kraft setzt.

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 dies zu verhindern, können Sie entweder:

  • Filtern Sie die Route 0.0.0.0/0 mit einem lokalen Edgegerät heraus.
  • Deaktivieren Sie die Weitergabe von 0.0.0.0/0 für spezifische Verbindungen.
    1. Trennen Sie die Verbindung mit ExpressRoute, VPN oder virtuellem Netzwerk.
    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. Stellen Sie die betreffenden Verbindungen erneut her.

Sie können Application Gateway in einem mit dem Hub verbundenen virtuellen Spoke-Netzwerk oder im virtuellen Netzwerk des Hubs hosten.

Virtuelles Netzwerkgerät in Azure Virtual Network für die Untersuchung des gesamten Netzwerkdatenverkehrs

Dieses Szenario umfasst das folgende Kundenprofil und diese Architekturkomponenten und Überlegungen:

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

  • Sie müssen Ihre Firewall-NVAs von Drittanbietern in einem virtuellen Hubnetzwerk verwenden, um den gesamten Datenverkehr zu überprüfen, und Sie können globale Reichweite aus geopolitischen oder anderen Gründen nicht verwenden.
    • Sie befinden sich zwischen lokalen Rechenzentren und der Azure VMware Solution.
    • Sie befinden sich zwischen Azure Virtual Network und der Azure VMware Solution.
    • Sie benötigen einen Interneteingang von Azure VMware Solution.
    • Sie benötigen den Internetausgang für Azure VMware Solution.
  • Sie benötigen eine differenzierte Kontrolle über Firewalls außerhalb der privaten Azure VMware Solution-Cloud.
  • Sie benötigen mehrere öffentliche IP-Adressen für eingehende Dienste und benötigen einen Block vordefinierter IP-Adressen in Azure. In diesem Szenario befinden sich die öffentlichen IP-Adressen nicht in Ihrem Besitz.

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

Allgemeine Übersicht

Das folgende Diagramm bietet einen allgemeinen Überblick über das Szenario.

Diagramm der Übersicht von Szenario 2 mit einer Drittanbieter-NVA im Azure Virtual Network-Hub, die den gesamten Netzwerkdatenverkehr überprüft.

Komponenten der Architektur

Implementieren Sie dieses Szenario mit folgenden Komponenten:

  • Firewall-NVAs von Drittanbietern, die in einem virtuellen Netzwerk zur Überprüfung des Datenverkehrs und anderer Netzwerkfunktionen gehostet werden.
  • Azure Route Server zum Routing des Datenverkehrs zwischen Azure VMware Solution, lokalen Rechenzentren und virtuellen Netzwerken.
  • Application Gateway zum Bereitstellen des L7 HTTP/S-Lastenausgleichs.

In diesem Szenario müssen Sie ExpressRoute Global Reach deaktivieren. Die Drittanbieter-NVAs sind für die Bereitstellung des ausgehenden Internetzugriffs für Azure VMware Solution verantwortlich.

Diagramm für Szenario 2: Drittanbieter-NVA in einem virtuellen Azure-Hubnetzwerk, die den gesamten Netzwerkdatenverkehr überprüft

Überlegungen

  • Konfigurieren Sie expressRoute Global Reach für dieses Szenario nie, da sie Azure VMware Solution Datenverkehrsfluss direkt zwischen Microsoft Enterprise Edge (MSEE) ExpressRoute-Routern ermöglicht, um das virtuelle Hubnetzwerk zu überspringen.
  • Azure Route Server muss in Ihrem Hub-VNet bereitgestellt werden und BGP-peered mit den NVAs im Transit-VNet sein. Konfigurieren Sie Azure Route Server so, dass die Verzweigungs-zu-Verzweigungskonnektivität zulässig ist.
  • Mithilfe von benutzerdefinierten Routingtabellen und benutzerdefinierten Routen wird Datenverkehr an/von Azure VMware Solution an das Lastenausgleichsmodul der NVAs von Drittanbietern weitergeleitet. Alle HA-Modi (aktiv/aktiv und aktiv/standby) werden unterstützt, mit garantierter Routingsymmetrie.
  • Wenn Sie eine hohe Verfügbarkeit für NVAs benötigen, lesen Sie Ihre NVA-Herstellerdokumentation und stellen Sie hochverfügbare NVAs bereit.

Ausgehender Datenfluss aus Azure VMware Solution mit oder ohne NSX-T oder NVA

Dieses Szenario umfasst das folgende Kundenprofil und diese Architekturkomponenten und Überlegungen:

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

  • Sie müssen die native NSX-T Data Center-Plattform verwenden, daher benötigen Sie eine PaaS-Bereitstellung für Azure VMware Solution.
  • Alternativ benötigen Sie ein BYOL-NVA (Bring-Your-Own-License) innerhalb von Azure VMware Solution für die Überprüfung des Datenverkehrs.
  • Optional ist bereits ExpressRoute-Konnektivität zwischen den lokalen Rechenzentren und Azure gegeben.
  • Sie benötigen eingehende HTTP/S- oder L4-Dienste.

Der gesamte Datenverkehr von Azure VMware Solution zu Azure Virtual Network, von Azure VMware Solution zum Internet und von Azure VMware Solution zu lokalen Rechenzentren wird durch die Tier-0-/Tier-1-Gateways von NSX-T Data Center oder die NVAs geleitet.

Allgemeine Übersicht

Das folgende Diagramm bietet einen allgemeinen Überblick über das Szenario.

Diagramm mit einem Überblick über das Szenario 3 mit ausgehendem Datenverkehr aus der Azure-VMware-Lösung mit oder ohne NSX-T Data Center oder NVA.

Komponenten der Architektur

Implementieren Sie dieses Szenario mit folgenden Komponenten:

  • Eine NSX Distributed Firewall (DFW) oder eine NVA hinter Tier-1 in Azure VMware Solution
  • Application Gateway zum Bereitstellen des L7-Lastenausgleichs.
  • L4-DNAT mit Verwendung von Azure Firewall.
  • Internet-Breakout von Azure VMware Solution.

Diagramm zu Szenario 3: Ausgehender Datenfluss aus Azure VMware Solution mit oder ohne NSX-T-Rechenzentrum oder NVA

Überlegungen

Aktivieren Sie den Internetzugriff im Azure-Portal. Bei diesem Design kann sich die ausgehende IP-Adresse ändern und ist nicht deterministisch. Öffentliche IP-Adressen befinden sich außerhalb des 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. Es liegt in Ihrer Verantwortung, die Lizenz bereitzustellen und Hochverfügbarkeit für das NVA zu implementieren.

In der VMware-Dokumentation finden Sie Optionen für die NVA-Platzierung und Informationen über die VMware-Beschränkung auf bis zu acht virtuelle Netzwerkschnittstellenkarten (NICs) für eine VM. Weitere Informationen finden Sie unter Firewallintegration in Azure VMware Solution.

Firewall-Lösungen von Drittanbietern in einem virtuellen Netzwerk des Hubs mit Azure Route Server

Dieses Szenario umfasst das folgende Kundenprofil und diese Architekturkomponenten und Überlegungen:

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

  • Sie möchten Azure VMware Solution Internetausgang mit Ihrem Drittanbieter-NVA im Azure VNet-Hub ausführen und den Datenverkehr zwischen Azure VMware Solution und Azure Virtual Network überprüfen.
  • Sie möchten den Datenverkehr zwischen lokalen Rechenzentren und Azure mithilfe Ihrer lokalen 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 befinden sich die öffentlichen IP-Adressen nicht in Ihrem Besitz.
  • Sie benötigen eine differenzierte Kontrolle über Firewalls außerhalb der privaten Azure VMware Solution-Cloud.

Allgemeine Übersicht

Das folgende Diagramm bietet einen allgemeinen Überblick über das Szenario.

Diagramm mit einem Überblick über das Szenario 4 mit einer Drittanbieter-NVA im V Net-Hub, die den Datenverkehr zwischen der Azure-VMware-Lösung und dem Internet sowie zwischen der Azure-VMware-Lösung und Azure Virtual Network überprüft.

Komponenten der Architektur

Implementieren Sie dieses Szenario mit folgenden Komponenten:

  • NVAs von Drittanbietern, die aktiv-aktiv oder aktiv-standby in einem VNet für Firewalls und andere Netzwerkfunktionen gehostet werden.
  • Azure Route Server zum Austausch von Routen zwischen Azure VMware Solution, lokalen Rechenzentren und virtuellen Netzwerken.
  • Ihre NVAs von Drittanbietern in Ihrem Azure Virtual Network Hub, um ausgehendes Internet für Azure VMware Solution bereitzustellen.
  • ExpressRoute für Konnektivität zwischen lokalen Rechenzentren und Azure VMware Solution.

Diagramm des Szenarios 4 mit einer Drittanbieter-NVA im V Net-Hub, die den Datenverkehr zwischen der Azure-VMware-Lösung und dem Internet sowie zwischen der Azure-VMware-Lösung und Azure Virtual Network überprüft.

Überlegungen

  • In diesem Entwurf befinden sich ausgehende öffentliche IP-Adressen mit NVAs im Azure VNet.
  • NVAs von Drittanbietern im virtuellen Netzwerkknotenpunkt BGP werden mit Azure Route Server (ECMP) abgeglichen und werben für die Standardroute) 0.0.0.0/0 zu Azure VMware Solution.
  • Die Standardroute 0.0.0.0/0 wird auch lokal über Global Reach angekündigt. Implementieren Sie einen lokalen Routenfilter, um das Lernen der Standardroute 0.0.0.0/0 zu verhindern.
  • Der Datenverkehr zwischen Azure VMware Solution und Ihrem lokalen Netzwerk findet in der Regel über ExpressRoute Global Reach statt, wie unter Peering lokaler Umgebungen mit Azure VMware Solution beschrieben. Die Datenverkehrsüberprüfung zwischen lokalen und Azure VMware Solution wird von Ihrem lokalen Drittanbieter-NVA ausgeführt, nicht von Ihren NVAs von Drittanbietern in Azure Virtual Network Hub.
  • Sie können Application Gateway in einem mit dem Hub verbundenen virtuellen Spoke-Netzwerk oder im virtuellen Netzwerk des Hubs hosten.

Nächste Schritte