Microsoft SQL Server 2025: Cluster-Varianten im Vergleich

Welche Microsoft SQL Server 2025 Cluster-Variante passt zu einem Unternehmen? Die Antwort hängt zuerst davon ab, was geschützt werden soll: eine vollständige Instanz, einzelne Datenbanken, ein gesamter Standort oder lediglich ein zusätzlicher Wiederherstellungsweg. "Always On" bezeichnet dabei keine einzelne Clustertechnik. Microsoft verwendet den Begriff als Dach für Failover Cluster Instances und Availability Groups. Log Shipping gehört ebenfalls zu den wichtigen Verfügbarkeitsoptionen, ist aber kein Cluster mit automatischem Failover.

Welche Microsoft SQL Server 2025 Cluster-Varianten gibt es?

Die wichtigsten Varianten unterscheiden sich im Schutzumfang und darin, ob mehrere Systeme dieselben Daten auf einem gemeinsamen Speicher nutzen oder eigene Datenkopien halten.

Eine FCI, eine AG und Log Shipping lösen also nicht dieselbe Aufgabe. Eine FCI schützt beispielsweise SQL-Server-Agent-Aufträge und andere Bestandteile der Instanz beim Knotenwechsel mit. Eine klassische AG konzentriert sich dagegen auf die Datenbanken in der Gruppe; Instanzobjekte müssen gesondert berücksichtigt werden. Die Wahl sollte deshalb bei den Anforderungen der Anwendung beginnen, nicht bei einer bevorzugten Produktfunktion.

Wann eignet sich eine Failover Cluster Instance?

Eine Failover Cluster Instance ist eine SQL-Server-Instanz, die auf mehreren Knoten eines Windows Server Failover Clusters installiert wird. Im Normalbetrieb ist jeweils ein Knoten für die Instanz aktiv. Fällt dieser aus oder wird ein geplanter Wechsel ausgelöst, übernimmt ein anderer Knoten die Clusterressourcen und startet die SQL-Server-Dienste. Anwendungen verbinden sich weiterhin über den virtuellen Namen der Instanz.

Der wichtigste Vorteil liegt im Schutz auf Instanzebene. Neben den Benutzerdatenbanken wechseln auch die zur Instanz gehörenden Dienste und Objekte mit. Das ist für Anwendungen interessant, die stark von Instanzkonfiguration, SQL-Server-Agent-Aufträgen oder Linked Servers abhängen. Eine FCI kann damit betrieblich einfacher sein als eine AG, bei der solche Bestandteile auf den Replikaten abgestimmt werden müssen.

Die entscheidende Grenze ist der Speicher: Alle Knoten einer FCI benötigen Zugriff auf die dafür vorgesehene gemeinsame Speicherlösung. Ein anderer Knoten bedeutet nicht automatisch eine zweite, unabhängige Kopie der Daten. Fällt die gemeinsame Speicherbasis aus, schützt ein reiner Knotenwechsel nicht ausreichend. Für standortübergreifende Datensicherheit kann eine FCI deshalb mit einer weiteren Methode wie AG oder Log Shipping kombiniert werden.

Ein FCI-Failover verursacht außerdem eine Unterbrechung. SQL Server startet auf dem Zielknoten und führt die notwendige Datenbankwiederherstellung aus. Wie lange das dauert, hängt unter anderem von Workload und Wiederherstellungsaufwand ab. Unternehmen sollten keine feste Wiederanlaufzeit aus der Bezeichnung „automatischer Failover“ ableiten, sondern reale Tests mit ihrer Anwendung durchführen.

Wann sind Availability Groups die bessere Wahl?

Always On Availability Groups replizieren die ausgewählten Datenbanken einer Gruppe auf andere SQL-Server-Instanzen. Jede Replik verwendet eigenen Speicher. Damit schützen AGs nicht nur gegen den Ausfall eines einzelnen Knotens, sondern können auch eine getrennte Datenkopie an einem anderen Standort bereitstellen. Ein Listener stellt Anwendungen einen Verbindungspunkt bereit, ohne dass sie den aktuell primären Server kennen müssen.

