Best Practice

DNS-Alias fuer SQL Server - Fuer und Wieder

Ein DNS-CNAME klingt nach einer einfachen Loesung fuer saubere Connection Strings - und ist es oft auch. Aber nach einer Server-Migration, einem AlwaysOn-Failover oder einem Listener-Umzug wird aus dem "einfach" schnell ein "warum hatten wir das nochmal so?". Eine ehrliche Bestandsaufnahme.

sqmSQLTool auf GitHub

Die Idee Wie es funktioniert Connection Strings Migration und Umzug Pro und Contra Empfehlung

Die Idee hinter dem DNS-Alias

Jeder DBA kennt das Problem: Anwendungen verbinden sich direkt auf den physikalischen Servernamen - SQLSRV01. Der Server wird abgeloest, der neue heisst SQLSRV07. Jetzt beginnt die Suche nach allen Connection Strings in allen Anwendungen, Config-Dateien und Skripten.

Die scheinbar elegante Loesung: Ein DNS-CNAME. Der Alias sql-crm zeigt auf den aktuellen Server. Anwendungen verbinden sich immer auf sql-crm. Bei einer Migration aendert der DBA nur den DNS-Eintrag - fertig.

Kerngedanke: Der DNS-Alias entkoppelt den logischen Namen (was die Anwendung kennt) vom physikalischen Namen (wo der SQL Server tatsaechlich laeuft).

Wie es funktioniert

DNS CNAME (Empfohlen)

Ein Alias-Eintrag im DNS. Der Name zeigt auf einen anderen DNS-Namen.

# DNS CNAME Eintrag: sql-crm CNAME SQLSRV01.domain.local # Nach Migration: sql-crm CNAME SQLSRV07.domain.local

SQL Server Alias (Client-seitig)

Konfiguriert via SQL Server Configuration Manager auf jedem Client - unabhaengig vom DNS.

# Registry auf dem Client: HKLM:\SOFTWARE\Microsoft\ MSSQLServer\Client\ConnectTo "sql-crm" = "DBMSSOCN,SQLSRV01,1433"

AlwaysOn Listener

Der sauberste Weg fuer HA-Umgebungen. Der Listener ist ein eigenes Netzwerkobjekt im WSFC-Cluster.

# Listener ist kein DNS-Alias! # Eigene IP im Cluster. sql-crm-ag A 10.1.2.50 # Failover = IP wechselt Node

Connection Strings - Was geht, was nicht

Szenario	Connection String	Kerberos SPN	Empfehlung
Physikalischer Server	`Server=SQLSRV01;Database=CRM;`	Automatisch	Vermeiden
DNS CNAME	`Server=sql-crm;Database=CRM;`	Manuell setzen!	Mit Aufwand
AlwaysOn Listener	`Server=sql-crm-ag;Database=CRM; MultiSubnetFailover=True;`	Automatisch	Beste Wahl
DNS CNAME + Port	`Server=sql-crm,1433;Database=CRM;`	Port erleichtert Kerberos	Akzeptabel

Kerberos und CNAME: Wenn der DNS-Alias sql-crm auf SQLSRV01 zeigt, muss der SPN fuer den SQL Service Account explizit auf den Alias-Namen gesetzt werden - sonst schlaegt Kerberos fehl und es wird auf NTLM zurueckgefallen. Das ist ein haeufig uebersehener Schritt!

# SPNs fuer DNS-Alias setzen (AD-Team erforderlich): setspn -A MSSQLSvc/sql-crm:1433 DOMAIN\SqlServiceAccount setspn -A MSSQLSvc/sql-crm.domain.local:1433 DOMAIN\SqlServiceAccount # Pruefen: setspn -L DOMAIN\SqlServiceAccount

Migration und Listener-Umzug - Die Praxis

Genau hier liegt der Haken. Der DNS-Alias klingt nach Flexibilitaet - in der Praxis bringt er bei AlwaysOn-Migrationen eigene Herausforderungen mit.

Szenario 1: Einfache Server-Migration

