Replikation zwischen Speichern

Die Replikation von Sitzungen von einem Speicher in einen anderen Speicher ist die Sitzungsreplikation auf einem anderen WebSphere Application Server. In diesem Modus können Sitzungen in einer oder mehreren WebSphere Application Server-Instanzen repliziert werden, um damit Single Points of Failure (SPOFs) für HTTP-Sitzungen auszuschalten.

[AIX Solaris HP-UX Linux Windows][z/OS]Die Instanz von WebSphere Application Server, in der die Sitzung derzeit verarbeitet wird, ist der Eigner der Sitzung. In einer Clusterumgebung werden Anforderungen für eine bestimmte Sitzung aufgrund der Sitzungsaffinität im Plug-in von WebSphere Application Server immer an denselben Server geleitet. Falls dieser Server ausfällt, leitet das Plug-in von WebSphere Application Server die Anforderungen an einen anderen geeigneten Server im Cluster weiter. In einem Peer-to-Peer-Cluster, bewirkt das Feature Hot Failover, dass das Plug-in in einen Server verschoben wird, der bereits die Sicherungskopie der Sitzung enthält und verhindert so, dass die Sitzung erneut von einem anderen Server mit der Sicherung abgerufen werden muss. In einem Client/Server-Cluster ruft der Server die Sitzung von einem Server ab, der die Sicherungskopie der Sitzung enthält. Jetzt wird dieser Server Eigner der Sitzung, und die Affinität wird zu diesem Server gepflegt.

[IBM i]Das Profil von WebSphere Application Server, in dem die Sitzung derzeit verarbeitet wird, ist der Eigner der Sitzung. In einer Clusterumgebung werden Anforderungen für eine bestimmte Sitzung aufgrund der Sitzungsaffinität im Plug-in von WebSphere Application Server immer an denselben Server geleitet. Falls das aktuelle Serverprofil, das Eigner der Sitzung ist, ausfällt, leitet das Plug-in von WebSphere Application Server die Anforderungen an einen anderen geeigneten Server im Cluster weiter. In einem Peer-to-Peer-Cluster, bewirkt das Feature Hot Failover, dass das Plug-in in einen Server verschoben wird, der bereits die Sicherungskopie der Sitzung enthält und verhindert so, dass die Sitzung erneut von einem anderen Server mit der Sicherung abgerufen werden muss. In einem Client/Server-Cluster ruft der Server die Sitzung von einem Server ab, der die Sicherungskopie der Sitzung enthält. Jetzt wird dieser Server Eigner der Sitzung, und die Affinität wird zu diesem Server gepflegt.

Es gibt drei mögliche Ausführungsmodi:
  • Servermodus: Die Instanz speichert nur Sicherungskopien anderer Sitzungen in WebSphere Application Server und versendet keine Kopien der Sitzungen, die in diesem Server erstellt werden.
  • Clientmodus: Die Instanz versendet nur Kopien eigener Sitzungen (Broadcast-Betrieb) und empfängt keine Sicherungskopien von Sitzungen anderer Server.
  • [AIX Solaris HP-UX Linux Windows][z/OS]Client/Server-Modus (Beide): Die Instanz versendet Kopien der eigenen Sitzungen (Broadcast-Betrieb) und fungiert gleichzeitig als Sicherungstabelle für Sitzungen anderer Instanzen von WebSphere Application Server.
  • [IBM i]Client/Server-Modus (Beide): Die Instanz versendet Kopien der eigenen Sitzungen (Broadcast-Betrieb) und fungiert gleichzeitig als Sicherungstabelle für Sitzungen anderer Instanzen von WebSphere Application Server.
Sie können den Replikationsmodus (Server, Client oder Client/Server (Beide)) auswählen, wenn Sie die Replikation zwischen Speichern mit der Sitzungsverwaltung konfigurieren. Die Standardeinstellung ist der Client/Server-Modus (Beide). Diese Speicheroption wird mit dem Modusparameter gesteuert.

