Führende Hosts und Clusterverwaltung (AppFabric 1.1-Cache)

Ein Microsoft AppFabric 1.1 für Windows Server-Cachecluster ist eine dynamische Gruppe von Servern, die zusammenarbeiten, um einen vereinheitlichten logischen Cache für die Daten Ihrer Anwendung bereitzustellen. Damit dies geschieht, ist Mehraufwand erforderlich, um die Clustervorgänge zwischen den Cachehosts zu orchestrieren. Die Clusterverwaltungsrolle ist für die Verwaltung der Cachehosts und letztlich auch des Cacheclusters verantwortlich.

Es bestehen zwei Hauptoptionen zum Ausführen der Cachecluster-Verwaltungsrolle. Die erste Option besteht darin, dass diese Rolle durch besondere Cachehosts ausgeführt wird, die als führende Hosts bezeichnet werden. Dies wird auch als "Aufladung" bezeichnet. Die zweite Option besteht darin, dass diese Rolle durch SQL Server ausgeführt wird. Dies wird auch als "Abladung" bezeichnet, weil die Verantwortung an SQL Server und nicht an den Cachecluster selbst abgeladen wird.

Wenn Sie Ihre Cachecluster-Konfigurationsdaten in einem freigegebenen Netzwerkordner (XML) speichern, müssen Sie Aufladung mit Verwaltung des führenden Hosts verwenden. Beachten Sie, dass führende Hosts die gleichen Cacheaufgaben wie andere Cachehosts ausführen, die nicht als führende Hosts reserviert sind. Sie sind jedoch zusätzlich dafür verantwortlich, mit den anderen führenden Hosts zusammenzuarbeiten, um die Clusterverwaltungsrolle auszuführen.

