SQL Server AlwaysOn & WFC-Quorum
Vor- und Nachteile im Überblick

Grundlagen – WFC, AG und FCI

SQL Server AlwaysOn ist ein Überbegriff für zwei technisch eigenständige HA-Konzepte: die Availability Groups (AG) auf Datenbankebene und die Failover Cluster Instances (FCI) auf Instanzebene. Beide setzen auf den Windows Server Failover Cluster (WSFC) auf – einem verteilten Dienst, der Knoten, Ressourcen und das Quorum verwaltet.

Availability Group (AG)

Eine AG bündelt eine Gruppe von Benutzerdatenbanken, die gemeinsam auf synchronisierte Replikate gespiegelt werden. Der Primär-Replikat nimmt Lese-/Schreibzugriffe entgegen; Sekundär-Replikate können für Lesezugriffe, Backup und Reporting genutzt werden. Bis zu 9 Sekundär-Replikate (SQL Server 2022) sind möglich, davon bis zu 3 synchron.

Failover Cluster Instance (FCI)

Eine FCI präsentiert dem Netzwerk eine einzelne virtuelle SQL Server-Instanz hinter einer virtuellen IP. Die Datenbankdateien liegen auf einem gemeinsamen Speicher (Shared Disk, CSV, SMB 3.0). Bei einem Knotenausfall übernimmt ein anderer Knoten die virtuelle IP und den freigegebenen Speicher – der SQL Server startet auf dem neuen Knoten neu. Es findet kein synchrones Daten-Streaming statt.

AG + FCI kombiniert

In Enterprise-Umgebungen werden beide Technologien kombiniert: FCIs als hochverfügbare Knoten innerhalb einer AG. So besteht Schutz sowohl vor Knotenausfällen (FCI-Ebene) als auch vor Standortausfällen (AG-Ebene).

WSFC Quorum-Varianten

Das Quorum verhindert Split-Brain-Szenarien: Nur die Partition, die eine Mehrheit der Quorum-Stimmen hält, darf weiterhin als aktiver Cluster operieren. SQL Server selbst kennt kein eigenes Quorum-Protokoll – er verlässt sich vollständig auf den WSFC.

# Aktuellen Quorum-Modus anzeigen 
Get-ClusterQuorum -Cluster "SQLCLUSTER01" 
 
# File Share Witness konfigurieren 
Set-ClusterQuorum -Cluster "SQLCLUSTER01" ` 
-NodeAndFileShareMajority "\\fileserver\quorum_share" 
 
# Cloud Witness setzen (ab Windows Server 2016) 
Set-ClusterQuorum -Cluster "SQLCLUSTER01" ` 
-CloudWitness ` 
-AccountName "mystorage" ` 
-AccessKey "<Base64-Key>" ` 
-Endpoint "core.windows.net" 
 
# Knotengewichtung prüfen (Dynamisches Quorum) 
Get-ClusterNode | Select-Object Name, NodeWeight, State

Availability Groups mit Quorum

Der Standardbetrieb einer AG setzt ein funktionierendes WSFC-Quorum voraus. Nur so kann ein automatisches Failover sicher ausgeführt werden: Der Cluster vergewissert sich, dass eine Mehrheit der Stimmen vorliegt, bevor das Sekundär-Replikat zur neuen Primärinstanz promoted wird.

Synchron vs. asynchron – Replikationsmodi

# Neue Availability Group anlegen (synchron, Auto Failover) 
New-DbaAvailabilityGroup ` 
-Primary "SQL-NODE1" ` 
-Secondary "SQL-NODE2" ` 
-Name "AG_PROD" ` 
-Database "AppDB", "ReportDB" ` 
-SeedingMode "Automatic" ` 
-AvailabilityMode "SynchronousCommit" ` 
-FailoverMode "Automatic" ` 
-Confirm:$false 
 
# Asynchrones DR-Replikat an bestehende AG anfügen 
Add-DbaAgReplica ` 
-SqlInstance "SQL-NODE1" ` 
-Replica "SQL-DR" ` 
-AvailabilityGroup "AG_PROD" ` 
-AvailabilityMode "AsynchronousCommit" ` 
-FailoverMode "Manual" 
 
# AG-Gesundheitsstatus abrufen 
Get-DbaAgDatabase -SqlInstance "SQL-NODE1" -AvailabilityGroup "AG_PROD" | 
Select-Object Name, SynchronizationState, IsJoined, IsSuspended