AGs sind besonders interessant, wenn Unternehmen niedrige Ziele für Datenverlust und Wiederanlaufzeit verfolgen oder zusätzlich lesbare Sekundärreplikate benötigen. Allerdings entscheidet die Konfiguration über das Verhalten. Für einen automatischen Failover müssen geeignete Replikate synchron arbeiten und den erforderlichen Zustand erreicht haben. Bei asynchroner Übertragung kann ein erzwungener Wechsel Datenverlust verursachen. „AG vorhanden“ ist daher keine belastbare Aussage über den tatsächlich erreichbaren Recovery Point Objective (RPO).

Auf Windows benötigt eine hochverfügbare AG einen Windows Server Failover Cluster als zugrunde liegende Clusterinfrastruktur. Anders als bei einer FCI müssen die AG-Replikate jedoch keinen gemeinsamen Datenspeicher verwenden. Auf Linux übernimmt eine unterstützte externe Clusterlösung diese Rolle; die Voraussetzungen unterscheiden sich von einer Windows-Implementierung. Eine clusterlose AG mit CLUSTER_TYPE = NONE kann für Migration oder lesbare Kopien sinnvoll sein, gilt aber nicht als Hochverfügbarkeitslösung mit automatischem Failover.

Was unterscheidet Basic AG und Enterprise AG?

Die Standard Edition von SQL Server 2025 unterstützt Basic Availability Groups: Eine Gruppe enthält genau eine Verfügbarkeitsdatenbank und besteht aus einem primären sowie einem sekundären Replikat. Die sekundäre Kopie steht nicht für lesende Abfragen, Backups oder Integritätsprüfungen zur Verfügung. Mehrere Basic AGs pro Instanz sind möglich, müssen aber jeweils separat geplant und betrieben werden.

Die Enterprise Edition unterstützt erweiterte AGs mit mehreren Datenbanken pro Gruppe und zusätzlichen Replikaten. Sie ermöglicht außerdem lesbare Sekundärreplikate und Distributed Availability Groups. Das bedeutet nicht, dass Enterprise immer erforderlich ist: Eine einzelne geschäftskritische Datenbank kann durchaus zur Basic AG passen. Sobald jedoch mehrere Datenbanken gemeinsam umschalten müssen oder Berichte auf einem Sekundärreplikat laufen sollen, werden die Grenzen von Basic AG für das Design entscheidend.

Wann lohnt sich eine Distributed Availability Group?

Eine Distributed Availability Group verbindet zwei eigenständige Availability Groups. Diese können auf getrennten Clustern und an unterschiedlichen Standorten liegen. Der Ansatz ist vor allem für Disaster Recovery und Migrationen interessant, wenn Organisationen nicht alle Replikate in einem gemeinsamen, standortübergreifenden Cluster betreiben möchten. Auch unterschiedliche Plattformumgebungen können in einer passenden Architektur über eine Distributed AG verbunden werden.

Der Vorteil ist die Trennung der Clusterverwaltung. Am primären und am zweiten Standort kann jeweils eine eigene AG existieren. Zwischen diesen Gruppen wird eine zusätzliche Replikationsbeziehung eingerichtet. Das bietet Gestaltungsspielraum, erhöht aber die Zahl der Komponenten, die überwacht und im Notfall verstanden werden müssen: Replikate, Listener, Datenfluss und Umschaltverfahren. Eine Distributed AG sollte daher nicht allein wegen ihrer größeren Reichweite gewählt werden.

Für Unternehmen mit Standard Edition ist diese Variante keine Option: Die Editionsübersicht führt Distributed Availability Groups für Enterprise auf; Basic AGs können nicht Teil einer Distributed AG sein. Wer zwei Standorte mit Standard Edition absichern möchte, muss andere unterstützte Architekturen und seine RPO-/RTO-Ziele prüfen.

Ist Log Shipping eine Cluster-Alternative?

