Freigeben über

Was ist SDN Multisite?

  • Artikel

Gilt für: Azure Local, Version 23H2

Gilt für: Windows Server 2025

Dieser Artikel enthält eine Übersicht über SDN Multisite, einschließlich seiner Vorteile und aktuellen Einschränkungen. Sie können es als Leitfaden zum Entwerfen Ihrer Netzwerktopologie und ihres Notfallwiederherstellungsplans verwenden.

SDN Multisite ermöglicht es Ihnen, die Funktionen herkömmlicher SDN zu erweitern, die an verschiedenen physischen Standorten bereitgestellt werden. SDN Multisite ermöglicht native Layer 2- und Layer 3-Konnektivität an verschiedenen physischen Standorten für virtualisierte Workloads. In diesem Artikel bedeuten alle Verweise auf Websites physische Standorte.

Informationen zum Verwalten von SDN Multisite finden Sie unter Manage SDN Multisite for Azure Local.

Informationen zum Verwalten von SDN Multisite finden Sie unter Manage SDN Multisite for Azure Local.

Vorteile

Hier sind die Vorteile der Verwendung von SDN Multisite:

  • Einheitliches Richtlinienverwaltungssystem. Mit freigegebenen virtuellen Netzwerken und Richtlinienkonfigurationen können Sie Ihre multisite-Netzwerke von jedem Standort aus verwalten und konfigurieren.
  • Nahtlose Arbeitsauslastungsmigration. Migrieren Sie Workloads nahtlos über physische Standorte hinweg, ohne IP-Adressen neu konfigurieren zu müssen oder bereits vorhandene Netzwerksicherheitsgruppen (Network Security Groups, NSGs) vorhanden zu müssen.
  • Automatische Reichweite für neue VMs. Erhalten Sie die automatische Erreichbarkeit für neu erstellte virtuelle Computer (VMs) in virtuellen Netzwerken sowie die automatische Verwaltbarkeit für alle zugehörigen NSGs an ihren physischen Standorten.

Begrenzungen

Das Feature für mehrere Standorte für SDN weist derzeit einige Einschränkungen auf:

  • Wird nur zwischen zwei Websites unterstützt.
  • Websites müssen über ein privates Netzwerk verbunden sein, da die Verschlüsselungsunterstützung für Websites, die über das Internet verbunden sind, nicht bereitgestellt wird.
  • Interner Lastenausgleich wird nicht standortübergreifend unterstützt.

Peering für mehrere Standorte

Mehrere Standorte erfordern Peering zwischen Standorten, die wie virtuelles Netzwerk-Peering initiiert werden. Eine Verbindung wird automatisch über Windows Admin Center auf beiden Websites initiiert. Nachdem eine Verbindung hergestellt wurde, wird Peering erfolgreich. Anweisungen zum Einrichten von Peering finden Sie unter Einrichten von Peering.

Mehrere Standorte erfordern Peering zwischen Standorten, die wie virtuelles Netzwerk-Peering initiiert werden. Eine Verbindung wird automatisch über Windows Admin Center auf beiden Websites initiiert. Sobald eine Verbindung hergestellt wurde, wird Peering erfolgreich. Anweisungen zum Einrichten von Peering finden Sie unter Einrichten von Peering.

In den folgenden Abschnitten werden die Rollen der einzelnen Websites in einer Umgebung mit mehreren Standorten sowie die Behandlung und Synchronisierung von Ressourcen zwischen Websites beschrieben.

Primäre und sekundäre Websiterollen

In einer multisite-SDN-Umgebung wird ein Standort als primär und als sekundär festgelegt. Der primäre Standort behandelt die Ressourcensynchronisierung. Während des Multisite-Peerings wird die primäre Website automatisch ausgewählt, die Sie später mithilfe von Windows Admin Center ändern können.

