Freigeben über

Konfigurieren eines DNN für eine Failoverclusterinstanz

  • Artikel

Gilt für: SQL Server auf Azure-VMs

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.

In Azure Virtual Machines wird über den Namen des verteilten Netzwerks (Distributed Network Name, DNN) Datenverkehr an die entsprechende Clusterressource weitergeleitet. Dieser Name stellt eine einfachere Möglichkeit zum Herstellen einer Verbindung mit der SQL Server-Failoverclusterinstanz (FCI) dar als der Name des virtuellen Netzwerks (Virtual Network Name, VNN). Zudem ist Azure Load Balancer nicht erforderlich.

In diesem Artikel erfahren Sie, wie Sie eine DNN-Ressource zum Weiterleiten von Datenverkehr an Ihre Failoverclusterinstanz mit SQL Server auf Azure-VMs für Hochverfügbarkeit und Notfallwiederherstellung (HADR) konfigurieren.

Als alternative Konnektivitätsoption bieten sich ein Name eines virtuellen Netzwerks und Azure Load Balancer an.

Übersicht

Der Name des verteilten Netzwerks (DNN) ersetzt den Namen des virtuellen Netzwerks (VNN) als Verbindungspunkt bei Verwendung mit einer Always On-Failoverclusterinstanz auf SQL Server-VMs. Dadurch muss Datenverkehr nicht mehr über eine Azure Load Balancer-Instanz weitergeleitet werden. So lassen sich Bereitstellung und Wartung vereinfachen und das Failover verbessern.

Bei einer Failoverclusterinstanz-Bereitstellung ist der VNN zwar noch vorhanden, aber der Client stellt eine Verbindung mit dem DNS-Namen des DNN anstatt dem VNN her.

Voraussetzungen

Bevor Sie die in diesem Artikel aufgeführten Schritte ausführen, sollten Sie über Folgendes verfügen:

Hinweis

Wenn Sie mehrere AGs oder FCIs auf demselben Cluster haben und entweder einen DNN- oder VNN-Listener einsetzen, benötigt jede AG oder FCI einen eigenen unabhängigen Verbindungspunkt.

Erstellen einer DNN-Ressource

Die DNN-Ressource wird in derselben Clustergruppe wie die SQL Server-FCI erstellt. Verwenden Sie PowerShell, um die DNN-Ressource in der FCI-Clustergruppe zu erstellen.

Mit dem folgenden PowerShell-Befehl wird der SQL Server-FCI-Clustergruppe mit dem Ressourcennamen <dnnResourceName> eine DNN-Ressource hinzugefügt. Der Ressourcenname wird verwendet, um eine Ressource eindeutig zu identifizieren. Verwenden Sie einen Namen, der für Sie sinnvoll und im gesamten Cluster eindeutig ist. Der Ressourcentyp muss Distributed Network Name sein.

Der -Group-Wert muss der Name der Clustergruppe sein, die der SQL Server-FCI entspricht, der Sie den Namen des verteilten Netzwerks hinzufügen möchten. Für eine Standardinstanz ist das typische Format SQL Server (MSSQLSERVER).

Add-ClusterResource -Name <dnnResourceName> `
-ResourceType "Distributed Network Name" -Group "<WSFC role of SQL Server instance>"

Verwenden Sie z. B. den folgenden PowerShell-Befehl, um die DNN-Ressourcen dnn-demo für eine SQL Server-Standard-FCI zu erstellen:

Add-ClusterResource -Name dnn-demo `
-ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"

Festlegen des DNN-DNS-Namens des Clusters

Legen Sie den DNS-Namen für die DNN-Ressource im Cluster fest. Der Cluster verwendet diesen Wert dann zum Weiterleiten von Datenverkehr an den Knoten, der derzeit die SQL Server-FCI hostet.

Clients verwenden den DNS-Namen, um eine Verbindung mit der SQL Server-FCI herzustellen. Sie können einen eindeutigen Wert auswählen. Wenn Sie bereits über eine vorhandene FCI verfügen und keine Clientverbindungszeichenfolgen aktualisieren möchten, können Sie den DNN so konfigurieren, dass er den aktuellen VNN verwendet, den Clients bereits verwenden. Zu diesem Zweck müssen Sie den VNN umbenennen, bevor Sie den DNN in DNS festlegen.

Verwenden Sie diesen Befehl, um den DNS-Namen für den DNN festzulegen:

Get-ClusterResource -Name <dnnResourceName> | `
Set-ClusterParameter -Name DnsName -Value <DNSName>

Clients verwenden den DNSName-Wert, um eine Verbindung mit der SQL Server-FCI herzustellen. Verwenden Sie beispielsweise den folgenden PowerShell-Befehl, damit Clients eine Verbindung mit FCIDNN herstellen:

Get-ClusterResource -Name dnn-demo | `
Set-ClusterParameter -Name DnsName -Value FCIDNN

