Vorbereiten virtueller Computer für eine FCI (SQL Server auf Azure-VMs)

Gilt für:SQL Server auf Azure-VM

In diesem Artikel wird beschrieben, wie Sie virtuelle Azure-Computer (VMs) für den Einsatz mit einer SQL Server-Failoverclusterinstanz (FCI) vorbereiten können. Die Konfigurationseinstellungen hängen von der FCI-Speicherlösung ab. Vergewissern Sie sich daher, dass Sie die für Ihre Umgebung und Ihr Unternehmen richtige Konfiguration wählen.

Weitere Informationen finden Sie in der Übersicht zu FCI mit SQL Server auf Azure-VMs und über Bewährte Methoden für Cluster.

Hinweis

Sie können Ihre Failoverclusterinstanzlösung jetzt mithilfe von Azure Migrate per Lift-und-Shift-Verfahren zu SQL Server auf Azure-VMs verschieben. Weitere Informationen finden Sie unter Migrieren einer Failoverclusterinstanz.

Voraussetzungen

  • Ein Microsoft Azure-Abonnement Erste Schritte mit einem kostenlosen Azure-Konto.
  • Eine Windows-Domäne auf virtuellen Azure-Maschinen oder ein lokales aktives Verzeichnis, das auf Azure mit virtueller Netzwerkkopplung erweitert wurde.
  • Ein Konto mit Berechtigungen zum Erstellen von Objekten auf virtuellen Azure-Computern und in Active Directory
  • Ein virtuelles Azure-Netzwerk und ein oder mehrere Subnetze mit ausreichend IP-Adressraum für diese Komponenten:
    • Beide virtuellen Computer
    • Eine IP-Adresse für den Windows-Failover-Cluster
    • Eine IP-Adresse für jede FCI
  • DNS-Konfiguration im Azure-Netzwerk mit Verweis auf die Domänencontroller

Wählen einer FCI-Speicheroption

Die Konfigurationseinstellungen für Ihren virtuellen Computer variieren je nach der Speicheroption, die Sie für Ihre SQL Server-Failoverclusterinstanz nutzen möchten. Bevor Sie den virtuellen Computer vorbereiten, prüfen Sie die verfügbaren FCI-Speicheroptionen. Wählen Sie die Option, die am besten zu Ihrer Umgebung und Ihren Geschäftsanforderungen passt. Wählen Sie dann im Verlauf dieses Artikels auf Grundlage Ihrer Speicherwahl die passenden VM-Konfigurationsoptionen sorgfältig aus.

VM-Verfügbarkeit auswählen

Für das Feature „Failovercluster“ müssen virtuelle Computer in einer Verfügbarkeitsgruppe oder Verfügbarkeitszone platziert werden.

Wählen Sie die VM-Verfügbarkeitsoption sorgfältig aus, die Ihrer beabsichtigten Clusterkonfiguration entspricht:

  • Azure freigegebene Datenträger: Die Verfügbarkeitsoption variiert, wenn Sie SSD Premium oder UltraDisk verwenden:
    • SSD Premium Zone Redundant Storage (ZRS) : Verfügbarkeitszone in verschiedenen Zonen. Premium SSD ZRS repliziert Ihren in Azure verwalteten Datenträger synchron über drei Azure-Verfügbarkeitszonen in der ausgewählten Region. VMs, die Teil eines Failover-Clusters sind, können in verschiedenen Verfügbarkeitszonen platziert werden. So können Sie eine zonenredundante SQL Server FCI erreichen, die ein VM-Verfügbarkeits-SLA von 99,99 % bietet. Die Latenzzeit der Datenträger für ZRS ist aufgrund der zonenübergreifenden Kopie der Daten höher.
    • SSD PremiumLocally Redundant Storage (LRS) : Availability Set in verschiedenen Fehler-/Aktualisierungsdomänen für Premium SSD LRS. Sie können die VMs auch in einer Nachbarschaftsplatzierungsgruppe platzieren, um sie näher beieinander zu platzieren. Die Kombination aus Availability Set und Proximity Placement Group bietet die niedrigste Latenz für gemeinsam genutzte Datenträger, da die Daten lokal in einem Rechenzentrum repliziert werden, und ermöglicht eine VM-Verfügbarkeits-SLA von 99,95 %.
    • Ultra Disk Locally Redundant Storage (LRS) : Verfügbarkeitszone, aber die VMs müssen sich in der gleichen Verfügbarkeitszone befinden. Ultra-Datenträger bieten die geringste Datenträger-Latenz und eignen sich am besten für IO-intensive Workloads. Da alle VMs, die Teil der FCI sind, in derselben Verfügbarkeitszone liegen müssen, beträgt die Verfügbarkeit der VMs nur 99,9%.
  • Premium-Dateifreigaben: Verfügbarkeitsgruppe oder Verfügbarkeitszone.
  • Direkte Speicherplätze: Verfügbarkeitsmenge.

