SQL Server Hochverfuegbarkeit im KMU: AlwaysOn, Log Shipping, Cluster

Warum “Hochverfuegbarkeit” im KMU eine andere Frage ist als im Konzern

Ein Konzern-DBA denkt in Multi-Subnet-AlwaysOn-Gruppen mit vier Replikaten, automatischem Seeding und einem dedizierten Cluster-Team. Im Schweizer KMU sieht die Realitaet anders aus: ein bis zwei Windows-Admins, die SQL Server nebenbei betreuen, ein Server-Raum oder ein kleines Rack im Keller, ein IT-Budget, das jede Enterprise-Lizenz dreimal umdreht. Die Frage ist deshalb nie “Welche Technologie ist am maechtigsten?”, sondern “Welcher Ausfall tut uns wirklich weh, und was kostet es, ihn zu verhindern?”.

Dieser Artikel ordnet die drei relevanten HA/DR-Techniken fuer SQL Server - AlwaysOn Availability Groups, Log Shipping und Failover Cluster Instances (FCI) - nach genau diesem Massstab ein: Schutzumfang, RTO/RPO, Lizenzkosten und Betriebsaufwand. Grundlagen zu SQL Server selbst findest du unter SQL Server Grundlagen und Support, Cluster-Basiswissen unter Windows Failover Cluster Grundlagen.

Die drei Technologien im Ueberblick

AlwaysOn Availability Groups (AG)

Seit SQL Server 2012 das Flaggschiff-Feature fuer Hochverfuegbarkeit. Eine Availability Group buendelt eine oder mehrere Benutzerdatenbanken zu einer Failover-Einheit. Ein primaeres Replikat nimmt Schreibzugriffe an, bis zu acht sekundaere Replikate (Enterprise Edition) halten synchron oder asynchron eine Kopie vor. Ein Listener (virtueller Netzwortname mit eigener IP) sorgt dafuer, dass Anwendungen nach einem Failover ohne Connection-String-Aenderung weiterarbeiten.

Kernmerkmale:

• Failover auf Datenbankgruppen-Ebene, nicht auf Instanzebene
• Synchroner Commit (kein Datenverlust, aber Latenz-Impact) oder asynchroner Commit (Datenverlust im Millisekunden- bis Sekundenbereich, kaum Latenz-Impact)
• Sekundaere Replikate koennen fuer Lesezugriffe (Reporting, Backups) genutzt werden - aber nur mit Enterprise Edition
• Basiert technisch auf einem Windows Server Failover Cluster (WSFC) als Verteilmechanismus, auch wenn kein gemeinsamer Storage noetig ist

Seit SQL Server 2016 gibt es zusaetzlich Basic Availability Groups fuer die Standard Edition: genau ein sekundaeres Replikat, keine Lesezugriffe, keine Backups auf dem Sekundaeren, nur eine Datenbank pro Gruppe. Das ist im KMU oft trotzdem die richtige Wahl, weil es AlwaysOn-Failover-Mechanik ohne Enterprise-Lizenz bringt.

Log Shipping

Die “alte”, aber immer noch vollkommen valide Technik: Der Primaerserver sichert regelmaessig das Transaktionslog, kopiert die Backup-Datei auf einen oder mehrere sekundaere Server, dort wird sie eingespielt (restore with standby oder norecovery). Kein Cluster, kein gemeinsamer Storage, kein Windows-Failover-Mechanismus - drei separate SQL Agent Jobs (Backup, Copy, Restore) erledigen die Arbeit.

Log Shipping funktioniert in jeder Edition, auch Standard und sogar Web Edition. Genau deshalb ist es im KMU-Kontext die guenstigste HA/DR-Option ueberhaupt - man zahlt nur fuer die zweite SQL-Server-Lizenz (mit Software Assurance fuer passiven Failover, dazu spaeter mehr).