Clients geben nun beim Herstellen einer Verbindung mit der SQL Server-FCI FCIDNN in ihre Verbindungszeichenfolge ein.

Warnung

Löschen Sie den aktuellen Namen des virtuellen Netzwerks nicht, da es sich um eine erforderliche Komponente der FCI-Infrastruktur handelt.

Umbenennen des VNN

Wenn Sie über einen vorhandenen virtuellen Netzwerknamen verfügen und möchten, dass Clients diesen Wert weiterhin verwenden, um eine Verbindung mit der SQL Server-FCI herzustellen, müssen Sie den aktuellen VNN in einen Platzhalterwert umbenennen. Nachdem der aktuelle VNN umbenannt wurde, können Sie den Wert des DNS-Namens für den DNN auf den VNN festlegen.

Für das Umbenennen des VNN gelten einige Einschränkungen. Weitere Informationen finden Sie unter Umbenennen einer FCI.

Wenn der aktuelle VNN für Ihr Unternehmen nicht erforderlich ist, überspringen Sie diesen Abschnitt. Nachdem Sie den VNN umbenannt haben, legen Sie den DNN-DNS-Namen des Clusters fest.

Onlineschalten der DNN-Ressource

Nachdem die DNN-Ressource entsprechend benannt wurde und Sie den Wert des DNS-Namens im Cluster festgelegt haben, verwenden Sie PowerShell, um die DNN-Ressource im Cluster online zu schalten:

Start-ClusterResource -Name <dnnResourceName>

Verwenden Sie z. B. den folgenden PowerShell-Befehl, um die DNN-Ressource dnn-demo zu starten:

Start-ClusterResource -Name dnn-demo

Konfigurieren möglicher Besitzer

Standardmäßig bindet der Cluster den DNN-DNS-Namen an alle Knoten im Cluster. Knoten im Cluster, die nicht Teil der SQL Server-FCI sind, sollten jedoch aus der Liste der möglichen DNN-Besitzer ausgeschlossen werden.

Um mögliche Besitzer zu aktualisieren, führen Sie die folgenden Schritte aus:

  1. Navigieren Sie im Failovercluster-Manager zu Ihrer DNN-Ressource.

  2. Klicken Sie mit der rechten Maustaste auf die DNN-Ressource, und wählen Sie Eigenschaften aus.

    Kontextmenü für die DNN-Ressource mit hervorgehobenem Befehl „Eigenschaften“.

  3. Deaktivieren Sie das Kontrollkästchen für alle Knoten, die nicht an der Failoverclusterinstanz teilnehmen. Die Liste möglicher Besitzer für die DNN-Ressource sollte mit der Liste möglicher Besitzer für die SQL Server-Instanzressource übereinstimmen. Wenn z. B. Data3 nicht an der FCI teilnimmt, ist die folgende Abbildung ein Beispiel für das Entfernen von Data3 aus der Liste möglicher Besitzer für die DNN-Ressource:

    Deaktivieren Sie das Kontrollkästchen neben den Knoten, die nicht an der FCI beteiligt sind, für mögliche Besitzer der DNN-Ressource.

  4. Klicken Sie auf OK, um die Einstellungen zu speichern.

Neustarten der SQL Server-Instanz

Verwenden Sie den Failovercluster-Manager, um die SQL Server-Instanz neu zu starten. Folgen Sie diesen Schritten:

  1. Navigieren Sie im Failovercluster-Manager zu Ihrer SQL Server-Ressource.
  2. Klicken Sie mit der rechten Maustaste auf die SQL Server-Ressource, und schalten Sie diese offline.
  3. Wenn alle zugeordneten Ressourcen offline sind, klicken Sie mit der rechten Maustaste auf die SQL Server-Ressource, und schalten Sie sie erneut online.

Aktualisieren der Verbindungszeichenfolge

Aktualisieren Sie die Verbindungszeichenfolge jeder Anwendung, die eine Verbindung mit dem SQL Server FCI-DNN herstellt, und schließen Sie MultiSubnetFailover=True in die Verbindungszeichenfolge ein. Wenn Ihr Client den Parameter „MultiSubnetFailover“ nicht unterstützt, ist er nicht mit einem DNN kompatibel.

Im Folgenden wird eine Beispielverbindungszeichenfolge für einen SQL FCI-DNN mit dem DNS-Namen FCIDNN angezeigt:

Data Source=FCIDNN, MultiSubnetFailover=True

