Wenn es um Hochverfügbarkeit für Microsoft SQL Server geht, stehen zwei etablierte Optionen zur Auswahl: Always On Availability Groups (AGs) und SQL Server Failover Cluster Instances (FCIs). Beide verfolgen das Ziel, Ausfälle abzufangen und die Datenverfügbarkeit zu gewährleisten – doch die technische Umsetzung, die Einsatzszenarien und die Anforderungen an die Umgebung unterscheiden sich erheblich. Die Wahl zwischen AGs und FCIs ist deshalb kein rein technischer Vergleich, sondern erfordert ein gutes Verständnis der geschäftlichen und infrastrukturellen Rahmenbedingungen.
Grundprinzipien und technologische Unterschiede
Failover Cluster Instances basieren auf einem klassischen Shared-Storage-Ansatz. Mehrere Knoten greifen auf einen gemeinsamen Speicher (z. B. ein SAN) zu, wobei jeweils nur ein Knoten aktiv ist. Im Fehlerfall übernimmt ein passiver Knoten die Kontrolle über den SQL Server-Dienst und den Speicher. Dieser Ansatz hat sich über viele Jahre bewährt, ist aber abhängig vom zugrundeliegenden Windows Server Failover Cluster (WSFC) und der Verfügbarkeit des gemeinsamen Speicher
Dem gegenüber stehen Always On Availability Groups, die ab SQL Server 2012 eingeführt wurden. Hierbei wird nicht die gesamte Instanz, sondern eine Auswahl von Datenbanken auf mehrere Replikate verteilt. Jeder Knoten hat seinen eigenen lokalen Speicher, auf den er synchron oder asynchron Replikationen erhält. Das bringt Vorteile bei Lese-Workloads und der geografischen Verteilung, erfordert jedoch ein umfassendes Verständnis von Datenkonsistenz, Latenz und Replikationsmechanismen.
Anwendungsszenarien im Vergleich
FCIs eignen sich besonders für Organisationen, die:
• eine vollständige Hochverfügbarkeit der gesamten SQL Server-Instanz benötigen,
• bestehende SAN-Infrastrukturen nutzen möchten,
• SQL-Agent-Jobs, Logins und verknüpfte Server als Teil der Hochverfügbarkeit absichern wollen,
• ein Szenario mit möglichst geringer Lizenzkomplexität anstreben.
Da FCIs auch mit der SQL Server Standard Edition betrieben werden können, lassen sich so unter Umständen signifikante Lizenzkosten sparen – vor allem bei kleineren Umgebungen.
Availability Groups spielen ihre Stärken aus, wenn:
• einzelne Datenbanken unabhängig voneinander hochverfügbar gemacht werden sollen,
• lesbare Replikate für Reporting- oder Backup-Zwecke gewünscht sind,
• ein hybrides oder Cloud-orientiertes Deployment angestrebt wird (Azure-Integration ist hier besonders nahtlos),
• ein höheres Maß an Granularität, Flexibilität und geografischer Verteilung notwendig ist.
Besonders wichtig: AGs sind in vollem Umfang nur mit der Enterprise Edition nutzbar. Die Standard Edition erlaubt lediglich die Nutzung von Basic Availability Groups, die auf zwei Replikate und eine Datenbank beschränkt sind – für viele Szenarien nicht ausreichend.
Verwaltung und Betrieb
FCIs lassen sich in der Regel einfacher verwalten, da sie wie eine normale Instanz erscheinen. Tools, Wartungspläne und Agent-Jobs laufen zentral weiter, und es müssen keine speziellen Replikationsstrategien berücksichtigt werden. Dennoch sollte man die Abhängigkeit vom zentralen Speicher und von WSFC nicht unterschätzen – dieser Layer muss gut konfiguriert und überwacht sein.
Availability Groups erfordern ein höheres Maß an Fachwissen: Latenzzeiten, Synchronisierungsstatus, potenzielle Split-Brain-Szenarien und automatisierte Failover-Konfigurationen müssen sorgfältig beobachtet und getestet werden. Dafür ermöglichen AGs ein deutlich flexibleres Deployment – etwa in Form von verteilten Umgebungen über mehrere Rechenzentren hinweg.
Ein weiterer wichtiger Punkt: Backups und Wartung müssen bei AGs pro Replikat sauber koordiniert werden.
Fazit: Keine Einheitslösung – aber klare Leitlinien
Ob Availability Groups oder Failover Cluster die richtige Wahl sind, lässt sich nicht pauschal beantworten. Entscheidend ist:
• Soll die gesamte Instanz hochverfügbar sein oder nur ausgewählte Datenbanken?
• Steht Shared Storage zur Verfügung – oder ist eine Lösung ohne gemeinsamen Speicher gewünscht?
• Werden lesbare Replikate benötigt?
• Wie hoch ist das Budget für Lizenzierung und Administration?
• Wie viel internes Know-how ist für Konfiguration, Monitoring und Betrieb vorhanden?
Wer auf einfache Verwaltung, geringere Lizenzkosten und klassische Verfügbarkeitskonzepte setzt, ist mit einem Failover Cluster gut beraten. Wer moderne, verteilte Architekturen bevorzugt und bereit ist, sich tiefer mit den Mechanismen von Replikation und Synchronisierung auseinanderzusetzen, findet in den Availability Groups ein mächtiges Werkzeug – insbesondere in größeren oder cloudbasierten Umgebungen.
