Ein Cluster schützt die Instanz. Eine Availability Group schützt die Datenbank.
„Wir haben einen SQL Server Cluster. Brauchen wir jetzt noch Always On?“ Die Frage hören wir oft, und sie zeigt das Problem: Die Begriffe werden vermischt. Always On ist bei Microsoft der Oberbegriff für zwei verschiedene Verfahren. Die Failover Cluster Instance (FCI), im Alltag „der Cluster“, schützt die ganze SQL-Server-Instanz. Die Availability Group (AG) schützt ausgewählte Datenbanken über eigene Datenkopien. Beide laufen auf einem Windows Server Failover Cluster, und doch schützen sie etwas anderes, mit anderen Folgen für Storage, Betrieb, Anwendung und Edition.
Dieser erste Teil erklärt die beiden Mechanismen, den Failover-Ablauf und was die Wahl im Alltag bedeutet. Editionsmatrix, Betriebskosten, Lizenzregeln und eine Entscheidungshilfe folgen in den weiteren Teilen.
Kurz gesagt
- „Always On“ ist kein Produkt, sondern zwei. Microsoft nennt so den Oberbegriff für Failover Cluster Instances und Availability Groups.
- Eine FCI stellt die Instanz hochverfügbar bereit. Ein Knoten ist aktiv, die anderen warten; alle teilen sich einen Storage. Verfügbarkeitsgruppen kommen dabei nicht zum Einsatz.
- Eine AG schützt Datenbanken, nicht die Instanz. Jedes Replikat ist eine eigene Instanz mit eigener Datenkopie; der Primary schickt seine Änderungen als Log an die Secondaries.
- Der Storage ist Stärke und Grenze der FCI. Eine Datenkopie, kein Schutz vor Storage-Ausfall, keine lesbare Kopie.
- Bei einer AG reisen Logins und Jobs nicht mit. Was zur Instanz gehört, muss auf jedem Replikat gepflegt werden; die Contained AG (ab SQL Server 2022, Enterprise) nimmt einen Teil davon ab.
- Standard kann beides, aber klein: FCI mit zwei Knoten und die Basic Availability Group mit einer Datenbank und zwei Replikaten. Die volle AG ist Enterprise.
Zwei Wörter, zwei Mechanismen
Ein Windows Server Failover Cluster (WSFC) ist die Plattform: mehrere Server, die sich gegenseitig überwachen, über ein Quorum entscheiden, wer noch mitspielen darf, und Rollen zwischen sich verschieben können. SQL Server setzt darauf zwei verschiedene Rollen:
| Failover Cluster Instance (FCI) | Availability Group (AG) | |
|---|---|---|
| Was geschützt wird | die ganze SQL-Server-Instanz | eine Gruppe von Benutzerdatenbanken |
| Wie viele Datenkopien | eine, auf gemeinsamem Storage | eine je Replikat |
| Wer läuft gleichzeitig | nur der aktive Knoten | alle Replikate, einer als Primary |
| Verbindungspunkt | virtueller Netzwerkname der Instanz | Listener der Gruppe |
| Was im Failover umzieht | die Instanz mit allem, was in ihr steckt | die Rolle „Primary“ für die Gruppe |
| Edition | Standard (2 Knoten), Enterprise (bis 16 Knoten) | Basic AG in Standard, volle AG in Enterprise |
Der Sprachgebrauch „SQL Server Cluster“ meint in der Praxis die FCI. Microsoft selbst spricht vom Cluster, wenn der WSFC gemeint ist. Für diesen Artikel gilt: Cluster = FCI, und das Wichtigste daran ist der Satz, mit dem viele Missverständnisse enden: Eine reine FCI enthält keine Verfügbarkeitsgruppen. Availability Groups sind ein eigenes Verfahren.
Die Failover Cluster Instance: eine Instanz, mehrere Knoten, ein Storage
Eine FCI ist eine SQL-Server-Instanz, die auf mehreren Clusterknoten installiert ist. Die Binärdateien liegen auf jedem Knoten, aber Daten und Transaktionslog liegen genau einmal: auf gemeinsamem Speicher, den alle Knoten erreichen können. Das kann ein SAN sein, iSCSI oder Fibre Channel, Storage Spaces Direct, eine SMB-Dateifreigabe oder ein Cluster Shared Volume. Nur TempDB darf lokal liegen, wenn der Pfad auf allen Knoten gültig ist.
Im WSFC bildet die Instanz eine Ressourcengruppe: Netzwerkname, IP-Adresse, die gemeinsamen Datenträger, der Datenbankdienst und der SQL Server Agent. Diese Gruppe gehört immer genau einem Knoten, dem Besitzer. Nur dort laufen die Dienste. Die anderen Knoten sind installiert, aber ihre Instanz ist gestoppt. Deshalb kann man dort nichts lesen und nichts abfragen.
Anwendungen verbinden sich mit dem virtuellen Netzwerknamen der Instanz, nicht mit einem Rechner. Beim Failover wird dieser Name am neuen Besitzer registriert; die Anwendung verbindet sich neu und landet wieder bei derselben Instanz. In Umgebungen mit mehreren Subnetzen hat jedes Subnetz eine eigene virtuelle IP; Clients sollten dann MultiSubnetFailover=True setzen, Microsoft empfiehlt das auch bei einem einzigen Subnetz.
Was mitgeht, weil es dieselbe Instanz ist: Datenbanken, Agent-Jobs, Linked Server, Serverkonfiguration. Es gibt nichts zu synchronisieren, weil es nur eine Instanz gibt. Das ist der große betriebliche Vorteil der FCI.
Was die FCI nicht leistet: Sie hat nur eine Kopie der Daten. Fällt der gemeinsame Speicher aus oder liefert er Fehler, hat die FCI nichts, worauf sie umschalten könnte. Microsoft sagt das ausdrücklich: Die FCI verlässt sich auf den Datenschutz der Speicherlösung. Wer eine zweite Datenkopie will, kombiniert die FCI mit einer AG oder mit Log Shipping auf physisch getrenntem Storage, oder nutzt Storage-Replikation des Herstellers.
Das Quorum entscheidet, ob der Cluster überhaupt arbeiten darf. Verliert der WSFC sein Quorum, geht die FCI offline, und ein Administrator muss eingreifen. Microsoft empfiehlt eine ungerade Zahl von Stimmen und seit Windows Server 2012 R2 immer einen Zeugen: Datenträger, Dateifreigabe oder Cloud-Zeuge in Azure.
Die Availability Group: mehrere Instanzen, mehrere Datenkopien, eine Gruppe
Eine AG ist ein Container für eine Gruppe von Benutzerdatenbanken, die gemeinsam umschalten. Jedes Replikat ist eine eigenständige SQL-Server-Instanz auf einem eigenen Clusterknoten, mit eigener Kopie der Datenbanken auf eigenem Storage. Gemeinsamer Speicher ist nicht nötig. Der Primary nimmt Schreibzugriffe an und schickt seine Transaktionslog-Records an die Secondaries, die sie nachspielen. Eine volle AG erlaubt bis zu neun Replikate.
Zwei Betriebsarten bestimmen, was ein Failover kostet:
- Synchroner Commit: Der Primary bestätigt eine Transaktion erst, wenn die Secondary das Log hart geschrieben hat. Kein Datenverlust beim Failover, dafür höhere Commit-Latenz; synchrone Replikate gehören deshalb in dasselbe Rechenzentrum oder an eine schnelle Leitung.
- Asynchroner Commit: Der Primary wartet nicht. Die Secondary kann zurückliegen, ein Failover dorthin ist nur erzwungen möglich, mit möglichem Datenverlust. Geeignet für große Entfernungen und Disaster Recovery.
Automatisches Failover gibt es nur bei synchronem Commit, synchronisiertem Ziel, gesundem Quorum und erfüllter Failover-Richtlinie. Der Health-Check arbeitet mit Standardwerten von 30 Sekunden für den Health-Check-Timeout und 20 Sekunden für den Lease-Timeout; Microsoft rät davon ab, sie zu senken.
Der Listener ist der virtuelle Netzwerkname der Gruppe. Er zeigt immer auf den aktuellen Primary; mit ApplicationIntent=ReadOnly kann er Leser auf eine lesbare Secondary umleiten. Nach einem Failover trennt er bestehende Verbindungen, neue landen beim neuen Primary.
Was nicht mitgeht: Alles, was zur Instanz gehört und nicht in der Datenbank liegt. Logins, Agent-Jobs, Linked Server, Credentials, Serverkonfiguration und Berechtigungen auf Serverebene müssen auf jedem Replikat gepflegt werden, Logins mit gleichen SIDs, Jobs mit einer Prüfung, ob die Instanz gerade Primary ist. Das ist der betriebliche Preis der AG. Seit SQL Server 2022 (Enterprise) gibt es dafür die Contained Availability Group, die Benutzer, Logins, Berechtigungen und Jobs in eigenen System-Datenbanken der Gruppe führt. Sie hat Grenzen: keine Replikation, keine SSIS-Pakete, keine Wartungspläne, und Verbindungen nur über den Listener der Contained AG.
Dazu kommen laufende Aufgaben, die eine FCI nicht kennt: Beim Hinzufügen eines Replikats muss die Datenbank dorthin kommen, per Backup und Restore oder per Automatic Seeding über den Log-Stream. Danach müssen Log-Versand und Redo überwacht werden. Solange eine Secondary angehalten ist, wird das Log des Primary nicht abgeschnitten.
Der Failover im Vergleich
| FCI | AG (synchron, automatisch) | |
|---|---|---|
| Was umschaltet | der Besitz der Ressourcengruppe: Name, IP, Datenträger, Dienste | die Rolle „Primary“ innerhalb der Gruppe |
| Was dann passiert | die Instanz startet auf dem neuen Knoten und durchläuft für jede Datenbank die Recovery: abgeschlossene Transaktionen werden nachgespielt, offene zurückgerollt | die Secondary übernimmt die Rolle; sie hat das Log bereits nachgespielt, die Datenbanken sind schon da |
| Dauer bestimmt durch | Dienststart und Recovery, also vor allem durch die längste offene Transaktion zum Zeitpunkt des Failovers | Erkennung und Rollenwechsel; Microsoft spricht von meist Sekunden |
| Datenverlust | keiner; es gibt nur eine Datenkopie | keiner bei synchronem Commit; bei asynchronem Replikat nur erzwungen, mit möglichem Verlust |
| Anwendung | verbindet sich neu zum selben Namen | verbindet sich neu zum Listener, Leser gegebenenfalls umgeleitet |
| Wer entscheidet | der WSFC über die Failover-Richtlinie der Instanz | die flexible Failover-Richtlinie der AG, oder manuell |
Microsoft vergleicht den FCI-Failover mit dem Aus- und Einschalten eines Servers: Die Instanz ist kurz weg und kommt mit allem zurück. Wie lange die Recovery dauert, hängt von der Last und den offenen Transaktionen ab. Accelerated Database Recovery (ab SQL Server 2019, auch in Standard) macht diese Phase weitgehend unabhängig von langen Transaktionen; das gilt für die Datenbanken einer FCI genauso wie für die einer AG. Konkrete Sekunden nennt Microsoft nicht, und wir nennen auch keine: Das messen wir in Teil 2 im Lab.
Was die Wahl im Alltag bedeutet
Betrieb. Bei der FCI patchen Sie den passiven Knoten, schwenken um, patchen den anderen; die Instanz bleibt eine. Bei der AG patchen Sie jedes Replikat, müssen aber Logins, Jobs und Konfiguration auf allen gleich halten. Failover einer AG lösen Sie per T-SQL oder SSMS aus, nicht im Failover Cluster Manager.
Anwendung. Beide Verfahren trennen beim Failover die Verbindungen. Eine Anwendung ohne Wiederverbindungslogik bleibt in beiden Fällen stehen. Bei einer AG kommt die Entscheidung dazu, ob Leser über den Listener auf eine Secondary dürfen.
Storage und Netz. Die FCI braucht gemeinsamen Speicher und verlässt sich auf ihn. Die AG braucht pro Replikat eigenen Speicher und ein Netz, das den Log-Strom trägt; bei synchronem Commit zahlt jede Transaktion die Latenz dieses Netzes.
Lesbare Kopien und Backups. Nur eine volle AG (Enterprise) hat lesbare Secondaries und kann Backups auf Secondaries ausführen; seit SQL Server 2025 auch Voll- und Differentialbackups, vorher nur Log- und Copy-Only-Backups. Eine FCI hat keine zweite Kopie, auf der etwas laufen könnte.
Testbarkeit. Ein Failover, den niemand geprobt hat, ist kein Schutz. Beide Verfahren lassen sich geplant umschalten; planen Sie das als wiederkehrende Übung ein, nicht als Ernstfall.
Und bei allem gilt: Hochverfügbarkeit ersetzt kein Backup. Eine Secondary ist keine Sicherung. Ein Anwenderfehler wird sofort repliziert. Nur ein getestetes Backup-Konzept oder Log Shipping mit verzögertem Restore fängt das ab. Wie Sie Ziele für Datenverlust und Wiederanlaufzeit (RPO und RTO) mit dem Erreichbaren vergleichen, zeigt unser Beitrag Backup und Restore: den Ernstfall planen.
Basic AG und Editionen in einem Absatz
Die Standard Edition bietet die FCI mit zwei Knoten und seit SQL Server 2016 die Basic Availability Group: eine Datenbank je Gruppe, zwei Replikate, synchron oder asynchron, automatisches Failover möglich. Nicht möglich sind lesbare Secondaries, Backups und Integritätsprüfungen auf der Secondary, Distributed AGs und das spätere Hochstufen zur vollen AG; dafür muss die Gruppe neu angelegt werden. Mehrere Basic AGs je Instanz sind erlaubt. Die volle AG mit bis zu neun Replikaten, lesbaren Secondaries, Contained AG und Distributed AG ist Enterprise. SQL Server 2025 ändert daran nichts: Standard bekommt höhere Kapazitätsgrenzen (32 Cores, 256 GB Buffer Pool) und den Resource Governor, aber keine Erweiterung bei Availability Groups. Die vollständige Matrix für 2017 bis 2025, was sie im Betrieb kostet und wann sich Enterprise rechnet, sind Teil 2 und Teil 3.
Ein Satz zur Lizenz, weil er die Architektur mitbestimmt: Passive Failover-Replikate sind lizenzrechtlich nur mit Software Assurance oder Subscription vorgesehen, und „passiv“ heißt, dass das Replikat keine Daten an Benutzer liefert. Eine lesbare Secondary ist damit nicht passiv. Die Regeln im Einzelnen und ihre Grenzen behandelt Teil 3; die Prüfung Ihres Vertrags bleibt Ihre Aufgabe.
Sonderfall: eine FCI als AG-Replikat
Beides lässt sich kombinieren: Eine FCI kann ein Replikat einer AG hosten, etwa um eine bestehende FCI um Disaster Recovery auf Datenbankebene zu ergänzen. Dabei gilt: Ein von einer FCI gehostetes Replikat unterstützt nur manuelles AG-Failover, und eine FCI stellt je AG nur ein Replikat. Für automatische Hochverfügbarkeit ist die Kopplung deshalb ungeeignet, für ein zweites Rechenzentrum brauchbar. Die Kombination überlagert die beiden Grundmodelle nicht; sie setzt sie übereinander.
Häufige Fragen
Ist „Always On“ dasselbe wie eine Availability Group? Nein. Always On ist bei Microsoft der Oberbegriff für FCI und AG. Wer „Always On“ sagt und die AG meint, sollte das dazusagen.
Brauche ich für eine FCI die Enterprise Edition? Nein. Standard erlaubt eine FCI mit zwei Knoten, Enterprise bis zu 16.
Schützt eine FCI vor einem Storage-Ausfall? Nein. Sie hat nur eine Datenkopie auf dem gemeinsamen Speicher. Für eine zweite Kopie braucht es eine AG, Log Shipping oder Storage-Replikation.
Reisen Logins und Agent-Jobs in einer AG mit? Nein. Sie gehören zur Instanz und müssen auf jedem Replikat gepflegt werden. Die Contained AG (ab 2022, Enterprise) führt sie mit der Gruppe.
Kann ich eine Basic AG später zu einer vollen AG machen? Nein. Die Gruppe muss entfernt und in einer Enterprise-Umgebung neu angelegt werden.
Was unterscheidet Log Shipping von einer AG? Log Shipping automatisiert Log-Backup, Kopie und Restore, der Rollenwechsel bleibt manuell, und ein verzögerter Restore kann Anwenderfehler abfangen. Eine AG repliziert laufend und kann automatisch umschalten.
Wie es weitergeht
Danach folgen:
- Teil 3 · Wann lohnt sich Enterprise? Anforderungen, die eine volle AG rechtfertigen, und die Lizenzregeln dahinter.
- Teil 4 · Entscheidungshilfe: wenige Fragen, begründete Kandidaten, keine Entscheidung aus drei Klicks.
Wenn Sie vor der Entscheidung stehen
Ob FCI, Basic AG oder volle AG zu Ihrer Anwendung passt, hängt an Zielen für Datenverlust und Wiederanlauf, an Storage, Standorten, Lesebedarf und daran, wer das Ganze betreibt. Im Verfügbarkeits-Review unseres Health Checks vergleichen wir Ihre Ziele mit dem, was Ihre Umgebung heute erreicht. Für Planung, Aufbau und Migration steht die Leistung Infrastruktur und Hochverfügbarkeit. Wir beraten ohne eigenes Lizenzverkaufsinteresse.
Quellen
Alle Aussagen dieses Teils stützen sich auf Microsoft-Dokumentation, geprüft am 08.11.2026: Always On Failover Cluster Instances; What is an Always On Availability Group; Basic Availability Groups; Failover Cluster Instance with Availability Groups; Editions and Supported Features 2017, 2019, 2022 und 2025; What's New in SQL Server 2025; Contained Availability Groups; Availability Modes; Failover and Failover Modes; Listeners and Client Connectivity; Lease and Health Check Timeout; Accelerated Database Recovery; Business Continuity and Database Recovery; Microsoft SQL Server Licensing Guidance und Product Terms (Fail-over rights). Die Zahl synchroner Replikate je Version nennt Microsoft auf verschiedenen Seiten unterschiedlich; dieser Teil nennt deshalb keine.