1. Einführung in SQL Server Hochverfügbarkeit
Hohe Verfügbarkeit in SQL Server Hochverfügbarkeit bezeichnet die Fähigkeit eines Systems, auch bei Hardwareausfällen, Softwareproblemen oder geplanten Wartungsarbeiten mit minimalen Ausfallzeiten betriebsbereit zu bleiben. Ihre Bedeutung kann nicht hoch genug eingeschätzt werden. Wenn Datenbanken nicht verfügbar sind, drohen Unternehmen unmittelbare Konsequenzen wie Umsatzeinbußen, Produktivitätsverluste und Kundenunzufriedenheit.
Obwohl Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR) oft synonym verwendet werden, decken sie unterschiedliche Ausfallszenarien ab. HA konzentriert sich auf die Minimierung von Ausfallzeiten durch lokale Fehler wie Server- oder Instanzabstürze, während DR für die Wiederherstellung nach großflächigen Katastrophen konzipiert ist, die ein gesamtes Rechenzentrum oder eine Region betreffen.
Zwei entscheidende Kennzahlen leiten die Planung von HA-Projekten:
- Die Recovery Time Objective (RTO) definiert die maximal akzeptable Ausfallzeit nach einem Fehler.
- Der Recovery Point Objective (RPO) legt den maximal tolerierbaren Datenverlust fest.
Die Verfügbarkeit wird üblicherweise in „Neunen“ gemessen: 99.9 % (drei Neunen) erlauben 8.76 Stunden Ausfallzeit pro Jahr, 99.99 % (vier Neunen) erlauben 52.6 Minuten und 99.999 % (fünf Neunen) beschränken die Ausfallzeit auf nur 5.26 Minuten pro Jahr.
2. SQL Server Überblick über Hochverfügbarkeitslösungen
2.1 Kategorien von HA-Lösungen
SQL Server Hochverfügbarkeitslösungen lassen sich anhand mehrerer Dimensionen kategorisieren:
- Schutzmechanismen auf Instanz- vs. Datenbankebene: Schutzmechanismen auf Instanzebene, wie z. B. Failover-Clusterinstanzen, schützen ganze Instanzen einschließlich aller Datenbanken und Serverobjekte, während Schutzmechanismen auf Datenbankebene, wie z. B. Always On Availability Groups, bestimmte Datenbanken schützen.
- Synchrone vs. asynchrone Datenübertragung: Synchrone Datenübertragung gewährleistet Datenverlustfreiheit, kann aber zu Latenz führen, während asynchrone Datenübertragung die Leistung optimiert, aber einen möglichen Datenverlust in Kauf nimmt.
- Automatisches vs. manuelles Failover: Das automatische Failover minimiert Ausfallzeiten ohne manuelles Eingreifen, während das manuelle Failover mehr Kontrolle bietet, aber ein Eingreifen des Administrators erfordert.
2.2 Gängige HA-Lösungen
SQL Server bietet acht primäre Hochverfügbarkeitslösungen, die jeweils auf spezifische Szenarien zugeschnitten sind:
- Always On-Verfügbarkeitsgruppen
- Enthaltene Verfügbarkeitsgruppen
- Verteilte Verfügbarkeitsgruppen
- Failoverclusterinstanzen
- SQL Server Replikation
- Protokollversand
- Datenbankspiegelung
- Link zur verwalteten Instanz
3. Always On-Verfügbarkeitsgruppen
Always On Verfügbarkeitsgruppen repräsentieren SQL Serverdie führende Datenbanklösung für Hochverfügbarkeit und Notfallwiederherstellung, die in SQL Server 2012. Es ermöglicht Gruppen von Datenbanken, gemeinsam als eine einzige Einheit auszufallen, und stellt gleichzeitig lesbare sekundäre Replikate für die Abfrageauslagerung bereit.
Hauptfunktionen
- Unterstützung für insgesamt bis zu 9 Replikate (1 primäres + 8 sekundäre)
- Bis zu 5 Replikate im synchronen Commit-Modus (1 primäres + 4 sekundäre)
- Automatisches Failover ohne Datenverlust im synchronen Modus
- Lesbare sekundäre Replikate für die Abfrageauslagerung
- Backup-Auslagerung auf sekundäre Replikate
- Verfügbarkeitsgruppen-Listener für automatisches Verbindungsrouting
- Nur-Lese-Routing für den Lastausgleich von Leseabfragen
- Mehrere Datenbanken fallen gemeinsam als Gruppe aus
Implementierungsschritte
- Konfigurieren Sie Windows Server Failover Clustering (WSFC) oder Linux Pacemaker-Cluster
- Aktivieren Sie die Funktion „Immer verfügbare Verfügbarkeitsgruppen“ auf allen SQL Server Instanzen
- Stellen Sie sicher, dass die Datenbanken das vollständige Wiederherstellungsmodell verwenden und über vollständige Backups verfügen.
- Erstellen Sie Datenbankspiegelungs-Endpunkte auf jeder Replik.
- Erstellen Sie die Verfügbarkeitsgruppe und fügen Sie Datenbanken hinzu.
- Konfigurieren Sie primäre und sekundäre Replikate mit den gewünschten Modi
- Erstellen und Konfigurieren des Verfügbarkeitsgruppenlisteners
- Konfigurieren Sie das Routing nur für Lesezugriffe, wenn lesbare sekundäre Router verwendet werden.
- Testen Sie die Ausfallsicherungsverfahren und überprüfen Sie die Anwendungskonnektivität.
Am besten geeignet für
- Geschäftskritische Datenbanken, die maximale Verfügbarkeit erfordern
- Organisationen, die sowohl lokale Hochverfügbarkeit als auch geografische Disaster Recovery benötigen
- Umgebungen, die Leseskalierungsfähigkeiten erfordern
- Anwendungen, die von der Auslagerung von Berichtsabfragen profitieren
- Datenbanken, die einen vollständigen Schutz vor Datenverlust erfordern
- Multi-Datenbank-Anwendungen, die ein koordiniertes Failover erfordern
Vorteile
- Kein Datenverlust im synchronen Commit-Modus
- Automatisches Failover minimiert Ausfallzeiten (typischerweise Sekunden).
- Gut lesbare Sekundärkreise reduzieren die Belastung der Primärkreise.
- Keine gemeinsame Speichernutzung erforderlich
- Unterstützt sowohl Windows- als auch Linux-Plattformen.
- Geografische Verteilung für die Katastrophenbewältigung
- Backup-Vorgänge können auf sekundäre Systeme ausgelagert werden.
- Anwendungsverbindungszeichenfolgen bleiben nach einem Failover unverändert.
Nachteile
- Für den vollen Funktionsumfang ist die Enterprise Edition erforderlich.
- Standard Edition beschränkt auf Basic AG (1 Datenbank, 1 sekundäres Laufwerk, kein lesbares sekundäres Laufwerk)
- Komplexe Konfiguration und Verwaltung
- Erfordert eine Cluster-Infrastruktur (WSFC oder Pacemaker)
- Objekte auf Instanzebene (Logins, Jobs) erfordern eine manuelle Synchronisierung.
- Der synchrone Modus kann zu Transaktionsverzögerungen führen.
- Lizenzkosten für mehrere Server
Referenzen
- SQL Server Always On-Verfügbarkeitsgruppen: Vollständiger Leitfaden
- Offizielles Microsoft-Dokument: Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server)
4. Enthaltene Verfügbarkeitsgruppen
Eingebettete Verfügbarkeitsgruppen, eingeführt in SQL Server 2022 werden die traditionellen Always On Availability Groups erweitert, indem Objekte auf Instanzebene automatisch über Replikate hinweg synchronisiert werden, wodurch die manuelle Replikation von Anmeldungen, Aufträgen und anderen Objekten auf Serverebene entfällt.
Hauptfunktionen
- Automatische Synchronisierung von Objekten auf Instanzebene (Logins, Benutzer, Rollen)
- SQL Server Agentenaufträge werden auf allen Replikaten repliziert
- Datenbankberechtigungen werden automatisch synchronisiert
- Alle Always On AG-Funktionen enthalten
- Vereinfachtes Failover mit vollständiger Umgebungsreplikation
- Unterstützung für Windows- und Linux-Plattformen
Implementierungsschritte
- Gewährleisten SQL Server 2022 oder später in allen Fällen
- Konfigurieren Sie die WSFC- oder Pacemaker-Clusterinfrastruktur.
- Die Funktion „Immer an“ auf allen Instanzen aktivieren
- Erstellen Sie eine enthaltene Verfügbarkeitsgruppe mit der Option CONTAINED.
- Fügen Sie Datenbanken zur enthaltenen AG hinzu.
- Erstellen Sie Anmeldungen und Jobs im AG-Kontext.
- Listener konfigurieren und Failover testen
Am besten geeignet für
- Organisationen, die eine vereinfachte AG-Verwaltung wünschen
- Umgebungen mit häufigen Ausfalltests oder -vorgängen
- Anwendungen, die viele Objekte auf Instanzebene benötigen
- New SQL Server Bereitstellungen ab 2022
- Teams, die eine reduzierte Konfiguration nach einem Failover anstreben
Vorteile
- Eliminiert die manuelle Synchronisierung von Anmeldungen und Aufträgen
- Schnelleres, zuverlässigeres Failover
- Reduzierter Verwaltungsaufwand
- Die Anwendungen funktionieren sofort nach dem Failover.
- Vereinfachte Notfallwiederherstellungsverfahren
- Alle traditionellen AG-Vorteile inklusive
Nachteile
- Erfordert SQL Server 2022 oder höher
- Für den vollen Funktionsumfang ist die Enterprise Edition erforderlich.
- Bestehende traditionelle AGs können nicht in geschlossene AGs umgewandelt werden.
- Alle Replikate müssen die integrierte AG-Funktion unterstützen.
- Zusätzliche Komplexität im Vergleich zu herkömmlichen AGs
Referenzen
5. Verteilte Verfügbarkeitsgruppen
Verteilte Verfügbarkeitsgruppen, eingeführt in SQL Server 2016 wurde eine „Availability Group of Availability Groups“-Architektur eingeführt, die zwei unabhängige AGs über separate Cluster hinweg für fortgeschrittene Disaster-Recovery- und Migrationsszenarien verbindet.
Hauptfunktionen
- Verbindet zwei unabhängige Verfügbarkeitsgruppen
- Jede AG unterhält ihren eigenen unabhängigen Cluster.
- Plattformübergreifende Unterstützung (Windows bis Linux)
- Clusterübergreifende Replikation ohne gemeinsame Clusterzugehörigkeit
- Ein AG dient als primärer, der andere als sekundärer AG.
- Unterstützt sowohl synchrone als auch asynchrone Modi
- Geografische Verteilung über Regionen oder Kontinente
Implementierungsschritte
- Erste Verfügbarkeitsgruppe (primärer DAG) erstellen und konfigurieren
- Zweite Verfügbarkeitsgruppe (sekundärer DAG) erstellen und konfigurieren
- Erstellen Sie eine verteilte AG, die die beiden AGs verknüpft.
- Konfigurieren Sie die Datensynchronisierung zwischen den AGs.
- Richten Sie auf jedem AG einen Listener für die Anwendungskonnektivität ein.
- Failover-Richtlinien konfigurieren und Testverfahren durchführen
- Überprüfen Sie die clusterübergreifende Kommunikation und Replikation.
Am besten geeignet für
- Notfallwiederherstellung über mehrere Regionen hinweg, die unabhängige Rechenzentren umfasst
- Plattformübergreifende Migration von Windows zu Linux oder umgekehrt
- Hybrid-Cloud-Szenarien, die lokale Systeme mit Azure verbinden
- Wichtige Versionsaktualisierungen, die ein verlängertes Migrationsfenster erfordern
- Organisationen mit mehreren unabhängigen Failover-Clustern
- Globale Unternehmen, die eine kontinentübergreifende Replikation benötigen
Vorteile
- Entkoppelt Clusterabhängigkeiten zwischen Standorten
- Ermöglicht eine echte geografische Verteilung
- Unterstützt plattformübergreifende Szenarien
- Jeder AG kann unabhängig ausfallen.
- Ideal für komplexe Migrationsprojekte
- Keine gemeinsam genutzte Clusterinfrastruktur erforderlich
- Kann sich über verschiedene Windows-Domänen oder Linux-Distributionen erstrecken
Nachteile
- Erfordert die Enterprise Edition
- Hohe Komplexität bei Konfiguration und Management
- Erfordert ein tiefes Verständnis sowohl der Cluster- als auch der AG-Technologie.
- Schwieriger zu beheben als bei Standard-AGs
- Zusätzliche Latenz bei regionsübergreifenden Szenarien
- Erfordert eine sorgfältige Planung der Ausfallverfahren.
Referenzen
6. Failover-Clusterinstanzen (FCI)
Failoverclusterinstanzen bieten hohe Verfügbarkeit auf Instanzebene durch gemeinsam genutzten Speicher und Windows Server-Failoverclustering und ermöglichen so das automatische Failover eines gesamten Clusters. SQL Server Instanz einschließlich aller Datenbanken und Objekte auf Serverebene.
Hauptfunktionen
- Schutz auf Instanzebene (alle Datenbanken fallen gleichzeitig aus)
- Aktiv-Passiv-Konfiguration mit gemeinsam genutztem Speicher
- Virtueller Netzwerkname (VNN) für transparentes Failover
- Automatisches Failover bei Ausfall des aktiven Knotens
- Kein Datenverlust (nur eine einzige Datenkopie)
- Eingeschlossene Objekte auf Serverebene (Logins, Jobs, verknüpfte Server)
- Unterstützt alle SQL Server Wiederherstellungsmodelle
Implementierungsschritte
- Windows Server-Failovercluster (WSFC) konfigurieren
- Gemeinsamen Speicher einrichten (SAN, SMB, Storage Spaces Direct)
- Cluster-Quorum-Einstellungen konfigurieren
- Installieren SQL Server als Failover-Clusterinstanz auf dem ersten Knoten
- Fügen Sie dem FCI zusätzliche Knoten hinzu.
- Virtuellen Netzwerknamen und IP-Adresse konfigurieren
- Test des Failover zwischen Clusterknoten
- Konfigurieren Sie Clientanwendungen zur Verwendung von VNN
Am besten geeignet für
- Organisationen mit bestehender gemeinsam genutzter Speicherinfrastruktur
- Umgebungen, die einen Schutz auf Instanzebene erfordern
- Lokale Hochverfügbarkeit innerhalb eines einzelnen Rechenzentrums
- Anwendungen, die einen gemeinsamen Ausfall aller Datenbanken erfordern
- Szenarien, in denen Objekte auf Serverebene geschützt werden müssen
- Nur Windows-Umgebungen (Linux wird für FCI nicht unterstützt)
Vorteile
- Vollständiger Schutz auf Instanzebene
- Garantiert kein Datenverlust
- Automatische Ausfallsicherheit
- Anmeldungen oder Jobs müssen nicht synchronisiert werden.
- Eine einzige Datenkopie reduziert die Speicherkosten.
- Unterstützt alle Wiederherstellungsmodelle
- Anwendungsverbindungszeichenfolgen bleiben nach Failover unverändert
Nachteile
- Erfordert eine teure, gemeinsam genutzte Speicherinfrastruktur
- Gemeinsam genutzter Speicher stellt einen Single Point of Failure dar.
- Keine Leseskalierungsfähigkeit (nur ein aktiver Knoten)
- Begrenzte geografische Verbreitung aufgrund von Lagerengpässen
- Standard Edition beschränkt auf 2 Knoten
- Nur für Windows (keine Linux-Unterstützung)
- Längere Ausfallzeit im Vergleich zu AGs (typischerweise Minuten)
- Komplexe Speicherkonfiguration und -verwaltung
Referenzen
- SQL Server Failover-Cluster: Vollständiger Leitfaden für Datenbankadministratoren
- Offizielles Microsoft-Dokument: Always On-Failoverclusterinstanzen (SQL Server)
7. SQL Server Replikation
SQL Server Die Replikation ist eine Datenverteilungstechnologie, die Daten kopiert und über mehrere Server verteilt. Sie unterstützt verschiedene Topologien, von der einfachen Einwegverteilung bis hin zu komplexen Multi-Master-Konfigurationen, wird aber primär für Berichtszwecke und weniger für reine Hochverfügbarkeitslösungen eingesetzt.
Hauptfunktionen
- Vier Replikationstypen: Snapshot, Transaktionsreplikation, Zusammenführung, Peer-to-Peer
- Granulare Datenauswahl (bestimmte Tabellen, Spalten, Zeilen)
- Unterstützung für mehrere Abonnenten von einem einzelnen Herausgeber
- Bidirektionale und Multi-Master-Topologien verfügbar
- Flexible Terminplanungs- und Synchronisierungsoptionen
- Konfliktlösung für die Mergereplikation
- Filterfunktionen mit WHERE-Prädikaten
Implementierungsschritte
- Distributor-Server konfigurieren (kann separat oder identisch mit dem Publisher-Server sein)
- Veröffentlichung in der Publisher-Datenbank erstellen
- Wählen Sie den Replikationstyp anhand der Anforderungen aus.
- Wählen Sie die zu replizierenden Artikel (Tabellen, Sichten, gespeicherte Prozeduren) aus.
- Konfigurieren Sie bei Bedarf Filterung und Datentransformation.
- Abonnentendatenbanken einrichten
- Abonnements erstellen (Push oder Pull)
- Abonnements mit Snapshot initialisieren
- Überwachung der Replikationsagenten und der Latenz
Am besten geeignet für
- Verteilung der Daten an mehrere Berichtsserver
- Leseskalierungsszenarien mit Berichtsworkloads
- Teilweise Datenverteilung an entfernte Standorte
- Datenkonsolidierung aus mehreren Quellen
- Gelegentlich verbundene Szenarien (Merge-Replikation)
- Unterstützende Rolle bei der Strategie zur Katastrophenbewältigung
Vorteile
- Granulare Kontrolle über replizierte Daten
- Mehrere Abonnenten werden unterstützt
- Flexible Topologieoptionen
- Kann bestimmte Tabellen oder Spalten replizieren
- Durch Filterung wird der Netzwerkverkehr reduziert.
- Unterstützt heterogene Replikation (SQL Server (zu Oracle)
- Funktioniert mit der Standard Edition
Nachteile
- Keine automatische Ausfallsicherung
- Komplexe Konfiguration und Verwaltung
- Potenzial für Replikationskonflikte (Merge und Peer-to-Peer)
- Latenz bei der Datensynchronisation
- Schemaänderungen erfordern eine sorgfältige Koordination
- Nicht als primäre HA-Lösung konzipiert
- Die Fehlersuche kann eine Herausforderung sein.
- Peer-to-Peer erfordert die Enterprise Edition.
Referenzen
- SQL Server Replikation: Vollständiger Leitfaden für Datenbankadministratoren
- Offizielles Microsoft-Dokument: SQL Server Replikation
8. Holztransport
Log Shipping bietet eine Lösung für die Notfallwiederherstellung und hohe Verfügbarkeit durch automatisierte Sicherungs-, Kopier- und Wiederherstellungsprozesse für Transaktionsprotokolle und bietet damit einen einfachen und kostengünstigen Ansatz zur Aufrechterhaltung synchronisierter sekundärer Datenbanken.
Hauptfunktionen
- Automatisierte Sicherungs-, Kopier- und Wiederherstellungsaufträge über den SQL-Agenten
- Unterstützung für mehrere sekundäre Server
- Konfigurierbare Sicherungs- und Wiederherstellungsintervalle
- Der STANDBY-Modus ermöglicht den Lesezugriff auf das sekundäre System.
- Verzögerte Protokollwiederherstellung zum Schutz vor Fehlern
- Monitor-Server für zentrale Überwachung
- Unterstützung für die Komprimierung von Transaktionsprotokollen
Implementierungsschritte
- Stellen Sie sicher, dass die primäre Datenbank das vollständige Wiederherstellungsmodell verwendet.
- Erstellen Sie eine vollständige Sicherung der primären Datenbank.
- Backup auf sekundärem Server mit NORECOVERY wiederherstellen
- Konfigurieren Sie den Protokollversand auf der primären Datenbank.
- Geben Sie einen freigegebenen Sicherungsordner an, auf den alle Server zugreifen können.
- Backup-Job-Zeitplan auf dem primären System konfigurieren
- Konfigurieren von Kopier- und Wiederherstellungsaufträgen auf dem sekundären Server
- Optional kann der Monitor-Server konfiguriert werden.
- Test-Failover-Verfahren
Am besten geeignet für
- Kostengünstige Lösungen zur Notfallwiederherstellung
- Organisationen mit Standard Edition-Lizenz
- Szenarien, die einen Datenverlust von wenigen Minuten tolerieren
- Umgebungen, die mit manuellem Failover vertraut sind
- Verzögerte Wiederherstellung für Fehlerschutzanforderungen
- Meldung von Arbeitslasten im STANDBY-Modus
- Einfache DR-Anforderungen ohne komplexe Infrastruktur
Vorteile
- Einfache Konfiguration und Bedienung
- Kostengünstig (Unterstützung der Standard Edition)
- Mehrere sekundäre Server werden unterstützt
- Konfigurierbare Verzögerung schützt vor logischen Fehlern
- Nur-Lese-Berichterstattung im Standby-Modus
- Toleriert hohe Netzwerklatenz
- Minimale Auswirkungen auf den primären Server
- Bewährte, ausgereifte Technologie
Nachteile
- Keine automatische Ausfallsicherung
- Muss für jede Datenbank separat konfiguriert werden.
- Synchronisierungsverzögerung (Minuten bis Stunden)
- Potenzieller Datenverlust basierend auf dem Sicherungsintervall
- Manuelles Failover erhöht die RTO
- Erfordert SQL Server Agent läuft auf allen Servern
- Sekundäre Datenbanken sind während der Protokollwiederherstellung nicht zugänglich.
- Anwendungen erfordern nach einem Failover Änderungen an der Verbindungszeichenfolge.
Referenzen
- SQL Server Logversand: Vollständiger Leitfaden für DBAs
- Offizielles Microsoft-Dokument: Informationen zum Protokollversand (SQL Server)
9. Datenbankspiegelung
Die Datenbankspiegelung ist eine veraltete Hochverfügbarkeitslösung auf Datenbankebene, die seitdem keine Verbesserungen mehr erfahren hat. SQL Server 2012, obwohl es auch in aktuellen Versionen weiterhin verfügbar ist. Microsoft empfiehlt dringend die Migration zu Always On Availability Groups für alle neuen Bereitstellungen.
Hauptfunktionen
- Haupt- und Spiegelserverarchitektur
- Optionaler Zeugenserver für automatisches Failover
- Zwei Betriebsmodi: Hohe Sicherheit und Hohe Leistung
- Unterstützung für synchronen und asynchronen Betrieb
- Automatische Seitenreparaturfunktion
- Schutz auf Datenbankebene
- Unterstützung der Verschlüsselung bei der Datenübertragung
Implementierungsschritte
- Stellen Sie sicher, dass die Datenbank das vollständige Wiederherstellungsmodell verwendet.
- Erstellen Sie eine vollständige Sicherung und stellen Sie diese mit NORECOVERY auf dem Spiegelserver wieder her.
- Erstellen Sie Spiegelungsendpunkte auf dem Haupt- und Spiegelserver.
- Zertifikate für die Authentifizierung konfigurieren
- Eine Spiegelungssitzung zwischen den Servern einrichten
- Optional kann der Zeugenserver für automatisches Failover konfiguriert werden.
- Betriebsmodus einstellen (Hohe Sicherheit oder Hohe Leistung)
- Test-Failover-Verfahren
Am besten geeignet für
- Legacy-Systeme, die bereits Datenbankspiegelung verwenden
- Beibehaltung der bestehenden Konfigurationen, bis eine Migration möglich ist
- Es werden keine weiteren Szenarien empfohlen (diese Funktion ist veraltet).
Vorteile
- Schnelles automatisches Failover im Hochsicherheitsmodus mit Zeugen
- Kein Datenverlust im Modus „Hohe Sicherheit“
- Automatische Seitenreparatur vom Partner
- Einfacher als Verfügbarkeitsgruppen für eine einzelne Datenbank
- Unterstützt Verschlüsselung für die Übertragung
- Laufende Upgrades mit minimalen Ausfallzeiten
Nachteile
- Veraltet seit SQL Server 2012 (kann entfernt werden)
- Konfiguration und Failover pro Datenbank
- Kein lesbarer Spiegel (keine Leseskalierungsfähigkeit)
- Jede Datenbank führt ein unabhängiges Failover durch.
- Aktualisierung der Verbindungszeichenfolge nach Failover erforderlich
- Beschränkt auf zwei Server (Hauptserver und Spiegelserver)
- Keine Verbesserungen oder neuen Funktionen
- Microsoft empfiehlt die Migration zu Always On AG.
Referenzen
10. Verwaltete Instanzverbindung
Managed Instance Link erstellt eine Hybridverbindung zwischen SQL Server und Azure SQL Managed Instance unter Verwendung der Technologie verteilter Verfügbarkeitsgruppen, wodurch eine nahezu Echtzeit-Datenreplikation für Szenarien der Notfallwiederherstellung, Migration und Cloud-Integration ermöglicht wird.
Hauptfunktionen
- Nahezu Echtzeitreplikation mittels verteilter AG-Technologie
- Einwegreplikation (SQL Server 2016-2019 zu Azure)
- Bidirektionale Replikation mit Failback (SQL Server 2022 +)
- Eine Datenbank pro Link (mehrere Links werden unterstützt)
- Lesbare Replikate auf Azure SQL Managed Instance
- Lizenzfreie passive DR-Replika-Option
- Online-Migration mit minimaler Ausfallzeit
Implementierungsschritte
- Danach SQL Server Umgebung (VPN oder ExpressRoute zu Azure)
- Konfigurieren einer verwalteten Azure SQL-Instanz
- Aktivieren Sie die Funktion „Immer an“ in AG. SQL Server
- Datenbankspiegelungs-Endpunkt erstellen
- Tauschen Sie Zertifikate zwischen SQL Server und MI
- Erstellen einer verwalteten Instanzverknüpfung mithilfe von SSMS oder Skripten
- Replikation und Synchronisierung prüfen
- Konfigurieren Sie das Routing nur für Lesezugriffe, wenn Sie es für die Leseskalierung verwenden.
- Test-Failover-Verfahren
Am besten geeignet für
- Hybride Notfallwiederherstellung mit cloudbasierter sekundärer
- Online-Migration zu Azure SQL Managed Instance
- Auslagerung von Analysen und Berichten nach Azure
- Organisationen, die eine Hybrid-Cloud-Strategie verfolgen
- Szenarien, die die Integration von Azure-Diensten erfordern
- Kostenoptimierung mit lizenzfreier passiver DR
Vorteile
- Optimale Migration zu Azure mit minimalen Ausfallzeiten und höchster Performance.
- Echte Online-Migration auf die Stufe „Geschäftskritisch“
- Bidirektionales Failover mit SQL Server 2022+
- Lizenzfreie passive DR-Replik reduziert die Kosten
- Integration mit Azure-Diensten ohne vollständige Migration
- Leseskalierungsfähigkeit mithilfe von Azure-Replikaten
- Automatisierte Backups auf Azure-Seite
- Geografische Verteilung auf Azure-Regionen
Nachteile
- Beschränkung auf eine Datenbank pro Verbindung
- Kann nicht mit Failovergruppen auf MI verwendet werden.
- Systemdatenbanken nicht repliziert
- Objekte auf Instanzebene erfordern eine manuelle Synchronisierung.
- SQL Server 2016-2019 nur in eine Richtung (kein Failback)
- Azure-Kosten für verwaltete Instanzen
- Netzwerkverbindungsanforderungen (VPN/ExpressRoute)
- Funktionseinschränkungen (Dateitabellen und Dateiströme werden nicht unterstützt)
Referenzen
11. Vergleich von Hochverfügbarkeitslösungen
11.1 Vergleichstabelle der Merkmale
| Funktion | Always On AG | Enthält AG | Verteilte AG | FCI | Replikation | Protokollversand | Spiegeln | MI Link |
|---|---|---|---|---|---|---|---|---|
| Ausgabe | Ent/Std | Ent/Std | Ent | Ent/Std | Ent/Std | Ent/Std | Ent/Std | Ent/Std |
| Schutzstufe | Datenbank | Datenbank + Instanz | Datenbank | Beispiel | Datenbank/Objekte | Datenbank | Datenbank | Datenbank |
| Datensynchronisierung | Synchron/Asynchron | Synchron/Asynchron | Synchron/Asynchron | Gemeinsam genutzt | Asynchron | Asynchron | Synchron/Asynchron | Asynchron |
| Automatisches Failover | Ja | Ja | Ja | Ja | Nein | Nein | Ja | Nein |
| Leseskalierung | Ja | Ja | Ja | Nein | Ja | Begrenzt | Nein | Ja |
| RTO | Sekunden | Sekunden | Sekunden | Minuten | Handbuch | Handbuch | Sekunden | Handbuch |
| RPO | Null/Min. | Null/Min. | Null/Min. | Null | Minimal | Minuten | Null/Min. | Minimal |
| Support-Status | Aktives | Aktives | Aktives | Aktives | Aktives | Aktives | Veraltete | Aktives |
11.2 Auswahl einer HA-Lösung
Bei der Auswahl der Lösung sollten folgende Faktoren berücksichtigt werden:
- Budgetüberlegungen haben einen erheblichen Einfluss auf die Lösungswahl: Die Anforderungen der Enterprise Edition wirken sich auf die Lizenzkosten aus, während die Infrastrukturanforderungen von teurem gemeinsam genutztem Speicher für FCIs bis hin zu Standardservern für Verfügbarkeitsgruppen reichen.
- Der Komplexitätsgrad ist sehr unterschiedlich: Log Shipping bietet die einfachste Implementierung, während verteilte Verfügbarkeitsgruppen umfangreiches Fachwissen erfordern.
- Die RTO-Anforderungen bestimmen die Technologieauswahl. Sekundenlange Ausfallzeiten erfordern Always-On-Verfügbarkeitsgruppen oder FCIs mit automatischem Failover. Minutenlange Toleranz ermöglicht manuelle Failover-Lösungen wie Log Shipping.
- Die RPO-Anforderungen sind gleichermaßen wichtig: Null-Datenverlust erfordert synchrone Lösungen, während eine Toleranz von wenigen Minuten das Log Shipping ermöglicht.
- Infrastrukturbeschränkungen, Anforderungen an die Lesekapazität, geografische Verteilungsanforderungen und Cloud-Hybrid-Szenarien beeinflussen die Auswahl der optimalen Lösung.
12. Best Practices für SQL Server Hochverfügbarkeit
12.1 Planung und Entwurf
Ermitteln Sie die Geschäftsanforderungen durch sorgfältige RTO- und RPO-Analysen für jede Datenbank. Wählen Sie passende Lösungen, die den Anforderungen entsprechen, anstatt standardmäßig auf die komplexesten Optionen zurückzugreifen. Planen Sie sowohl lokale Hochverfügbarkeit als auch geografische Notfallwiederherstellung mithilfe mehrschichtiger Ansätze. Dokumentieren Sie die Architektur umfassend, einschließlich Netzwerkdiagrammen, Failover-Prozeduren und Wiederherstellungshandbüchern.
12.2 Umsetzungsleitfaden
Die Ausfallsicherungsverfahren sollten regelmäßig durch geplante Tests und simulierte Ausfälle geprüft werden, um sie zu validieren. SQL Server Hochverfügbarkeitslösungen und Teambereitschaft. Kontinuierliche Überwachung von Zustand und Leistung mithilfe von SQL Serverintegrierte Tools wie SQL Server Profiler und DMVs. Konfigurieren Sie umfassende Warnmeldungen für Synchronisierungsverzögerungen, Failover-Ereignisse und Beeinträchtigungen des Systemzustands. Warten Sie SQL Server Sicherungsstrategien Trotz HA-Implementierung bleiben Backups die letzte Verteidigungslinie gegen logische Beschädigung und versehentliches Löschen. Halten Sie Ihre Systeme mit kumulativen Updates, Sicherheitspatches und Firmware-Updates auf dem neuesten Stand. Validieren Sie Wiederherstellungsverfahren regelmäßig durch tatsächliche Wiederherstellungen und Anwendungstests und seien Sie darauf vorbereitet, mit Szenarien wie den folgenden umzugehen: Datenbanken hängen im Wiederherstellungsmodus fest.
12.3 Überwachung und Wartung
Nutzen Sie Tools wie SQL Server Activity Monitor, SQL Server Performance Monitorund Dynamic Management Views umfassend für die Gesundheitsüberwachung und Ausführung DBCC-CHECKDB Überprüfen Sie regelmäßig die Datenbankintegrität. Nutzen Sie das Always On Dashboard zur visuellen Beurteilung des Zustands der Verfügbarkeitsgruppe. Überwachen Sie Synchronisierungsverzögerungen sorgfältig, insbesondere bei asynchronen Replikaten und Log Shipping. Verfolgen Sie Failover-Ereignisse akribisch. SQL Server Erweiterte Ereignisse Analysieren Sie die Ursachen für die auftretenden Muster. Legen Sie Leistungsgrundlagen für den Normalbetrieb fest und überwachen Sie Abweichungen, die auf potenzielle Probleme hinweisen. Führen Sie regelmäßige Kapazitätsplanungsüberprüfungen durch, um sicherzustellen, dass die Infrastruktur das wachsende Arbeitsaufkommen unterstützt.
13. FAQ
F: Was ist der Unterschied zwischen Hochverfügbarkeit und Notfallwiederherstellung in SQL Server?
A: Hochverfügbarkeit minimiert Ausfallzeiten bei lokalen Störungen innerhalb eines Rechenzentrums, typischerweise durch automatisches Failover und Wiederherstellungszeiten (RTOs) von Sekunden oder Minuten. Disaster Recovery schützt vor regionalen Katastrophen, üblicherweise mit manuellem Failover und längeren RTOs, deckt aber Ereignisse ab, die ganze Einrichtungen betreffen.
F: Worin besteht der Unterschied zwischen Hochverfügbarkeits- (HA) und Leseskalierungslösungen?
A: Hochverfügbarkeitslösungen gewährleisten die Erreichbarkeit von Datenbanken auch bei Ausfällen und konzentrieren sich dabei auf maximale Verfügbarkeit und automatische Failover-Funktionen. Read-Scale-Lösungen verbessern die Abfrageleistung, indem sie Lesezugriffe auf mehrere Datenbankreplikate verteilen und so Durchsatz und Antwortzeiten optimieren. Obwohl diese Lösungen unterschiedlichen Zwecken dienen, kann dieselbe Technologie, wie beispielsweise Always On Availability Groups, beide Vorteile gleichzeitig bieten: Lesbare sekundäre Replikate ermöglichen Read-Scale und dienen gleichzeitig als Failover-Ziele für Hochverfügbarkeit.
F: Welche SQL Server Welche Hochverfügbarkeitslösung ist am besten für meine Bedürfnisse geeignet?
A: Die beste Lösung hängt von den RTO- und RPO-Zielen, dem Budget, der verfügbaren Edition, der Infrastruktur und dem vorhandenen Fachwissen ab. Always On Availability Groups eignen sich für die meisten Unternehmensszenarien, während Log Shipping in kostensensiblen Umgebungen gut funktioniert. Vergleichen Sie Ihre Anforderungen mit der Vergleichstabelle.
F: Ist für Always On-Verfügbarkeitsgruppen die Enterprise Edition erforderlich?
A: Die Standard Edition unterstützt Basic Availability Groups mit erheblichen Einschränkungen: eine Datenbank pro Gruppe, ein sekundäres Replikat und keine lesbaren sekundären Replikate. Der volle Funktionsumfang mit mehreren Datenbanken, acht sekundären Replikaten und lesbaren Replikaten ist nur in der Enterprise Edition verfügbar.
F: Kann ich Log Shipping verwenden mit SQL Server Standardausgabe?
A: Ja, Log Shipping wird in der Standard Edition vollständig unterstützt und ist somit eine attraktive und kostengünstige Disaster-Recovery-Lösung für Unternehmen ohne Enterprise Edition-Lizenz.
F: Worin besteht der Unterschied zwischen Always On-Verfügbarkeitsgruppen und Datenbankspiegelung?
A: Die Datenbankspiegelung ist veraltet und arbeitet auf Ebene einzelner Datenbanken ohne lesbaren sekundären Zugriff. Always On-Verfügbarkeitsgruppen unterstützen Gruppen von Datenbanken mit bis zu acht sekundären Datenbanken, lesbare Replikate und eine erweiterte Überwachung. Microsoft empfiehlt die Migration zu Always On.
F: Wie wähle ich zwischen Failoverclusterinstanzen und Verfügbarkeitsgruppen?
A: Wählen Sie FCIs für den Schutz auf Instanzebene bei gemeinsam genutzter Speicherinfrastruktur. Wählen Sie Verfügbarkeitsgruppen für den Schutz auf Datenbankebene, Leseskalierungsfunktionen und geografische Verteilung ohne gemeinsam genutzten Speicher. Unternehmen kombinieren häufig beide Ansätze für einen umfassenden Schutz.
F: Kann ich mehrere kombinieren? SQL Server Hochverfügbarkeitslösungen?
A: Ja, die Kombination von Lösungen ist üblich. FCIs können als Replikate von Verfügbarkeitsgruppen dienen und so lokale Hochverfügbarkeit auf Instanzebene sowie geografische Disaster Recovery auf Datenbankebene gewährleisten. Log Shipping kann Verfügbarkeitsgruppen ergänzen und zusätzlichen Schutz für entfernte Systeme bieten. Testen Sie kombinierte Konfigurationen gründlich.
F: Worin besteht der Unterschied zwischen synchroner und asynchroner Replikation?
A: Die synchrone Replikation wartet auf die Bestätigung des sekundären Servers, bevor sie die Änderungen festschreibt. Dadurch wird Datenverlust ausgeschlossen, es kann jedoch zu Latenzzeiten kommen. Die asynchrone Replikation erfolgt ohne Wartezeit, optimiert die Leistung, kann aber bei einem Failover zu Datenverlusten führen.
F: Benötige ich trotzdem noch Backups, wenn ich habe? SQL Server Hochverfügbarkeit konfiguriert?
A: Absolut. Hochverfügbarkeit schützt zwar vor Hardwareausfällen, aber nicht vor logischen Beschädigungen, versehentlichem Löschen oder böswilligen Aktionen, die sich auf alle Kopien auswirken. Backups bleiben unerlässlich für die Wiederherstellung zu einem bestimmten Zeitpunkt und die Einhaltung von Compliance-Anforderungen.
F: Benötige ich trotzdem noch Backups, wenn ich habe? SQL Server Hochverfügbarkeit konfiguriert?
A: Absolut ja. Hochverfügbarkeit schützt zwar vor Hardwareausfällen, aber nicht vor Datenbankbeschädigung, versehentlichem Löschen oder böswilligen Eingriffen. Backups sind weiterhin unerlässlich für die Wiederherstellung zu einem bestimmten Zeitpunkt und die Einhaltung von Compliance-Anforderungen. Falls Datenbankdateien beschädigt werden und Backups nicht verfügbar oder ebenfalls beschädigt sind, sind spezialisierte Systeme erforderlich. Software zur Reparatur von SQL-Datenbanken kann dabei helfen, Daten aus beschädigten MDF-, NDF- und Sicherungsdateien wiederherzustellen.
F: Was ist eine Contained Availability Group und wie unterscheidet sie sich von einer regulären Availability Group?
A: Eingebettete Verfügbarkeitsgruppen, eingeführt in SQL Server Ab 2022 werden Instanzobjekte wie Anmeldungen, Aufträge und Metadaten automatisch synchronisiert. Reguläre Verfügbarkeitsgruppen synchronisieren hingegen nur Datenbankobjekte, sodass Instanzobjekte manuell repliziert werden müssen.
F: Kann ich Daten replizieren von SQL Server zu Azure SQL Managed Instance?
A: Ja, Managed Instance Link bietet hybride Replikation zwischen SQL Server und Azur. SQL Server 2016-2019 unterstützt unidirektionale Replikation, während SQL Server Ab Version 2022+ wird die bidirektionale Replikation mit Failback für Notfallwiederherstellung, Migration und Hybrid-Szenarien ermöglicht.
F: Was passiert mit SQL Server Agentenjobs während eines Failovers?
A: Bei herkömmlichen Verfügbarkeitsgruppen müssen Aufträge manuell auf sekundären Replikaten erstellt werden. Enthaltene Verfügbarkeitsgruppen (SQL Server Ab Version 2022 werden Aufträge automatisch synchronisiert. Failover-Clusterinstanzen schließen Aufträge als Teil des Instanzschutzes ein.
14. Fazit
SQL Server bietet umfassende Hochverfügbarkeitslösungen für unterschiedlichste Anforderungen – von Abteilungsdatenbanken bis hin zu unternehmenskritischen Systemen. Jede Lösung bietet spezifische Funktionen und Kompromisse, die Datenbankadministratoren für fundierte Entscheidungen verstehen müssen.
Always On Availability Groups sind die führende Technologie für moderne Bereitstellungen. Contained Availability Groups vereinfachen die Administration, während Distributed Availability Groups komplexe plattformübergreifende Szenarien ermöglichen. Failover-Clusterinstanzen erfüllen weiterhin die Anforderungen an den Schutz auf Instanzebene, und Log Shipping bleibt für kostensensible Szenarien relevant. Managed Instance Link eröffnet Cloud-Hybrid-Möglichkeiten und verbindet lokale Systeme mit Cloud-Umgebungen. SQL Server mit Azure.
Die Abstimmung von Lösungen auf spezifische Geschäftsanforderungen ist der entscheidende Erfolgsfaktor. Es gibt keine Universallösung. Unternehmen müssen RTO- und RPO-Anforderungen, Budgetbeschränkungen, Infrastrukturkapazitäten und administrative Expertise sorgfältig evaluieren. Oft kombiniert die beste Architektur mehrere Lösungen für umfassenden Schutz. Prüfen Sie, wie Ihre HA-Strategie mit Ihren umfassenderen Cloud-Einführungsplänen übereinstimmt, und konsultieren Sie Fachartikel für detaillierte Implementierungshinweise, um Ihre Ziele zu erreichen. SQL Server Die Infrastruktur bietet die Zuverlässigkeit, die Ihr Unternehmen benötigt.
Über den Autor
Yuan Sheng ist ein erfahrener Datenbankadministrator (DBA) mit über 10 Jahren Erfahrung in SQL Server Umgebungen und Unternehmensdatenbankverwaltung. Er hat Hunderte von Datenbankwiederherstellungsszenarien in Finanzdienstleistungs-, Gesundheits- und Fertigungsunternehmen erfolgreich gelöst.
Yuan ist spezialisiert auf SQL Server Datenbankwiederherstellung, Hochverfügbarkeitslösungen und Leistungsoptimierung. Seine umfangreiche praktische Erfahrung umfasst die Verwaltung von Multi-Terabyte-Datenbanken, die Implementierung von Always On Availability Groups und die Entwicklung automatisierter Backup- und Wiederherstellungsstrategien für unternehmenskritische Geschäftssysteme.
Durch sein technisches Fachwissen und seinen praktischen Ansatz konzentriert sich Yuan auf die Erstellung umfassender Anleitungen, die Datenbankadministratoren und IT-Experten bei der Lösung komplexer SQL Server Herausforderungen effizient. Er bleibt auf dem Laufenden mit den neuesten SQL Server und die sich entwickelnden Datenbanktechnologien von Microsoft und testet regelmäßig Wiederherstellungsszenarien, um sicherzustellen, dass seine Empfehlungen den bewährten Vorgehensweisen der Praxis entsprechen.
Haben Sie Fragen zu SQL Server Wiederherstellung oder benötigen Sie zusätzliche Anleitung zur Datenbank-Fehlerbehebung? Yuan begrüßt Feedback und Vorschläge zur Verbesserung dieser technischen Ressourcen.