(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

AlwaysOn-Failoverclusterinstanzen (SQL Server)

Als Teil des SQL Server AlwaysOn-Angebots nutzen AlwaysOn-Failoverclusterinstanzen die Funktionalität Windows Server-Failoverclustering (WSFC), um eine hohe lokale Verfügbarkeit durch Redundanz auf Serverinstanzebene (eine Failoverclusterinstanz (FCI)) 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 AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

In diesem Thema:

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)

    Wichtiger Hinweis 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.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [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

Je nachdem, wann Ihre SQL Server-Instanz zuletzt einen Prüfpunktvorgang ausgeführt hat, kann sich eine beträchtliche Menge an modifizierten 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 kann die FCI die Menge an modifizierten Seiten, die im Puffercache behalten wurde, 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 Indirekte Prüfpunkte.

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 wird die aktive SQL Server-Instanz für die ausführliche Komponentendiagnose durch eine gespeicherte Systemprozedur mithilfe einer dedizierten 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.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

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.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Konzepte und Tasks

Thema

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)

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Beschreibungen der Themen

Thema

Beschreibt die Installation eines neuen SQL Server-FCIs.

Erstellen eines neuen SQL Server-Failoverclusters (Setup)

Beschreibt die Aktualisierung eines SQL Server 2012-Failoverclusters.

Aktualisieren 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 AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft