Freigeben über

Always-On-Failoverclusterinstanzen (SQL Server)

Gilt für:SQL Server

Always-On-Failoverclusterinstanzen von SQL Server nutzen Windows Server-Failoverclustering (WSFC), um lokale Hochverfügbarkeit bereitzustellen. Eine Failoverclusterinstanz (Failover Cluster Instance, FCI) ist auf Ebene der Serverinstanz redundant. Ein FCI ist eine einzelne Instanz von SQL Server, die über Windows Server-Clusterknoten und möglicherweise über mehrere Subnetze hinweg installiert ist. In einem Netzwerk wird eine FCI als eine Instanz von SQL Server angezeigt, die auf einem einzelnen Computer ausgeführt wird. Die FCI bietet jedoch die Möglichkeit des Failovers von einem WSFC-Knoten zu einem anderen, wenn der aktuelle Knoten nicht verfügbar ist.

Eine FCI kann mithilfe von Always-On-Verfügbarkeitsgruppen eine Remote-Notfallwiederherstellung auf Datenbankebene bereitstellen. Weitere Informationen finden Sie unter Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

SQL Server-Failoverclusterinstanzen unterstützen Direkte Speicherplätze für Clusterspeicherressourcen, die in der Windows Server 2016 Datacenter Edition eingeführt wurden. Weitere Informationen finden Sie unter Direkte Speicherplätze in Windows Server.

Failoverclusterinstanzen unterstützen auch freigegebene Clustervolumes (CSV). Weitere Informationen finden Sie unter Grundlegendes zu freigegebenen Clustervolumes in einem Failovercluster.

Hinweis

SQL Server 2025 (17.x) bietet Unterstützung, um strenge Verbindungen mit Ihrer Failoverclusterinstanz zu erzwingen .

Vorteile von Failoverclusterinstanzen

Wenn Serverhardware- oder Softwarefehler auftreten, treten die Anwendungen oder Clients auf, die eine Verbindung mit der Serverumgebung herstellen. Redundante Knoten schützen die Verfügbarkeit der SQL Server-Instanz, wenn es sich um eine FCI anstelle einer eigenständigen Instanz handelt. Nur jeweils einer der Knoten in der FCI kann die WSFC-Ressourcengruppe besitzen. Wenn ein Fehler auftritt (z. B. Hardwarefehler, Betriebssystemfehler, Anwendung oder Dienstfehler) oder während eines geplanten Upgrades verschiebt der Cluster den Besitz der Ressourcengruppe auf einen anderen WSFC-Knoten. Dieser Prozess ist für Clients oder Anwendungen, die eine Verbindung mit SQL Server herstellen, transparent. Der Prozess minimiert die Ausfallzeiten, die die Anwendung oder clients während eines Fehlers erleben. Im Folgenden finden Sie einige wichtige Vorteile, die SQL Server-Failoverclusterinstanzen bereitstellen:

  • Schutz auf Instanzebene durch Redundanz.

  • Automatisches Failover im Falle eines Fehlers (Hardwarefehler, Betriebssystemfehler oder Anwendungs- und Dienstfehler).

    Wichtig

    In einer Verfügbarkeitsgruppe wird das automatische Failover von einer FCI auf andere Knoten innerhalb der Verfügbarkeitsgruppe nicht unterstützt. Daher sollten FCIs und eigenständige Knoten nicht innerhalb einer Verfügbarkeitsgruppe gekoppelt werden, wenn automatisches Failover eine wichtige Komponente Ihrer Hochverfügbarkeitslösung ist. Diese Kopplung kann jedoch für Ihre Notfallwiederherstellungslösung vorgenommen werden.

  • Unterstützung für eine breite Palette von Speicherlösungen, einschließlich WSFC-Clusterdatenträgern (iSCSI, Fiber Channel usw.) und SMB-Dateifreigaben (Server Message Block).

  • Notfallwiederherstellung über einen Multisubnetz-FCI oder Ausführen einer in einer Verfügbarkeitsgruppe gehosteten FCI-Datenbank. Mit der Multi-Subnet-Unterstützung in SQL Server 2012 (11.x) erfordert ein Multi-Subnetz-FCI kein virtuelles LAN. Diese Unterstützung erhöht die Verwaltbarkeit und Sicherheit eines Multi-Subnetz-FCI.

  • Kein erneutes Konfigurieren von Anwendungen und Clients bei Failovern.

  • Flexible Failoverrichtlinie für granulare Auslöser für automatische Failover.

  • Zuverlässige Failover durch regelmäßige und ausführliche Zustandserkennung mithilfe dedizierter und permanenter Verbindungen.

  • Konfigurierbarkeit und Voraussagbarkeit der Failoverzeit durch indirekte Hintergrundprüfpunkte.

  • Gedrosselter Ressourceneinsatz bei Failovern.