Ressourcenbehandlung

  • Wenn der primäre Standort nicht erreichbar ist, können globale Ressourcen und Ressourcen, die globale Validierung oder globale Kundenadressenzuweisungen erfordern, nicht über den sekundären Standort aktualisiert werden. Andere lokale Ressourcen können jedoch über den sekundären Standort aktualisiert werden.

    Beispiele für Ressourcen, die eine globale Validierung benötigen, sind:

    • MAC-Pools.
    • Logischer Netzwerk-/IP-Pool.

    Beispiele für globale Zertifizierungsstellenzuweisungen sind:

    • Interner Lastenausgleich für virtuelle Subnetze. Derzeit wird dies nicht über mehrere Standorte unterstützt.
    • Gatewayverbindungen für virtuelle Subnetze.

  • Wenn die sekundäre Website nicht erreichbar ist, können Ressourcen über den primären Standort aktualisiert werden. Der sekundäre Standort verfügt jedoch möglicherweise über veraltete Ressourcen, bis die Verbindung wiederhergestellt wird. Sobald die Verbindung wiederhergestellt wurde, wird die Synchronisierung fortgesetzt.

  • Wenn der primäre Standort nicht mehr vorhanden ist, können Sie Den sekundären Standort als neuen primären Standort festlegen, um Updates für Ihre Netzwerksicherheitsgruppen und virtuellen Netzwerke durchzuführen. Allerdings gehen alle ausstehenden Datensynchronisierungen vom alten primären Standort verloren. Um dieses Problem zu beheben, wenden Sie dieselben Änderungen auf dem neuen primären Standort an, sobald die alte primäre Website wieder online ist. Sie kann jedoch auch zu globalen Zuordnungskonflikten der Zertifizierungsstelle führen.

Ressourcensynchronisierung

Wenn Sie SDN Multisite aktivieren, werden nicht alle Ressourcen von jedem Standort auf allen Websites synchronisiert. Hier sind die Listen der Ressourcen, die synchronisiert werden und die nicht synchronisiert bleiben.

  • Synchronisierte Ressourcen

    Diese Ressourcen werden nach der Einrichtung von Peering auf allen Websites synchronisiert. Sie können diese Ressourcen von jedem Standort aus aktualisieren, sei es primär oder sekundär. Die primäre Website ist jedoch dafür verantwortlich, sicherzustellen, dass diese Ressourcen auf Websites angewendet und synchronisiert werden. Richtlinien und Anweisungen für die Verwaltung dieser Ressourcen bleiben in einer SDN-Umgebung mit nur einem Standort identisch.

  • Synchronisierte Ressourcen

    Diese Ressourcen werden nach der Einrichtung von Peering auf allen Websites synchronisiert. Sie können diese Ressourcen von jedem Standort aus aktualisieren, sei es primär oder sekundär. Die primäre Website ist jedoch dafür verantwortlich, sicherzustellen, dass diese Ressourcen auf Websites angewendet und synchronisiert werden. Richtlinien und Anweisungen für die Verwaltung dieser Ressourcen bleiben in einer SDN-Umgebung mit nur einem Standort identisch.

  • Nicht synchronisierte Ressourcen

    Diese Ressourcen werden nach dem Herstellen von Peering nicht synchronisiert:

    • Lastenausgleichsrichtlinien.
    • Virtuelle IP-Adressen (VIPs).
    • Gatewayrichtlinien.
    • Logische Netzwerke. Obwohl logische Netzwerke nicht über Standorte hinweg synchronisiert werden, werden IP-Pools auf Überlappungen überprüft und diese Überlappung ist nicht zulässig.

    Diese Richtlinien werden auf der lokalen Website erstellt, und wenn Sie dieselben Richtlinien auf der anderen Website verwenden möchten, müssen Sie sie dort manuell erstellen. Wenn sich Ihre Back-End-VMs für Lastenausgleichsrichtlinien auf einem einzelnen Standort befinden, funktioniert die Konnektivität über SLB ohne zusätzliche Konfiguration einwandfrei. Wenn Sie jedoch davon ausgehen, dass die Back-End-VMs von einer Website zur anderen wechseln, funktioniert die Konnektivität standardmäßig nur, wenn back-End-VMs hinter einer VIP auf der lokalen Website vorhanden sind. Wenn alle Back-End-VMs an einen anderen Standort verschoben werden, schlägt die Konnektivität über diese VIP fehl.

