Freigeben über

Migrieren einer SQL Server-Verfügbarkeitsgruppe zu mehreren Subnetzen: SQL Server auf Azure-VMs

  • Artikel

Gilt für: SQL Server auf Azure-VMs

In diesem Artikel erfahren Sie, wie Sie Ihre Always On-Verfügbarkeitsgruppe von einem einzelnen Subnetz zu mehreren Subnetzen migrieren, um die Verbindung Ihres Listeners in Azure mit Ihrem SQL Server auf Azure-VMs zu vereinfachen.

Tipp

Es gibt viele Methoden zum Bereitstellen einer Verfügbarkeitsgruppe. Vereinfachen Sie Ihre Bereitstellung, indem Sie Ihre SQL Server-VMs in mehreren Subnetzen innerhalb desselben virtuellen Azure-Netzwerks erstellen. So benötigen Sie weder eine Azure Load Balancer-Instanz noch einen verteilten Netzwerknamen (DNN) für Ihre Always On-Verfügbarkeitsgruppe. Wenn Sie Ihre Verfügbarkeitsgruppe bereits in einem einzelnen Subnetz erstellt haben, können Sie sie in eine Umgebung mit mehreren Subnetzen migrieren.

Übersicht

Kund*innen, die SQL Server auf Azure-VMs ausführen, können eine Always On-Verfügbarkeitsgruppe entweder in einem einzelnen Subnetz oder in mehreren Subnetzen (Multisubnetz) implementieren. Eine Konfiguration mit mehreren Subnetzen vereinfacht die Umgebung der Verfügbarkeitsgruppen, da kein Azure Load Balancer und kein DNN (Distributed Network Name) erforderlich ist, um Datenverkehr an den Listener im Azure-Netzwerk weiterzuleiten. Die Verwendung eines Multisubnetzansatzes wird empfohlen, erfordert jedoch die Verwendung von MultiSubnetFailover = true in den Verbindungszeichenfolgen einer Anwendung. Dies ist möglicherweise nicht sofort möglich, da es Änderungen auf Anwendungsebene nach sich zieht.

Wenn Sie ursprünglich eine Verfügbarkeitsgruppe in einem einzelnen Subnetz erstellt haben und eine Azure Load Balancer-Instanz oder einen DNN für den Listener verwenden und nun die Komplexität reduzieren möchten, indem Sie zu einer Konfiguration mit mehreren Subnetzen wechseln, können Sie dies mit einigen manuellen Aktionen erledigen.

Bevor Sie mit der Migration einer vorhandenen Umgebung beginnen, sollten Sie die Risiken einer Änderung einer aktiv verwendeten Umgebung abwägen.

Wählen Sie eine der folgenden beiden Möglichkeiten zum Migrieren Ihrer Verfügbarkeitsgruppe zu mehreren Subnetzen aus:

  • Erstellen einer neuen Umgebung für parallele Tests
  • Manuelles Verschieben einer vorhandenen Verfügbarkeitsgruppe

Achtung

Die Durchführung einer Migration ist mit einem gewissen Risiko verbunden. Führen Sie also stets in einer Nicht-Produktionsumgebung gründliche Tests durch, bevor Sie zu einer Produktionsumgebung wechseln.

Neue Umgebung mit parallelen Tests

Die erste Methode für den Wechsel zu einer Verfügbarkeitsgruppe mit mehreren Subnetzen besteht darin, eine neue Umgebung einzurichten. Bei dieser Vorgehensweise müssen Sie Folgendes ausführen:

  1. Erstellen neuer VMs
  2. Erstellen einer neuen Verfügbarkeitsgruppe in einer Konfiguration mit mehreren Subnetzen
  3. Sichern und Wiederherstellen Ihrer aktuellen Datenbank in der neuen Umgebung