Availability Groups ohne Quorum (Clusterless / Force)

Seit SQL Server 2017 können AGs auch ohne WSFC betrieben werden (Clusterless AG). Daneben gibt es den Notfallbefehl FORCE_FAILOVER_ALLOW_DATA_LOSS für Situationen, in denen der Cluster kein Quorum mehr hat und der Primär dauerhaft nicht erreichbar ist.

Clusterless AG (ab SQL Server 2017)

Force-Failover (FORCE_FAILOVER_ALLOW_DATA_LOSS)

-- !! Nur im Notfall !! 
-- Schritt 1: WSFC Quorum auf dem verbleibenden Knoten erzwingen 
Start-ClusterNode -FixQuorum 
 
-- Schritt 2: Force Failover auf dem Sekundär-Replikat ausführen 
ALTER AVAILABILITY GROUP [AG_PROD] 
FORCE_FAILOVER_ALLOW_DATA_LOSS; 
 
-- Schritt 3: Nach Wiederherstellung – alten Primär als Sekundär joinen 
ALTER DATABASE [AppDB] SET HADR RESUME; 
ALTER AVAILABILITY GROUP [AG_PROD] SET (ROLE = SECONDARY); 
 
-- Clusterless AG erstellen (SQL Server 2017+, CLUSTER_TYPE = NONE) 
CREATE AVAILABILITY GROUP [AG_READSCALE] 
WITH (CLUSTER_TYPE = NONE) 
FOR DATABASE [AppDB] 
REPLICA ON 
N'SQL-NODE1' WITH (ENDPOINT_URL = N'TCP://node1:5022', 
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL), 
N'SQL-NODE2' WITH (ENDPOINT_URL = N'TCP://node2:5022', 
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL);

Failover Cluster Instance (FCI)

Die FCI bietet HA auf Instanzebene. Da alle Knoten denselben freigegebenen Speicher nutzen, entfällt die Datenreplikation – der Failover ist ein Neustart der SQL-Instanz auf einem anderen Knoten unter Übernahme der gemeinsamen Ressourcen (virtuelle IP, Name, Speicher).

Aktiv/Aktiv vs. Aktiv/Passiv FCI

# SQL Server Cluster-Ressourcen anzeigen 
Get-ClusterResource | Where-Object { $_.ResourceType -eq "SQL Server" } | 
Select-Object Name, State, OwnerNode 
 
# Aktuellen Eigentümerknoten ermitteln 
Get-ClusterGroup -Cluster "SQLCLUSTER01" | 
Where-Object { $_.Name -like "SQL*" } | 
Select-Object Name, OwnerNode, State 
 
# Geplanten Knotenwechsel durchführen 
Move-ClusterGroup -Name "SQL Server (MSSQLSERVER)" ` 
-Node "SQL-NODE2" 
 
# Cluster-Informationen per SMO / dbaTools abrufen 
$srv = Connect-DbaInstance -SqlInstance "SQLCLUSTER01" 
$srv.IsClustered 
$srv.ClusterName 
$srv.ClusterQuorumState

Lizenzmodelle – Aktiv/Passiv & Software Assurance

Die Wahl des HA-Modells hat direkte Auswirkungen auf die SQL Server-Lizenzkosten. Microsoft gewährt unter bestimmten Bedingungen Lizenzerleichterungen für Hochverfügbarkeits-Replikate.

Entscheidungsmatrix – Welche Architektur wann?

# Alle AGs mit Replikat-Details 
Get-DbaAvailabilityGroup -SqlInstance "SQL-NODE1" | 
Select-Object Name, PrimaryReplica, AutomatedBackupPreference, 
HealthCheckInterval, FailureConditionLevel 
 
# Synchronisierungszustand aller AG-Datenbanken 
Get-DbaAgDatabase -SqlInstance "SQL-NODE1" | 
Format-Table AvailabilityGroup, Name, SynchronizationState, 
SynchronizationHealth, EstimatedDataLoss, 
EstimatedRecoveryTime -AutoSize 
 
# Replikat-Latenz und Log-Send-Queue (relevant für async DR) 
Get-DbaAgReplica -SqlInstance "SQL-NODE1" -AvailabilityGroup "AG_PROD" | 
Select-Object Name, Role, AvailabilityMode, FailoverMode, 
LogSendQueueSize, RedoQueueSize, LastSentTime, LastRedoneTime