Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Da die globale IT-Umgebung immer unvorhersehbarer wird, ist eine belastbare Hochverfügbarkeitsstrategie zur Sicherstellung der Geschäftskontinuität wichtiger denn je. Viele SQL Server-Datenbankadministratoren und Unternehmen möchten einen SQL Server-Aktiv-Aktiv-Cluster aufbauen – aufgrund seiner Vorteile wie nahezu ausfallfreier Betrieb, Lastverteilung und Skalierbarkeit.
In diesem Leitfaden erklären wir, was ein Aktiv-Aktiv-Cluster ist, zeigen Ihnen Schritt für Schritt dessen Einrichtung und stellen eine professionelle Datenbankreplikationslösung vor, mit der Sie Aktiv-Aktiv-Cluster unkompliziert erstellen können.
Ein Aktiv-Aktiv-Cluster ist eine Hochverfügbarkeitsarchitektur, bei der zwei oder mehr Knoten gleichzeitig Arbeitslasten verarbeiten.
Ein typischer Aktiv-Aktiv-Cluster bietet folgende Funktionen:
Kurz gesagt: Nein – der Windows Server Failover Cluster (WSFC) unterstützt keinen echten Aktiv-Aktiv-Cluster für Schreibzugriffe.
Bei SQL Server handelt es sich bei einem Aktiv-Aktiv-Cluster um eine WSFC-Konfiguration, bei der mehrere unabhängige SQL Server-Instanzen gleichzeitig auf unterschiedlichen Clusterknoten laufen. Jede Instanz verwaltet einen eigenen Satz an Datenbanken, während die Hochverfügbarkeit durch automatische Failover-Mechanismen sichergestellt wird.
Die SQL Server-Aktiv-Aktiv-Konfiguration bedeutet nicht, dass dieselbe Datenbank gleichzeitig auf mehreren Knoten aktiv ist und mehrere Server gleichzeitig Lese- und Schreibzugriffe auf eine gemeinsame Datenbank ausführen (dies wäre ein lastverteilter oder verteilter Datenbankbetrieb). Stattdessen ist jeder Server (Knoten) im Cluster „aktiv“, da er mindestens eine SQL Server-Instanz hostet.
Das bedeutet, SQL Server unterstützt ein sogenanntes „Read-Scale-Aktiv-Aktiv-Modell“ und keinen echten Aktiv-Aktiv-Cluster mit Schreibzugriffen auf mehreren Knoten.
SQL Server Aktiv-Passiv-Failover-Cluster: Nur ein Knoten führt die produktive SQL Server-Instanz aus und bedient Client-Anfragen, während der zweite Knoten als ungenutzte Standby-Einheit ohne aktive Datenbankoperationen wartet.
Falls der primäre Knoten aufgrund von Hardware-, Netzwerk- oder Dienstproblemen ausfällt, wechselt der Cluster die SQL Server-Instanz automatisch auf den passiven Knoten. Diese Konfiguration bietet zuverlässige Hochverfügbarkeit bei einfacher Verwaltung, jedoch bleibt der Standby-Knoten im Normalbetrieb unausgelastet und verschwendet Rechen- und Arbeitsspeicherressourcen.
SQL Server Aktiv-Aktiv-Cluster: Bezeichnet eine Konfiguration, bei der mehrere unabhängige SQL Server-Instanzen gleichzeitig auf unterschiedlichen Clusterknoten laufen und jeweils eigene Datenbanken und Anwendungen verwalten.
Jeder Knoten verarbeitet seine eigene Arbeitslast aktiv, sodass Serverhardware deutlich effizienter genutzt wird als bei einem Aktiv-Passiv-Cluster.
In der Praxis bestehen Unterschiede hinsichtlich Leistung, Kosten und Einsatzbereichen. Unten finden Sie eine direkte Vergleichstabelle.
|
|
SQL Server Aktiv-Aktiv-Cluster |
SQL Server Aktiv-Passiv-Cluster |
|
Hardwareauslastung |
Maximale Auslastung: Alle Knoten sind aktiv, hosten unabhängige SQL Server-Instanzen und verarbeiten Arbeitslasten. Es gibt keine ungenutzte Hardware, Serverressourcen werden optimal ausgeschöpft. |
Niedrige Auslastung: Ein Knoten (passiv) befindet sich dauerhaft im Leerlauf als Standby. Hardwareressourcen gehen verloren, da der passive Knoten nur im Failover-Fall aktiviert wird. |
|
Auswirkungen auf die Leistung beim Failover |
Mäßige Auswirkungen: Fällt ein Knoten aus, wird seine SQL-Instanz auf einen intakten Knoten migriert, der dann mehrere Instanzen hostet. Dies kann vorläufige Ressourcenkonflikte (CPU, Arbeitsspeicher) verursachen, bis der ausgefallene Knoten wiederhergestellt ist. |
Minimale Auswirkungen: Der passive Knoten ist leer und ausschließlich für die Übernahme der einzelnen SQL-Instanz vorgesehen. Das Failover läuft in den meisten Fällen schneller ab, ohne Ressourcenkonflikte, da der Standby-Knoten keine vorhandene Arbeitslast hat. |
|
Lizenzkosten |
Höhere Kosten: Es werden Lizenzen für alle bereitgestellten SQL Server-Instanzen und alle Knoten benötigt, da jeder Knoten aktive Instanzen hostet. Für alle Clusterfunktionen ist üblicherweise die Enterprise Edition erforderlich. |
Niedrigere Kosten: Es muss nur eine SQL Server-Instanz lizenziert werden, da der passive Knoten als Standby fungiert und keine aktive Instanz ausführt. Die Lizenzierung beschränkt sich auf den aktiven Knoten und die einzelne Instanz.
|
|
Komplexität der Bereitstellung |
Höhere Komplexität: Erfordert die Bereitstellung mehrerer SQL Server-Instanzen auf einem Windows Server Failover Cluster (WSFC), die Konfiguration von Instanzabhängigkeiten, Failover-Regeln und Lastverteilung. Es bedarf einer sorgfältigen Kapazitätsplanung, um Ressourcenengpässe nach einem Failover zu vermeiden.
|
Niedrigere Komplexität: Einfache Einrichtung mit einer einzelnen SQL Server-Instanz auf einem WSFC, einem aktiven und einem passiven Standby-Knoten. Die Konfiguration konzentriert sich auf grundlegende Failover- und Quorum-Einstellungen, sodass die Verwaltung für Datenbankadministratoren vereinfacht wird.
|
|
Ideal geeignete Einsatzbereiche |
Unternehmen mit mehreren unabhängigen Datenbanken (z. B. CRM, Berichterstellung, Protokollierung), die Hochverfügbarkeit benötigen und die Hardwareauslastung maximieren möchten. Geeignet für Umgebungen, in denen ungenutzte Ressourcen nicht vertretbar sind und Arbeitslasten auf Instanzen aufgeteilt werden können.
|
Unternehmen mit einer einzelnen kritischen Datenbank (z. B. Finanztransaktionen, zentrale Geschäftsanwendungen), für die Einfachheit und minimale Auswirkungen beim Failover oberste Priorität haben. Geeignet für Teams mit begrenzten DBAs oder Umgebungen, bei denen Hardwarekosten weniger relevant sind als einfache Verwaltung.
|
Welche Variante sollten Sie wählen?
Die Entscheidung zwischen einem SQL Server-Aktiv-Aktiv-Cluster und einem Aktiv-Passiv-Cluster hängt von den Prioritäten Ihres Unternehmens, den Eigenschaften der Arbeitslasten und den vorhandenen Ressourcen ab. Unten finden Sie eine klare Aufteilung als Entscheidungshilfe:
►Wählen Sie einen SQL Server-Aktiv-Aktiv-Cluster, wenn Sie mehrere unabhängige Datenbanken besitzen, die auf separate SQL-Instanzen aufgeteilt werden können, und Sie die Hardwareauslastung maximieren möchten.
Diese Architektur ist ideal für Unternehmen, die keine ungenutzten Serverressourcen dulden können und Hochverfügbarkeit für mehrere Arbeitslasten benötigen. Sie funktioniert am besten, wenn Sie über DBAs verfügen, die die erhöhte Komplexität verwalten können, und eine Kapazitätsplanung für den Betrieb nach einem Failover durchführen (sicherstellen, dass ein einzelner Knoten vorläufig alle Instanzen übernehmen kann).
►Wählen Sie einen Aktiv-Passiv-Cluster, wenn Sie eine einzelne kritische Datenbank (oder eine kleine Gruppe eng verbundener Datenbanken) betreiben, für die Einfachheit und minimale Auswirkungen beim Failover oberste Priorität haben.
Diese Architektur eignet sich hervorragend für Unternehmen mit begrenzten Datenbankkenntnissen, da sie weniger Konfiguration und Wartung erfordert. Sie ist ebenfalls besser geeignet, wenn Hardwarekosten keine große Rolle spielen und schnelle, wenig beeinträchtigende Failover-Vorgänge wichtiger sind als eine effiziente Ressourcennutzung.
Obwohl SQL Server keinen echten Mehrknoten-Schreibzugriff unterstützt, können Sie dennoch eine „aktiv-aktiv-ähnliche“ Architektur entwerfen, die die Ressourcenauslastung maximiert und die Leistung verbessert. Im Folgenden die detaillierten Schritte.
Schritt 1: Installieren des WSFC-Features auf allen Knoten
Öffnen Sie auf jedem Knoten (Knoten 1 und Knoten 2) den Server-Manager, navigieren Sie zu „Rollen und Features hinzufügen“ und wählen Sie das Feature „Failover-Clustering“ aus. Folgen Sie dem Assistenten zur Installation des Features einschließlich aller erforderlichen Abhängigkeiten (z. B. .NET Framework). Starten Sie jeden Knoten nach der Installation neu, um die Einrichtung abzuschließen.
Schritt 2: Ausführen des Cluster-Validierungstests
Bevor Sie den Cluster erstellen, führen Sie den Cluster-Validierungstest aus, um sicherzustellen, dass alle Knoten die WSFC-Anforderungen erfüllen. Öffnen Sie den Failover-Cluster-Manager auf einem Knoten, wählen Sie „Konfiguration überprüfen“ aus und fügen Sie beide Knoten zur Validierungsliste hinzu. Wählen Sie die Option „Alle Tests ausführen“, um Hardware, Software, Netzwerk und Speicherkonfigurationen zu prüfen. Überprüfen Sie den Validierungsbericht – beheben Sie alle Fehler oder Warnungen, bevor Sie fortfahren (kritische Fehler verhindern die Clustererstellung).
Schritt 3: Erstellen des WSFC
Wählen Sie im Failover-Cluster-Manager „Cluster erstellen“ und folgen Sie dem Assistenten. Geben Sie einen eindeutigen Clusternamen ein und weisen Sie dem Cluster eine statische IP-Adresse zu. Stellen Sie sicher, dass beide Knoten dem Cluster hinzugefügt werden, und prüfen Sie die Quorum-Konfiguration – bei einem Zwei-Knoten-Cluster wählen Sie einen Quorum-Witness (Dateifreigabe, Datenträger oder Cloud-Witness), um Split-Brain-Szenarien zu vermeiden.
Schließen Sie den Assistenten zur Clustererstellung ab und bestätigen Sie im Failover-Cluster-Manager, dass der Cluster-Status „Online“ lautet.
Schritt 4: Installieren der ersten gruppierten SQL Server-Instanz (Knoten 1)
Legen Sie das SQL Server-Installationsmedium auf Knoten 1 ein und starten Sie den Setup-Assistenten. Wählen Sie „Neue SQL Server-Failover-Cluster-Installation“ aus und folgen Sie den Aufforderungen. Wählen Sie die SQL Server Enterprise Edition sowie die benötigten Features aus. Weisen Sie der Instanz einen eindeutigen Instanznamen, einen virtuellen Netzwerknamen (VNN) und eine statische IP-Adresse zu.
Konfigurieren Sie den gemeinsamen Speicher für System- und Benutzerdatenbanken der Instanz und richten Sie ein Domänendienstkonto für die SQL Server- und SQL Server-Agent-Dienste ein. Schließen Sie die Installation ab und prüfen Sie im Failover-Cluster-Manager, ob die Instanz online ist.
Schritt 5: Installieren der zweiten gruppierten SQL Server-Instanz (Knoten 2)
Wiederholen Sie den Installationsvorgang auf Knoten 2, wählen Sie aber nur „Knoten zu einem SQL Server-Failover-Cluster hinzufügen“, wenn Sie einen Knoten zu einer vorhandenen Instanz hinzufügen möchten – für einen Aktiv-Aktiv-Cluster benötigen Sie eine zweite unabhängige gruppierte Instanz.
Starten Sie stattdessen erneut den Setup-Assistenten und wählen Sie „Neue SQL Server-Failover-Cluster-Installation“, um eine zweite Instanz zu erstellen.
Weisen Sie einen eindeutigen Instanznamen zu (z. B. SQLINSTANCE02), einen abweichenden virtuellen Netzwerknamen sowie eine separate statische IP-Adresse (z. B. 192.168.1.101) und einen separaten gemeinsamen Speicher (um Ressourcenkonflikte mit der ersten Instanz zu vermeiden).
Verwenden Sie dasselbe Domänendienstkonto für die SQL-Dienste (oder ein anderes Konto mit gleichwertigen Berechtigungen) und schließen Sie die Installation ab.
Prüfen Sie im Failover-Cluster-Manager, ob die zweite Instanz online ist.
Schritt 6: Konfigurieren bevorzugter Besitzer und Failover-Einstellungen
Legen Sie für jede SQL-Instanz den bevorzugten Besitzerknoten fest, um eine optimale Verteilung der Arbeitslasten zu gewährleisten. Navigieren Sie im Failover-Cluster-Manager zur Ressource der SQL Server-Instanz, klicken Sie mit der rechten Maustaste darauf, wählen Sie „Eigenschaften“ und wechseln Sie zur Registerkarte „Bevorzugte Besitzer“.
Legen Sie für SQLINSTANCE01 Knoten 1 als bevorzugten Besitzer fest; für SQLINSTANCE02 Knoten 2. Konfigurieren Sie zusätzlich Failover-Schwellenwerte (z. B. maximale Failover-Vorgänge pro Stunde) und Failback-Regeln (sofort, verzögert oder kein Failback) wie im Abschnitt „Failover-Mechanismus“ beschrieben.
Nach der Installation beider Instanzen bestätigen Sie, dass jede Instanz auf ihrem bevorzugten Knoten ausgeführt wird und alle Cluster-Ressourcen (Instanz, Speicher, Netzwerk) online sind. Dies können Sie über die Dienste-Konsole auf jedem Knoten und den Failover-Cluster-Manager überprüfen.
Herkömmliche SQL Server-Failover-Cluster sind auf gemeinsamen Speicher angewiesen und unterliegen strengen Einschränkungen bezüglich eines einheitlichen Rechenzentrums. Dadurch sind standort- und cloudübergreifende Aktiv-Aktiv-Architekturen schwer umzusetzen.
Fällt der Speicher aus, bricht der gesamte Cluster zusammen. Gleichzeitig ergibt sich die Einschränkung auf ein einzelnes Rechenzentrum aus strengen Latenzgrenzen für Cluster-Heartbeat und Speicherverbindungen. Standort-, regions- oder cloudübergreifende Bereitstellungen sind dadurch unpraktikabel und anfällig für Split-Brain-Szenarien.
An dieser Stelle empfehlen wir i2Stream – eine moderne, protokollbasierte Datenreplikationslösung mit echten Aktiv-Aktiv-Funktionen. Sie nutzt semantisches CDC (Change Data Capture), um Daten zwischen Knoten zu replizieren. Dadurch werden bidirektionale parallele Lese- und Schreibzugriffe auf mehrere Datenbankinstanzen ermöglicht – vor Ort, in der Cloud oder in hybriden Umgebungen.
Hauptvorteile von i2Stream:
