Freigeben über

Was ist SDN Multisite?

  • Artikel

Gilt für: Azure Stack HCI, Version 23H2

Dieser Artikel bietet eine Übersicht über SDN Multisite, einschließlich seiner Vorteile und aktuellen Einschränkungen. Sie können es als Leitfaden verwenden, um Ihren Netzwerktopologie- und Notfallwiederherstellungsplan zu entwerfen.

Mit SDN Multisite können Sie die Funktionen herkömmlicher SDN in Azure Stack HCI-Clustern 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 Verwalten von SDN Multisite für Azure Stack HCI.

Vorteile

Hier sind die Vorteile der Verwendung von SDN Multisite:

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

Einschränkungen

Das SDN Multisite-Feature hat derzeit einige Einschränkungen:

  • Wird nur zwischen zwei Standorten unterstützt.
  • Standorte müssen über ein privates Netzwerk verbunden sein, da keine Verschlüsselungsunterstützung für Über das Internet verbundene Websites bereitgestellt wird.
  • Der interne Lastenausgleich wird nicht standortübergreifend unterstützt.

Peering für mehrere Standorte

Multisites erfordern Peering zwischen Standorten, das wie das Peering virtueller Netzwerke initiiert wird. Eine Verbindung wird an beiden Standorten automatisch über Windows Admin Center initiiert. Sobald eine Verbindung hergestellt wurde, ist das Peering erfolgreich. Anweisungen zum Einrichten von Peering finden Sie unter Einrichten von Peering.

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

Primäre und sekundäre Standortrollen

In einer SDN-Umgebung mit mehreren Standorten wird ein Standort als primärer und der andere als sekundärer Standort festgelegt. Der primäre Standort übernimmt die Ressourcensynchronisierung. Beim Peering mit mehreren Standorten wird automatisch der primäre Standort ausgewählt, den Sie später mithilfe von Windows Admin Center ändern können.

Ressourcenhandling

  • Wenn der primäre Standort nicht erreichbar ist, können globale Ressourcen und Ressourcen, die eine globale Überprüfung oder globale Kundenadressenzuordnungen 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 erfordern:

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

    Beispiele für globale Zertifizierungsstellenzuordnungen sind:

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

  • Wenn der sekundäre Standort 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 Konnektivität wiederhergestellt ist. Sobald die Konnektivität wiederhergestellt wurde, wird die Synchronisierung fortgesetzt.

  • Wenn der primäre Standort ausfällt, können Sie Ihren sekundären Standort als neuen primären Standort festlegen, um Updates für Ihre Netzwerksicherheitsgruppen und virtuellen Netzwerke durchzuführen. Jede ausstehende Datensynchronisierung vom alten primären Standort geht jedoch verloren. Um dieses Problem zu beheben, wenden Sie dieselben Änderungen am neuen primären Standort an, sobald der alte primäre Standort wieder online ist. Dies kann jedoch auch zu globalen Ca-Zuordnungskonflikten führen.

Ressourcensynchronisierung

Wenn Sie SDN Multisite aktivieren, werden nicht alle Ressourcen von jedem Standort über alle Standorte hinweg synchronisiert. Hier sind die Listen der Ressourcen aufgeführt, die synchronisiert und nicht synchronisiert bleiben.

  • Synchronisierte Ressourcen

    Diese Ressourcen werden nach der Einrichtung des Peerings auf allen Websites synchronisiert. Sie können diese Ressourcen von jedem beliebigen Standort aus aktualisieren, sei es primär oder sekundär. Der primäre Standort ist jedoch dafür verantwortlich, sicherzustellen, dass diese Ressourcen standortübergreifend angewendet und synchronisiert werden. Richtlinien und Anweisungen zum Verwalten dieser Ressourcen bleiben identisch wie in einer SDN-Umgebung mit einem einzelnen Standort.

  • Nicht synchronisierte Ressourcen

    Diese Ressourcen werden nach dem Einrichten des Peerings nicht synchronisiert:

    • Lastenausgleichsrichtlinien.
    • Virtuelle IP-Adressen (VIPs).
    • Gatewayrichtlinien.
    • Logische Netzwerke. Obwohl logische Netzwerke nicht standortübergreifend synchronisiert werden, werden IP-Pools auf Überlappung ü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 wünschen, müssen Sie sie dort manuell erstellen. Wenn sich Ihre Back-End-VMs für Lastenausgleichsrichtlinien an einem einzelnen Standort befinden, funktioniert die Konnektivität über SLB ohne zusätzliche Konfiguration einwandfrei. Wenn Sie jedoch erwarten, dass die Back-End-VMs von einem Standort zum anderen wechseln, funktioniert die Konnektivität standardmäßig nur, wenn sich hinter einer VIP am lokalen Standort Back-End-VMs befinden. Wenn alle Back-End-VMs an einen anderen Standort verschoben werden, schlägt die Konnektivität über diese VIP fehl.

Ost-West-Datenverkehr und Subnetzfreigabe

Multisite ermöglicht es VMs an verschiedenen Standorten mit bereitgestelltem SDN, über dasselbe Subnetz zu kommunizieren, ohne SDN-Gatewayverbindungen einrichten zu müssen. Dies vereinfacht die Netzwerktopologie und reduziert den Bedarf an zusätzlichen VMs und Subnetzen. Der Datenpfad zwischen VMs an verschiedenen Standorten hängt von der zugrunde liegenden physischen Infrastruktur ab.

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

VM-zu-VM-Kommunikation ohne SDN Multisite

Bei 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 herstellen. Außerdem müssen Sie zusätzliche Subnetze für Ihre Anwendungen bereitstellen. Wenn jeder Standort beispielsweise Front-End-Anwendungen hostet, würden Sie separate Subnetzbereiche wie 10.1/16 und 10.6/16 zuordnen. Darüber hinaus müssen Sie beim Einrichten einer Gatewayverbindung zusätzliche VMs für Ihre Gateway-VMs zuweisen und diese anschließend verwalten.

Diagramm zur Darstellung der Kommunikation von VM zu VM zwischen zwei physischen Standorten in einem herkömmlichen SDN-Setup.

VM-zu-VM-Kommunikation mit SDN Multisite

Mit SDN Multisite über zwei physische Standorte hinweg können Sie über native Layer-2-Konnektivität für die kommunikation zwischen Standorten verfügen. Dadurch 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 veranschaulicht, können Front-End-Anwendungen an beiden Standorten dasselbe Subnetz verwenden, z. B. 10.1/16, anstatt zwei separate zu verwalten. Bei diesem Setup hängt der Datenfluss von einer VM zu einer anderen ausschließlich von Ihrer zugrunde liegenden physischen Infrastruktur ab, soweit nicht eine zusätzliche SDN-Gateway-VM durchlaufen werden muss.

Diagramm zur Darstellung der Kommunikation zwischen VM und VM mit SDN Multisite

Software Load Balancer und ihre Einschränkungen

Derzeit sind Software Load Balancer lokale Ressourcen für jeden Ihrer physischen Standorte. Dies bedeutet, dass Richtlinien und Konfigurationen des Lastenausgleichs nicht über mehrere Standorte hinweg 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 anhand eines Beispielszenarios erläutert, das sowohl ohne als auch mit der Migration von Workload-VMs veranschaulicht wird. Angenommen, Sie verfügen über zwei Azure Stack HCI-Cluster mit aktiviertem SDN Multisite, von denen jeweils eine eigene SDN-Infrastruktur bereitgestellt und konfiguriert ist. In diesem Szenario möchte ein Client VM1 mit der IP-Adresse 10.0.0.5 und der VIP-Adresse 11.0.0.5 erreichen.

Lastenausgleich in SDN Multisite ohne Migration von Workload-VMs

Wenn in SDN Multisite keine VM-Migration zwischen Standorten erfolgt, werden Datenpakete wie üblich weitergeleitet, ähnlich wie beim herkömmlichen SDN-Setup. Die folgende Animation veranschaulicht den Datenpfad vom Clientcomputer zu VM1 über SLB MUX1 in Cluster 2.

Animation, die den Lastenausgleich in einer SDN-Umgebung mit mehreren Websites zeigt, ohne Workloads zu migrieren.

Lastenausgleich in SDN Multisite mit migrierenden Workload-VMs

Wenn Sie sich entscheiden, einen virtuellen Computer oder alle VMs hinter der VIP zum anderen Standort zu migrieren, treten möglicherweise Situationen auf, in denen die VM, die Sie erreichen möchten, über die VIP je nach Standort nicht erreichbar ist. Dies liegt daran, dass Lastenausgleichsressourcen für jeden Azure Stack HCI-Cluster lokal sind. Wenn workload-VMs verschoben werden, sind die Konfigurationen auf den MUXes nicht global, sodass der andere Standort migrationen nicht weiß. Die folgende Animation veranschaulicht die Migration von VMs von Cluster 2 zu Cluster 1 und wie der Pfad des Datenpakets nach der Migration fehlschlägt.

Animation, die den Lastenausgleich in einer SDN-Umgebung mit mehreren Websites mit migrationsfähigen Workloads zeigt.

Um diese Einschränkung zu umgehen, können Sie einen externen Lastenausgleich verwenden, der die Verfügbarkeit von Back-End-VMs an jedem Standort überprüft und den Datenverkehr entsprechend weitergibt. Weitere Informationen finden Sie unter Verwenden eines externen Lastenausgleichs in Multisite mit migrierenden Workload-VMs.

Verwenden eines externen Lastenausgleichs in Multisite mit migrierenden Workload-VMs

Sie können einen externen Lastenausgleich aktivieren, um zu überprüfen, ob back-End-VMs hinter einem Lastenausgleich an einem Ihrer Standorte vorhanden sind. Wenn sich hinter einem Lastenausgleich keine Back-End-VMs befinden, wird die VIP für die MUX nicht bis zum externen Lastenausgleich angekündigt, und anschließend schlägt jeder gesendete Integritätstest 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 externen lokalen Softwareausgleichs als Lösung für die Migration von VMs zwischen Standorten in einem Setup mit mehreren Standorten zeigt.

Wenn die Bereitstellung eines externen Lastenausgleichs jedoch nicht möglich ist, verwenden Sie die Softwarelastenausgleichslösung wie unter Lastenausgleich in SDN Multisite ohne Migration von Workload-VMs beschrieben, solange Sie keine migrierenden Workload-VMs haben.

Gateways und ihre Einschränkungen

SDN-Gatewayverbindungen sind auch lokale Ressourcen, die nicht standortübergreifend von Multisite synchronisiert werden. Jeder Standort verfügt über eigene Gateway-VMs und Gatewayverbindungen. Wenn eine Workload-VM erstellt oder zu einem Standort migriert wird, erhält sie eine lokale Gatewaykonfiguration wie Gatewayrouten. Wenn Sie eine Gatewayverbindung für ein bestimmtes virtuelles Netzwerk an einem Standort erstellen, verlieren VMs von diesem Standort aus 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 Multisite für Azure Stack HCI