In Windows Server AppFabric 1.0 bestand das Standardverhalten für einen Cachecluster, der seine Konfigurationsdaten in SQL Server speicherte, im Abladen der Cachecluster-Verwaltungsrolle an SQL Server. Dies hat sich AppFabric 1.1 geändert. Das Standardverhalten für neue Cachecluster besteht darin, immer Aufladung zu verwenden, wenn führende Hosts vorhanden sind, um den Cachecluster zu verwalten. Auf diese Weise wird die Verfügbarkeit des Cacheclusters verbessert, weil der Cachecluster teilweise funktionstüchtig bleibt, wenn der Konfigurationsspeicher nicht mehr verfügbar ist (unabhängig davon, ob es sich um eine XML-Datei oder eine SQL Server-Datenbank handelt. Beachten Sie, dass Vorgänge, die die Konfiguration des Cacheclusters untersuchen oder ändern, unter diesen Umständen nicht verfügbar sind.

Es ist auch weiterhin möglich, eine Abladung aller Cachecluster-Verwaltungsaufgaben an SQL Server auszuführen. Zuerst müssen Sie den Cachecluster mit dem Befehl New-CacheCluster manuell erstellen und den Parameter Offloading auf Wahr festlegen. Die andere Anforderung besteht darin, dass der Provider SQL Server (System.Data.SqlClient) sein muss.

Die folgende Tabelle zeigt die Beziehung zwischen Ihrer Auswahl zum Installationszeitpunkt und den Optionen für die Clusterverwaltung. Weitere Informationen zur Auswahl der für Ihre Situation geeigneten Konfigurationsoptionen finden Sie unter Speicheroptionen für die Clusterkonfiguration.

Aufgaben der Clusterverwaltungsrolle

Zwei Konfigurationshaupteinstellungen bestimmen, wie der Cluster hinsichtlich der Clusterverwaltung funktioniert:

• leadHostManagement: Diese Einstellung auf Clusterebene legt fest, von wem die Clusterverwaltungsrolle ausgeführt wird. Wenn der Wert True ist, üben führende Hosts die Clusterverwaltungsrolle aus. Wenn Sie Ihre Clusterkonfigurationseinstellungen in einem freigegebenen Netzwerkordner gespeichert haben, ist True der einzig gültige Wert für diese Einstellung. Der Wert False gibt an, dass SQL Server oder ein benutzerdefinierter Anbieter die Clusterverwaltungsrolle ausführt. Wenn SQL Server oder ein benutzerdefinierter Anbieter zum Speichern der Clusterkonfigurationseinstellungen verwendet wird, können Sie diese Einstellung auf True festlegen und führende Hosts die Clusterverwaltungsrolle ausführen lassen.

• leadHost: Diese Einstellung auf Cachehostebene legt fest, welche Cachehosts führende Hosts sind, wenn führende Hosts die Clusterverwaltungsrolle ausführen. Selbst wenn SQL Server die Clusterverwaltungsrolle ausführt, legt das Installationsprogramm führende Hosts für den Fall fest, dass Sie die Einstellung leadHostManagement zu einem späteren Zeitpunkt ändern.

Weitere Informationen zum Ändern dieser Einstellungen finden Sie unter Festlegen von Clusterverwaltungsrolle und führenden Hosts (AppFabric 1.1)..

Führende Hosts führen die Clusterverwaltungsrolle aus

Wenn die Einstellungen leadHostManagement und leadHost den Wert true besitzen, wird der Cachehost heraufgestuft, übernimmt größere Verantwortung im Cluster und wird als führender Host festgelegt. Der führende Host arbeitet zusätzlich zu den Zwischenspeicherungsaufgaben von Daten normaler Hosts mit anderen führenden Hosts zusammen, um die Clustervorgänge zu verwalten.

Fehler eines führenden Hosts

Damit der Cachecluster verfügbar bleibt, muss die Mehrheit der führenden Hosts verfügbar bleiben. Dies stellt in kleinen Clustern ein höheres Risiko als in großen Clustern dar, weil weniger Serverfehler erforderlich sind, um den Cluster herunterzufahren.

Die folgende Abbildung zeigt einen aus sechs Servern bestehenden Cachecluster. In diesem Beispiel üben führende Hosts die Clusterverwaltungsrolle aus, und zwei Cachehosts wurden als führende Hosts festgelegt.

Wenn einer der normalen Cachehosts im Cluster ausfällt, wird der Cluster weiterhin ausgeführt. Die Daten der nicht führenden Hosts gehen in diesem Fall verloren (wenn hohe Verfügbarkeit nicht aktiviert wurde), der restliche Cluster setzt die Ausführung jedoch fort und speichert Daten. Der Cluster würde sogar dann noch funktionieren, wenn alle vier Cachehosts ausfallen, die keine führenden Hosts sind.

Wenn nur einer der führenden Hosts ausfällt, wird der gesamte Cachecluster heruntergefahren, weil keine Mehrheit von führenden Hosts mehr ausgeführt wird. Wenn Sie dieses Risiko verringern möchten, besteht die Option, weitere führende Hosts festzulegen.

Festlegen zusätzlicher führender Hosts

Sie können nach der Installation weitere führende Hosts definieren. Bedenken Sie jedoch unbedingt, dass die Zuweisung einer zu großen Anzahl führender Hosts ebenfalls ein Problem darstellen kann:

• Es muss immer eine Mehrheit führender Hosts verfügbar sein, damit der Cachecluster weiterhin ausgeführt wird. Je mehr Hosts als führende Hosts festgelegt werden, desto weniger Serverfehler kann der Cluster ausgleichen, um betriebsfähig zu bleiben.

• In kleinen Clustern, in denen ein oder zwei Ausfälle führender Hosts zu einem Clusterausfall führen, wird empfohlen, weitere führende Hosts festzulegen.

• In großen Clustern sollten fünf bis sieben führende Hosts ausreichen, um sicherzustellen, dass ein Cluster mit 50 Cacheservern funktionsfähig bleibt.

Weitere Informationen zum Ändern der Zuweisungen für führende Hosts finden Sie unter Festlegen von Clusterverwaltungsrolle und führenden Hosts (AppFabric 1.1)..

Änderungen in Microsoft AppFabric 1.1 für Windows Server

Damit die Verfügbarkeit des Cacheclusters verbessert wird, wurde in AppFabric 1.1 der Vorgang geändert, der zum Zuweisen von führenden Standardhosts verwendet wird. AppFabric 1.1 legt automatisch jeden Cachehost, der dem Cachecluster hinzugefügt wird, als führenden Host mit maximal sieben führenden Hosts fest. Sie sind auch weiterhin in der Lage, weitere führende Hosts zuzuweisen. Verwenden Sie zu diesem Zweck den Befehl Set-CacheHostConfig mit dem Parameter IsLeadHost, der auf Wahr festgelegt ist. Es ist auch möglich, einen Cachehost aus der Rolle des führenden Hosts zu entfernen, indem IsLeadHost auf "Falsch" festgelegt wird.

SQL Server führt die Clusterverwaltungsrolle aus

Wenn der Cachecluster mit aktivierter Abladung erstellt wurde, weist die Einstellung leadHostManagement den Wert false auf. Unter diesen Umständen führt jeder Host unabhängig von der Einstellung leadHost nur seine normalen Aufgaben eines nicht führenden Hosts zur Zwischenspeicherung von Daten aus. Die Instanz von SQL Server, die zum Speichern der Clusterkonfigurationseinstellungen verwendet wird, wird auch zum Ausführen der Clusterverwaltungsrolle verwendet.

Auftreten eines Serverfehlers

Damit der Cluster verfügbar bleibt, wenn SQL Server die Clusterverwaltungsrolle ausführt (Abladung), muss mindestens ein Cachehost in der Lage sein, auf die SQL Server-Datenbank zuzugreifen.

Die folgende Abbildung zeigt einen aus sechs Servern bestehenden Cachecluster.

In diesem Beispiel führt SQL Server die Clusterverwaltungsrolle aus, und alle sechs Cachehosts können ihre Ressourcen für den Datenzugriff für die Cacheclients reservieren.

Wenn einer der Cachehosts im Cluster ausfällt, gehen die Daten auf diesen Servern verloren (wenn hohe Verfügbarkeit nicht aktiviert wurde), der Cluster wird jedoch weiterhin ausgeführt. Die Daten auf den anderen Cachehosts sind auch weiterhin für die Cacheclients verfügbar. Unter diesen Umständen bleibt der Cluster sogar funktionsfähig, wenn fünf der sechs Cachehosts ausfallen.

Wenn SQL Server ausfällt, wird der gesamte Cluster innerhalb weniger Minuten heruntergefahren. Damit dieses Risiko verringert wird, wird dringend die Verwendung der Microsoft Windows Server 2008 Failover-Clusterunterstützung (https://go.microsoft.com/fwlink/?LinkId=130692) zum Hosten einer „geclusterten“ Datenbankressource als Speicherort der Cacheclusterkonfiguration und für die Clusterverwaltungsrolle empfohlen.

Siehe auch

Konzepte

Diagramm der physischen Windows Server AppFabric-Cachearchitektur (AppFabric 1.1-Cache)
Diagramm der logischen Windows Server AppFabric-Cachearchitektur (AppFabric 1.1-Cache)

  2012-03-05