Wichtig

Sie können die Verfügbarkeitsgruppe nicht mehr festlegen oder ändern, nachdem Sie einen virtuellen Computer erstellt haben.

Subnetze

Für SQL Server auf Azure-VMs haben Sie die Möglichkeit, Ihre SQL Server-VMs in einem einzigen Subnetz oder in mehreren Subnetzen bereitzustellen.

Die Bereitstellung Ihrer VMs in mehreren Subnetzen nutzt die Cluster-OR-Abhängigkeit für IP-Adressen und entspricht der Erfahrung vor Ort bei der Verbindung mit Ihrer Failover-Cluster-Instanz. Der Multi-Subnetz-Ansatz wird für SQL Server auf Azure-VMs empfohlen, um die Verwaltung zu vereinfachen und die Failover-Zeiten zu verkürzen.

Die Bereitstellung Ihrer VMs in einem einzelnen Subnetz erfordert eine zusätzliche Abhängigkeit von einem Azure Load Balancer oder einem verteilten Netzwerknamen (DNN), um den Datenverkehr zu Ihrer FCI zu leiten.

Wenn Sie Ihre SQL Server-VMs in mehreren Subnetzen bereitstellen, befolgen Sie die Schritte in diesem Abschnitt, um Ihre virtuellen Netzwerke mit zusätzlichen Subnetzen zu erstellen, und weisen Sie den VMs nach der Erstellung der SQL Server-VMs sekundäre IP-Adressen innerhalb dieser Subnetze zu. Wenn Sie Ihre SQL Server-VMs in einem einzigen Subnetz bereitstellen, ist keine zusätzliche Netzwerkkonfiguration erforderlich.

Platzieren Sie beide virtuellen Maschinen in einem einzigen Subnetz, das über genügend IP-Adressen für beide virtuellen Maschinen und alle FCIs verfügt, die Sie eventuell in dem Cluster installieren werden. Dieser Ansatz erfordert eine zusätzliche Komponente, um Verbindungen zu Ihrer FCI zu leiten, wie z. B. einen Azure Load Balancer oder einen verteilten Netzwerknamen (DNN).

Wenn Sie sich dafür entscheiden, Ihre SQL Server-VMs in einem einzigen Subnetz einzusetzen , prüfen Sie die Unterschiede zwischen den Azure Load Balancer- und DNN-Konnektivitätsoptionen und entscheiden Sie, welche Option für Sie am besten geeignet ist, bevor Sie den Rest Ihrer Umgebung für Ihre FCI vorbereiten.

Wenn Sie Ihre SQL Server-VMs in einem einzigen Subnetz bereitstellen, ist keine zusätzliche Netzwerkkonfiguration erforderlich.

Konfigurieren des DNS

Konfigurieren Sie Ihr virtuelles Netzwerk für die Verwendung Ihres DNS-Servers. Ermitteln Sie zunächst die DNS-IP-Adresse und fügen Sie sie dann zu Ihrem virtuellen Netzwerk hinzu.

DNS-IP-Adresse ermitteln

Ermitteln Sie die IP-Adresse des DNS-Servers, und fügen Sie ihn der Konfiguration des virtuellen Netzwerks hinzu. In diesem Abschnitt wird gezeigt, wie Sie die DNS-IP-Adresse identifizieren, wenn sich der DNS-Server auf einer virtuellen Maschine in Azure befindet.

Gehen Sie folgendermaßen vor, um die IP-Adresse der DNS-Server-VM im Azure-Portal zu ermitteln:

  1. Gehen Sie zu Ihrer Ressourcengruppe im Azure-Portal und wählen Sie die DNS-Server-VM.
  2. Wählen Sie auf der Seite VM die Option Netzwerke im Bereich Einstellungen.
  3. Beachten Sie die Adresse NIC Private IP, da dies die IP-Adresse des DNS-Servers ist. Auf dem Beispielbild lautet die private IP-Adresse 10.38.0.4.

On the DC-VM-1 page, choose Networking in the Settings pane, and then note the NIC private IP address. Use this IP address as the DNS server.

Konfigurieren des DNS für das virtuelle Netzwerk

