Freigeben über


Hohe Verfügbarkeit (AppFabric 1.1-Cache)

Wenn hohe Verfügbarkeit aktiviert ist, wird eine Kopie jedes zwischengespeicherten Objekts oder Bereichs auf einem separaten Cachehost verwaltet. Der Cachecluster verwaltet die Wartung dieser Kopien und stellt sie Ihrer Anwendung zur Verfügung, wenn die primären Kopien nicht verfügbar sind. Es sind keine Codeänderungen erforderlich, um Ihre cacheaktivierten Anwendungen für hohe Verfügbarkeit bereitzustellen. Die folgende Abbildung zeigt, wie Kopien von Objekten und Bereichen auf separaten Hosts gespeichert werden, wenn das Feature „Hohe Verfügbarkeit“ aktiviert ist.

„Velocity“ - Konsistenz bei hoher Verfügbarkeit (Übersicht)

Konfiguration für hohe Verfügbarkeit

„Hohe Verfügbarkeit“ wird auf Cacheebene in den Clusterkonfigurationseinstellungen konfiguriert. Als Eigenschaft des Caches können Sie diese beim erstmaliges Erstellen des Caches mithilfe des Befehls New-Cache aktivieren, wobei der Parameter Secondaries gleich 1 ist. Dies informiert die Windows PowerShell-Cmdlets für die Cacheverwaltung, dass eine Kopie jedes zwischengespeicherten Objekts oder Bereichs gewünscht wird. Wenn Sie den Parameter Secondaries auf 0 festlegen, deaktivieren Sie das Feature „Hohe Verfügbarkeit“. Standardmäßig ist die Option „Hohe Verfügbarkeit“ deaktiviert, wenn Sie einen neuen Cache erstellen. Weitere Informationen zum Bearbeiten der Cachekonfigurationseinstellungen finden Sie unter Bearbeiten der Cachekonfigurationseinstellungen mit Windows PowerShell.