Ost-West-Datenverkehrsfluss und Subnetzfreigabe

Multisite ermöglicht VMs an verschiedenen Standorten mit SDN,die für die Kommunikation über dasselbe Subnetz bereitgestellt werden, ohne SDN-Gatewayverbindungen einrichten zu müssen. Dies vereinfacht die Netzwerktopologie und reduziert die Notwendigkeit weiterer VMs und Subnetze. Der Datenpfad zwischen virtuellen Computern auf verschiedenen Standorten basiert auf der zugrunde liegenden physischen Infrastruktur.

In den folgenden Szenarien wird verglichen, wie die VM-Kommunikation zwischen zwei physischen Standorten in einem herkömmlichen SDN-Setup und in einem SDN Multisite-Setup hergestellt wird.

VM-zu-VM-Kommunikation ohne SDN Multisite

In einer herkömmlichen Einrichtung mit SDN, die an zwei physischen Standorten bereitgestellt wird, müssen Sie eine L3- oder GRE-Gatewayverbindung für die standortübergreifende Kommunikation einrichten. Sie müssen auch weitere Subnetze für Ihre Anwendungen bereitstellen. Wenn z. B. alle Standorte Frontend-Anwendungen hosten, weisen Sie separate Subnetzbereiche wie 10.1/16 und 10.6/16 zu. Darüber hinaus müssen Sie, wenn Sie eine Gatewayverbindung einrichten, weitere VMs für Ihre Gateway-VMs zuweisen und diese anschließend verwalten.

Diagramm zum Anzeigen der VM-Zu-VM-Kommunikation zwischen zwei physischen Standorten in einem herkömmlichen SDN-Setup.

VM-zu-VM-Kommunikation mit SDN Multisite

Mit SDN Multisites an zwei physischen Standorten können Sie systemeigene Layer 2-Konnektivität für die standortübergreifende Kommunikation haben. Auf diese Weise können Sie über einen einzelnen Subnetzbereich für Ihre Anwendungen verfügen, die sich über beide Standorte erstrecken, sodass keine SDN-Gatewayverbindung eingerichtet werden muss. Wie im folgenden Diagramm dargestellt, können Front-End-Anwendungen an beiden Standorten dasselbe Subnetz wie 10.1/16 verwenden, anstatt zwei separate zu verwalten. Bei dieser Einrichtung basiert der Datenfluss von einem virtuellen Computer zu einem anderen ausschließlich auf Ihrer zugrunde liegenden physischen Infrastruktur und vermeidet die Notwendigkeit, eine andere SDN-Gateway-VM zu durchlaufen.

Diagramm zum Anzeigen der VM-zu-VM-Kommunikation mit SDN Multisite.

Softwarelastenausgleichsgeräte und deren Einschränkungen

Derzeit sind Softwarelastenausgleichsgeräte lokale Ressourcen für jeden Ihrer physischen Websites. Dies bedeutet, dass Lastenausgleichsrichtlinien und -konfigurationen nicht über mehrere Standorte synchronisiert werden. Beachten Sie dies beim Migrieren von VMs von einem Standort zu einem anderen in einem SDN Multisite-Setup.

Lastenausgleich in SDN Multisite: Beispielszenario

In den folgenden Abschnitten wird der Lastenausgleich in multisite durch ein Beispielszenario erläutert, in dem sowohl ohne als auch mit der Migration von Workload-VMs veranschaulicht wird. Angenommen, Sie verfügen über zwei lokale Azure-Instanzen mit aktivierter SDN Multisite, wobei jeweils eine eigene SDN-Infrastruktur bereitgestellt und konfiguriert ist. In diesem Szenario möchte ein Client VM1 mit IP-Adresse 10.0.0.5 und VIP von 11.0.0.5 erreichen.

