AlwaysOn erlaubt nicht das Setzen eines Preferred Owners in den Cluster-Einstellungen. Der Preferred Owner lässt sich normalerweise so vewenden, dass der Cluster-Dienst (falls Failback eingeschaltet ist) automatisch wieder auf einen der bevorzugten Knoten zurück schwenkt. Dies kann durchaus sehr praktisch sein, da in der Praxis evt. ein Knoten mit deutlich besserer Hardware ausgestattet ist als ein anderer. Sollten beide Knoten verfügbar sein, will man, dass der Dienst auf dem Knoten mit der schnellsten Hardware läuft.
Auch bei AlwaysOn AAGs wäre dies sehr praktisch, wird aber nicht unterstützt. Zwar kann man einen Preferred Owner bei der Rolle im Failover Cluster Manager eingeben, diese Einstellung wird für die AAG allerdings ignoriert.
Geht man im Failover Cluster Manager auf die entsprechende AAG und wählt Properties, so sieht man die Preferred Owner.
Zwar lässt sich hier ein Knoten als Preferred Owner einstellen und es kommt auch nicht zu einer Fehlermeldung, dennoch wird dieser Preferred Owner bei der Failback Einstellung ignoriert im Zusammenspiel mit AlwaysOn.
Ich habe dafür folgenden Code geschrieben, der einen Failback auf den aktuellen Knoten auf dem der T-SQL Code ausgeführt wird, durchführt:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
DECLARE @CanFailback int; SELECT @CanFailback=COUNT(*) FROM sys.dm_hadr_availability_replica_states S JOIN sys.availability_groups A ON S.group_id=A.group_id WHERE S.is_local=1 AND S.role=2 AND S.connected_state=1 AND S.recovery_health=1 AND A.name=N'AdvAAG5'; IF(@CanFailback=1) BEGIN ALTER AVAILABILITY GROUP [AdvAAG5] FAILOVER; END |
In diesem Beispiel heißt die AAG AdvAAG5. Der Failback soll dabei nur ausgelöst werden, wenn der aktuelle Knoten verbunden ist und die AAG übernehmen kann. Weiterhin wird hier geprüft, dass der aktuelle Knoten der den Failback auslöst gerade nicht der Primärknoten ist, der bereits die AAG Primär betreibt, denn in diesem Fall ist ein Failback natürlich unnötig.
SQL Server Agent Job erstellen für Failback
Als nächstes richten wir nun einen SQL Server Agent Job ein, der nur auf dem Knoten läuft, der normal den Dienst betreiben soll, also unseren Preferred Owner. In der Regel sollte das der schnellste Knoten sein, falls die Knoten nicht über die gleiche Hardware verfügen.
Dazu wird zuerst ein neuer Job im SQL Server Agent erstellt. WICHTIG: Dieser Job darf nur auf dem Knoten laufen, der nachher auch die AAG Primär betreiben soll, wenn der aktuelle Knoten synchron läuft.
Wir geben dem Job einen Namen.
Jetzt wird für den Job ein einzelner neuer T-SQL Jobstep hinzugefügt.
Innerhalb des Jobsteps kommt jetzt der T-SQL Code von oben rein, der den Failback auslöst. Hier ist darauf zu achten, als Database die master Datenbank anzugeben!
Danach geben wir dem Job noch einen Zeitplan, damit er automatisch läuft.
In diesem Fall lassen wir den Job alle 10 Minuten laufen. Alle 10 Minuten wird also der dieser Knoten versuchen einen Failover durchzuführen, wenn er nicht der Primärknoten ist, und die AAG wieder zu sich holen. Damit können wir das Verhalten eines Preferred Owners für die AAG simulieren. So können wir sicherstellen, dass im Cluster die AAG normalerweise auf dem gewünschten Knoten läuft. Nur falls der Hauptknoten offline ist, darf die AAG auch auf dem anderen Knoten primär laufen. In diesem Fall holt sich der Hauptknoten die AAG auch nicht zurück und führt kein Failback durch.
Doch VORSICHT: Diese Vorgehensweise hat durchaus auch Nachteile! So wird in diesem Fall der Hauptknoten immer wenn er synchron läuft, die AAG an sich reißen (spätestens nach 10 Minuten). Will man dies aktiv nicht, beispielsweise weil der Hauptknoten gepatcht werden soll, muss man vorher den erstellten Job deaktivieren.