Freigeben über

Always-On-Failoverclusterinstanzen (SQL Server)

  • Artikel

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. Eine FCI ist eine einzelne Instanz von SQL Server, die auf mehreren Windows Server-Clusterknoten und möglicherweise in mehreren Subnetzen 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 Verfügbarkeitsgruppen (SQL Server).

Hinweis

Windows Server 2016 Datacenter Edition führt die Unterstützung für direkte Speicherplätze (Storage Spaces Direct, S2D) ein. Failoverclusterinstanzen von SQL Server unterstützen S2D für Clusterspeicherressourcen. Weitere Informationen finden Sie unter Direkte Speicherplätze in Windows Server.

Failoverclusterinstanzen unterstützen außerdem freigegebene Clustervolumes (Clustered Shared Volumes, CSVs). Weitere Informationen finden Sie unter Grundlegendes zu freigegebenen Clustervolumes in einem Failovercluster.

Vorteile einer Failoverclusterinstanz

Wenn bei einem Server Hardware- oder Softwarefehler auftreten, kommt es bei den mit dem Server verbundenen Anwendungen oder Clients zu Ausfallzeiten. Redundante Knoten schützen die Verfügbarkeit der SQL Server-Instanz, wenn es sich um eine FCI statt einer eigenständigen Instanz handelt. Nur jeweils einer der Knoten in der FCI kann die WSFC-Ressourcengruppe besitzen. Bei einem Fehler (Hardwarefehler, Betriebssystemfehler, Anwendungs- oder Dienstfehler) oder einem geplanten Upgrade überträgt 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. Das minimiert die Ausfallzeiten der Anwendungen oder Clients bei einem Fehler. Die folgende Liste enthält einige wichtige Vorteile, die SQL Server -Failoverclusterinstanzen bieten:

  • Schutz auf Instanzebene durch Redundanz.

  • Automatisches Failover bei einem Fehler (Hardwarefehler, Betriebssystemfehler, Anwendungs- oder Dienstfehler).

    Wichtig

    In einer Verfügbarkeitsgruppe wird ein automatisches Failover von einer FCI zu anderen Knoten innerhalb der Verfügbarkeitsgruppe nicht unterstützt. Dies bedeutet, dass FCIs und eigenständige Knoten nicht miteinander innerhalb einer Verfügbarkeitsgruppe verbunden werden sollten, wenn ein automatisches Failover eine wichtige Komponente Ihrer Hochverfügbarkeitslösung darstellt. Diese Kopplung kann jedoch für Ihre Notfallwiederherstellungslösung vorgenommen werden.

  • Unterstützung für ein umfangreiches Array von Speicherlösungen, einschließlich WSFC-Clusterdatenträger (iSCSI, Fiber-Channel usw.) und SMB-Dateifreigaben (Server Message Block).

  • Notfallwiederherstellung mit einem Multisubnetz-FCI oder durch Ausführung einer FCI-gehosteten Datenbank in einer Verfügbarkeitsgruppe. Mit der neuen Multisubnetzunterstützung in Microsoft SQL Server 2012 (11.x) ist für eine Multisubnetz-FCI nicht länger eine VLAN-Verbindung erforderlich, wodurch die Verwaltbarkeit und die Sicherheit der Multisubnetz-FCI verbessert werden.

  • 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

In einer Produktionsumgebung:

  • Verwenden Sie statische IP-Adressen in Verbindung mit der virtuellen IP-Adresse einer Failoverclusterinstanz.
  • Nutzen Sie DHCP nicht in einer Produktionsumgebung. Wenn es zu einer Ausfallzeit kommt und das DHCP-IP-Leasing abläuft, ist für die erneute Registrierung der dem DNS-Namen zugeordneten neuen DHCP-IP-Adresse zusätzlich Zeit erforderlich.

Failoverclusterinstanz – Übersicht

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, sofern installiert

  • 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. Bei einem Failover – unabhängig davon, ob es sich um ein automatisches oder geplantes Failover handelt – kommt es zu folgendem Ablauf:

  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. Verbindungsanforderungen für Clientanwendungen werden automatisch an den neuen aktiven Knoten mit dem gleichen virtuellen Netzwerknamen (VNN) übertragen

Die FCI ist online, solange sein zugrunde liegender WSFC-Cluster in gutem Quorumzustand (die Mehrheit der Quorum-WSFC-Knoten ist als automatische Failoverziele verfügbar) ist. Wenn der WSFC-Cluster sein Quorum verliert, und zwar unabhängig davon, ob durch einen Hardware-, Software-, Netzwerkfehler oder durch eine nicht ordnungsgemäße Quorumkonfiguration, wird der gesamte WSFC-Cluster zusammen mit der FCI in den Offlinemodus versetzt. 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 Microsoft SQL Server 2012 (11.x) kann die FCI die im Puffercache beibehaltene Anzahl modifizierter Seiten mithilfe von indirekten Prüfpunkten einschränken. Obwohl dadurch zusätzliche Ressource unter normaler Arbeitsauslastung belegt werden, wird die Failoverzeit vorhersagbarer und besser konfigurierbar. Dies ist sehr nützlich, wenn in der Vereinbarung zum Servicelevel in Ihrer Organisation die Wiederherstellungszeit-Zielsetzung (Recovery Time Objective, RTO) für Ihre Hochverfügbarkeitslösung angegeben wird. Weitere Informationen zu indirekten Prüfpunkten finden Sie unter Indirect Checkpoints.

Zuverlässige Systemüberwachung und flexible Failoverrichtlinie

