AlwaysOn-Failoverclusterinstanzen (SQL Server)
Als Teil des SQL Server-Always On-Angebots nutzen Always On-Failoverclusterinstanzen die Funktionalität des Windows Server-Failoverclustering (WSFC), um durch Redundanz auf Serverinstanzebene (eine Failoverclusterinstanz [FCI]) lokale Hochverfügbarkeit zu bieten. Eine FCI ist eine einzelne Instanz von SQL Server . Diese ist auf Windows Server-Failoverclustering-Knoten (WSFC) und möglicherweise auf mehreren Subnetzen installiert. 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 zur Failoverbereitstellung von einem WSFC-Knoten zu einem anderen, wenn der aktuelle Knoten nicht verfügbar ist.
Eine FCI kann AlwaysOn-Verfügbarkeitsgruppen nutzen, um die Remotewiederherstellung im Notfall auf Datenbankebene bereitzustellen. Weitere Informationen finden Sie unter Failoverclustering und Always On-Verfügbarkeitsgruppen (SQL Server).
Hinweis
Ab SQL Server 2014 unterstützt Always On Failoverclusterinstanzen clustered Shared Volumes (CSV) sowohl in Windows Server 2008 R2 als auch in Windows Server 2012. Weitere Informationen zu CSVs finden Sie unter Grundlegendes zu freigegebenen Clustervolumes in einem Failovercluster.
In diesem Thema:
Vorteile einer Failoverclusterinstanz
Wenn bei einem Server Hardware- oder Softwarefehler auftreten, kommt es bei den mit dem Server verbundenen Anwendungen oder Clients zu Ausfallzeiten. Wenn eine SQL Server-Instanz konfiguriert wird, um eine FCI (statt einer eigenständigen Instanz) zu sein, wird die Hochverfügbarkeit dieser SQL Server-Instanz vom Vorhandensein redundanter Knoten in der FCI geschützt. 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 wird der Ressourcengruppenbesitz zu einem anderen WSFC-Knoten verschoben. Dieser Prozess ist für den Client oder die Anwendung transparent, der bzw. die eine Verbindung mit SQL Server herstellt. Dadurch werden die Ausfallzeiten der Anwendung oder des Clients bei einem Fehler minimiert. Die folgende Liste enthält einige wichtige Vorteile, die SQL Server -Failoverclusterinstanzen bieten:
Schutz auf Instanzebene durch Redundanz
Automatisches Failover im Fall eines Fehlers (Hardwarefehler, Betriebssystemfehler, Anwendungs- oder Dienstfehler)
Wichtig
In einer AlwaysOn-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).
Notfallwiederherstellungslösung mit Multisubnetz-FCI oder durch Ausführung einer FCI-gehosteten Datenbank innerhalb einer AlwaysOn-Verfügbarkeitsgruppe. Mit der neuen Unterstützung für mehrere Subnetze in MicrosoftSQL Server 2012 erfordert eine FCI mit mehreren Subnetzen kein virtuelles LAN mehr, was die Verwaltbarkeit und Sicherheit einer FCI mit mehreren Subnetzen erhöht.
Kein erneutes Konfigurieren von Anwendungen und Clients während Failover ausgeführt werden
Flexible Failoverrichtlinie für präzise Triggerereignisse für automatische Failover
Zuverlässige Failover durch regelmäßige und ausführliche Zustandserkennung mithilfe von dedizierten und permanenten Verbindungen
Konfigurierbarkeit und Voraussagbarkeit der Failoverzeit durch indirekte Hintergrundprüfpunkte
Eingeschränkte Ressourcenauslastung während Failover ausgeführt werden
Empfehlungen
Es wird empfohlen, in einer Produktionsumgebung statische IP-Adressen zusammen mit der virtuellen IP-Adresse einer Failoverclusterinstanz zu verwenden. Von der Verwendung von DHCP in einer Produktionsumgebung wird abgeraten. 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 bringt die SQL Server instance 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. Wenn ein Failover auftritt, und zwar unabhängig davon, ob es ein automatisches Failover oder ein geplantes Failover ist, treten folgende Ereignisse ein:
Außer wenn eine Hardware- oder ein Systemfehler auftritt, werden alle modifizierten Seiten im Puffercache auf den Datenträger geschrieben.
Alle jeweiligen SQL Server -Dienste in der Ressourcengruppe werden im aktiven Knoten beendet.
Der Ressourcengruppenbesitz wird auf einen anderen Knoten in der FCI übertragen.
Der neue Ressourcengruppenbesitzer startet seine SQL Server -Dienste.
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 Ihr SQL Server instance zuletzt einen Prüfpunktvorgang ausgeführt hat, kann es im Puffercache eine erhebliche Menge an modifiziert Seiten geben. 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 MicrosoftSQL Server 2012 kann die FCI indirekte Prüfpunkte verwenden, um die Menge modifiziert im Puffercache gespeicherten Seiten zu drosseln. 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 MicrosoftSQL Server 2012 verwendet der WSFC-Dienst eine dedizierte Verbindung, um die aktive SQL Server instance nach detaillierten Komponenten abzufragen, die über eine gespeicherte Systemprozedur Diagnose. 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 Failover Policy for Failover Cluster Instances.
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. Im Falle eines Fehlers (Hardwarefehler, Betriebssystemfehler, Anwendungs- oder Dienstfehler) oder eines geplanten Upgrades wird der Ressourcengruppenbesitz auf 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 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 AlwaysOn-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, 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 werden die Ausfallzeiten 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 Tasks des SQL Server-Failovers
| Konzepte und Tasks | Thema |
|---|---|
| Beschreibt den Fehlererkennungsmechanismus und die flexible Failoverrichtlinie. | Failover Policy for Failover Cluster Instances |
| Beschreibt Konzepte hinsichtlich FCI-Verwaltung und -Wartung. | Verwaltung und Wartung von Failoverclusterinstanzen |
| Beschreibt die Konfiguration und Konzepte von Multisubnetzen. | SQL Server Multisubnetzclustering (;SQL Server); |
Verwandte Themen
| Beschreibungen der Themen | Thema |
|---|---|
| Beschreibt die Installation eines neuen SQL Server -FCIs. | Erstellen eines neuen SQL Server-Failoverclusters (; Setup); |
| Beschreibt das Upgrade auf einen SQL Server 2014-Failovercluster. | Upgraden eines SQL Server-Failoverclusters |
| Beschreibt Konzepte des Windows-Failoverclustering und stellt Links zu Tasks für Windows-Failoverclustering bereit. | Windows Server 2008: Übersicht über Failovercluster Windows Server 2008 R2: Übersicht über Failovercluster |
| 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 Always On-Verfügbarkeitsgruppen (SQL Server) |