Dynamischer Cache-Provider

Die Anwendungsprogrammierschnittstelle (API, Application Programming Interface) für dynamischen Cache steht Java-EE-Anwendungen zur Verfügung, die in WebSphere Application Server implementiert sind. Der dynamische Cache-Provider kann genutzt werden, um Geschäftsdaten und generierte HTML zwischenzuspeichern oder um die zwischengespeicherten Daten in der Zelle über den Datenreplikationsservice (DRS) zu synchronisieren.

Übersicht

Früher war der einzige Serviceprovider für die Anwendungsprogrammierschnittstelle "Dynamic Cache" die in WebSphere Application Server integrierte Standardsteuerkomponente für dynamische Cache. Kunden können die Serviceproviderschnittstelle für dynamischen Cache in WebSphere Application Server verwenden, um eXtreme Scale in den dynamischen Cache zu integrieren. Indem Sie die Funktionalität konfigurieren, ermöglichen Sie Anwendungen, die mit der API für dynamischen Cache geschrieben wurden, und Anwendungen, die Caching auf Containerebene verwenden (z. B. Servlets), die Nutzung der Features und Leistungsfunktionen von WebSphere eXtreme Scale.

Sie können den dynamischen Cache-Provider, wie im Abschnitt Dynamischen Cache-Provider für WebSphere eXtreme Scale konfigurieren beschrieben, installieren und konfigurieren.

Einsatz von WebSphere eXtreme Scale festlegen

Die verfügbaren Features in WebSphere eXtreme Scale erweitern die verteilten Funktionen der API "Dynamic Cache" weit über das hinaus, was die Standardsteuerkomponente für dynamischen Cache und der Datenreplikationsservice bieten. Mit eXtreme Scale können Sie Caches erstellen, die wirklich auf mehrere Server verteilt, anstatt nur repliziert und unter den Servern synchronisiert werden. Außerdem sind die Caches von eXtreme Scale transaktionsorientiert und hoch verfügbar, wodurch sichergestellt wird, dass jeder Server denselben Inhalt für den dynamischen Cacheservice sieht. WebSphere eXtreme Scale bietet eine höhere Servicequalität für die Cachereplikation als der Datenreplikationsservice.

Diese Vorteile bedeuten jedoch nicht, dass der dynamische Cache-Provider von eXtreme Scale die richtige Wahl für jede Anwendung ist. Verwenden Sie die folgenden Entscheidungsbäume und Featurevergleichsmatrizes, um festzustellen, welche Technologie sich am besten für Ihre Anwendung eignet.

Entscheidungsbaum für die Migration vorhandener Anwendungen mit dynamischem Cache

Vorhandene Anwendung mit dynamischem Cache

Entscheidungsbaum für die Auswahl eines Cache-Providers für neue Anwendungen

Neue Anwendung

Featurevergleich

Tabelle 1. Featurevergleich
Cachefeatures Standardprovider eXtreme-Scale-Provider eXtreme-Scale-API

Lokales Speicher-Caching

x

x

x

Verteiltes Caching

Integriert

Integriert, integriert-partitioniert und fern-partitioniert

Mehrere

Linear skalierbar

 

x

x

Zuverlässige Replikation (synchron)

 

ORB

ORB

Plattenüberlauf

x

   

Bereinigung

Basierend auf LRU-/TTL-/Heapspeicher

LRU/TTL (pro Partition)

Mehrere

Ungültigmachen

x

x

x

Beziehungen

Abhängigkeits-IDs, Schablonen

Abhängigkeits-IDs, Schablonen

x

Suchoperationen ohne Schlüssel

   

Abfrage und Index

Back-End-Integration

   

Loader

Transaktionsorientiert

 

Implizit

x

Schlüsselbasierter Speicher

x

x

x

Ereignisse und Listener

x

x

x

Integration von WebSphere Application Server

Nur einzelne Zelle

Mehrere Zellen

Zellenunabhängig

Unterstützung von Java Standard Edition

x

x

Überwachung und Statistiken

x

x

x

Sicherheit

x

x

x

Tabelle 2. Nahtlose Technologieintegration
Cachefeatures Standardprovider eXtreme-Scale-Provider eXtreme-Scale-API

Caching von Servlet-/JSP-Ergebnissen in WebSphere Application Server

Version 5.1+

Version 6.1.0.25+

 

Caching von Web-Service-Ergebnissen (JAX-RPC) in WebSphere Application Server

Version 5.1+

Version 6.1.0.25+

 