Log Shipping erstellt Transaktionsprotokoll-Backups einer primären Datenbank, kopiert sie auf einen oder mehrere sekundäre Server und spielt sie dort ein. Der Vorgang kann automatisiert laufen; der Wechsel auf eine sekundäre Datenbank erfolgt jedoch nicht automatisch. Deshalb ist Log Shipping eher eine Disaster-Recovery-Alternative als ein Ersatz für einen Cluster, der ohne manuelle Entscheidung umschalten soll.

Die Variante kann passen, wenn eine Anwendung eine längere Wiederanlaufzeit toleriert und ein geplanter manueller Umschaltprozess akzeptabel ist. Ein bewusst verzögertes Einspielen der Protokolle kann zusätzlich helfen, auf Bedienfehler zu reagieren. Dem stehen ein von den Backup- und Kopierintervallen abhängiger möglicher Datenverlust und mehr Arbeit beim Rollenwechsel gegenüber. Auch Instanzobjekte und die Umstellung der Anwendungsverbindungen müssen berücksichtigt werden.

Log Shipping und AG schließen sich nicht grundsätzlich aus. Eine Organisation kann beispielsweise eine lokale AG für schnellen Failover betreiben und zusätzlich Log Shipping als getrennten Wiederherstellungsweg prüfen. Ob diese Kombination sinnvoll ist, hängt von der Anwendung und den verfügbaren Betriebsressourcen ab. Keine der Varianten ersetzt getestete Backups und eine dokumentierte Wiederherstellung.

Was ist bei SQL Server 2025 neu?

SQL Server 2025 führt keine völlig neue Grundkategorie von Datenbankclustern ein. Microsoft erweitert jedoch Verfügbarkeits-, Diagnose- und Sicherheitsfunktionen, die bei der Architekturentscheidung relevant sind. Dazu zählen Verbesserungen beim Wiederanlauf einer AG, beim Datenfluss zwischen Replikaten und bei Distributed AGs. Für persistente AG-Zustandsprobleme kann RestartThreshold auf 0 gesetzt werden, damit der Windows Server Failover Cluster die AG-Ressource unmittelbar umschaltet. Eine solche Einstellung gehört in einen getesteten Betriebsplan; schnelleres Auslösen allein garantiert noch keine kürzere Unterbrechung der Anwendung.

Weitere Änderungen betreffen die Verwaltung: Bei einem AG-Listener kann eine IP-Adresse entfernt werden, ohne den gesamten Listener zu löschen. Für lesendes und schreibendes Routing lässt sich eine bestehende Routingangabe wieder auf NONE setzen. SQL Server 2025 verbessert außerdem die Synchronisierung verteilter AGs in bestimmten asynchronen Szenarien. Welche Neuerung im Einzelfall einen messbaren Vorteil bringt, sollte anhand des eigenen Netzwerk- und Lastprofils geprüft werden.

Für AGs, FCIs und Log Shipping ist die Unterstützung von TLS 1.3 mit TDS 8.0 bedeutsam. Sie verlangt dennoch eine sorgfältige Prüfung von Zertifikaten und Verbindungseinstellungen. Bei bestehenden Log-Shipping-Topologien ist insbesondere zu unterscheiden, was nach einem Upgrade weiterläuft und was für eine ausdrücklich erzwungene strengere Verschlüsselung neu konfiguriert werden muss. Sicherheitseinstellungen sollten deshalb Teil des Migrationstests sein, nicht erst eine Aufgabe nach dem Produktivwechsel.

Welche Variante passt zu welchem Szenario?

Diese Zuordnung ist eine Ausgangshilfe, keine automatische Produktempfehlung. Besonders wichtig ist, ob eine Anwendung mehrere Datenbanken konsistent als Einheit benötigt. Ebenso relevant sind Anmeldekonten, SQL-Server-Agent-Aufträge und externe Abhängigkeiten. Ein technisch erfolgreicher Datenbank-Failover ist wenig wert, wenn die Anwendung danach wegen fehlender Instanzobjekte, eines ungeeigneten Verbindungsnamens oder nicht erreichbarer Dienste ausfällt.

Wie planen Unternehmen die Cluster-Architektur?

1. RPO und RTO festlegen. RPO beschreibt den maximal tolerierbaren Datenverlust, RTO die angestrebte Wiederanlaufzeit. Beide Werte sollten pro Anwendung feststehen, bevor eine Technik ausgewählt wird.
2. Schutzumfang erfassen. Dokumentieren Sie Datenbanken, Instanzobjekte, Agent-Aufträge, Schnittstellen, Verbindungszeichenfolgen und Abhängigkeiten zu anderen Systemen.
3. Edition und Plattform prüfen. Standard und Enterprise unterstützen unterschiedliche AG-Funktionen. Windows-Cluster und Linux-Cluster haben zudem unterschiedliche Betriebsmodelle.
4. Fehlerfälle getrennt testen. Knoten-, Speicher-, Netzwerk- und Standortausfall sind unterschiedliche Szenarien. Eine FCI mit gemeinsamem Speicher beantwortet beispielsweise nicht automatisch die Frage nach einer unabhängigen Datenkopie.
5. Failover und Rückkehr üben. Testen Sie nicht nur den Wechsel auf das Zielsystem, sondern auch Anwendungskonnektivität, Konsistenz, Backupbetrieb und den geregelten Weg zurück.
6. Wiederherstellung unabhängig absichern. Hochverfügbarkeit verhindert nicht jeden Bedienfehler und ersetzt keine überprüften Backups.

Ein Beispiel verdeutlicht die Auswahl: Ein Unternehmen betreibt eine Anwendung mit einer einzigen zentralen Datenbank und SQL Server Standard. Soll bei Ausfall des primären Servers möglichst schnell ein zweiter Server übernehmen, kann eine Basic AG ein passender Prüfpfad sein. Benötigt dieselbe Anwendung dagegen mehrere Datenbanken, die gemeinsam wechseln müssen, und sollen Berichte auf sekundären Kopien laufen, muss das Team die Möglichkeiten einer Enterprise AG bewerten. Die Entscheidung folgt den Anforderungen – nicht allein der Anzahl der Server.

Kann SQL Server 2025 Standard Edition einen automatischen Failover ausführen?

Ja, grundsätzlich sowohl mit einer unterstützten FCI als auch mit einer passend konfigurierten Basic AG. Bei der Basic AG kommt es unter anderem auf synchrone Übertragung und den Zustand des Zielreplikats an. Die Standard Edition hebt die Grenzen der Basic AG dadurch nicht auf: Pro Gruppe ist nur eine Datenbank mit einem primären und einem sekundären Replikat möglich. Außerdem lässt sich das sekundäre Replikat nicht für lesende Abfragen oder Backups verwenden. Ob ein automatischer Wechsel die Anwendung ausreichend schnell wiederherstellt, muss praktisch getestet werden.

Ist „Always On“ bei SQL Server 2025 gleichbedeutend mit Availability Groups?

Nein. Microsoft verwendet „Always On“ als übergeordneten Begriff für Availability Groups und Failover Cluster Instances. Eine FCI schützt eine komplette Instanz durch einen Wechsel zwischen Knoten, die den für die Instanz vorgesehenen Speicher nutzen. Eine AG schützt die aufgenommenen Datenbanken mittels eigener Kopien auf verschiedenen Replikaten. Deshalb führt die Aussage „Wir nutzen Always On“ noch nicht zu einem eindeutigen Architekturverständnis. In Betriebsdokumentationen sollte die konkrete Variante samt Edition, Replikationsmodus, Speicherdesign und vorgesehenem Failover-Verfahren genannt werden.

Ist Log Shipping günstiger und damit immer die beste Lösung für einen zweiten Standort?

Nicht zwangsläufig. Log Shipping kann eine vergleichsweise einfache Disaster-Recovery-Variante sein, insbesondere wenn ein manueller Rollenwechsel und ein vom Übertragungsintervall abhängiger Datenstand akzeptabel sind. Es bietet jedoch keinen automatischen Failover und verlangt einen klaren Prozess für die Umstellung von Anwendung und Instanzabhängigkeiten. Die Gesamtkosten bestehen nicht nur aus Lizenzen: Überwachung, Tests, Wiederanlaufzeit und Betriebsrisiken zählen ebenfalls. Deshalb ist Log Shipping nur dann die richtige Wahl, wenn es die festgelegten RPO- und RTO-Ziele tatsächlich erfüllt.

Braucht eine Availability Group gemeinsamen Speicher?

Nein. AG-Replikate verwenden für ihre Datenbanken getrennte Speicherressourcen. Die Datenänderungen werden zwischen den SQL-Server-Instanzen übertragen. Unter Windows ist für eine hochverfügbare AG trotzdem ein Windows Server Failover Cluster als Clusterinfrastruktur erforderlich. Das wird gelegentlich verwechselt: „WSFC erforderlich“ bedeutet bei einer AG nicht „gemeinsamer Datenbankspeicher erforderlich“. Eine FCI nutzt dagegen gemeinsamen Speicher für ihre Knoten. Wer beide Technologien kombiniert, muss diese unterschiedlichen Speichergrenzen im Architekturdiagramm deutlich machen.

Ersetzen Availability Groups oder FCIs ein Backupkonzept?

Nein. Eine AG hält eine weitere Datenkopie vor, eine FCI ermöglicht den Wechsel des aktiven Knotens. Beides erfüllt andere Aufgaben als ein überprüfbares Backup mit definierter Aufbewahrung und Wiederherstellung. Auch Log Shipping beruht zwar auf Transaktionsprotokoll-Backups, ersetzt aber nicht automatisch eine vollständige Backupstrategie. Unternehmen sollten regelmäßig testen, ob sich Datenbanken und abhängige Systeme innerhalb der vorgesehenen Zeit wiederherstellen lassen. Hochverfügbarkeit und Backup sind ergänzende, nicht austauschbare Bestandteile der Geschäftskontinuität.

Schützt eine FCI auch gegen den Ausfall des Speichers?

Nicht allein durch den Knotenwechsel. Die Knoten einer FCI greifen auf den gemeinsamen Speicher der Instanz zu. Dieser Speicher muss selbst hochverfügbar ausgelegt sein; sonst kann er zum gemeinsamen Ausfallpunkt werden. Eine FCI stellt auch keine zweite unabhängige Datenkopie wie eine AG bereit. Für Schutz gegen größere Speicher- oder Standortausfälle kann eine zusätzliche Methode erforderlich sein. Welche Kombination geeignet ist, hängt vom Infrastrukturdesign, dem akzeptierten Datenverlust und dem dokumentierten Wiederherstellungsverfahren ab.

Wann ist eine Distributed Availability Group sinnvoll?

Sie ist vor allem dann interessant, wenn zwei eigenständige Availability Groups auf unterschiedlichen Clustern verbunden werden sollen – etwa für einen zweiten Standort oder eine Migration. Dadurch müssen nicht alle Replikate einem einzigen standortübergreifenden Cluster angehören. Der Gewinn an architektonischer Trennung geht mit zusätzlicher Komplexität bei Replikation, Überwachung und Umschaltung einher. Distributed AGs sind in SQL Server 2025 der Enterprise Edition vorbehalten; eine Basic AG der Standard Edition kann nicht daran teilnehmen. Vor der Einführung sollte das Team den übergreifenden Rollenwechsel vollständig testen.

Wo finden Teams passende Weiterbildung?

Für Planung und Betrieb bietet allskills-training.com eine Übersicht der Microsoft-SQL-Server-Seminare. Thematisch passen insbesondere das Seminar Microsoft SQL Server AlwaysOn sowie die SQL-Server-Administration. Wer Linux als Plattform prüft, findet zusätzlich ein Seminar zur Administration unter Linux. allskills Training Berlin listet SQL-Server-Angebote für Berlin und online; konkrete Inhalte und Termine sollten auf den Kursseiten geprüft werden.