Empfehlungen

Verwenden Sie in einer Produktionsumgebung statische IP-Adressen in Verbindung mit der virtuellen IP-Adresse einer Failoverclusterinstanz.

Nutzen Sie DHCP nicht in einer Produktionsumgebung. Wenn die DHCP-IP-Lease abläuft, ist bei Ausfallzeiten zusätzliche Zeit erforderlich, um die neue DHCP-IP-Adresse erneut zu registrieren, die dem DNS-Namen zugeordnet ist.

Übersicht über Failoverclusterinstanzen

Eine FCI wird in einer WSFC-Ressourcengruppe mit einem oder mehreren WSFC-Knoten ausgeführt. Wenn die FCI gestartet wird, übernimmt einer der Knoten den Besitz der Ressourcengruppe und schaltet seine SQL Server-Instanz online. Zu den Ressourcen, die dieser Knoten besitzt, gehören:

  • Netzwerkname
  • IP-Adresse
  • Freigegebene Datenträger
  • SQL Server -Datenbank-Engine-Dienste
  • SQL Server -Agent-Dienst
  • SQL Server Analysis Services-Dienst, wenn er installiert ist
  • Eine Dateifreigaberessource, wenn die FILESTREAM-Funktion installiert ist

Nur der Ressourcengruppenbesitzer (und kein anderer Knoten in der FCI) kann jederzeit die jeweiligen SQL Server -Dienste in der Ressourcengruppe ausführen. Wenn ein Failover auftritt, unabhängig davon, ob es sich um ein automatisches Failover oder ein geplantes Failover handelt, geschieht die folgende Ereignissequenz:

  1. Außer wenn eine Hardware- oder ein Systemfehler auftritt, werden alle modifizierten Seiten im Puffercache auf den Datenträger geschrieben.

  2. Alle jeweiligen SQL Server -Dienste in der Ressourcengruppe werden im aktiven Knoten beendet.

  3. Der Ressourcengruppenbesitz wird auf einen anderen Knoten in der FCI übertragen.

  4. Der neue Ressourcengruppenbesitzer startet seine SQL Server -Dienste.

  5. Clientanwendungsverbindungsanforderungen werden automatisch mit demselben virtuellen Netzwerknamen an den neuen aktiven Knoten weitergeleitet.

Der FCI ist online, solange sein zugrunde liegender WSFC-Cluster in guter Quorumintegrität liegt. (Die meisten Quorum-WSFC-Knoten sind als automatische Failoverziele verfügbar.) Wenn der WSFC-Cluster sein Quorum verliert, sei es aufgrund von Hardware-, Software- oder Netzwerkfehlern oder einer fehlerhaften Quorumkonfiguration, wird der gesamte WSFC-Cluster zusammen mit dem FCI offline gebracht. Ein manueller Eingriff ist dann in diesem ungeplanten Failoverszenario erforderlich, um in den verbleibenden verfügbaren Knoten das Quorum wiederherzustellen, damit der WSFC-Cluster und die FCI wieder in den Onlinemodus versetzt werden können. Weitere Informationen finden Sie unter WSFC-Quorummodi und Abstimmungskonfiguration (SQL Server).

Vorhersagbare Failoverzeit

