Konfigurieren eines ILB-Listeners für Verfügbarkeitsgruppen auf Azure SQL Server-VMs

Artikel
05/02/2017

Übersicht

Wichtig

Azure bietet zwei Bereitstellungsmodelle für das Erstellen und Verwenden von Ressourcen: Azure Resource Manager und klassisch. Dieser Artikel gilt für das klassische Bereitstellungsmodell. Wir empfehlen für die meisten Neubereitstellungen das Resource Manager-Modell.

Informationen zum Konfigurieren eines Listeners für eine AlwaysOn-Verfügbarkeitsgruppe im Resource Manager-Modell finden Sie unter Konfigurieren eines Load Balancers für eine AlwaysOn-Verfügbarkeitsgruppe in Azure.

Ihre Verfügbarkeitsgruppe kann Replikate enthalten, die ausschließlich lokal, ausschließlich in Azure oder sowohl lokal als auch in Azure verfügbar sind (Hybridkonfigurationen). Azure-Replikate können sich innerhalb derselben Region oder in mehreren Regionen befinden, wobei mehrere virtuelle Netzwerke verwendet werden. Bei den Verfahren in diesem Artikel wird davon ausgegangen, dass bereits eine Verfügbarkeitsgruppe konfiguriert wurde, Sie jedoch noch keinen Listener konfiguriert haben.

Richtlinien und Einschränkungen für interne Listener

Bei Verwendung eines internen Load Balancers (ILB) mit einem Verfügbarkeitsgruppenlistener in Azure gelten folgende Richtlinien:

Der Verfügbarkeitsgruppenlistener wird unter Windows Server 2008 R2, Windows Server 2012 und Windows Server 2012 R2 unterstützt.
Da der Lister mit dem internen Load Balancer (ILB) konfiguriert wird und nur ein ILB pro Clouddienst vorhanden ist, wird für jeden Clouddienst maximal ein Verfügbarkeitsgruppenlistener unterstützt. Es ist jedoch möglich, mehrere externe Listener zu erstellen. Weitere Informationen finden Sie unter Konfigurieren eines externen Listeners für AlwaysOn-Verfügbarkeitsgruppen in Azure.

Festlegen des Zugriffs auf den Listener

Sie müssen beachten, dass es zwei Methoden zum Konfigurieren eines Verfügbarkeitsgruppenlisteners in Azure gibt. Diese Methoden unterscheiden sich durch den Typ des Azure-Lastenausgleichs, den Sie verwenden, wenn Sie den Listener erstellen. In der folgenden Tabelle sind die Unterschiede beschrieben:

Typ des Lastenausgleichs	Implementierung	Zu verwenden in folgenden Fällen:
Extern	Verwendet die öffentliche virtuelle IP-Adresse des Clouddiensts, der die virtuellen Computer (VMs) hostet.	Sie müssen auf den Listener von außerhalb des virtuellen Netzwerks zugreifen, auch über das Internet.
Intern	Verwendet einen internen Lastenausgleich mit einer privaten Adresse für den Listener.	Sie können auf den Listener nur im gleichen virtuellen Netzwerk zugreifen. Dieser Zugriff schließt Site-to-Site-VPNs in Hybridszenarien ein.

Wichtig

Für einen Listener, der die öffentliche VIP-Adresse des Clouddiensts (externer Lastenausgleich) verwendet, fallen keine Gebühren für ausgehende Datenübertragungen an, solange sich der Client, der Listener und die Datenbanken in der gleichen Azure-Region befinden. Andernfalls gelten alle über den Listener zurückgegebenen Daten als ausgehende Datenübertragungen und werden zu normalen Datenübertragungsraten berechnet.

ILB kann nur für virtuelle Netzwerke mit regionalem Umfang konfiguriert werden. Vorhandene virtuelle Netzwerke, die für eine Affinitätsgruppe konfiguriert wurden, können ILB nicht verwenden. Weitere Informationen finden Sie unter Übersicht über den internen Lastenausgleich.

