AlwaysOn-Failoverclusterinstanzen (SQL Server)

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 hohe Verfü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 Multisubnetzunterstützung in Microsoft SQL Server 2012 ist für ein 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 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

Es wird empfohlen, in einer Produktionsumgebung statische IP-Adressen zusammen mit der virtuellen IP-Adresse einer Failoverclusterinstanz verwenden. 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.

[Nach oben]

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

• Netzwerkname

• IP-Adresse

• Freigegebene Datenträger

• SQL Server-Datenbankmoduldienste

• 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:

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

Zuverlässige Systemüberwachung und flexible Failoverrichtlinie

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 Fehler (Hardwarefehler, Betriebssystemfehler, Anwendungs- oder Dienstfehler) oder einem geplanten Upgrade wird der Ressourcengruppenbesitz zu einem anderen Knoten in der FCI verschoben. Die Anzahl der in der WSFC-Ressourcengruppe unterstützten Knoten hängt von der 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.

Speicherung

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.

[Nach oben]

[Nach oben]

[Nach oben]