Caching von HTTP-Sitzungen

   

x

Cache-Provider für OpenJPA und Hibernate

   

x

Datenbanksynchronisation mit OpenJPA und Hibernate

   

x

Tabelle 3. Programmierschnittstellen
Cachefeatures Standardprovider eXtreme-Scale-Provider eXtreme-Scale-API

Befehlsbasierte API

Befehls-Framework-API

Befehls-Framework-API

DataGrid-API

Map-basierte API

DistributedMap-API

DistributedMap-API

ObjectMap-API

EntityManager-API

   

x

Eine ausführlichere Beschreibung zur Funktionsweise der verteilten Caches in eXtreme Scale finden Sie in Topologie planen.

Anmerkung: In einem verteilten eXtreme-Scale-Cache können nur Einträge gespeichert werden, bei denen sowohl der Schlüssel als auch der Wert die Schnittstelle "java.io.Serializable" implementieren.

Topologietypen

Ein dynamischer Cacheservice, der mit dem eXtreme-Scale-Provider erstellt wurde, kann in jeder der drei verfügbaren Topologien implementiert werden und ermöglicht Ihnen, den Cache speziell an Ihren Leistungs-, Ressourcen-und Verwaltungsbedarf anzupassen. Diese Topologien sind die integrierte, die integriert, partitionierte Topologie und die ferne Topologie.

Integrierte Topologie

Die integrierte Topologie ist dem dynamischen Standardcache- und DRS-Provider sehr ähnlich. Verteilte Cacheinstanzen, die mit der integrierten Topologie erstellt werden, enthalten eine vollständige Kopie des Caches in jedem Prozess von eXtreme Scale, der auf den dynamischen Cacheservice zugreift und ermöglichen damit die lokale Durchführung aller Leseoperationen. Alle Schreiboperationen erfolgen über einen Einzelserverprozess, in dem die Transaktionssperren verwaltet werden, bevor sie auf den restlichen Servern repliziert werden. Deshalb eignet sich diese Topologie besser für Workloads, bei denen Anzahl der Leseoperationen im Cache im Vergleich mit den Schreiboperationen im Cache wesentlich höher ist.

Mit der integrierten Topologie werden neue oder aktualisierte Cacheeinträge nicht sofort in jedem einzelnen Serverprozess sichtbar. Ein Cacheeintrag wird erst dann sichtbar (selbst für den Server, der ihn generiert hat), wenn er über die asynchronen Replikationsservices von WebSphere eXtreme Scale weitergegeben wird. Diese Services arbeiten so schnell, wie es die Hardware zulässt, aber es kommt trotzdem zu einer kleinen Verzögerung. Die integrierte Topologie wird in der folgenden Abbildung veranschaulicht:

Integrierte Topologie

Integrierte, partitionierte Topologie

Für Workloads, bei denen die Anzahl der Schreiboperationen größer-gleich der Anzahl der Leseoperationen ist, wird die integrierte, partitionierte Topologie oder die ferne Topologie empfohlen. Bei der integrierten, partitionierten Topologie sind alle Cachedaten in den Prozessen von WebSphere Application Server enthalten, die auf den Cache zugreifen. In jedem einzelnen Prozess wird jedoch nur ein Teil der Cachedaten gespeichert. Alle Lese- und Schreiboperationen für die Daten in dieser "Partition" erfolgen über den Prozess, d. h., dass die meisten Anforderungen an den Cache über einen Prozedurfernaufruf verarbeitet werden. Dies führt zu einer höheren Latenzzeit für Leseoperationen als bei der integrierten Topologie, aber die Kapazität des verteilten Caches für die Verarbeitung von Lese- und Schreiboperationen steigt linear zur Anzahl der Prozesse von WebSphere Application Server, die auf den Cache zugreifen. Außerdem wird die maximale Größe des Caches bei dieser Topologie nicht durch die Größe eines einzelnen WebSphere-Prozesses beschränkt. Da jeder Prozess nur einen Teil des Caches enthält, entspricht die maximale Cachegröße der summierten Größe alle Prozesse abzüglich der Kosten für den Prozess. Die integrierte, partitionierte Topologie wird in der folgenden Abbildung veranschaulicht:

Integrierte, partitionierte Topologie