Nachdem die FCI erfolgreich gestartet wurde, überwacht der WSFC-Dienst sowohl den Zustand des zugrunde liegenden WSFC-Clusters als auch den Zustand der SQL Server -Instanz. Ab Microsoft SQL Server 2012 (11.x) wird die aktive SQL Server-Instanz für die ausführliche Komponentendiagnose durch eine gespeicherte Systemprozedur über eine dedizierte Verbindung vom WSFC-Dienst abgerufen. Die Implikation hiervon erfolgt dreifach:

  • 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. Dadurch wird es möglich, zwischen einem stark ausgelasteten System und einem System, das tatsächlich einen fehlerhaften Zustand aufweist, zu unterscheiden. Dadurch lassen sich Probleme wie falsche Failover verhindern.

  • Die ausführliche Komponentendiagnose macht es möglich, eine flexiblere Failoverrichtlinie zu konfigurieren, wodurch Sie auswählen können, welche Fehlerbedingungen Failover auslösen bzw. welche sie nicht 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 mit dem Protokolldatei-Viewer laden, um die Komponentenstatus zu überprüfen, die zu einem Failover führen, damit Sie bestimmen können, wodurch das Failover verursacht wurde.

Weitere Informationen finden Sie unter Failoverrichtlinie für Failoverclusterinstanzen.

Elemente einer Failoverclusterinstanz

Eine FCI besteht aus einem Satz physischer Server (Knoten), die über eine ähnliche Hardwarekonfiguration sowie über eine identische Softwarekonfiguration verfügen, einschließlich Betriebssystemversion und Patchebene sowie SQL Server -Version, -Patchebene, -Komponenten und -Instanzname. Identische Softwarekonfiguration ist notwendig, um sicherzustellen, dass die FCI vollständig funktional sein kann, da es zwischen den Knoten Failover ausführt.

WSFC-Ressourcengruppe
Eine SQL Server -FCI wird in einer WSFC-Ressourcengruppe ausgeführt. Jeder Knoten in der Ressourcengruppe behält eine synchronisierte Kopie der Konfigurationseinstellungen und Prüfpunkt-Registrierungsschlüssel bei, um die vollständige Funktionalität der FCI nach einem Failover sicherzustellen. Zudem besitzt nur einer der Knoten im Cluster die Ressourcengruppe zu einer bestimmten Zeit (der aktive Knoten). Der WSFC-Dienst verwaltet den Servercluster, Quorumkonfiguration, Failoverrichtlinie und Failovervorgänge sowie die VNN und virtuelle IP-Adressen für die FCI. Bei einem Ausfall (von Hardware, Betriebssystem, Anwendun oder Dienst) oder einem geplanten Upgrade wird der Ressourcengruppenbesitz zu einem 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 der FCI installiert. Dieser Prozess ähnelt eigenständigen Installationen von SQL Server . Während des Starts werden die Dienste jedoch nicht automatisch gestartet, sondern durch den WSFC verwaltet.

Storage
Im Gegensatz zur Verfügbarkeitsgruppe muss eine FCI freigegebenen Speicher zwischen allen Knoten der FCI für Datenbank und Protokolle verwenden. Der freigegebene Speicher kann die Form von WSFC-Clusterdatenträgern, direkten Speicherplätzen (Storage Spaces Direct, S2D), Datenträgern auf einem SAN oder Dateifreigaben auf einem SMB aufweisen. Auf diese Weise verfügen alle Knoten in der FCI immer dann über die gleiche Sicht der Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, die einzelne Fehlerquelle zu sein. Die FCI hängt zudem von der zugrunde liegenden Speicherlösung ab, um Datenschutz sicherzustellen.

Netzwerkname
Der VNN für die FCI stellt einen einheitlichen Verbindungspunkt für die FCI bereit. Dadurch können Anwendungen eine Verbindung zum VNN herstellen, ohne dass sie den derzeit aktiven Knoten kennen müssen. Wenn ein Failover auftritt, wird der VNN für den neuen aktiven Knoten registriert, nachdem dieser gestartet wurde. Dieser Prozess ist für den Client oder die Anwendung transparent, der bzw. die eine Verbindung mit SQL Server herstellt. Dadurch wird die Downtime der Anwendung oder des Clients bei einem Fehler minimiert.

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 VNN 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 der FCI herstellen, die den gleichen VNN nach einem Multisubnetzfailover verwendet.

Konzepte und Aufgaben des SQL Server-Failovers

Konzepte und Tasks 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 von Multisubnetzen. SQL Server-Multisubnetzclustering (SQL Server)

Zugehörige Themen

Beschreibungen der Themen Artikel
Beschreibt die Installation eines neuen SQL Server -FCIs. Erstellen eines neuen SQL Server-Failoverclusters (Setup)
Beschreibt die Aktualisierung eines SQL Server -Failoverclusters. Upgraden einer Failoverclusterinstanz von SQL Server
Beschreibt Konzepte des Windows-Failoverclustering und stellt Links zu Aufgaben für das Windows-Failoverclustering bereit. Windows Server-Failovercluster mit SQL Server
Beschreibt die Unterschiede der Konzepte zwischen Knoten in einer FCI und Replikaten innerhalb einer Verfügbarkeitsgruppe. Zudem werden Überlegungen zum Hosten mithilfe einer FCI für eine Verfügbarkeitsgruppe eines Replikats dargelegt. Failoverclustering und Verfügbarkeitsgruppen (SQL Server)
Beschreibt SQL Server mit Azure Arc-Unterstützung. SQL Server mit Azure Arc-Unterstützung
Beschreibt, wie Sie mit einer Failover-Clusterressource in Azure interagieren können. Anzeigen von Always On-Failoverclusterinstanzen in Azure Arc