Der grosse Unterschied zu AlwaysOn: Es gibt keinen automatischen Failover. Ein Failover ist ein manueller (oder skriptgesteuerter) Vorgang: letztes Log-Backup einspielen, Datenbank online nehmen, Anwendungen umstellen. Das macht Log Shipping zur richtigen Wahl fuer geplante Wartungsfenster und als guenstige DR-Absicherung, aber zur falschen Wahl, wenn ein Verkaufsportal nachts um 3 Uhr ohne Personal weiterlaufen muss.

Failover Cluster Instances (FCI)

FCI schuetzt die komplette SQL-Server-Instanz inklusive System-Datenbanken, Jobs, Logins und Zertifikaten - nicht nur einzelne Benutzerdatenbanken. Technisch laeuft die Instanz auf einem Windows Server Failover Cluster mit gemeinsamem Storage (Shared Disk, meist ueber ein SAN, iSCSI oder Storage Spaces Direct). Faellt ein Knoten aus, startet die Instanz auf einem anderen Knoten neu und bindet denselben Storage ein - fuer Clients sichtbar als kurzer Verbindungsabbruch (Sekunden bis wenige Minuten), nicht als Datenverlust.

FCI ist die einzige der drei Techniken, bei der Standard Edition auf beiden Knoten reicht (Zwei-Knoten-FCI). Mehr als zwei Knoten oder Multi-Subnet-FCI verlangen Enterprise Edition.

Vergleichstabelle: Welche Technik fuer welchen Fall

*Bei FCI muessen im Gegensatz zu AG/Log-Shipping in der Praxis oft beide Knoten voll lizenziert werden, da Microsoft die “passive secondary use rights” unter Software Assurance an bestimmte Bedingungen knuepft (max. Failover-Haeufigkeit, keine Nutzung fuer andere Zwecke). Kläre das im Zweifel mit dem Microsoft-Lizenzpartner ab, bevor du eine Architektur festlegst.

Entscheidungsbaum: Welche HA-Strategie passt zu meinem Betrieb?

Frage 1: Wie viel Downtime pro Ausfall ist geschaeftlich akzeptabel (RTO)?
│
├─ RTO > 1 Stunde, RPO > 15 Minuten OK
│   └─ Log Shipping genuegt.
│       Guenstig, funktioniert mit Standard Edition,
│       aber manueller Failover-Prozess muss geuebt sein.
│
├─ RTO < 1 Minute, RPO nahe 0, nur EINE Datenbank kritisch
│   └─ Basic Availability Group (Standard Edition)
│       Automatischer Failover, kein Enterprise-Aufpreis,
│       aber kein Lesezugriff auf Sekundaer moeglich.
│
├─ RTO < 1 Minute, RPO nahe 0, MEHRERE Datenbanken/Reporting-Load
│   └─ Volle Availability Group (Enterprise Edition)
│       Hoehere Lizenzkosten, dafuer Lastverteilung
│       auf lesbare Sekundaere moeglich.
│
└─ Schutz vor Ausfall der gesamten Instanz
    (Jobs, Logins, SSIS-Pakete, mehrere Datenbanken gemeinsam)
    └─ Failover Cluster Instance (FCI)
        Braucht gemeinsamen Storage (SAN/S2D),
        schuetzt NICHT vor Storage-Ausfall -
        deshalb oft kombiniert mit Log Shipping oder AG als DR-Ebene.

AlwaysOn AG einrichten: Die wichtigsten Schritte

Eine vollstaendige AG-Einrichtung sprengt den Rahmen dieses Artikels, aber die zentralen PowerShell- und T-SQL-Bausteine solltest du kennen, um Troubleshooting und Reviews von Setup-Skripten machen zu koennen.

1. AlwaysOn-Feature auf Instanzebene aktivieren (erfordert Neustart des SQL-Server-Dienstes):

Enable-SqlAlwaysOn -ServerInstance "SQL01" -Force

2. Availability Group erstellen (auf dem primaeren Replikat, T-SQL):

CREATE AVAILABILITY GROUP [AG_ERP]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    FAILURE_CONDITION_LEVEL = 3,
    HEALTH_CHECK_TIMEOUT = 30000
)
FOR DATABASE [ERP_Produktiv]
REPLICA ON
    'SQL01' WITH (
        ENDPOINT_URL = 'TCP://sql01.kmu.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC
    ),
    'SQL02' WITH (
        ENDPOINT_URL = 'TCP://sql02.kmu.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC
    );