Lastenausgleich in SDN Multisites ohne Migration von Workload-VMs

Wenn in SDN Multisite keine VM-Migration zwischen Speicherorten vorhanden ist, werden Datenpakete wie gewohnt weitergeleitet, ähnlich wie bei der herkömmlichen SDN-Einrichtung. Die folgende Animation veranschaulicht den Datenpfad vom Clientcomputer zu VM1 über SLB MUX1 in Cluster 2.

Animation, die den Lastenausgleich in einer SDN Multisite-Umgebung ohne Migration von Workloads zeigt.

Lastenausgleich in SDN Multisites mit Migrieren von Workload-VMs

Wenn Sie sich entscheiden, einen virtuellen Computer oder alle virtuellen Computer hinter der VIP zu dem anderen Standort zu migrieren, können Sie situationen auftreten, in denen der virtuelle Computer, den Sie erreichen möchten, je nach Standort nicht erreichbar ist. Dies geschieht, da Lastenausgleichsressourcen für jede lokale Azure-Instanz lokal sind. Während VMs für Arbeitsauslastungen verschoben werden, sind die Konfigurationen für die MUXes nicht global, sodass der andere Standort nicht über Migrationen weiß. Die folgende Animation veranschaulicht die VMs-Migration von Cluster 2 zu Cluster 1 und wie der Pfad des Datenpakets nach der Migration fehlschlägt.

Animation, die den Lastenausgleich in einer SDN Multisite-Umgebung mit Migration von Workloads zeigt.

Um diese Einschränkung zu umgehen, können Sie den externen Lastenausgleich verwenden, der die Verfügbarkeit von Back-End-VMs auf den einzelnen Websites überprüft und den Datenverkehr entsprechend leitet. Weitere Informationen finden Sie unter Verwenden des externen Lastenausgleichs auf mehreren Websites mit der Migration von Workload-VMs.

Verwenden des externen Lastenausgleichs in multisites beim Migrieren von Workload-VMs

Sie können einen externen Lastenausgleich aktivieren, um zu überprüfen, ob back-End-VMs hinter einem Lastenausgleich auf einem Ihrer Websites vorhanden sind. Wenn keine Back-End-VMs hinter einem Lastenausgleichsmodul vorhanden sind, wird die VIP für die MUX nicht bis zum externen Lastenausgleich angekündigt, und alle gesendeten Integritätssonden schlagen fehl. Dieser externe Lastenausgleich stellt die Konnektivität mit Workloads sicher, auch wenn VMs von einem Standort zu einem anderen wechseln.

Diagramm, das die Verwendung eines lokalen Balancers für externe Software als Lösung zum Migrieren von virtuellen Computern zwischen Websites in einem Multisite-Setup zeigt.

Wenn die Bereitstellung eines externen Lastenausgleichs jedoch nicht machbar ist, verwenden Sie die Softwarelastenausgleichslösung, wie im Lastenausgleich in SDN Multisite beschrieben, ohne Workload-VMs zu migrieren, solange Keine Migration von Workload-VMs vorhanden ist.

Gateways und deren Einschränkungen

SDN multisite synchronisiert keine lokalen Ressourcen wie Gatewayverbindungen über Standorte hinweg. Jeder Standort verfügt über eigene Gateway-VMs und Gatewayverbindungen. Wenn eine Workload-VM erstellt oder zu einem Standort migriert wird, wird die lokale Gatewaykonfiguration wie Gatewayrouten abgerufen. Wenn Sie eine Gatewayverbindung für ein bestimmtes virtuelles Netzwerk an einem Standort erstellen, verlieren VMs von diesem Standort bei der Migration zum anderen Standort die Gatewaykonnektivität. Damit VMs die Gatewaykonnektivität bei der Migration beibehalten können, müssen Sie eine separate Gatewayverbindung für dasselbe virtuelle Netzwerk am anderen Standort konfigurieren.

Nächste Schritte

Verwalten von SDN Multisites für Azure Local

Verwalten von SDN Multisites für Azure Local