Alter Server: SQLSRV01
Neuer Server: SQLSRV07
DNS-Alias: sql-crm
DNS umbiegen - fertig!
TTL beachten (empfohlen: 300s vor Migration)
SPN neu setzen nicht vergessen

Szenario 2: AlwaysOn Listener-Umzug

Alter Listener: sql-crm-ag (IP: 10.1.2.50)
Neuer Cluster, neuer Listener
DNS-Alias reicht NICHT!
Listener ist ein Cluster-Objekt, kein DNS-Name
IP muss im neuen WSFC neu angelegt werden
Koordination: DBA + AD-Team + Netzwerk

Szenario 3: Distributed AG

Altes System bleibt online
Neues System seeded via Distributed AG
Listener-Name bleibt gleich nach Cutover
Sauberste Zero-Downtime Variante
Kein DNS-Flip noetig
Applikation bemerkt nichts

Ablauf: DNS-Alias Umzug mit Distributed AG

TTL reduzieren - DNS TTL auf 300 Sekunden setzen (5 Minuten vor Migrationsfenster)

Distributed AG aufbauen - Seeding laeuft transparent im Hintergrund, Applikation bleibt auf altem System

Synchronisation abwarten - log_send_queue_size muss 0 sein

Applikation stoppen - geordnetes Beenden aller Verbindungen

Failover der Distributed AG - ALTER AVAILABILITY GROUP [DAG] FAILOVER

Listener / DNS umbiegen - DNS-Alias oder Cluster-IP auf neuen Server. SPNs anpassen!

Applikation starten - verbindet sich auf gleichen Namen, neues System antwortet

Pro und Contra - Die ehrliche Bilanz

Pro DNS-Alias

Connection Strings bleiben unveraendert
Server-Migration ohne Anwendungsaenderung
Zentrales Management im DNS
Unabhaengig von SQL Server Version
Funktioniert auch fuer Nicht-AlwaysOn Instanzen
Schnelles Rollback: DNS zurueckbiegen

Contra DNS-Alias

Kerberos SPNs muessen manuell gesetzt werden
DNS-Cache TTL kann Downtime verlaengern
Kein Ersatz fuer AlwaysOn Listener bei HA
Kein automatisches Failover
Zusaetzliche Dokumentationsebene
MultiSubnetFailover funktioniert nicht mit CNAME

Wichtig: MultiSubnetFailover=True im Connection String funktioniert nicht mit einem DNS-CNAME! Der Treiber sendet parallele Verbindungsversuche an alle IPs - ein CNAME liefert aber nur eine IP. Fuer AlwaysOn-Failover-Szenarien ist der native Listener immer die bessere Wahl.

Empfehlung

Umgebung	Empfehlung	Begruendung
Standalone SQL Server	DNS-Alias (CNAME)	Einfach, flexibel, saubere Migration
AlwaysOn AG (HA)	AlwaysOn Listener	Automatisches Failover, MultiSubnetFailover
AlwaysOn AG (Migration)	Distributed AG + Listener-Uebernahme	Zero-Downtime, kein DNS-Flip noetig
Legacy-Anwendungen ohne Aenderung	DNS-Alias als Uebergangsloesung	Wenn Connection String nicht aenderbar
Microservices / Cloud-ready	Service Discovery / Config-Service	DNS zu statisch fuer dynamische Umgebungen

Fazit: Der DNS-Alias ist ein bewaehertes Werkzeug - aber kein Allheilmittel. Wer AlwaysOn betreibt, sollte den nativen Listener bevorzugen. Der DNS-Alias glaeenzt dort, wo keine HA-Infrastruktur vorhanden ist und eine saubere Namenstrennung zwischen Anwendung und Infrastruktur benoetigt wird.

# PowerShell: SPN-Report mit sqmSQLTool Get-sqmSpnReport -SqlInstance "sql-crm" # Zeigt ob SPNs korrekt gesetzt sind fuer den Alias # und welcher Service Account verwendet wird

sqmSQLTool - SPN-Report und AlwaysOn-Diagnose

Get-sqmSpnReport und Export-sqmAlwaysOnConfiguration helfen bei der Diagnose von SPN- und Listener-Problemen in komplexen Migrationsszenarien.

Auf GitHub ansehen