Angenommen, Sie haben ein Grid von Serverprozessen mit jeweils 256 MB freiem Heapspeicher für einen dynamischen Cacheservice. Der dynamische Standardcacheprovider und der Provider von eXtreme Scale, der die integrierte Topologie verwendet, sind beide auf eine Speichercachegröße von 256 MB abzüglich Prozesskosten beschränkt. Lesen Sie hierzu den Abschnitt "Kapazitätsplanung und hohe Verfügbarkeit" weiter hinten in diesem Dokument. Der eXtreme-Scale-Provider, der die integrierte, partitionierte Topologie verwendet, ist auf eine Cachegröße von 1 GB abzüglich Prozesskosten beschränkt. Der Provider von WebSphere eXtreme Scale unterstützt somit speicherinterne dynamische Cacheservices, die die Größe eines einzelnen Serverprozesses überschreiten. Der dynamische Standardcacheprovider stützt sich auf die Verwendung eines Plattencaches, damit Cacheinstanzen über die Größe eines Einzelprozesses hinweg anwachsen können. In vielen Situationen können Sie sich durch den Provider von WebSphere eXtreme Scale den Plattencache und die kostenintensiven Plattenspeichersysteme, die für eine angemessene Leistung des Plattencaches erforderlich sind, sparen.

Ferne Topologie

Die ferne Topologie kann ebenfalls verwendet werden, um den Bedarf an einem Plattencache zu umgehen. Der einzige Unterschied zwischen der fernen Topologie und der integrierten, partitionierten Topologie besteht darin, dass bei einer fernen Topologie alle Cachedaten außerhalb der Prozesse von WebSphere Application Server gespeichert werden. WebSphere eXtreme Scale unterstützt eigenständige Containerprozesse für Cachedaten. Diese Containerprozesse haben geringere Kosten als ein Prozess von WebSphere Application Server und sind auch nicht auf die Verwendung einer bestimmten Java Virtual Machine (JVM) beschränkt. Die Daten für einen dynamischen Cacheservice, auf den mit einem 32-Bit-Prozess von WebSphere Application Server zugegriffen wird, könnte sich beispielsweise in einem eXtreme-Scale-Containerprozess befinden, der in einer 64-Bit-JVM ausgeführt wird. Dies ermöglicht Benutzern, die höhere Speicherkapazität von 64-Bit-Prozessen für das Caching zu nutzen, ohne das zusätzliche Kosten für den 64-Bit-Betrieb bei den Anwendungsserverprozessen anfallen. Die ferne Topologie wird in der folgenden Abbildung veranschaulicht:

Ferne Topologie

Datenkomprimierung

Ein weiteres Leistungsfeature, das der dynamische Cache-Provider von WebSphere eXtreme Scale Benutzern für die Verwaltung der Cachekosten bietet, ist Komprimierung. Der dynamische Standardcacheprovider unterstützt keine Komprimierung zwischengespeicherter Daten im Speicher. Mit dem Provider von eXtreme Scale ist dies möglich. Die Cachekomprimierung mit dem Komprimierungsalgorithmus (deflate) kann in jeder der drei verteilten Topologien aktiviert werden. Die Aktivierung der Komprimierung erhöht die Kosten für Lese- und Schreiboperationen, steigert aber drastisch die Cachedichte für Anwendungen wie das Caching von Servlets und JSP-Dateien.

Lokaler Speichercache

Der dynamische Cache-Provider von WebSphere eXtreme Scale kann auch zur Unterstützung dynamischer Cacheinstanzen verwendet werden, in denen die Replikation inaktiviert ist. Wie beim dynamischen Standardcacheprovider können in diesen Caches nicht serialisierbare Daten gespeichert werden. Außerdem bieten Sie in großen Mehrprozessorunternehmensservern häufig eine bessere Leistung als der dynamische Standardcacheprovider, weil der Codepfad von eXtreme Scale auf einem möglichst hohe Anzahl gemeinsamer Zugriff auf den Speichercache ausgelegt ist.

Funktionale Unterschiede zwischen der dynamischen Cachesteuerkomponente und eXtreme Scale

Bei lokalen Speichercaches, in denen die Replikation inaktiviert ist, sind keine wesentlichen funktionalen Unterschiede zwischen Caches, die vom dynamischen Standardcacheprovider unterstützt werden, und WebSphere eXtreme Scale bemerkbar. Dem Benutzer sollten eigentlich keine funktionalen Unterschiede zwischen den beiden Caches auffallen, abgesehen davon, dass von WebSphere eXtreme Scale unterstützte Caches keine Auslagerung auf die Platte oder Statistiken und Operationen unterstützen, die sich auf die Größe des Caches im Speicher beziehen.

Bei Caches, in denen die Replikation aktiviert ist, unterscheiden sich die von den meisten Aufrufen der API "Dynamic Cache" zurückgegebenen Ergebnisse kaum, unabhängig davon, ob der Kunde den dynamischen Standardcacheprovider oder den dynamischen Cache-Provider von eXtreme Scale verwendet. Für einige Operationen kann das Verhalten der dynamischen Cachesteuerkomponente nicht mit eXtreme Scale emuliert werden.

Statistiken zum dynamischen Cache

Statistiken zum dynamischen Cache werden über die Anwendung "CacheMonitor" oder die MBean der API "dynamic cache" berichtet. Wenn Sie den dynamischen Cache-Provider von eXtreme Scale verwenden, werden Statistiken weiterhin über diese Schnittstellen berichtet, aber der Kontext der Statistikwerte ist anders.

Wenn eine dynamische Cacheinstanz von drei Servern (A, B und C) gemeinsam genutzt wird, gibt das Statistikobjekt des dynamischen Caches nur Statistiken für die Kopie des Caches auf dem Server zurück, auf dem der Aufruf abgesetzt wurde. Wenn die Statistiken auf Server A abgerufen werden, spiegeln sie nur die Aktivitäten auf Server A wider.

Mit eXtreme Scale gibt es nur einen einzigen verteilten Cache, der von allen Servern gemeinsam genutzt wird, so dass es nicht möglich ist, die meisten Statistiken auf Serverbasis zu verfolgen, wie es der dynamische Standardcacheprovider tut. Im Folgenden finden Sie eine Liste der Statistiken, die von der API für Cachestatistiken berichtet werden, einschließlich einer Beschreibung ihrer Funktionalität, wenn Sie den dynamischen Cache-Provider von WebSphere eXtreme Scale verwenden. Wie der Standardprovider werden diese Statistiken nicht synchronisiert und können deshalb bei gleichzeitigen Workloads bis zu 10 % variieren.

  • Cachetreffer: Cachetreffer werden auf Serverbasis verfolgt. Wenn der Datenverkehr auf Server A 10 Cachetreffer generiert und der Datenverkehr auf Server B 20 Cachetreffer, werden in den Cachestatistiken 10 Cachetreffer auf Server A und 20 Cachetreffer auf Server B berichtet.
  • Cachefehler: Cachefehler werden wie Cachetreffer auf Serverbasis berichtet.
  • Speichercacheeinträge: In dieser Statistik wird die Anzahl der Cacheeinträge im verteilten Cache berichtet. Jeder Server, der auf den Cache zugreift, berichtet denselben Wert für diese Statistik, und der Wert gibt die Gesamtanzahl der Cacheeinträge im Speicher über alle Server wider.
  • Speichercachegröße in MB: Diese Metrik wird nur für Caches unterstützt, die eine ferne, integrierte oder integrierte partitionierte Topologie verwenden. Sie berichtet die Anzahl der Megabyte des Java-Heapspeichers, der vom Cache im gesamten Grid belegt wird. Diese Statistik berichtet die Heapspeicherbeleigung nur für primäre Partitionen. Replikate müssen gesondert berücksichtigt werden. Da die Standardeinstellung für die ferne und die integrierte partitionierte Topologie ein asynchrones Replikat ist, müssen Sie diese Zahl verdoppeln, um die echte Speicherbelegung des Caches zu erhalten.
  • Entfernte Cacheeinträge: Diese Statistik berichtet die Gesamtanzahl der Einträge, die über beliebige Methoden aus dem Cache entfernt wurden, und ist ein kumulierter Wert für den gesamten verteilten Cache. Wenn der Datenverkehr auf Server A 10 ungültig gemachte Einträge und der Datenverkehr auf Server B 20 ungültig gemachte Einträge generiert, ist der Wert auf beiden Servern 30.
  • Entfernte LRU-Cacheeinträge: Diese Statistik ist wie die entfernten Cacheeinträge ein kumulierter Wert. Sie verfolgt die Anzahl der Einträge, die entfernt wurden, um den Cache unter seiner maximalen Größe zu halten.
  • Ungültig gemachte Einträge wegen Zeitlimitüberschreitung: Diese Statistik ist ebenfalls eine kumulierte Statistik und verfolgt die Anzahl der Einträge, die entfernt wurden, weil das zulässige Zeitlimit überschritten wurde.
  • Explizit ungültig gemachte Einträge: Diese Statistik ist ebenfalls eine kumulierte Statistik und verfolgt die Anzahl der Einträge, die durch direkte Ungültigmachung nach Schlüssel, Abhängigkeits-ID oder Schablone entfernt wurden.
  • Erweiterte Statistiken: Der dynamische Cache-Provider von eXtreme Scale exportiert die folgenden Schlüsselzeichenfolgen für erweiterte Statistiken.
    • com.ibm.websphere.xs.dynacache.remote_hits: Die Gesamtanzahl der im eXtreme-Scale-Container verfolgten Cachetreffer. Diese Statistik ist eine kumulierte Statistik, und der Wert in der erweiterten Statistik-Map ist ein Wert vom Typ long.
    • com.ibm.websphere.xs.dynacache.remote_misses: Die Gesamtanzahl der im eXtreme-Scale-Container verfolgten Cachefehler. Diese Statistik ist eine kumulierte Statistik, und der Wert in der erweiterten Statistik-Map ist ein Wert vom Typ long.