Je nachdem, wann Ihre SQL Server-Instanz zuletzt einen Prüfpunktvorgang ausgeführt hat, kann sich eine erhebliche Anzahl modifizierter Seiten im Puffercache befinden. Folglich dauern Failover so lange, wie das Schreiben der verbleibenden modifizierte Seiten auf den Datenträger dauert. Dadurch kann es zu einer langen und nicht vorhersagbaren Failoverzeit kommen. Ab SQL Server 2012 (11.x) kann der FCI indirekte Prüfpunkte verwenden, um die Anzahl der im Puffercache gespeicherten schmutzigen Seiten zu drosseln. Dies verbraucht zwar mehr Ressourcen unter normalen Workloads, macht die Failoverzeit jedoch vorhersehbarer und konfigurierbarer. Dies ist nützlich, wenn die Vereinbarung auf Serviceebene in Ihrer Organisation das Wiederherstellungszeitziel (RTO) für Ihre Hochverfügbarkeitslösung angibt. Weitere Informationen finden Sie unter indirekten Prüfpunkten.

Zuverlässige Systemüberwachung und flexible Failoverrichtlinie

Nachdem der FCI erfolgreich gestartet wurde, überwacht der WSFC-Dienst sowohl den Status des zugrunde liegenden WSFC-Clusters als auch die Integrität der SQL Server-Instanz. Ab SQL Server 2012 (11.x) verwendet der WSFC-Dienst eine dedizierte Verbindung, um die aktive SQL Server-Instanz für detaillierte Komponentendiagnosen über eine gespeicherte Systemprozedur abzufragen. Es gibt drei sich ergebende Auswirkungen:

  • Die dedizierte Verbindung zur SQL Server -Instanz macht es möglich, jederzeit die Komponentendiagnose zuverlässig abzurufen, und zwar sogar bei starker Auslastung der FCI. Diese Funktion ermöglicht es, zwischen einem System zu unterscheiden, das stark geladen ist, und einem System, das Fehlerbedingungen aufweist, wodurch Probleme wie falsche Failovers verhindert werden.

  • Mit der detaillierten Komponentendiagnose können Sie eine flexiblere Failoverrichtlinie konfigurieren, wobei Sie auswählen können, welche Fehlerbedingungen Failover auslösen.

  • Mit der ausführlichen Komponentendiagnose wird auch rückwirkend eine bessere Problembehandlung automatischer Failover ermöglicht. Die Diagnoseinformationen werden in Protokolldateien gespeichert, die den SQL Server -Fehlerprotokollen zugeordnet werden. Sie können sie in den Protokolldatei-Viewer laden, um die Komponentenzustände zu prüfen, die bis zum Failover vorkommen, um zu bestimmen, was das Failover verursacht hat.

Weitere Informationen finden Sie unter Failoverrichtlinie für Failoverclusterinstanzen.

Konfigurieren der TLS 1.3-Verschlüsselung

SQL Server 2025 (17.x) führt die TDS 8.0-Unterstützung ein, die das Erzwingen der TLS 1.3-Verschlüsselung für die Kommunikation zwischen dem Windows Server-Failovercluster und Ihren Failoverclusterinstanzen ermöglicht.

Überprüfen Sie zunächst die Verbindung mit strenger Verschlüsselung.

Hinweis

Sql Server 2025 (17.x) Failoverclusterinstanzinstallation schlägt fehl, wenn TLS 1.2 auf dem Computer deaktiviert ist.

Elemente einer Failoverclusterinstanz

Eine FCI besteht aus einer Reihe physischer Server (Knoten), die ähnliche Hardwarekonfiguration und auch identische Softwarekonfiguration enthalten, die Betriebssystemversion und Patchebene sowie SQL Server-Version, Patchebene, Komponenten und Instanzname enthält. Identische Softwarekonfiguration ist erforderlich, um sicherzustellen, dass der FCI voll funktionsfähig sein kann, wenn er zwischen den Knoten fehlschlägt.

WSFC-Ressourcengruppe