GO

SEEDING_MODE = AUTOMATIC erspart dir das manuelle Backup/Restore der Datenbank auf dem Sekundaeren - SQL Server uebertraegt die Daten direkt ueber das Endpoint. Bei grossen Datenbanken (mehrere hundert GB) kann das je nach Netzwerk aber deutlich laenger dauern als ein Restore von einem lokalen Backup; dann lieber SEEDING_MODE = MANUAL waehlen.

3. Sekundaere Replik beitreten lassen:

ALTER AVAILABILITY GROUP [AG_ERP] JOIN;
ALTER AVAILABILITY GROUP [AG_ERP] GRANT CREATE ANY DATABASE;

4. Listener anlegen (fuer transparenten Anwendungszugriff):

ALTER AVAILABILITY GROUP [AG_ERP]
ADD LISTENER 'AGL-ERP' (
    WITH IP ((N'10.10.5.50', N'255.255.255.0')),
    PORT = 1433
);

Anwendungen verbinden sich danach nicht mehr auf SQL01, sondern auf AGL-ERP - der Listener loest automatisch auf das aktuell primaere Replikat auf.

Log Shipping einrichten: Die drei Jobs

Log Shipping laesst sich komplett ueber das SSMS-Wizard (Datenbankeigenschaften → Transaktionsprotokollversand) oder per T-SQL/System-Stored-Procedures konfigurieren. Die Kernlogik in drei Jobs:

-- Auf dem Primaerserver: Backup-Job
EXEC master.dbo.sp_add_log_shipping_primary_database
    @database = N'ERP_Produktiv',
    @backup_directory = N'\\fileserver\logshipping\ERP_Produktiv',
    @backup_share = N'\\fileserver\logshipping\ERP_Produktiv',
    @backup_job_name = N'LSBackup_ERP_Produktiv',
    @backup_retention_period = 4320, -- Minuten, hier 3 Tage
    @backup_threshold = 60,          -- Alarm, wenn 60 Min kein neues Backup
    @monitor_server = N'SQL-MON',
    @backup_compression = 1;
GO

-- Auf dem Sekundaerserver: Copy- und Restore-Job
EXEC master.dbo.sp_add_log_shipping_secondary_primary
    @primary_server = N'SQL01',
    @primary_database = N'ERP_Produktiv',
    @backup_source_directory = N'\\fileserver\logshipping\ERP_Produktiv',
    @backup_destination_directory = N'D:\LSCopy\ERP_Produktiv',
    @copy_job_name = N'LSCopy_ERP_Produktiv',
    @restore_job_name = N'LSRestore_ERP_Produktiv',
    @restore_delay = 0,
    @restore_mode = 0,               -- 0 = NORECOVERY, 1 = STANDBY
    @monitor_server = N'SQL-MON';
GO

@restore_mode = 1 (STANDBY) haelt die Zieldatenbank lesbar zwischen den Restores - praktisch fuer Reporting-Zugriffe, aber bremst das naechste Log-Restore, weil vorher alle offenen Leser getrennt werden muessen.

Manueller Failover-Ablauf bei Log Shipping:

1. Letztes ausstehendes Transaktionslog vom Primaerserver manuell sichern (BACKUP LOG ... WITH NORECOVERY)
2. Diese letzte Log-Datei auf den Sekundaerserver kopieren und einspielen
3. Datenbank auf dem Sekundaerserver mit RESTORE DATABASE ... WITH RECOVERY online nehmen
4. Anwendungs-Connection-Strings / DNS-Eintraege auf den neuen Server umstellen
5. Log-Shipping-Jobs deaktivieren, damit nicht versehentlich in die falsche Richtung ueberschrieben wird

Failover Cluster Instance: Storage ist der Knackpunkt

FCI unterscheidet sich fundamental von AG und Log Shipping, weil beide Knoten auf denselben Storage zugreifen - es gibt physisch nur eine Kopie der Datenbankdateien. Das bedeutet:

• Kein Schutz vor Storage-Ausfall oder Datenkorruption (ein beschaedigtes MDF-File betrifft beide Knoten gleichermassen)
• Zwingend gemeinsamer Speicher: klassisches SAN via Fibre Channel/iSCSI, oder seit Windows Server 2016 Storage Spaces Direct (S2D) als guenstigere Alternative ohne dediziertes SAN
• Quorum-Konfiguration des zugrundeliegenden WSFC ist entscheidend fuer stabilen Betrieb

Cluster-Validierung vor der Installation (Pflichtschritt, den viele KMU-Admins ueberspringen und spaeter bereuen):

Test-Cluster -Node "SQL01","SQL02" -Include "Storage","Network","System Configuration","Inventory"

Quorum-Konfiguration mit Cloud Witness (empfohlen bei zwei Knoten, da kein drittes Rechenzentrum noetig ist):

Set-ClusterQuorum -CloudWitness -AccountName "stgquorumkmu" -AccessKey "<StorageAccountKey>" -Endpoint "core.windows.net"

Der Cloud Witness braucht nur ein kleines Azure-Storage-Konto (LRS reicht, Kosten im Cent-Bereich pro Monat) und kommuniziert ausschliesslich ueber HTTPS (Port 443) - ideal fuer KMU, die kein drittes physisches Rechenzentrum fuer einen Fileshare-Witness betreiben wollen.

Lizenzierungsfolgen: Wo das Geld tatsaechlich hingeht

Die Lizenzierung ist im KMU-Kontext oft der entscheidende Faktor - technisch waere die volle Enterprise-AG meist die eleganteste Loesung, aber der Preisunterschied ist erheblich.

• SQL Server Standard Edition: Core-basierte Lizenz, deutlich guenstiger pro Core als Enterprise. Reicht fuer FCI (2 Knoten), Basic AG und Log Shipping.
• SQL Server Enterprise Edition: Noetig fuer volle AGs (mehr als 2 Replikate, lesbare Sekundaere, mehrere Datenbanken pro Gruppe), FCI mit mehr als 2 Knoten, Multi-Subnet-FCI. Kostet pro Core ein Vielfaches von Standard.
• Software Assurance (SA) fuer passive Failover-Rechte: Ohne SA muss theoretisch jeder Knoten, der SQL Server ausfuehrt - auch der passive/sekundaere - voll lizenziert werden. Mit aktiver SA gewaehrt Microsoft “passive secondary use rights”: Der sekundaere Knoten braucht keine eigene Lizenz, solange er wirklich nur passiv ist (kein Lesezugriff, keine Backups, keine andere Nutzung) und nicht laenger als eine begrenzte Zeitspanne pro Jahr als aktiver Knoten dient. Sobald der Sekundaere fuer Reporting oder Backups genutzt wird (typisch bei vollen AGs mit Enterprise), muss er ebenfalls lizenziert sein.

Seit SQL Server 2025 wurden die Standard-Edition-Limits erhoeht (bis 32 Cores und 256 GB RAM statt vorher 24 Cores/128 GB), was Basic AGs und FCI auf Standard Edition fuer mittelgrosse KMU-Workloads deutlich attraktiver macht, ohne sofort auf Enterprise wechseln zu muessen. Bei bestehenden aelteren Versionen (2019/2022) gelten noch die niedrigeren Limits - das lohnt sich bei der naechsten Migrationsplanung zu pruefen.

Failover testen: Der Teil, den die meisten KMU auslassen

Eine HA-Loesung, die nie getestet wurde, ist keine HA-Loesung - sie ist eine Hoffnung. Die drei Techniken erfordern unterschiedliche Testverfahren:

AlwaysOn AG - manueller Failover-Test:

-- Auf dem gewuenschten neuen primaeren Replikat ausfuehren
ALTER AVAILABILITY GROUP [AG_ERP] FAILOVER;

Bei synchronem Commit ist das ein “Zero Data Loss”-Failover. Bei asynchronem Commit oder wenn ein Replikat nicht synchronisiert ist, verlangt SQL Server explizit FAILOVER WITH DATA_LOSS als Bestaetigung - ein guter eingebauter Schutz gegen versehentliche Datenverluste.

Health-Check des AG-Status:

SELECT
    ag.name AS AGName,
    ar.replica_server_name,
    ars.role_desc,
    ars.synchronization_health_desc,
    ars.connected_state_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id;

FCI - Failover-Test ueber Failover Cluster Manager oder PowerShell:

Move-ClusterGroup -Name "SQL Server (MSSQLSERVER)" -Node "SQL02"

Log Shipping - Monitoring der Verzoegerung:

EXEC master.dbo.sp_help_log_shipping_monitor;

Diese Prozedur zeigt dir sofort, wie alt das letzte kopierte und restaurierte Log ist - der wichtigste Frueh-Indikator, wenn ein Copy- oder Restore-Job stillschweigend fehlschlaegt (z.B. wegen vollem Zielverzeichnis oder abgelaufenem Service-Account-Passwort).

Monitoring im Alltag

Fuer den taeglichen Betrieb reichen im KMU oft einfache, aber konsequent eingesetzte Bordmittel:

• AlwaysOn Dashboard in SSMS (Rechtsklick auf Availability Group → Show Dashboard) fuer einen visuellen Ueberblick ueber Synchronisationsstatus und Failover-Bereitschaft
• SQL Server Agent Alerts auf die Fehlernummern 1480 (AG-Failover erfolgt) und 41414 (Synchronisationsstatus kritisch), die per E-Mail an das IT-Team gehen
• Extended Events Session AlwaysOn_health (seit SQL Server 2012 standardmaessig aktiv) fuer detaillierte Diagnose von Verbindungsabbruechen zwischen Replikaten
• Fuer Log Shipping: der bereits erwaehnte sp_help_log_shipping_monitor als scheduled Job mit Alarmierung bei Ueberschreitung des Backup/Restore-Thresholds
• Allgemeines Server- und Cluster-Monitoring gehoert in dieselbe Monitoring-Loesung wie der Rest der Infrastruktur - siehe Monitoring Grundlagen

Praxis-Szenario: Ein typisches Schweizer KMU

Ein Maschinenbau-Betrieb mit 80 Mitarbeitenden betreibt ein ERP-System auf SQL Server Standard Edition. Die Geschaeftsleitung akzeptiert maximal 30 Minuten Downtime waehrend der Kernarbeitszeit, toleriert aber laengere Ausfaelle nachts und am Wochenende. Zwei Server stehen im selben Serverraum, ein dritter (guenstiger) Server steht im 15 km entfernten Aussenlager.

Die passende Architektur: Basic Availability Group zwischen den beiden Servern im Serverraum (automatischer Failover bei Hardware-Ausfall eines Knotens, Standard Edition reicht) plus Log Shipping vom primaeren AG-Replikat zum Server im Aussenlager (guenstige DR-Absicherung gegen Totalverlust des Hauptstandorts, z.B. durch Brand). Ein Zwei-Knoten-FCI waere hier ueberdimensioniert, weil der gemeinsame Storage im selben Raum ohnehin kein Schutz gegen den Hauptrisikofall (Stromausfall/Brand im Gebaeude) waere.

Weiterlernen

• Overview of Always On Availability Groups - offizielle Microsoft-Dokumentation zur AG-Architektur
• Basic Availability Groups - Details und Einschraenkungen fuer Standard Edition
• About Log Shipping - vollstaendige Referenz zu Log-Shipping-Konfiguration
• Failover Cluster Instances Overview - FCI-Architektur und Storage-Optionen
• Deploy a quorum witness for a failover cluster - Quorum- und Witness-Konfiguration im WSFC
• SQL Server Licensing Guide (PDF) - offizielle Lizenzierungsunterlagen fuer HA-Szenarien

Verwandte Themen: SQL Server Grundlagen und Support, Windows Failover Cluster Grundlagen, Virtualisierung Hochverfuegbarkeit, Backup-Strategie 3-2-1-Regel, IT-Notfallplanung Disaster Recovery, SQL Server Sicherheit haerten