Zurückgesetzte Statistiken berichten

Der dynamische Cache-Provider ermöglicht Ihnen, Cachestatistiken zurückzusetzen. Mit dem Standardprovider löscht die Rücksetzoperation nur die Statistiken des betroffenen Servers. Der dynamische Cache-Provider von eXtreme Scale verfolgt die meisten seiner Statistikdaten in fernen Cachecontainern. Diese Daten werden weder gelöscht noch geändert, wenn die Statistiken zurückgesetzt werden. Stattdessen wird das Verhalten des dynamischen Standardcaches im Client simuliert, indem die Differenz zwischen dem aktuellen Wert einer bestimmten Statistik und dem Wert dieser Statistik beim letzten Aufruf der Rücksetzoperation auf diesem Server berichtet wird.

Wenn der Datenverkehr auf Server A beispielsweise 10 entfernte Cacheeinträge generiert, werden in den Statistiken für Server A und Server B 10 entfernte Einträge berichtet. Werden die Statistiken auf Server B jetzt zurückgesetzt und generiert der Datenverkehr auf Server A weitere 10 entfernte Einträge, werden in den Statistiken für Server A 20 entfernte Einträge berichtet und in den Statistiken für Server B 10.

Dynamische Cacheereignisse

Die API "Dynamic Cache" ermöglicht Benutzern die Registrierung von Ereignis-Listenern. Wenn Sie eXtreme Scale als dynamischen Cache-Provider verwenden, arbeiten die Ereignis-Listener für lokale Speichercaches erwartungsgemäß.

Bei verteilten Caches richtet sich das Ereignisverhalten nach der verwendeten Topologie. Für Caches, die die integrierte Topologie verwenden, werden Ereignisse auf dem Server generiert, der die Schreiboperationen verarbeitet, dem so genannten primären Shard. Das bedeutet, dass nur ein einziger Server Ereignisbenachrichtigungen empfängt, aber dieser Server erhält alle Ereignisbenachrichtigungen, die normalerweise vom dynamischen Cache-Provider erwartet werden. Da WebSphere eXtreme Scale das primäre Shard zur Laufzeit auswählt, ist es nicht möglich sicherzustellen, dass immer ein bestimmter Serverprozess diese Ereignisse empfängt.

Integrierte partitionierte Caches generieren Ereignisse auf jedem Server, der eine Partition des Caches enthält. Wenn ein Cache also 11 Partitionen hat und jeder Server in einem Grid von WebSphere Application Server Network Deployment mit 11 Servern eine der Partitionen enthält, empfängt jeder Server die dynamischen Cacheereignisse für die Cacheeinträge, die er enthält. Es gibt keinen einzigen Prozess, der alle Ereignisse sieht, es sei denn, alle 11 Partitionen befinden sich in diesem einen Serverprozess. Wie bei der integrierten Topologie ist es nicht möglich sicherzustellen, dass immer ein bestimmter Serverprozess einen bestimmten Ereignissatz empfängt.

Caches, die die ferne Topologie verwenden, unterstützen keine dynamischen Cacheereignisse.

MBean-Aufrufe

Der dynamische Cache-Provider von WebSphere eXtreme Scale unterstützt kein Platten-Caching. Alle MBean-Aufrufe, die sich auf Platten-Caching beziehen, funktionieren nicht.

Zuordnung einer Replikationsrichtlinie für den dynamischen Cache

Der in WebSphere Application Server integrierte dynamische Cache-Provider unterstützt mehrere Richtlinien für die Cachereplikation. Diese Richtlinien können global oder für jeden Cacheeintrag konfiguriert werden. In der Dokumentation zum dynamischen Cache finden Sie eine Beschreibung dieser Replikationsrichtlinien.

Der dynamische Cache-Provider von eXtreme Scale berücksichtigt diese Richtlinien nicht direkt. Die Replikationsmerkmale eines Caches richten sich nach dem konfigurierten Typ für die verteilte eXtreme-Scale-Topologie und gelten für alle Werte in diesem Cache, unabhängig von der vom dynamischen Cacheservice definierten Replikationsrichtlinie für den Eintrag. Die folgende Liste enthält alle Replikationsrichtlinien, die vom dynamischen Cacheservice unterstützt werden, und veranschaulicht, welche eXtreme-Scale-Topologie ähnliche Replikationsmerkmale bietet.

Beachten Sie, dass der dynamische Cache-Provider von eXtreme Scale die Richtlinieneinstellungen für die DRS-Replikation für einen Cache bzw. Cacheeintrag ignoriert. Benutzer müssen die Topologie auswählen, die ihren Replikationsanforderungen am besten entspricht.

  • NOT_SHARED: Derzeit kommt keine der vom dynamischen Cache-Provider von eXtreme Scale bereitgestellten Topologien dieser Richtlinie nahe. Das bedeutet, dass alle Daten, die im Cache gespeichert werden, Schlüssel und Werte haben müssen, die java.io.Serializable implementieren.
  • SHARED_PUSH: Die integrierte Topologie kommt dieser Replikationsrichtlinie nahe. Wenn ein Cacheeintrag erstellt wird, wird er in allen Servern repliziert. Server suchen nur lokal nach Cacheeinträgen. Wird ein Eintrag lokal nicht gefunden, wird davon ausgegangen, dass der Eintrag nicht vorhanden ist, und es werden keine anderen Server nach dem Eintrag abgefragt.
  • SHARED_PULL und SHARED_PUSH_PULL: Die integrierte, partitionierte Topologie und die ferne Topologie kommen dieser Replikationsrichtlinie nahe. Der verteilte Status des Caches ist in allen Servern vollständig konsistent.

Diese Informationen werden hauptsächlich bereitgestellt, damit Sie sicherstellen können, dass die Topologie Ihre Anforderungen bezüglich verteilter Konsistenz erfüllt. Wenn die integrierte Topologie beispielsweise die bessere Wahl für Ihre Implementierungs- und Leistungsanforderungen ist, Sie aber die von SHARED_PUSH_PULL unterstützte Cachekonsistenzstufe benötigen, sollten Sie die integrierte, partitionierte Topologie verwenden, selbst wenn die Leistung geringfügig schwächer ist.

Sicherheit

Sie können dynamische Cacheinstanzen, die in einer integrierten oder einer integrierten, partitionierten Topologie ausgeführt werden, mit den in WebSphere Application Server integrierten Sicherheitsfunktionen schützen. Weitere Informationen hierzu finden Sie in der Dokumentation zum Sichern von Anwendungsservern im Information Center von WebSphere Application Server.

Wenn ein Cache in einer fernen Topologie ausgeführt wird, kann ein eigenständiger extreme-Scale-Client eine Verbindung zum Cache herstellen und den Inhalt der dynamischen Cacheinstanz beeinflussen. Der dynamische Cache-Provider von eXtreme Scale besitzt ein Verschlüsselungsfeature, das nur geringe Kosten produziert, aber verhindern kann, dass Cachedaten von Clients, die keine Clients von WebSphere Application Server sind, gelesen oder geändert werden. Zum Aktivieren dieses Features setzen Sie den optionalen Parameter com.ibm.websphere.xs.dynacache.encryption_password in jeder Instanz von WebSphere Application Server, die auf den dynamischen Cache-Provider zugreift, auf denselben Wert. Daraufhin werden der Wert und die Benutzermetadaten für den Cacheeintrag mit 128-Bit-AES-Verschlüsselung verschlüsselt. Es ist sehr wichtig, dass für alle Server derselbe Wert definiert wird. Server können keine Daten lesen, die von Servern mit einem anderen Wert für diesen Parameter in den Cache gestellt werden.

Wenn der Provider von eXtreme Scale erkennt, dass unterschiedliche Werte für diese Variable in demselben Cache gesetzt sind, generiert er eine Warnung im Protokoll des Containerprozesses von eXtreme Scale.

Lesen Sie in der Dokumentation zu eXtreme Scale die Informationen zur Übersicht über die Sicherheit, wenn SSL- oder Clientauthentifizierung erforderlich ist.

Weitere Informationen