Eine SQL Server -FCI wird in einer WSFC-Ressourcengruppe ausgeführt. Jeder Knoten in der Ressourcengruppe verwaltet eine synchronisierte Kopie der Konfigurationseinstellungen und check-point-Registrierungsschlüssel, um die vollständige Funktionalität der FCI nach einem Failover sicherzustellen. Nur einer der Knoten im Cluster besitzt die Ressourcengruppe gleichzeitig (der aktive Knoten). Der WSFC-Dienst verwaltet den Servercluster, die Quorumkonfiguration, die Failoverrichtlinie und Failovervorgänge zusätzlich zum Namen des virtuellen Netzwerks und der virtuellen IP-Adressen für die FCI. Wenn ein Fehler (Hardwarefehler, Betriebssystemfehler oder Anwendungs- und Dienstfehler) oder ein geplantes Upgrade vorhanden ist, wird der Besitz der Ressourcengruppe in einen anderen Knoten in der FCI verschoben. Die Anzahl der Knoten, die in einer WSFC-Ressourcengruppe unterstützt werden, hängt von Ihrer SQL Server-Edition ab. Der gleiche WSFC-Cluster kann abhängig von der Hardwarekapazität, z. B. CPUs, Arbeitsspeicher und Anzahl von Datenträgern, zudem mehrere FCIs (mehrere Ressourcengruppen) ausführen.

SQL Server-Binärdateien

Die Produktbinärdateien werden lokal auf jedem Knoten des FCI in einem Prozess installiert, der sql Server-eigenständigen Installationen ähnelt. Während des Starts werden die Dienste jedoch nicht automatisch gestartet, sondern von WSFC verwaltet.

Storage

Im Gegensatz zu einer Verfügbarkeitsgruppe muss ein FCI gemeinsam genutzten Speicher für alle Knoten des FCI für Datenbank- und Protokollspeicher verwenden. Der freigegebene Speicher kann sich in Form von WSFC-Clusterdatenträgern, Datenträgern auf einem SAN, Direkte Speicherplätze oder Dateifreigaben auf einem SMB befinden. Daher verfügen alle Knoten in der FCI immer dann über dieselbe Ansicht von Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, den einzelnen Fehlerpunkt zu sein, und dass FCI von der zugrunde liegenden Speicherlösung abhängt, um den Datenschutz zu gewährleisten.

Netzwerkname

Der Name des virtuellen Netzwerks für den FCI stellt einen einheitlichen Verbindungspunkt für die FCI bereit. Mit diesem einheitlichen Verbindungspunkt können Anwendungen eine Verbindung mit dem Namen des virtuellen Netzwerks herstellen, ohne den aktuell aktiven Knoten kennen zu müssen. Wenn ein Failover auftritt, wird der Name des virtuellen Netzwerks nach dem Start im neuen aktiven Knoten registriert. Dieser Prozess ist transparent für den Client oder die Anwendung, der eine Verbindung mit SQL Server herstellt, und minimiert die Ausfallzeiten, die die Anwendung oder clients während eines Fehlers auftreten.

Der folgende Screenshot zeigt den Netzwerknamen für die Failoverclusterinstanz im Failovercluster-Manager:

Screenshot des FCI-Netzwerknamens im Failovercluster-Manager.

Virtuelle IP-Adressen

Im Fall einer Multisubnetz-FCI wird jedem Subnetz eine virtuelle IP-Adresse in der FCI zugewiesen. Während eines Failovers wird der Name des virtuellen Netzwerks auf dem DNS-Server aktualisiert, um auf die virtuelle IP-Adresse für das jeweilige Subnetz zu verweisen. Anwendungen und Clients können dann eine Verbindung mit dem FCI herstellen, indem sie denselben virtuellen Netzwerknamen nach einem Multisubnetzfailover verwenden.

Konzepte und Aufgaben des SQL Server-Failovers

Konzepte und Aufgaben Artikel
Beschreibt den Fehlererkennungsmechanismus und die flexible Failoverrichtlinie. Failoverrichtlinie für Failoverclusterinstanzen
Beschreibt Konzepte hinsichtlich FCI-Verwaltung und -Wartung. Verwaltung und Wartung von Failoverclusterinstanzen
Beschreibt die Konfiguration und Konzepte für mehrere Subnetze. SQL Server-Multi-Subnetzclustering

SQL Server FCI-unterstützte Konfiguration in WSFC