Der Schwerpunkt dieses Artikels liegt auf dem Erstellen eines Listeners, der einen ILB verwendet. Wenn Sie einen öffentlichen oder externen Listener benötigen, finden Sie die entsprechenden Schritte im Artikel zum Einrichten eines externen Listeners.

Erstellen von VM-Endpunkten mit Lastenausgleich und Direct Server Return

Zunächst erstellen Sie einen ILB durch Ausführen des Skripts weiter unten in diesem Abschnitt.

Erstellen Sie einen Endpunkt mit Lastenausgleich für jeden virtuellen Computer mit einem Azure-Replikat. Wenn Replikate in mehreren Regionen vorhanden sind, muss sich jedes Replikat für diese Region im selben Clouddienst im selben virtuellen Azure-Netzwerk befinden. Das Erstellen von Verfügbarkeitsgruppenreplikaten, die sich über mehrere Azure-Regionen erstrecken, erfordert die Konfiguration mehrerer virtueller Netzwerke. Weitere Informationen zum Konfigurieren von Verbindungen zwischen virtuellen Netzwerken finden Sie unter Konfigurieren der Verbindung zwischen virtuellen Netzwerken.

Wechseln Sie im Azure-Portal zu jedem virtuellen Computer, der ein Replikat hostet, um die Details anzuzeigen.
Klicken Sie auf die Registerkarte Endpunkte für jeden virtuellen Computer.
Stellen Sie sicher, dass die Werte für Name und Öffentlicher Port des gewünschten Listenerendpunkts nicht bereits verwendet werden. In dem Beispiel in diesem Abschnitt lautet der Name MyEndpoint und der Port 1433.
Laden Sie auf dem lokalen Client das aktuelle PowerShell-Modul herunter, und installieren Sie es.
Starten Sie Azure PowerShell.
Eine neue PowerShell-Sitzung wird geöffnet, und die Azure-Verwaltungsmodule werden geladen.
Führen Sie Get-AzurePublishSettingsFile aus. Dieses Cmdlet leitet Sie zu einem Browser weiter, damit Sie eine Datei mit Veröffentlichungseinstellungen in ein lokales Verzeichnis herunterladen können. Möglicherweise werden Sie aufgefordert, die Anmeldeinformationen für Ihr Azure-Abonnement einzugeben.
Führen Sie den folgenden Befehl Import-AzurePublishSettingsFile mit dem Pfad der Datei mit Veröffentlichungseinstellungen aus, die Sie heruntergeladen haben:
```
Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
```
Nachdem die Datei mit Veröffentlichungseinstellungen importiert wurde, können Sie Ihr Azure-Abonnement in der PowerShell-Sitzung verwalten.
Weisen Sie für ILB eine statische IP-Adresse zu. Untersuchen Sie das aktuelle virtuelle Netzwerk, indem Sie den folgenden Befehl ausführen:
```
(Get-AzureVNetConfig).XMLConfiguration
```
Notieren Sie sich den unter Subnetz angegebenen Namen für das Subnetz, in dem sich die zum Hosten der Replikate verwendeten VMs befinden. Dieser Name wird für den $SubnetName-Parameter des Skripts verwendet.
Notieren Sie sich den für VirtualNetworkSite angegebenen Namen und den ersten Wert AddressPrefix für das Subnetz, in dem sich die zum Hosten der Replikate verwendeten VMs befinden. Suchen Sie nach einer verfügbaren IP-Adresse, indem Sie diese beiden Werte im Befehl Test-AzureStaticVNetIP verwenden und AvailableAddresses untersuchen. Wenn z.B. der Name des virtuellen Netzwerks MyVNet lautet und der Adressbereich des Subnetzes bei 172.16.0.128 beginnt, werden die verfügbaren Adressen mit folgendem Befehl aufgelistet:
```
(Test-AzureStaticVNetIP -VNetName "MyVNet"-IPAddress 172.16.0.128).AvailableAddresses
```
Wählen Sie eine der verfügbaren Adressen aus, und verwenden Sie diese in dem Skript im nächsten Schritt als $ILBStaticIP-Parameter.

Kopieren Sie das folgende PowerShell-Skript in einen Text-Editor, und legen Sie die Variablenwerte passend für Ihre Umgebung fest. Für einige Parameter sind Standardwerte angegeben.

Bei vorhandenen Bereitstellungen, die Affinitätsgruppen verwenden, kann kein ILB hinzugefügt werden. Weitere Informationen zu den Voraussetzungen für den internen Lastenausgleich finden Sie unter Interner Load Balancer (Übersicht).

Wenn Ihre Verfügbarkeitsgruppe sich über mehrere Azure-Regionen erstreckt, müssen Sie das Skript zudem in jedem Datencenter für den Clouddienst und die Knoten ausführen, die sich in diesem Datencenter befinden.

# Define variables
$ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
$AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
$SubnetName = "<MySubnetName>" # subnet name that the replicas use in the virtual network
$ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
$ILBName = "AGListenerLB" # customize the ILB name or use this default value

# Create the ILB
Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP

# Configure a load-balanced endpoint for each node in $AGNodes by using ILB
ForEach ($node in $AGNodes)
{
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name "ListenerEndpoint" -LBSetName "ListenerEndpointLB" -Protocol tcp -LocalPort 1433 -PublicPort 1433 -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM
}

Nachdem Sie die Variablen festgelegt haben, kopieren Sie das Skript zum Ausführen aus dem Text-Editor in Ihre PowerShell-Sitzung. Wenn die Eingabeaufforderung weiterhin >> anzeigt, drücken Sie erneut die EINGABETASTE, um die Skriptausführung zu starten.

Sicherstellen der Installation von KB2854082, falls erforderlich

Wenn auf allen Servern im Cluster Windows Server 2008 R2 oder Windows Server 2012 ausgeführt wird, müssen Sie sicherstellen, dass der Hotfix KB2854082 auf allen lokalen Servern oder virtuellen Azure-Computern installiert ist, die Teil des Clusters sind. Auf allen Servern oder virtuellen Computern, die sich im Cluster befinden, aber nicht in der Verfügbarkeitsgruppe, sollte dieser Hotfix ebenfalls installiert sein.

Laden Sie in der Remotedesktopsitzung für jeden Clusterknoten KB2854082 in ein lokales Verzeichnis herunter. Installieren Sie dann den Hotfix nacheinander auf allen Clusterknoten. Wenn der Clusterdienst derzeit auf dem Clusterknoten ausgeführt wird, wird der Server am Ende der Installation des Hotfixes neu gestartet.

Warnung

Das Beenden des Clusterdiensts oder das Neustarten des Servers wirkt sich auf den Quorumzustand des Clusters und der Verfügbarkeitsgruppe aus und kann dazu führen, dass der Cluster offline geschaltet wird. Um die Hochverfügbarkeit des Clusters während der Installation zu gewährleisten, überprüfen Sie Folgendes:

Der Cluster weist einen optimalen Quorumzustand auf.
Vor der Installation des Hotfixes auf einem Knoten sind alle Clusterknoten online.
Bevor die Installation des Hotfixes auf einem anderen Knoten im Cluster ausgeführt wird, muss die Installation des Hotfixes auf einem Knoten vollständig abgeschlossen sein, einschließlich des kompletten Neustarts des Servers.

Öffnen der Firewallports in Verfügbarkeitsgruppenknoten

In diesem Schritt erstellen Sie eine Firewallregel, um den Testport für den Endpunkt mit Lastenausgleich (59999 wie bereits angegeben) zu öffnen, und eine weitere Regel, um den Port des Verfügbarkeitsgruppenlisteners zu öffnen. Da Sie den Endpunkt mit Lastenausgleich auf den virtuellen Computern erstellt haben, die Verfügbarkeitsgruppenreplikate enthalten, müssen Sie den Testport und den Listenerport auf den entsprechenden virtuellen Computern öffnen.

Starten Sie auf virtuellen Computern, die Replikate hosten, Windows-Firewall mit erweiterter Sicherheit.
Klicken Sie mit der rechten Maustaste auf Eingehende Regeln, und klicken Sie dann auf Neue Regel.
Wählen Sie auf der Seite Regeltyp die Option Port aus, und klicken Sie dann auf Weiter.
Wählen Sie auf der Seite Protokoll und Ports die Option TCP aus, geben Sie 59999 in das Feld Bestimmte lokale Ports ein, und klicken Sie dann auf Weiter.
Lassen Sie auf der Seite Aktion die Option Verbindung zulassen aktiviert, und klicken Sie dann auf Weiter.
Akzeptieren Sie auf der Seite Profil die Standardeinstellungen, und klicken Sie dann auf Weiter.
Geben Sie auf der Seite Name in das Textfeld Name einen Regelnamen ein, z.B. AlwaysOn-Listenertestport, und klicken Sie dann auf Fertig stellen.
Wiederholen Sie die vorherigen Schritte für den Port des Verfügbarkeitsgruppenlisteners (wie weiter oben im $EndpointPort-Parameter des Skripts angegeben), und geben Sie dann einen geeigneten Regelnamen an, z.B. AlwaysOn-Listenerport.

Erstellen des Verfügbarkeitsgruppenlisteners

Erstellen Sie den Verfügbarkeitsgruppenlistener in zwei Schritten. Erstellen Sie zunächst die Clientzugriffspunktclusterressource, und konfigurieren Sie Abhängigkeiten. Konfigurieren Sie als zweiten Schritt die Clusterressourcen mit PowerShell.

Erstellen des Clientzugriffspunkts und Konfigurieren der Clusterabhängigkeiten

In diesem Schritt erstellen Sie manuell den Verfügbarkeitsgruppenlistener im Failovercluster-Manager und in SQL Server Management Studio.

Öffnen Sie den Failovercluster-Manager über den Knoten, der das primäre Replikat hostet.
Wählen Sie den Knoten Netzwerke aus, und notieren Sie dann den Namen des Clusternetzwerks. Dieser Name wird in der Variablen $ClusterNetworkName im PowerShell-Skript verwendet.
Erweitern Sie den Clusternamen, und klicken Sie dann auf Rollen.
Klicken Sie im Bereich Rollen mit der rechten Maustaste auf den Verfügbarkeitsgruppennamen, und wählen Sie dann Ressource hinzufügen>Clientzugriffspunkt aus.
Erstellen Sie im Feld Name einen Namen für diesen neuen Listener, klicken Sie zweimal auf Weiter und anschließend auf Fertig stellen.
Schalten Sie den Listener oder die Ressource jetzt noch nicht online.
Klicken Sie auf die Registerkarte Ressourcen, und erweitern Sie dann den Clientzugriffspunkt, den Sie gerade erstellt haben. Die IP-Adressressource für jedes der Clusternetzwerke im Cluster wird angezeigt. Wenn dies eine reine Azure-Lösung ist, wird nur eine IP-Adressressource angezeigt.
Führen Sie einen der folgenden Schritte aus:
- So konfigurieren Sie eine Hybridlösung
  
  a. Klicken Sie mit der rechten Maustaste auf die IP-Adressressource, die Ihrem lokalen Subnetz entspricht, und wählen Sie dann Eigenschaften aus. Notieren Sie den Namen der IP-Adresse und des Netzwerks.
  
  b. Wählen Sie Statische IP-Adresse aus, weisen Sie eine nicht verwendete IP-Adresse zu, und klicken Sie dann auf OK.
- So konfigurieren Sie eine reine Azure-Lösung
  
  a. Klicken Sie mit der rechten Maustaste auf die IP-Adressressource, die Ihrem Azure-Subnetz entspricht, und wählen Sie dann "Eigenschaften" aus.
  
  Hinweis
  
  Kann der Listener später durch eine in Konflikt stehende IP-Adresse, die von DHCP ausgewählt wird, nicht online geschaltet werden, können Sie in diesem Eigenschaftenfenster eine gültige statische IP-Adresse konfigurieren.
  
  b. Ändern Sie im selben Fenster mit den Eigenschaften der IP-Adresse den Wert für IP-Adressname.
  Dieser Name wird in der Variablen $IPResourceName des PowerShell-Skripts verwendet. Wenn die Lösung mehrere virtuelle Azure-Netzwerke umfasst, wiederholen Sie diesen Schritt für jede IP-Ressource.

Konfigurieren der Clusterressourcen mit PowerShell

Für den ILB muss die IP-Adresse des internen Load Balancers verwendet werden, der zuvor erstellt wurde. Verwenden Sie das folgende Skript, um diese IP-Adresse in PowerShell abzurufen:
```
# Define variables
$ServiceName="<MyServiceName>" # the name of the cloud service that contains the AG nodes
(Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress
```

Kopieren Sie in einer der VMs das unten stehende PowerShell-Skript für Ihr Betriebssystem in einen Text-Editor, und legen Sie dann die Variablen auf die zuvor notierten Werte fest.

Verwenden Sie für Windows Server 2012 oder spätere Versionen das folgende Skript:

# Define variables
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP address resource name
$ILBIP = "<X.X.X.X>" # the IP address of the ILB

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

Verwenden Sie für Windows Server 2008 R2 das folgende Skript:

# Define variables
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP address resource name
$ILBIP = "<X.X.X.X>" # the IP address of the ILB

Import-Module FailoverClusters

cluster res $IPResourceName /priv enabledhcp=0 address=$ILBIP probeport=59999  subnetmask=255.255.255.255

Nachdem Sie die Variablen festgelegt haben, öffnen Sie ein Windows PowerShell-Fenster mit erhöhten Rechten, und fügen Sie das Skript aus dem Text-Editor in Ihre PowerShell-Sitzung ein, um es auszuführen. Wenn die Eingabeaufforderung weiterhin >> anzeigt, drücken Sie erneut die EINGABETASTE, um die Skriptausführung zu starten.
Wiederholen Sie die vorherigen Schritte für jede VM.
Mit diesem Skript wird die IP-Adressressource mit der IP-Adresse des Clouddiensts konfiguriert, und weitere Parameter wie der Testport werden festgelegt. Wenn die IP-Adressressource online geschaltet wird, kann sie auf Abrufvorgänge am Testport reagieren, die von dem zuvor erstellten Endpunkt mit Load Balancer ausgehen.

Onlineschalten des Listeners

Erweitern Sie im Failovercluster-Manager Rollen, und markieren Sie dann Ihre Verfügbarkeitsgruppe.
Klicken Sie auf der Registerkarte Ressourcen mit der rechten Maustaste auf den Listenernamen, und klicken Sie dann auf Eigenschaften.
Klicken Sie auf die Registerkarte Abhängigkeiten . Wenn mehrere Ressourcen aufgeführt sind, überprüfen Sie, ob die IP-Adressen OR-Abhängigkeiten aufweisen (keine AND-Abhängigkeiten).
Klicken Sie auf OK.
Klicken Sie mit der rechten Maustaste auf den Listenernamen, und klicken Sie dann auf Online schalten.
Sobald der Listener online ist, klicken Sie auf der Registerkarte Ressourcen mit der rechten Maustaste auf die Verfügbarkeitsgruppe, und klicken Sie dann auf Eigenschaften.
Erstellen Sie eine Abhängigkeit für die Ressource des Listenernamens (nicht den Namen der IP-Adressressourcen), und klicken Sie dann auf OK.
Starten Sie SQL Server Management Studio, und stellen Sie dann eine Verbindung mit dem primären Replikat her.
Wechseln Sie zu AlwaysOn High Availability>Groups><AvailabilityGroupName>>Availability Group Listeners.
Der Listenername, den Sie im Failovercluster-Manager erstellt haben, sollte angezeigt werden.
Klicken Sie mit der rechten Maustaste auf den Listenernamen, und klicken Sie dann auf Eigenschaften.
Geben Sie mit dem zuvor verwendeten „$EndpointPort“ im Feld Port die Portnummer für den Verfügbarkeitsgruppenlistener an (in diesem Tutorial war 1433 der Standardwert), und klicken Sie dann auf OK.

Aufgaben nach der Erstellung

Nachdem Sie den Verfügbarkeitsgruppenlistener erstellt haben, kann es erforderlich sein, die Clusterparameter „RegisterAllProvidersIP“ und „HostRecordTTL“ für die Listenerressource anzupassen. Diese Parameter können die Zeit für eine erneute Verbindung nach einem Failover verkürzen, was Verbindungstimeouts verhindern kann. Weitere Informationen zu diesen Parametern sowie Beispielcode finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners.

Testen des Verfügbarkeitsgruppenlisteners (innerhalb desselben virtuellen Netzwerks)

In diesem Schritt testen Sie den Verfügbarkeitsgruppenlistener mithilfe einer Clientanwendung, die im selben Netzwerk ausgeführt wird.

Für die Clientkonnektivität gelten folgende Anforderungen:

Clientverbindungen mit dem Listener müssen von Computern ausgehen, die sich in einem anderen Clouddienst als dem, der die AlwaysOn-Verfügbarkeitsreplikate hostet, befinden.
Wenn sich die AlwaysOn-Replikate in unterschiedlichen Subnetzen befinden, müssen Clients MultisubnetFailover=True in der Verbindungszeichenfolge angeben. Diese Bedingung führt zu parallelen Verbindungsversuchen mit Replikaten in unterschiedlichen Subnetzen. Zu diesem Szenario gehört eine regionsübergreifende AlwaysOn-Verfügbarkeitsgruppenbereitstellung.

Ein Beispiel ist die Verbindung mit dem Listener über einen der virtuellen Computer im gleichen virtuellen Azure-Netzwerk (jedoch nicht über den, der ein Replikat hostet). Eine einfache Möglichkeit zum Ausführen dieses Tests besteht darin, SQL Server Management Studio mit dem Verfügbarkeitsgruppenlistener zu verbinden. Eine weitere einfache Methode ist die Ausführung von SQLCMD.exe wie folgt:

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15

Hinweis

Wenn der EndpointPort-Wert 1433 ist, müssen Sie ihn nicht im Aufruf angeben. Beim vorherigen Aufruf wird zudem davon ausgegangen, dass der Clientcomputer zur gleichen Domäne gehört und dass dem Aufrufer Berechtigungen für die Datenbank mithilfe der Windows-Authentifizierung gewährt wurden.

Führen Sie beim Testen des Listeners ein Failover der Verfügbarkeitsgruppe durch, um sicherzustellen, dass Clients über Failover eine Verbindung mit dem Listener herstellen können.

Nächste Schritte

Zusätzlich zum automatischen Verbinden von Clients mit dem primären Replikat kann ein Listener verwendet werden, um schreibgeschützte Workloads an sekundäre Replikate umzuleiten. Auf diese Weise kann die Leistung und Skalierbarkeit Ihrer Lösung insgesamt verbessern. Weitere Informationen finden Sie unter Use ReadIntent Routing with Azure AlwaysOn Availability Group Listener (Verwenden von ReadIntent-Routing mit Azure AlwaysOn-Verfügbarkeitsgruppenlistener).