Bei der Replikation zwischen Speichern wird eine Instanz des Datenreplikationsservice in einem Anwendungsserver erstellt, der mit anderen Instanzen des Datenreplikationsservice in fernen Anwendungsservern kommuniziert. Sie müssen diese Instanz des Datenreplikationsservice als Teil einer Replikationsdomäne konfigurieren. Die Instanzen des Datenreplikationsservice in unterschiedlichen und voneinander unabhängigen Anwendungsservern, die für die gegenseitige Replikation verwendet werden, müssen in derselben Domäne konfiguriert werden. Sie müssen für alle Sitzungsmanager, die mit einer Replikationsdomäne verbunden sind, dieselbe Topologie konfigurieren. Wenn eine Session-Manager-Instanz in einer Domäne die Client/Server-Topologie verwendet, müssen die übrigen Session-Manager-Instanzen in dieser Domäne eine Kombination von Servern sein, die entweder als Client oder als Server konfiguriert sind. Falls eine Sitzungsmanagerinstanz die Peer-to-Peer-Topologie verwendet, müssen alle Sitzungsmanagerinstanzen als Client und als Server konfiguriert sein. Beispielsweise können zwei Datenreplikationsservices, von denen einer nur als Server und der andere als Client und Server fungiert, nicht in derselben Replikationsdomäne existieren. Wenn aufgrund der Konfiguration der Replikation zwischen Speichern im Sitzungsmanager auf mehreren Ebenen für dieselbe Domäne mehrere DRS-Instanzen in demselben Anwendungsservers vorhanden sind, müssen diese denselben Modus haben.

In Bezug auf den Modus sind dies die wichtigsten Beispiele für die Konfiguration der Replikation zwischen Speichern:

Obwohl die Administrationskonsole Flexibilität und weitere Funktionen für die Replikationskonfiguration zwischen Speichern zulässt, werden offiziell nur die bereitgestellten Konfigurationen unterstützt.

Standardmäßig ist in einem Cluster ein Replikat verfügbar. Sie können die Anzahl der Replikate in der Replikationsdomäne ändern.

[z/OS]

Replikation von HTTP-Sitzungen im Controller

Die WebSphere Application Server for z/OS, in denen die Replikation von HTTP-Sitzungen zwischen Speichern konfiguriert ist, können replizierte HTTP-Sitzungsdaten im Controller speichern und Daten in anderen WebSphere Application Servern replizieren. HTTP-Sitzungsdaten, die in einem Controller gespeichert sind, können von jedem Servant dieses Controllers abgerufen werden. Die HTTP-Sitzungsaffinität bleibt weiterhin einem bestimmten Servant zugeordnet. Wenn dieser Servant jedoch ausfällt, kann jeder der anderen Servants die im Controller gespeicherten HTTP-Sitzungsdaten abrufen und eine neue Affinität einrichten.

Die Möglichkeit, HTTP-Sitzungen im Controller zu speichern, kann unter z/OS auch in nicht verwalteten Anwendungsservern konfiguriert werden. Wenn dieses Feature aktiviert ist, speichern die Servants die HTTP-Sitzungsdaten im Controller, damit sie abgerufen werden, falls ein Servant ausfällt, der den verwalteten Servern ähnlich ist. HTTP-Sitzungsdaten, die im Controller eines nicht verwalteten Anwendungsservers gespeichert sind, können nicht von anderen Anwendungsservern abgerufen werden und werden nicht in anderen Anwendungsservern repliziert.

Die Möglichkeit, HTTP-Sitzungsdaten im Controller eines nicht verwalteten Anwendungsservers zu speichern, wird mit der Einstellung "true" für die angepasste JVM-Eigenschaft "HttpSessionEnableUnmanagedServerReplication" aktiviert. Sie können diese Eigenschaft unter Server > Anwendungsserver > Servername definieren. Klicken Sie anschließend unter "Serverinfrastruktur" auf Java- und Prozessmanagement > Prozessdefinition > Servant > Java Virtual Machine > Angepasste Eigenschaften.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprs_memory2memory
Dateiname:cprs_memory2memory.html