Konfigurieren Sie das virtuelle Netzwerk so, dass es die IP-Adresse des DNS-Servers verwendet.

Führen Sie die folgenden Schritte aus, um Ihr virtuelles Netzwerk für DNS zu konfigurieren:

  1. Gehen Sie zu Ihrer Ressourcengruppe im Azure-Portal und wählen Sie Ihr virtuelles Netzwerk.
  2. Wählen Sie DNS-Server unter dem Fenster Einstellungen und dann Benutzerdefiniert.
  3. Geben Sie die private IP-Adresse, die Sie zuvor ermittelt haben, in das Feld IP-Adresse ein, z. B. 10.38.0.4, oder geben Sie die interne IP-Adresse Ihres internen DNS-Servers an.
  4. Wählen Sie Speichern aus.

 Select DNS servers under the Settings pane and then select Custom. Enter the private IP address you identified previously in the IP Address field, such as 10.38.0.4.

Erstellen der virtuellen Computer

Nachdem Sie Ihr virtuelles VM-Netzwerk konfiguriert und die VM-Verfügbarkeit ausgewählt haben, können Sie Ihre virtuellen Maschinen erstellen. Sie können wählen, ob Sie ein Azure Marketplace-Image einsetzen möchten, bei dem SQL Server bereits installiert ist oder nicht. Wenn Sie jedoch ein Image für SQL Server auf Azure-VMs wählen, müssen Sie SQL Server vom virtuellen Computer deinstallieren, ehe Sie die Failoverclusterinstanz konfigurieren können.

NIC-Überlegungen

Bei einem Azure VM-Gast-Failover-Cluster empfehlen wir eine einzelne NIC pro Server (Clusterknoten). Azure-Netzwerke verfügen über physische Redundanz, was zusätzliche Netzwerkkarten in einem Azure IaaS VM-Gastcluster überflüssig macht. Obwohl im Clustervalidierungsbericht eine Warnung ausgegeben wird, dass die Knoten nur in einem einzigen Netzwerk erreichbar sind, kann diese Warnung für Azure IaaS-VM-Gast-Failovercluster einfach ignoriert werden.

Platzieren Sie beide virtuellen Computer wie folgt:

  • In derselben Azure-Ressourcengruppe wie Ihre Verfügbarkeitsgruppe, wenn Sie mit Verfügbarkeitsgruppen arbeiten.
  • Im selben virtuellen Netzwerk wie Ihr Domänencontroller und DNS-Server oder in einem virtuellen Netzwerk, das über eine geeignete Verbindung zu Ihrem Domänencontroller verfügt.
  • In der Azure-Verfügbarkeitsgruppe oder- Verfügbarkeitszone.

Sie können einen virtuellen Azure-Computer erstellen, indem Sie ein Image mit oder ohne vorinstalliertes SQL Server verwenden. Wenn Sie das SQL Server-Image wählen, müssen Sie die SQL Server-Instanz manuell deinstallieren, bevor Sie die Failoverclusterinstanz installieren.

Sekundäre IP-Adressen zuweisen

Wenn Sie Ihre SQL Server-VMs in einem einzigen Subnetz bereitgestellt haben, überspringen Sie diesen Schritt. Wenn Sie Ihre SQL Server-VMs auf mehrere Subnetze verteilt haben, um die Konnektivität mit Ihrer FCI zu verbessern, müssen Sie jeder VM die sekundären IP-Adressen zuweisen.

Weisen Sie jeder SQL Server-VM sekundäre IP-Adressen zu, die für den Netzwerknamen der Failover-Cluster-Instanz verwendet werden sollen, und für Windows Server 2016 und früher weisen Sie jeder SQL Server-VM auch sekundäre IP-Adressen für den Clusternetzwerknamen zu. Dadurch entfällt die Notwendigkeit eines Azure Load Balancer, wie er in einer Umgebung mit einem einzigen Subnetz erforderlich ist.

Unter Windows Server 2016 und früher müssen Sie jeder SQL Server-VM eine zusätzliche sekundäre IP-Adresse zuweisen, die für die Windows-Cluster-IP verwendet wird, da der Cluster den Cluster-Netzwerknamen anstelle des standardmäßigen verteilten Netzwerknamens (DNN) verwendet, der in Windows Server 2019 eingeführt wurde. Bei einem DNN wird das Clusternamensobjekt (CNO) automatisch mit den IP-Adressen für alle Knoten des Clusters registriert, so dass keine spezielle Windows-Cluster-IP-Adresse erforderlich ist.

Wenn Sie Windows Server 2016 und früher verwenden, befolgen Sie die Schritte in diesem Abschnitt, um jeder SQL Server-VM eine sekundäre IP-Adresse für den FCI-Netzwerknamen und den Cluster zuzuweisen.

Wenn Sie Windows Server 2019 oder höher verwenden, weisen Sie nur eine sekundäre IP-Adresse für den FCI-Netzwerknamen zu und überspringen Sie die Schritte zur Zuweisung einer Windows-Cluster-IP, es sei denn, Sie planen, Ihren Cluster mit einem virtuellen Netzwerknamen (VNN) zu konfigurieren. In diesem Fall weisen Sie jeder SQL Server-VM beide IP-Adressen zu, wie Sie es bei Windows Server 2016 tun würden.

Um den VMs zusätzliche sekundäre IPs zuzuweisen, gehen Sie wie folgt vor:

  1. Gehen Sie zu Ihrer Ressourcengruppe im Azure-Portal und wählen Sie die erste SQL Server-VM.

  2. Wählen Sie im Bereich Einstellungen die Option Netzwerk und anschließend die Netzwerkschnittstelle aus:

    Select Networking in the Settings pane, and then select the Network Interface

  3. Wählen Sie auf der Seite Netzwerkschnittstelle die Option IP-Konfigurationen im Bereich Einstellungen und wählen Sie dann + Hinzufügen, um eine zusätzliche IP-Adresse hinzuzufügen:

    IP configurations

  4. Führen Sie auf der Seite IP-Konfiguration hinzufügen die folgenden Schritte aus:

    1. Geben Sie den Name für die Windows-Cluster-IP-Adresse an, beispielsweise windows-cluster-ip für Windows 2016 und früher. Überspringen Sie diesen Schritt, wenn Sie mit Windows Server 2019 oder höher arbeiten.
    2. Setzen Sie die Zuweisung auf Statisch.
    3. Geben Sie eine unbenutzte IP-Adresse im selben Subnetz (SQL-Subnetz-1) wie die SQL Server-VM ein, z. B. 10.38.1.10.
    4. Belassen Sie die Öffentliche IP-Adresse auf dem Standardwert von Disassoziieren.
    5. Wählen Sie OK, um das Hinzufügen der IP-Konfiguration abzuschließen.

    Add Cluster IP by entering in an used IP address in the subnet of the first SQL Server VM

  5. Wählen Sie erneut + Hinzufügen, um eine zusätzliche IP-Adresse für den FCI-Netznamen zu konfigurieren (mit einem Namen wie FCI-Netzname), wobei Sie wiederum eine nicht verwendete IP-Adresse in SQL-Subnetz-1 wie 10.38.1.11 angeben:

    Select + Add again to configure an additional IP address for the availability group listener (with a name such as availability-group-listener), again using an unused IP address in SQL-subnet-1 such as 10.31.1.11

  6. Wiederholen Sie diese Schritte auch für die zweite SQL Server-VM. Weisen Sie zwei ungenutzte sekundäre IP-Adressen im SQL-Subnetz-2 zu. Verwenden Sie die Werte aus der folgenden Tabelle, um die IP-Konfiguration hinzuzufügen (die IP-Adressen sind jedoch nur Beispiele, Ihre können abweichen):

    Feld Eingabe Eingabe
    Name windows-cluster-ip FCI-Netz-Name
    Speicherbelegung statischen statischen
    IP-Adresse 10.38.2.10 10.38.2.11

Deinstallieren von SQL Server

Im Rahmen des Prozesses der FCI-Erstellung installieren Sie SQL Server als Clusterinstanz im Failovercluster. Wenn Sie einen virtuellen Computer mit Azure Marketplace-Image ohne SQL Server bereitgestellt haben, können Sie diesen Schritt überspringen. Wenn Sie ein Image mit vorinstallierter SQL Server-Instanz bereitgestellt haben, müssen Sie die Registrierung der SQL-IaaS-Agent-Erweiterung für die SQL Server-VM aufheben und SQL Server anschließend deinstallieren.

Aufheben der Registrierung der SQL-IaaS-Agent-Erweiterung für die VM

SQL Server-VM-Images aus Azure Marketplace werden automatisch mit der SQL-IaaS-Agent-Erweiterung registriert. Bevor Sie die vorinstallierte SQL Server-Instanz deinstallieren, müssen Sie zuerst die Registrierung der SQL-IaaS-Agent-Erweiterung für jede SQL Server-VM aufheben.