Erstellen Sie zunächst in der neuen Umgebung mit mehreren Subnetzen den Listener unter einem anderen Namen als in der bestehenden Subnetzumgebung. Ein neu benannter Listener in einer neuen Verfügbarkeitsgruppe ermöglicht parallele Tests der Anwendung (Tests im Multisubnetz mit dem aktuellen Lastenausgleich oder DNN).

Nachdem die Umgebung mit mehreren Subnetzen gründlich überprüft wurde, können Sie per Cutover zur neuen Infrastruktur migrieren. Verwenden Sie je nach Umgebung (Produktion, Test) ein Wartungsfenster, um die Änderung abzuschließen. Stellen Sie während des Wartungsfensters die Datenbank im neuen primären Replikat wieder her, löschen Sie den Verfügbarkeitsgruppenlistener in beiden Umgebungen, und erstellen Sie den Listener dann in der Umgebung mit mehreren Subnetzen mit demselben Namen wie zuvor, der auch in der Verbindungszeichenfolge der Anwendung verwendet wird.

Das Einrichten einer neuen Umgebung in einer Konfiguration mit mehreren Subnetzen ist mit der Bereitstellung über das Azure-Portal jetzt noch einfacher.

Manuelles Verschieben einer vorhandenen Verfügbarkeitsgruppe

Die andere Möglichkeit besteht darin, manuell von der Umgebung mit einem Subnetz zu einer mit mehreren Subnetzen zu wechseln. Zum Migrieren mit diesem Verfahren benötigen Sie Folgendes:

  • Eine IP-Adresse für jeden Computer in einem der neuen Subnetze
  • Verbindungszeichenfolgen, die bereits MultiSubnetFailover = true verwenden

Führen Sie die folgenden Schritte aus, um Ihre Verfügbarkeitsgruppe zu einer Konfiguration mit mehreren Subnetzen zu migrieren:

  1. Erstellen Sie ein neues Subnetz für jedes sekundäre Subnetz, da sich alle VMs derzeit im selben Subnetz befinden.

  2. Ermitteln Sie die Cluster-IP-Adresse und Listener-IP-Adresse für alle Server in der Verfügbarkeitsgruppe. Wenn Sie beispielsweise über eine Verfügbarkeitsgruppe mit zwei Knoten verwenden, gilt Folgendes:

    VM-Name Subnet Cluster IP Listener IP
    VM1 (primär) 10.1.1.0/24 (vorhandenes Subnetz) 10.1.1.15 10.1.1.16
    VM2 (sekundär) 10.1.2.0/24 (neues Subnetz) 10.1.2.15 10.1.2.16

  3. Fügen Sie die Cluster-IP-Adresse und die Listener-IP-Adresse auf dem primären Replikatserver hinzu. Das Hinzufügen dieser IP-Adressen ist ein Onlinevorgang.

  4. Verschieben Sie den sekundären Server im Azure-Portal in das neue Subnetz, indem Sie zur VM und dann zu >Netzwerk > Netzwerkschnittstelle > IP-Konfigurationen wechseln. Beim Verschieben des Servers in ein neues Subnetz wird der sekundäre Replikatserver neu gestartet.

  5. Fügen Sie die Cluster-IP-Adresse und die Listener-IP-Adresse auf dem sekundären Replikatserver hinzu. Das Hinzufügen dieser IP-Adressen ist ein Onlinevorgang.

  6. Da an diesem Punkt die IP-Adressen und Subnetze vorhanden sind, können Sie den Lastenausgleich löschen.

  7. Löschen Sie den Listener.

  8. Wenn Sie Windows Server 2019 oder höhere Versionen verwenden, überspringen Sie diesen Schritt. Wenn Sie Windows Server 2016 verwenden, fügen Sie die Cluster-IP-Adressen manuell der FCI hinzu.

  9. Erstellen Sie den Listener mit den neuen Listener-IP-Adressen neu.

  10. Leeren Sie das DNS auf allen Servern mit ipconfig /flushdns.

Nächste Schritte