SQL Server FCIs, die auf WSFC basieren, werden in den folgenden Produkten unterstützt:

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016 Standard- und Datacenter-Editionen
  • Windows Server 2019 Standard- und Datacenter-Editionen
  • Windows Server 2022 Standard- und Datacenter-Editionen

Windows Server bietet zwei Arten von Clusteringdiensten:

Nur die Serverclusterlösungen können zusammen mit SQL Server für hohe Verfügbarkeit verwendet werden, wenn ein Knoten verloren geht oder wenn ein Problem mit einer Instanz von SQL Server besteht. Netzwerklastenausgleich kann in einigen Fällen zusammen mit eigenständigen schreibgeschützten SQL Server-Installationen verwendet werden.

Jeder SQL Server-FCI erfordert Folgendes:

  • Eine dedizierte Clustergruppe mit eindeutig zugewiesenen Laufwerkbuchstaben.
  • Mindestens eine eindeutige IP-Adresse.
  • Eindeutige virtuelle Server- und Instanznamen innerhalb der Domäne.

Unterstützung von Nicht-Microsoft-Clusterlösungen

SQL Server wird mit Microsoft Server Clustering entwickelt und getestet. Wenn Sie ein Nicht-Microsoft-Clustering-Produkt verwenden, sollte Ihr primärer Supportkontakt für Installations-, Leistungs- oder Clusterverhaltensprobleme der Lösungsanbieter sein. Microsoft bietet kommerziellen angemessenen Support für Nicht-Microsoft-Clusterinstallationen, ähnlich der Unterstützung für eigenständige SQL Server-Bereitstellungen.

Anzahl der unterstützten Knoten

Ausführliche Informationen zur maximalen Anzahl der unterstützten Knoten für Always On-Failoverclusterinstanzen finden Sie unter:

Unterstütztes Betriebssystem

Informationen zu unterstützten Betriebssystemen für SQL Server-Failoverclustering finden Sie unter Überprüfen des Betriebssystems vor der Installation des Failoverclusterings.

Bereitgestellte Laufwerke

Die Verwendung von bereitgestellten Laufwerken wird für Cluster, die eine SQL Server-Installation enthalten, nicht unterstützt. Weitere Informationen finden Sie unter SQL Server-Unterstützung für bereitgestellte Volumes.

Freigegebene Clustervolumes (CSV)

SQL Server 2012 (11.x) und frühere Versionen unterstützen die Verwendung von CSV für SQL Server in einem Failovercluster nicht.

Informationen zur Verwendung von CSV mit SQL Server 2014 (12.x) oder neueren Versionen finden Sie in den folgenden Ressourcen:

Domänencontrollereinschränkungen

SQL Server-Failoverclusterinstanzen werden für Failoverclusterinstanzknoten, die als Domänencontroller konfiguriert sind, nicht unterstützt.

Überlegungen zur Domänenmigration

SQL Server 2005 (9.x) und höhere Versionen können nicht zu einer neuen Domäne migriert werden. Sie müssen die Failoverclusterkomponenten deinstallieren und erneut installieren. Weitere Informationen finden Sie unter Verschieben eines Windows Server-Clusters von einer Domäne in eine andere.

Bevor Sie SQL Server deinstallieren, sollten Sie die folgenden Schritte ausführen:

  • Legen Sie SQL Server so fest, dass die Sicherheit im gemischten Modus verwendet wird, oder fügen Sie den SQL Server-Anmeldeinformationen neue Domänenkonten hinzu.

  • Benennen Sie den Ordner um, der DATA Systemdatenbanken enthält, damit er nach der erneuten Installation wieder eingetauscht werden kann, um Ausfallzeiten zu reduzieren.

  • Entfernen Sie keine SQL Server-Supportdateien, SQL Server Native Client, Integration Services oder Arbeitsstationskomponenten, es sei denn, Sie erstellen den gesamten Knoten neu.

Warnung

Wenn während des Deinstallationsprozesses Fehler auftreten, müssen Sie den Knoten möglicherweise neu erstellen, um SQL Server erneut zu installieren.

Verwandte Inhalte

  • Last updated on