Wenn der DNN den ursprünglichen VNN nicht verwendet, müssen SQL-Clients, die eine Verbindung mit der SQL Server-FCI herstellen, außerdem ihre Verbindungszeichenfolge auf den DNN-DNS-Namen aktualisieren. Um diese Anforderung zu vermeiden, können Sie den Wert des DNS-Namens auf den Namen des VNN aktualisieren. Zunächst müssen Sie jedoch den vorhandenen VNN durch einen Platzhalter ersetzen.

Testfailover

Testen Sie das Failover der Clusterressource, um die Clusterfunktionalität zu validieren.

Führen Sie die folgenden Schritte aus, um das Failover zu testen:

  1. Stellen Sie mithilfe von RDP eine Verbindung mit einem der SQL Server-Clusterknoten her.
  2. Öffnen Sie den Failovercluster-Manager. Wählen Sie Rollen aus. Achten Sie darauf, welcher Knoten im Besitz der SQL Server-FCI-Rolle ist.
  3. Klicken Sie mit der rechten Maustaste auf die SQL Server-FCI-Rolle.
  4. Wählen Sie Verschieben aus, und wählen Sie dann Bestmöglicher Knoten aus.

Unter Failovercluster-Manager wird die Rolle angezeigt, und die Ressourcen werden in den Offlinezustand versetzt. Die Ressourcen werden dann verschoben und auf dem anderen Knoten dann wieder in den Onlinezustand versetzt.

Testen der Konnektivität

Melden Sie sich zum Testen der Konnektivität an einem anderen virtuellen Computer in demselben virtuellen Netzwerk an. Öffnen Sie SQL Server Management Studio, und stellen Sie eine Verbindung mit der SQL Server-FCI mithilfe des DNN-DNS-Namens her.

Bei Bedarf können Sie SQL Server Management Studio herunterladen.

Vermeiden von IP-Konflikten

Dies ist ein optionaler Schritt, um zu verhindern, dass die von der FCI-Ressource verwendete virtuelle IP-Adresse (VIP-Adresse) einer anderen Ressource in Azure als Duplikat zugewiesen wird.

Obwohl Kunden jetzt den DNN verwenden, um eine Verbindung mit der SQL Server-FCI herzustellen, können der Name des virtuellen Netzwerks (VNN) und die virtuelle IP-Adresse nicht gelöscht werden, da es sich um erforderliche Komponenten der FCI-Infrastruktur handelt. Da es jedoch keinen Load Balancer mehr gibt, der die virtuelle IP-Adresse in Azure reserviert, besteht das Risiko, dass einer anderen Ressource im virtuellen Netzwerk dieselbe IP-Adresse wie die von der FCI verwendete virtuelle IP-Adresse zugewiesen wird. Dies kann möglicherweise zu einem Konflikt aufgrund der doppelt vorhandenen IP-Adresse führen.

Konfigurieren Sie eine APIPA-Adresse oder einen dedizierten Netzwerkadapter, um die IP-Adresse zu reservieren.

APIPA-Adresse

Um zu vermeiden, dass doppelte IP-Adressen verwendet werden, konfigurieren Sie eine APIPA-Adresse (auch als Link-Local-Adresse bezeichnet). Führen Sie hierzu den folgenden Befehl aus:

Get-ClusterResource "virtual IP address" | Set-ClusterParameter 
    –Multiple @{"Address"="169.254.1.1";"SubnetMask"="255.255.0.0";"OverrideAddressMatch"=1;"EnableDhcp"=0}

In diesem Befehl ist „virtual IP address“ (virtuelle IP-Adresse) der Name der geclusterten VIP-Adressressource, und „169.254.1.1“ ist die für die VIP-Adresse ausgewählte APIPA-Adresse. Wählen Sie die Adresse aus, die am besten zu Ihrem Unternehmen passt. Legen Sie OverrideAddressMatch=1 fest, damit die IP-Adresse in jedem Netzwerk, einschließlich des APIPA-Adressraums, verwendet werden kann.

Dedizierte Netzwerkadapter

Alternativ können Sie einen Netzwerkadapter in Azure konfigurieren, um die von der virtuellen IP-Adressressource verwendete IP-Adresse zu reservieren. Dadurch wird jedoch die Adresse im Subnetzadressraum genutzt, und es entsteht zusätzlicher Mehraufwand, weil sichergestellt werden muss, dass der Netzwerkadapter nicht für andere Zwecke verwendet wird.

Einschränkungen

  • Der Client, der eine Verbindung mit dem DNN-Listener herstellt, muss den Parameter MultiSubnetFailover=True in der Verbindungszeichenfolge unterstützen.
  • Es gibt möglicherweise weitere Überlegungen, wenn Sie mit anderen SQL Server-Features und einer FCI mit einem DNN arbeiten. Weitere Informationen finden Sie unter FCI mit DNN-Interoperabilität.

Nächste Schritte

Weitere Informationen finden Sie unter: