Das automatische Failover der AlwaysOn-Verfügbarkeitsgruppe funktioniert nicht

Spielen mit dem AG-Setup Ich habe die WSFC eingerichtet und mit zwei Knoten in einer Verfügbarkeitsgruppe namens DevClusterOnline konfiguriert. Auf beiden Knoten (DEV-AWEB5 primär, DEV-AWEB6 sekundär) wird Windows Server 2008 R2 ausgeführt.

Wenn ich die Gesundheit meiner AG überprüfe, bekomme ich Folgendes:

Wenn Sie die folgende Abfrage ausführen, wird folgende Ergebnismenge zurückgegeben:

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

Wenn ich DEV-AWEB5 trenne, kann ich keine Verbindung zum Group Listener (DevListener) herstellen, aber ich kann einen Ping-Befehl senden, der auf meinen Ping reagiert. Das Replikat - DEV-AWEB6 wechselt in den Status RESOLVING und auf meine Datenbank kann nicht zugegriffen werden. Ich kann jedoch manuell in Management Studio gehen und Failover auf DEV-AWEB6 setzen. Dann bin ich wieder betriebsbereit und DevListener akzeptiert wieder Verbindungen.

Angesichts der Tatsache, dass diese Fakten bestätigen, dass das Failover tatsächlich funktioniert, dass ich Commits synchronisiert und das automatische Failover konfiguriert habe, habe ich keine Ahnung, was passiert, wenn in meinem Setup eine Fehlfunktion auftritt.

Wenn ich DEV-AWEB5 trenne, erwarte ich, dass mein Replikat die Verbindung und damit auch DevListener beibehält. Ich gehe davon aus, dass ich durch das automatische Failover eine transparente Verbindung zum AG Listener herstellen kann. Aus Sicht des Endbenutzers sollte bei Verwendung eines Websystems nicht erkennbar sein, dass einer der DB-Server ausfällt.

Ich stecke hier fest. Kann mich bitte jemand aufklären, was ich falsch mache?

Wenn ich DEV-AWEB5 trenne

Definieren Sie "Trennen", wenn Sie so wollen. Ich vermute, Sie haben die Box hochgehalten, aber SQL Server heruntergefahren.

Ich kann keine Verbindung zum Gruppen-Listener (DevListener) herstellen, aber ich kann ihn anpingen und er reagiert auf meinen Ping

Dies liegt daran, dass der Listener nur ein virtueller Netzwerkname (VNN) innerhalb der WSFC-Clusterressourcengruppe für die dargestellte Verfügbarkeitsgruppe ist. Ihr DEV_AWEB5-Knoten besitzt weiterhin die Clusterressourcengruppe, aber es ist höchstwahrscheinlich nur die AG-Clusterressource, die sich in einem fehlerhaften Zustand befindet. Die VNN muss noch online sein (erwartetes Verhalten). Es zeigt einfach auf den Knoten, der diese Ressourcengruppe besitzt (in diesem Fall DEV-AWEB5). Wenn Sie PowerShell-Remoting aktiviert haben und Folgendes ausgeführt haben:

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

Wenn Sie RDP in DEV-AWEB5 ausführen können (vorausgesetzt, Sie verfügen über die Fähigkeit und Zugänglichkeit usw.), können Sie RDP auch unter Verwendung des Listenernamens ( mstsc /v:YourListenerName) ausführen . Es ist nur eine VNN.

Die Rückgabe davon wäre der Computername Ihres besitzenden Knotens.

Bei all Ihren Symptomen würde ich wetten, dass Sie Ihre Failover-Schwelle erreicht haben. Der Failover-Schwellenwert bestimmt, wie oft der Cluster in einem bestimmten Zeitraum versucht, ein Failover Ihrer Ressourcengruppe durchzuführen. Die Standardeinstellung dieser Werte ist max. Failover n - 1 (wobei n die Anzahl der Knoten ist) in einem Zeitraum von 6 Stunden . Sie können dies anhand des folgenden WSFC PowerShell-Befehls sehen:

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

Das gibt Ihnen nur die Einstellungen (die Sie natürlich ändern können, wenn Sie dies wünschen).

Um zu beweisen, dass dies bei Ihnen der Fall ist, müssen Sie das Clusterprotokoll generieren (die Systemereignisprotokolle gehen nur ins Detail, wenn "fehlgeschlagen" ist oder so etwas).

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

Das wird standardmäßig in den Ordner "C: \ Windows \ Cluster \ Reports" gestellt, und die Datei heißt "Cluster.log".

Wenn Sie dieses Clusterprotokoll öffnen, sollten Sie in der Lage sein, die folgende Zeichenfolge zu finden, die genau angibt, was passiert ist und warum es passiert ist:

Kein Failover über Gruppe [YourClusterGroupName] , FailoverCount [Anzahl der Failover] , Failover-Schwellenwert [Failover-Schwellenwert] , NodeAvailCount [Anzahl der verfügbaren Knoten ].

Die obige Meldung ist einfach eine WSFC, die Ihnen mitteilt, dass Ihre Gruppe kein Failover durchführen wird, weil zu viel passiert ist (Sie haben den Schwellenwert erreicht).

Warum passiert das? Nur um zu verhindern, dass der Ping-Pong-Effekt von Clusterressourcen zwischen Knoten zu häufig hin und her wechselt.

Während dies bei Failover-Tests häufig der Fall ist, weist dies in der Produktion normalerweise auf ein Problem hin, das untersucht werden sollte.

Das Hinzufügen von MSSQL als generische Serviceressource ist nicht die Antwort.

Dadurch wird nur der Cluster-Manager für den SQL Server-Dienst verantwortlich. OK, ja, das Failover wird automatisch ausgeführt. In SQL Server Configuration Manager werden Sie jedoch feststellen, dass Ihre Dienste jetzt auf "Manuell" eingestellt sind, um anzuzeigen, dass der Cluster-Manager aktiviert ist Jetzt haben Sie die Kontrolle über Ihren SQL Server-Dienst.

Sie beauftragen Cluster Manager mit der Verwaltung einer NON Clustered Application.

Es wird in Tränen enden.

Der richtige Ansatz, um die SQL Server-Verfügbarkeitsgruppen gemäß der MS-Dokumentation korrekt zu konfigurieren.

Stellen Sie außerdem sicher, dass Sie die auf der Registerkarte Cluster-Manager> Rollen> Failover definierten Failover-Parameter nicht überschreiten.

Wenn Sie diese Grenzwerte überschreiten, führt der Cluster kein Failover Ihrer Ressourcen durch und ein Fehler wird im Anwendungsereignisprotokoll veröffentlicht.