Distributed Availability Groups
Das DBA-Tool für Migration & Multi-Site
Verteilte Verfügbarkeitsgruppen verbinden zwei separate AGs über WSFC-Grenzen hinweg – perfekt für standortübergreifende Disaster Recovery, Cloud-Migrationen und versionenübergreifende Setups.
🔗 Was ist eine Distributed Availability Group?
Eine verteilte Verfügbarkeitsgruppe (Distributed AG) ist eine spezielle AG, die zwei separate Verfügbarkeitsgruppen über verschiedene Windows Server Failover Cluster (WSFC) hinweg miteinander verbindet. Die einzelnen AGs können sich dabei an unterschiedlichen Orten befinden – ob on-premises, in der Public Cloud oder sogar plattformübergreifend (Windows/Linux).
🏛️ Klassische AG
- Alle Nodes in einem WSFC
- Max. 8 Replicas
- Kein gemeinsamer Storage nötig
- Abhängig von Windows Cluster
🌍 Distributed AG
- Verbindet zwei unabhängige WSFC
- Bis zu 18 Replicas (9+9)
- Kein gemeinsamer Cluster
- Wird vollständig in SQL Server verwaltet
✅ Wann ist der Einsatz sinnvoll? Primär für Disaster Recovery zusätzlich zur High Availability. Durch die Aufteilung auf zwei Cluster wird der Netzwerk-Traffic über das WAN halbiert – ein massiver Vorteil in Cloud- oder Multi-DC-Szenarien.
⚙️ Zwei Hauptszenarien für DBAs
☁️ 1. Migration in die Cloud (oder neues Rechenzentrum)
Mit einer Distributed AG lassen sich Datenbanken live und mit minimaler Downtime von on-premises nach Azure, AWS oder in ein neues Rechenzentrum verschieben. Die DAG synchronisiert im Hintergrund, beim Cutover erfolgt ein Failover auf den Forwarder.
📶 2. Versionen- / plattformübergreifende Migration
Da die beiden AGs unabhängig sind, kann die Ziel-AG eine neuere SQL-Version oder sogar ein anderes Betriebssystem (Windows/Linux) nutzen. Perfekt für schrittweise Upgrades von SQL Server 2016/2019 auf 2022 oder 2025.
🛠️ Technisches Vorgehen – Schritt für Schritt
📋 Voraussetzungen
- SQL Server Enterprise Edition (ab 2016) auf beiden Seiten
- Netzwerkverbindung zwischen den Clustern (Ports 1433, 5022 und ggf. Load Balancer)
- Für automatisches Seeding: identische Instanznamen auf beiden Seiten
- Database Mirroring Endpoints konfiguriert (LISTENER_IP = ALL ist Pflicht)
📝 Schritt 1: Erste AG (Quelle) erstellen
-- Beispiel: AG auf Quelle (OnPremAG)
CREATE AVAILABILITY GROUP [OnPremAG]
WITH (AUTOMATED_BACKUP_PREFERENCE = PRIMARY)
FOR DATABASE [AdventureWorks]
REPLICA ON N'OnPremNode1' WITH (ENDPOINT_URL = N'TCP://OnPremNode1.contoso.com:5022'),
N'OnPremNode2' WITH (ENDPOINT_URL = N'TCP://OnPremNode2.contoso.com:5022');📝 Schritt 2: Zweite AG (Ziel) vorbereiten
-- Beispiel: AG auf Ziel (AzureAG) – zunächst leer
CREATE AVAILABILITY GROUP [AzureAG]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
REPLICA ON N'SQLVM1' WITH (ENDPOINT_URL = N'TCP://SQLVM1.contoso.com:5022'),
N'SQLVM2' WITH (ENDPOINT_URL = N'TCP://SQLVM2.contoso.com:5022');📝 Schritt 3: Distributed AG erstellen (auf globalem Primary)
-- Distributed AG erstellen (global primary = OnPremAG)
CREATE AVAILABILITY GROUP [DistributedAG]
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
'OnPremAG' WITH
(
LISTENER_URL = 'TCP://OnPremAGListener.contoso.com:1433',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
),
'AzureAG' WITH
(
LISTENER_URL = 'TCP://AzureAGListener.contoso.com:1433',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);🔄 Failover & Cutover
-- 1. Synchronisationsstatus prüfen (auf global primary)
SELECT ag.name, db_name(drs.database_id) AS DB, drs.synchronization_state_desc, drs.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;-- 2. Failover der Distributed AG (auf global primary)
ALTER AVAILABILITY GROUP [DistributedAG] FAILOVER;-- 3. (Optional) Distributed AG auflösen, wenn Migration abgeschlossen
DROP AVAILABILITY GROUP [DistributedAG];⚠️ Herausforderungen & Stolpersteine
🔧 1. Kein GUI – reine T-SQL-Konfiguration
Distributed AGs lassen sich nicht über den SSMS-Assistenten erstellen. Alles muss per T-SQL-Skript erfolgen – ein häufiger Fehler ist die falsche Reihenfolge beim Erstellen.
🌐 2. Netzwerk & Firewall
Die Kommunikation zwischen den Clustern benötigt durchgängig offene Ports (1433, 5022) und funktionierende Namensauflösung. In Azure ist zudem ein Load Balancer für den Listener erforderlich.
📛 3. Identische Instanznamen (für automatisches Seeding)
Für AUTOMATIC SEEDING müssen die Instanznamen auf Quelle und Ziel exakt übereinstimmen. Bei Abweichungen ist nur manuelles Seeding möglich.
🗂️ 4. Systemdatenbanken / Server-Objekte
Logins, Jobs und Linked Server werden nicht automatisch migriert. Diese müssen nach dem Failover mit Tools wie dbatools oder manuell übertragen werden.
🔮 Ausblick SQL Server 2025
Mit SQL Server 2025 (General Availability November 2025) wird die interne Synchronisation optimiert, um die Netzwerksättigung im asynchronen Modus zu reduzieren. Vorteile:
- Weniger Bandbreitenverbrauch bei der Replikation über lange Distanzen
- Bessere Performance in Cloud- und Multi-DC-Szenarien
- Weiterhin volle Kompatibilität zu bestehenden Distributed AGs
✅ Fazit für Administratoren
📌 Wann sollte ich eine Distributed AG einsetzen?
- Migration on-premises → Cloud (Azure, AWS)
- Standortübergreifende Disaster Recovery (zwei Rechenzentren)
- Upgrade von SQL Server 2016/2019 auf 2022/2025
- Wechsel des Betriebssystems (z. B. Windows → Linux)
In all diesen Szenarien ist die Distributed AG die eleganteste Lösung mit minimaler Downtime. Beachten Sie: Der Konfigurationsaufwand ist höher als bei einer klassischen AG, aber er zahlt sich durch Flexibilität und geringere Netzwerklasten aus.
🎯 Empfehlung: Nutzen Sie eine Skriptvorlage und testen Sie den Failover gründlich in einer Staging-Umgebung. Tools wie dbatools helfen bei der Migration von Logins, Jobs und Linked Servern.