Deinstallieren von SQL Server

Nachdem Sie die Registrierung der Erweiterung aufgehoben haben, können Sie SQL Server deinstallieren. Befolgen Sie dazu auf jedem virtuellen Computer diese Schritte:

  1. Verbindung mit diesem virtuellen Computer über RDP herstellen Wenn Sie die Verbindung mit einem virtuellen Computer per RDP zum ersten Mal herstellen, wird gefragt, ob Sie zulassen möchten, dass dieser PC über das Netzwerk ermittelt werden kann. Wählen Sie Ja aus.
  2. Öffnen Sie Programme und Funktionen in der Systemsteuerung.
  3. Klicken Sie unter Programme und Features mit der rechten Maustaste auf Microsoft SQL Server 201_ (64-Bit) , und wählen Sie dann Deinstallieren/Ändern aus.
  4. Wählen Sie Entfernen.
  5. Wählen Sie die Standardinstanz aus.
  6. Entfernen Sie alle Funktionen unter Database Engine Services, Analysis Services und Reporting Services - Native. Entfernen Sie nichts unter SharedFeatures. Sie sehen dann etwas wie den folgenden Screenshot: Select features
  7. Wählen Sie Weiter und anschließend Entfernen aus.
  8. Nachdem die Instanz erfolgreich entfernt wurde, starten Sie den virtuellen Computer neu.

Öffnen der Firewall

Öffnen Sie auf jedem virtuellen Computer den von SQL Server verwendeten TCP-Port in der Windows-Firewall. Standardmäßig verwendet SQL Server Port 1433. Wenn Sie dies in Ihrer Umgebung geändert haben, öffnen Sie den Port, für den Sie Ihre SQL Server-Instanz konfiguriert haben. Port 1433 ist automatisch für SQL Server-Images geöffnet, die über den Azure Marketplace bereitgestellt werden.

Wenn Sie einen Load Balancer für ein einzelnes Subnetz-Szenario verwenden, müssen Sie auch den Port öffnen, den die Health Probe verwendet. Standardmäßig verwendet der Health Probe den Port 59999, aber es kann jeder TCP-Port sein, den Sie bei der Erstellung des Load Balancers angeben.

In dieser Tabelle sind die Ports aufgeführt, die Sie je nach Ihrer FCI-Konfiguration möglicherweise öffnen müssen:

Zweck Port Notizen
SQL Server TCP 1433 Dies ist der normale Port für Standardinstanzen von SQL Server. Falls Sie ein Image aus dem Katalog verwendet haben, ist dieser Port automatisch geöffnet.

Verwendet von: Allen FCI-Konfigurationen.
Integritätstest TCP 59999 Beliebiger geöffneter TCP-Port. Konfigurieren Sie diesen Port für den Integritätstest des Lastenausgleichs und den Cluster.

Verwendet von: FCI mit Load Balancer in einem einzigen Subnetz-Szenario.
Dateifreigabe UDP 445 Der vom Dateifreigabedienst verwendete Port.

Verwendet von: FCI mit Premium-Dateifreigabe.

Beitreten zur Domäne

Außerdem müssen Ihre virtuellen Computer der Domäne beitreten. Nutzen Sie hierfür eine Schnellstartvorlage.

Überprüfen der Speicherkonfiguration

Über Azure Marketplace erstellte virtuelle Computer werden mit angefügtem Speicher bereitgestellt. Wenn Sie planen, Ihren FCI-Speicher unter Verwendung von Premium-Dateifreigaben oder freigegebenen Azure-Datenträgern zu konfigurieren, können Sie den angefügten Speicher entfernen, um Kosten zu sparen, da lokaler Speicher nicht für die Failoverclusterinstanz genutzt wird. Es ist jedoch möglich, den angefügten Speicher für FCI-Lösungen mit „Direkte Speicherplätze“ zu verwenden, sodass es in diesem Fall nicht unbedingt sinnvoll ist, ihn zu entfernen. Überprüfen Sie Ihre FCI-Speicherlösung, um herauszufinden, ob das Entfernen von angefügtem Speicher optimal ist, um Kosten zu sparen.

Nächste Schritte

Nachdem Sie Ihre Umgebung mit virtuellen Computern vorbereitet haben, können Sie nun Ihre Failoverclusterinstanz konfigurieren.

Befolgen Sie einen der folgenden Leitfäden, um die für Ihr Unternehmen geeignete FCI-Umgebung zu konfigurieren:

Weitere Informationen finden Sie unter: