Lift-and-Shift-Netzwerkentwurfspfad

Dieses Handbuch bietet einen sequenzierten Lesepfad durch den Azure Netzwerkentwurfsleitfaden für Kunden, die lokale Workloads zu Azure Infrastructure as a Service (IaaS) migrieren, ohne anwendungen neu zu entwerfen. Führen Sie die nummerierten Schritte aus, um Ihr Netzwerk von Grund auf neu zu erstellen, und treffen Sie die richtigen Entscheidungen in jeder Phase.

Overview

Eine Lift-and-Shift-Migration verschiebt vorhandene lokale Workloads in Azure virtuelle Computer (VMs) mit minimalen Änderungen an der Anwendungsarchitektur. Ihre Anwendungen behalten ihre vorhandenen Kommunikationsmuster, Abhängigkeiten und Konfigurationen bei. Das Netzwerk, das Sie in Azure erstellen, muss diese vorhandenen Muster unterstützen und gleichzeitig Azure systemeigene Sicherheits- und Konnektivitätsdienste nutzen.

Ihre Zielarchitektur ist eine Hub-and-Spoke-Topologie mit zentralisierten gemeinsamen Diensten. Ein einzelnes virtuelles Hubnetzwerk (Virtual Network, VNet) hostet Ihre VPN Gateway- oder ExpressRoute-Verbindung zurück zur lokalen Umgebung, Azure Bastion für den sicheren VM-Zugriff, Azure Firewall für die zentrale Datenverkehrsüberprüfung und DNS-Weiterleitung. Spoke-VNetze beherbergen Ihre migrierten Workload-VMs, die standardmäßig voneinander isoliert und für die Kommunikation zwischen Workloads über den Hub verbunden sind.

Dieser Lesepfad führt Sie durch 10 wichtige Artikel in fünf Phasen. Jeder Artikel baut auf den Entscheidungen auf, die Sie im vorherigen Schritt getroffen haben. Am Ende verfügen Sie über ein produktionsreifes Netzwerkdesign, das Ihre migrierten Workloads durch mehrschichtige Sicherheit und Konnektivität unterstützt.

Voraussetzungen

• Lesen Sie die Übersicht über die Azure-Netzwerkplanung und den Entwurf, um sich über verfügbare Dienste und den Aufbau des Leitfadens zu orientieren.
• Füllen Sie einen Bestand Ihres vorhandenen lokalen Netzwerks aus: IP-Bereiche, Subnetze, Firewallregeln, DNS-Zonen und Datenverkehrsflüsse zwischen Anwendungen (Sie verweisen auf diesen Bestand in den grundlegenden Artikeln: VNets und Subnetzen, IP-Adressplanung und NSG-Konfiguration).
• Ermitteln Sie, welche Workloads Sie zuerst migrieren möchten. Beginnen Sie mit einer Pilotgruppe, bevor Sie Ihren vollständigen Nachlass migrieren.
• Dokumentieren Sie Ihre lokalen Konnektivitätsanforderungen: Bandbreite für Azure, Latenzempfindlichkeit und Failovererwartungen.

Ihr Lesepfad

Arbeiten Sie in dieser Reihenfolge durch diese Phasen. Jede Phase baut auf den Entscheidungen aus dem vorherigen auf.

Phase 1: Stiftungen

Beginnen Sie mit den drei grundlegenden Artikeln. Diese Entscheidungen gestalten alles, was folgt.

1. Virtuelle Netzwerke und Subnetze

Erstellen Sie das VNet, das Ihre migrierten virtuellen Computer hosten soll. Ordnen Sie Ihre vorhandenen Netzwerksegmente Azure Subnetzen zu. Konzentrieren Sie sich auf die Grenzen der Subnetzisolierung: welche Arbeitslasten sich ein Subnetz teilen, welche ein eigenes Subnetz benötigen und wie viele IP-Adressen jedes Subnetz auf Grundlage Ihrer VM-Anzahl benötigt.

2. IP-Adressplanung

Vermeiden Sie IP-Überlappungen mit Ihrer lokalen Umgebung. Verwenden Sie einen /16 Classless Inter-Domain Routingpool (CIDR) pro VNet, um Platz für Wachstum zu lassen. Wenn sich Ihre lokalen Adressbereiche mit den von Azure reservierten Adressen oder mit den Adressbereichen anderer Azure-Abonnements überschneiden, planen Sie vor der Migration eine Strategie zur Neuadressierung.

3. Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen

Spiegeln Sie Ihre vorhandenen Firewallregeln als Netzwerksicherheitsgruppen (Network Security Groups, NSGs) wieder. Übersetzen Sie Ihre lokalen Zugriffssteuerungslisten (Access Control Lists, ACLs) in NSG-Regeln mit einem Standardablehnungsstatus. Verwenden Sie Anwendungssicherheitsgruppen (APPLICATION Security Groups, ASGs), um VMs nach Rolle zu gruppieren, anstatt einzelne IP-Adressen zu verwalten.

Phase 2: Topologie

4. Hub-and-Spoke-Topologie

Hub-and-Spoke ist die Standardtopologie für Lift-and-Shift-Migrationen mit mehreren Workloads. Platzieren Sie gemeinsame Dienste im Hub-VNet: VPN Gateway, Azure Bastion, Azure Firewall und DNS-Weiterleitungen. Jeder Workload erhält ein eigenes Spoke-VNet, das mit dem Hub per Peering verbunden ist. Spokes kommunizieren über die Hub-Firewall, wodurch Sie den Datenverkehr zentral steuern können.

Phase 3: Konnektivität

5. Hybridkonnektivität

Das VPN Gateway oder Azure ExpressRoute zu Ihrer lokalen Umgebung ist Ihre kritischste Abhängigkeit für die Migration. Ohne diese Verbindung können migrierte VMs keine lokalen Dienste erreichen, von deren Abhängigkeit sie abhängen, und Ihre Benutzer können keine migrierten Anwendungen erreichen. Bemessen Sie die Bandbreite Ihres Gateways anhand der Datenverkehrsmuster, die Sie in Ihrem Inventar dokumentiert haben.

6. Entwickler- und Administratorzugriff

Azure Bastion bietet sicheren Remotedesktop Protocol (RDP) und Secure Shell (SSH)-Zugriff auf Ihre migrierten VMs, ohne sie für das öffentliche Internet verfügbar zu machen. Stellen Sie Bastion im Hub-VNet bereit, damit alle Speichen einen einzigen Zugriffspunkt gemeinsam nutzen. Ersetzen Sie Ihre vorhandene Jump-Box-Infrastruktur durch diesen verwalteten Service.

Phase 4: Sicherheit

7. DNS-Sicherheit und Auflösung privater Namen

Bewahren Sie ihr älteres DNS-Benennungsverhalten während der Migration auf. Ihre migrierten virtuellen Maschinen müssen Hostnamen der lokalen Infrastruktur auflösen, und lokale Systeme müssen in Azure gehostete Namen auflösen. Konfigurieren Sie Azure DNS Private Resolver für die bidirektionale Weiterleitung. Bewahren Sie Ihre vorhandenen DNS-Benennungskonventionen auf, um die Neukonfiguration der Anwendung zu vermeiden.

8. Ausgehender Internetzugriff

Zentralisieren Sie den gesamten ausgehenden Internetdatenverkehr über die Hubfirewall. Deaktivieren Sie den standardmäßigen Zugriff nach außen für Ihre Spoke-VNets, und leiten Sie den ausgehenden Datenverkehr mithilfe benutzerdefinierter Routen (UDRs) über Azure Firewall. Dieser Ansatz spiegelt Ihr vorhandenes lokales Modell wieder, bei dem eine Umkreisfirewall den gesamten internetgebundenen Datenverkehr steuert.

9. Azure Firewall

Stellen Sie Azure Firewall im Hub-VNet zur zentralen Steuerung des Ost-West-Datenverkehrs (zwischen den Spokes) und des ausgehenden Nord-Süd-Datenverkehrs bereit. Übersetzen Sie Ihre lokalen Firewallrichtlinien in Azure Firewall Regeln. Verwenden Sie Netzwerkregeln für Nicht-HTTP-Datenverkehr und Anwendungsregeln zum Filtern von HTTP/HTTPS-Datenverkehr mit vollqualifizierten Domänennamen (FQDNs) als Ziel.

Phase 5: Vorgänge

10. Netzwerküberwachung und Observierbarkeit

Richten Sie Azure Network Watcher und Verbindungsmonitor ein, um Ihren Migrationsbasisplan zu überprüfen. Stellen Sie sicher, dass Verbindungspfade wie erwartet funktionieren. Messen Sie die Latenz zwischen Azure VMs und lokalen Systemen, und richten Sie Leistungsvergleiche ein, bevor Sie Produktionsworkloads migrieren.

Bedingte Artikel

Nicht jede Lift-and-Shift-Migration erfordert dieselbe Artikelauswahl. Fügen Sie diese Artikel basierend auf Ihren spezifischen Anforderungen ein:

Zusammenfassung

Wenn Sie diesem Lesepfad gefolgt sind, haben Sie ein Hub-and-Spoke-Netzwerk mit zentralisierten freigegebenen Diensten entworfen, eine VPN- oder ExpressRoute-Konnektivität zurück zur lokalen Umgebung eingerichtet, Azure Firewall für die zentrale Inspektion des Datenverkehrs bereitgestellt, die DNS-Weiterleitung für die Namensauflösung konfiguriert, den VM-Zugriff über Azure Bastion abgesichert und die Überwachung zur Validierung Ihrer Migration eingerichtet. Diese Architektur unterstützt Ihre migrierten Workloads und bietet Ihnen dabei eine zentrale Sicherheit und betriebliche Sichtbarkeit.

Nächste Schritte

• Migrieren und Modernisieren des Netzwerkpfads: Wenn Ihre nächste Phase die Einführung von PaaS-Diensten oder -Containern umfasst
• Entwurfsphasen auf einen Blick: Für die allgemeine phasenbasierte Zusammenfassung des Azure Netzwerkdesigns
• Azure Netzwerkplan und Designübersicht: Zur funktionsbasierten Erkundung aller verfügbaren Dienste