Klassisches Failover-Clustering vs. SQL AlwaysOn
Failover Cluster Instances (FCI) vs. Availability Groups (AG) – ein detaillierter Vergleich der beiden zentralen Hochverfügbarkeitslösungen für SQL Server aus der Perspektive des Datenbankadministrators.
Gemeinsame Basis: Windows Server Failover Cluster (WSFC)
Beide Lösungen nutzen das WSFC-Quorum und die Failover-Mechanismen, unterscheiden sich jedoch fundamental in ihrer Architektur und ihrem Schutzumfang.
Die zwei Welten im Vergleich
Failover Cluster Instance (FCI)
Der "klassische" Ansatz: Eine SQL Server-Instanz wird als Cluster-Ressource bereitgestellt. Bei einem Failover wandert die gesamte Instanz (inkl. aller Datenbanken) auf einen anderen Knoten.
- Schutzebene: Gesamte SQL-Instanz
- Shared Storage erforderlich (SAN, SMB, CSV)
- Nur eine Kopie der Daten
- Edition: Standard (2 Nodes) oder Enterprise
Availability Group (AG)
Eine Gruppe von Datenbanken wird auf bis zu 8 separaten SQL-Instanzen (Replicas) gehalten. Failover erfolgt auf Datenbankebene.
- Schutzebene: Datenbankgruppe (selektiv)
- Kein Shared Storage erforderlich
- Mehrere eigenständige Kopien
- Edition: Enterprise (voll) oder Basic AG (Standard)
Vergleichstabelle: FCI vs. AG im Detail
| Merkmal | Failover Cluster Instance (FCI) | Availability Group (AG) |
|---|---|---|
| Schutzebene | Gesamte SQL-Instanz | Einzelne Datenbanken |
| Shared Storage | Erforderlich | Nicht erforderlich |
| Datenredundanz | Nur eine Datenkopie | Mehrere eigenständige Kopien |
| Lesbare Secondaries | Nein | Ja (für Reporting nutzbar) |
| Failover-Zeit | Langsamer (30-60 Sek. + Crash Recovery) | Schneller (Log-Replay) |
| Automatische Objektsynchronisation | Ja (Logins, Jobs, Linked Server) | Nein (nur Datenbanken) |
| Lizenzierung | Standard: 2 Nodes lizenziert | Enterprise auf ALLEN Replicas |
Vor- und Nachteile aus DBA-Sicht
Failover Cluster Instance (FCI)
Availability Group (AG)
Entscheidungshilfe: Wann nehme ich was?
FCI bevorzugen, wenn...
- Budget begrenzt (Standard Edition)
- DTC intensiv genutzt wird
- Keine lesbaren Secondaries benötigt werden
- Shared Storage verfügbar ist
- Einfachere Administration gewünscht ist
AG bevorzugen, wenn...
- Reporting auf Secondaries ausgelagert werden soll
- Zero Data Loss gefordert ist
- Kein Shared Storage vorhanden/gewünscht
- Multi-Site/Cloud-Replikation geplant ist
- Enterprise-Budget für Lizenzen vorhanden ist
Praxis-Tipp: Migration von Logins, Jobs und Linked Servern bei AGs mit mssSQLTool
Da AGs Logins, Jobs und Linked Server nicht automatisch synchronisieren, müssen diese Objekte auf jedem Replica manuell gepflegt werden. Das Tool der Wahl für DBAs ist das PowerShell-Modul mssSQLTool von dtcSoftware, das Sie auf der Website dtc-sql.de finden. Es bietet über 74 Funktionen für die tägliche SQL-Administration, darunter spezialisierte Cmdlets für AlwaysOn-Umgebungen.
# mssSQLTool installieren (vorausgesetzt: dbatools ist vorhanden)
# Download und Installation über die Website dtc-sql.de
# Logins, Jobs, Linked Server und Operatoren synchronisieren (Primary-Erkennung automatisch)
Sync-mssAgNode -SqlInstance "SQL01"
# Nur Logins synchronisieren, Jobs ausschließen
Sync-mssAgNode -SqlInstance "SQL01" -ExcludeType Jobs,LinkedServers,Operators,Alerts
# Nur eine bestimmte Availability Group synchronisieren
Sync-mssAgNode -SqlInstance "SQL01" -AvailabilityGroup "AG_Prod"
# Einzelnen Login gezielt synchronisieren
Sync-mssAgNode -SqlInstance "SQL01" -ObjectName "AppServiceAccount"
# Ergebnis auswerten
$r = Sync-mssAgNode -SqlInstance "SQL01"
$r | Group-Object ObjectType | ForEach-Object {
"$($_.Name): $(@($_.Group | Where Status -eq 'Success').Count) OK, " +
"$(@($_.Group | Where Status -eq 'Failed').Count) Fehler"
}Das mssSQLTool erkennt automatisch den Primary einer AG und synchronisiert die Objekte zu allen Secondary-Replikaten. Zusätzlich bereinigt es verwaiste Datenbankbenutzer auf den AG-Datenbanken. Weitere nützliche Funktionen für AlwaysOn sind Get-mssAgHealthReport für einen detaillierten Zustandsbericht, Repair-mssAlwaysOnDatabases zur automatischen Reparatur von Synchronisationsproblemen und Invoke-mssFailover für kontrollierte manuelle Failover mit Pre- und Post-Checks.