Die Funktion „Hohe Verfügbarkeit“ der Microsoft AppFabric 1.1 für Windows Server-Cache-Funktionen erfordert, dass alle Knoten im Cachecluster Enterprise Edition (oder höher) von Windows Server 2008 oder Windows Server 2008 R2 ausführen. Vergewissern Sie sich, dass alle Cacheknoten für hohe Verfügbarkeit mit einem unterstützten Betriebssystem ausgeführt werden. Weitere Informationen zu unterstützten Betriebssystemen finden Sie im Abschnitt „Softwareanforderungen“ des AppFabric-Installationshandbuchs (https://go.microsoft.com/fwlink/?LinkId=169172).

Speicherung der sekundären Kopie

Der Cachecluster wählt den Speicherort für sekundäre Kopien von Objekten und Bereichen aus. Ebenso wie AppFabric zwischengespeicherte Objekte auf alle Cachehosts im Cluster verteilt, werden auch die sekundären Kopien dieser Objekte auf alle Cachehosts im Cluster verteilt.

Verwalten der Konsistenz

Unabhängig davon, ob hohe Verfügbarkeit aktiviert ist, verhalten sich cacheaktivierte Anwendungen so, als wäre nur die primäre Kopie des zwischengespeicherten Objekts vorhanden. Alle Add-, Put- und Remove-Methodenaufrufe werden zuerst für das primäre Objekt auf dem Cachehost initiiert, auf dem es gespeichert ist. Nachdem der Aufruf an den Cachehost, der das primäre Objekt oder den primären Bereich verwaltet, iniziiert wurde, unterscheidet sich die resultierende Aktion, je nachdem, ob hohe Verfügbarkeit aktiviert ist.

Wenn hohe Verfügbarkeit aktiviert ist, erfolgt als zusätzlicher Schritt die Benachrichtigung des Hosts, der die sekundäre Kopie verwaltet, darüber, dass eine Änderung ansteht. Der Cachehost mit der primären Kopie des Objekts wartet dann auf eine Bestätigung vom anderen Host, bevor er dem Client bestätigt, dass der Vorgang abgeschlossen ist.

Ein Beispiel hierfür sind die Cachehosts A und B in der folgenden Abbildung. Sobald der Cachehost A eine Anforderung empfängt, beginnt er mit der Verarbeitung der Anforderung und benachrichtigt den Cachehost B über die Änderung. Der Cachehost B sendet dann eine Bestätigung zurück an den Cachehost A. Wenn der Cachehost A die Bestätigung empfängt, stellt er die Änderung fertig und sendet dann eine Bestätigung zurück an die cacheaktivierte Anwendung. Durch diesen Vorgang wird sichergestellt, dass die sekundäre Kopie des Objekts oder Bereichs immer den gleichen Status wie die primäre Kopie aufweist. Dieser Vorgang wird als starke Konsistenz bezeichnet.

„Velocity“ - Konsistenz bei hoher Verfügbarkeit

Leistungsüberlegungen

Da der Cachehost, der die sekundäre Kopie des Objekts oder Bereichs verwaltet, alle Änderungen an der primären Kopie bestätigen muss, wird die Leistung hinsichtlich der Antwortzeit der Schreibvorgänge aus der cacheaktivierten Anwendung geringfügig verschlechtert. Beachten Sie, dass diese Leistungsbeeinträchtigung Lesevorgänge von Elementen, die sich bereits im Cache befinden, nicht betrifft. Sie sollten außerdem die Zeit berücksichtigen, die zum erneuten Laden des Caches mit Objekten erforderlich ist, wenn der Cachehost, der die primären Kopien dieser Objekte verwaltet, verloren geht.

Auswirkungen eines Cachehostfehlers

Bei einem Cachehostfehler ändert sich nichts für die cacheaktivierte Anwendung (vorausgesetzt, es ist noch eine ausreichende Anzahl von Cachehosts verfügbar, um die Ausführung des Clusters zu gewährleisten). Der Cachecluster leitet Anforderungen für das Objekt erneut an den Cachehost weiter, der die sekundäre Kopie des Objekts verwaltet hat. Im Cluster werden den sekundären Kopien aller primären Objekte erhöhte Rechte zugewiesen, sodass sie die neuen primären Objekte werden. Anschließend werden sekundäre Kopien dieser neuen primären Objekte an andere Cachehosts im Cluster verteilt. Sekundäre Objekte mit Fehlern für den Cachehost werden durch neue sekundäre Objekte ersetzt und im Cluster verteilt. Dieser Vorgang gilt auch für Bereiche.

Damit das Feature „Hohe Verfügbarkeit“ Sie beim Isolieren der Anwendung vor Fehlern eines Cachehosts schützt, müssen mindestens drei Cachehosts Mitglieder des Cacheclusters sein. Dies beruht auf der Anforderung strenger Konsistenz, die besagt, dass immer zwei Kopien eines zwischengespeicherten Objekts oder Bereichs in einem für hohe Verfügbarkeit aktivierten Cache vorhanden sein müssen. Damit zwei Kopien eines Caches oder Bereichs verwaltet werden, erfordert ein für hohe Verfügbarkeit aktivierter Cache mindestens zwei Cachehosts, um zu funktionieren.

Angenommen, Sie haben einen für hohe Verfügbarkeit aktivierten Cache namens HACache in einem Cachecluster mit drei Servern erstellt, wie in der folgenden Tabelle gezeigt. In diesem Beispiel wurde SQL Server für die Ausführung der Clusterverwaltungsrolle konfiguriert (damit in diesem Beispiel der potenzielle Verlust führender Hosts nicht berücksichtigt werden muss).

Zeit Cachehost 1 Cachehost 2 Cachehost 3 HACache (benannter, für hohe Verfügbarkeit aktivierter Cache)

T1

Wird ausgeführt.

Wird ausgeführt.

Wird ausgeführt.

Verfügbar

T2

Wird ausgeführt.

Wird ausgeführt.

Beendet

Verfügbar

T3

Wird ausgeführt.

Beendet

Beendet

Nicht verfügbar

Wenn drei Cachehosts verfügbar sind, können bei T1 zwei Kopien zwischengespeicherter Objekte oder Bereiche auf einem von drei verfügbaren Servern gespeichert werden. Wenn bei T2 ein Cacheserver ausfällt, ist HACache auch weiterhin verfügbar, weil noch zwei Cachehosts zum Speichern der beiden Kopien der zwischengespeicherten Objekte oder Bereiche verfügbar sind. Wenn der zweite Cachehost bei T3 ausfällt, wird HACache nicht verfügbar. Dies ist der Fall, weil kein weiterer Cachehost mehr zum Speichern der zweiten Kopie der zwischengespeicherten Objekte oder Bereiche verfügbar ist.

Weitere Empfehlungen zur hohen Verfügbarkeit

Beachten Sie die folgenden Empfehlungen, um die Verfügbarkeit der zwischengespeicherten Daten zu optimieren:

  • Setzen Sie ein große Anzahl von Cachehosts ein.

  • Stellen Sie das verteilte Cachesystem im Umkreis einer Firewall bereit. Dabei sollten alle Server (einschließlich Cacheclients, Cachehosts, primärer Datenquellenserver und Server, der den Speicherort der Clusterkonfiguration hostet) Mitglieder der gleichen Domäne sein.

  • Verwenden Sie SQL Server oder einen benutzerdefinierten Anbeter, um die Cachecluster-Konfigurationseinstellungen zu speichern.

  • Halten Sie kostenintensive Konfigurationsänderungen gering, die das Beenden des Clusters erfordern. Erstellen Sie benannte Caches nach Möglichkeit erneut, anstatt den gesamten Cachecluster zu beenden und Cachekonfigurationsänderungen in den Clusterkonfigurationseinstellungen vorzunehmen.

  • Verwenden Sie immer den Befehl Stop-CacheHost, um den Cachedienst zu beenden, bevor Sie einen Serverneustart ausführen. Wenn führende Hosts die Clusterverwaltungsrolle ausführen, kann das Cmdlet Stop-CacheHost nicht erfolgreich ausgeführt werden, wenn die Beendigung des Cachediensts dazu führt, dass der gesamte Cachecluster automatisch herunterfährt (aufgrund fehlender Mehrheit der ausgeführten führenden Hosts).

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