Übersicht über WebSphere eXtreme Scale

WebSphere eXtreme Scale ist ein elastisches, skalierbares speicherinternes Datengrid. Das Datengrid übernimmt folgende Aufgaben: dynamische Zwischenspeicherung, Partitionierung, Replikation und Verwaltung von Anwendungsdaten und Geschäftslogik in mehreren Servern. WebSphere eXtreme Scale unterstützt die Verarbeitung hoher Transaktionsaufkommen mit hoher Effizienz und linearer Skalierbarkeit. Außerdem können Sie mit WebSphere eXtreme Scale Servicequalitäten wie Transaktionsintegrität, hohe Verfügbarkeit und voraussagbare Antwortzeiten erreichen.

WebSphere eXtreme Scale kann auf verschiedene Arten eingesetzt werden. Sie können das Produkt als äußerst leistungsfähigen Cache, als speicherinternen Datenbankverarbeitungsbereich für die Verwaltung von Anwendungsstatus oder zum Erstellen von XTP-Anwendungen (Extreme Transaction Processing) verwenden. Zur XTP-Funktionalität gehört eine Anwendungsinfrastruktur für die Unterstützung Ihrer anspruchsvollsten geschäftskritischen Anwendungen.

Elastische Skalierbarkeit

Eine elastische Skalierbarkeit wird durch die Verwendung eines verteilten Objekt-Cachings erreicht. Mit elastischer Skalierbarkeit überwacht und verwaltet das Datengrid sich selbst. Das Datengrid kann Server in der Topologie hinzufügen und entfernen und somit nach Bedarf die Speicher-, Netzdurchsatz- und Verarbeitungskapazität erhöhen und verringern. Beim Einleiten eines so Vorwärtsskalierungs- oder Scale-out-Prozesses wird dem aktiven Datengrid Kapazität hinzugefügt, ohne dass ein Neustart erforderlich ist. Beim Rückskalierungs - oder Scale-in-Prozess werden Kapazitäten sofort entfernt. Außerdem ist das Datengrid selbst-heilend, d. h., es kann sich nach Fehlern automatisch wiederherstellen.

WebSphere eXtreme Scale und speicherinterne Datenbanken im Vergleich

WebSphere eXtreme Scale ist eigentlich keine speicherinterne Datenbank. Eine speicherinterne Datenbank ist zu einfach, um derartig komplexe Situationen zu verwalten, wie WebSphere eXtreme Scale es kann. Wenn eine speicherinterne Datenbank einen Server hat, der ausfällt, kann sie dieses Problem nicht beheben. Ein Ausfall kann katastrophal sein, wenn sich die gesamte Umgebung auf diesem einen Server befindet.

Zur Vermeidung dieser Art von Fehlern teilt eXtreme Scale die jeweilige Datenmenge in Partitionen auf, die Baumstrukturschemas mit Integritätsbedingungen entsprechen. Baumstrukturschemas mit Integritätsbedingungen beschreiben die Beziehung zwischen Entitäten. Wenn Sie Partitionen verwenden, müssen die Entitätsbeziehungen eine Datenstruktur im Baumformat modellieren. In dieser Struktur ist der Kopf des Baums die Stammentität und die einzige Entität, die partitioniert wird. Alle untergeordneten Entitäten der Stammentität sind in derselben Partition wie die Stammentität gespeichert. Jede Partition ist als primäre Kopie oder Shard vorhanden. Eine Partition enthält auch Replikat-Shards für die Sicherung der Daten. Eine speicherinterne Datenbank kann diese Funktion nicht bereitstellen, weil sie diese Struktur und Dynamik nicht besitzt. Bei einer speicherinternen Datenbank müssen Sie die Operationen implementieren, die WebSphere eXtreme Scale automatisch ausführt. Sie können SQL-Operationen in speicherinternen Datenbanken ausführen und damit die Verarbeitungsgeschwindigkeit im Vergleich mit Datenbanken, die nicht im Speicher aufgeführt werden, verbessern. WebSphere eXtreme Scale hat anstelle der SQL-Unterstützung eine eigene Abfragesprache. Diese Abfragesprache ist elastischer, ermöglicht die Partitionierung von Daten und bietet eine zuverlässige Fehlerbehebung.

WebSphere eXtreme Scale mit Datenbanken

Mit dem Write-behind-Cachefeature kann WebSphere eXtreme Scale als Front-End-Cache für eine Datenbank eingesetzt werden. Durch die Verwendung dieses Front-End-Caches können Sie den Durchsatz erhöhen und die Datenbanklast und Konkurrenzsituationen in der Datenbank verringern. WebSphere eXtreme Scale ermöglicht eine horizontale Skalierung einer Topologie (Scale-out und Scale-in) zu vorhersagbaren Verarbeitungskosten.

Die folgende Abbildung zeigt eine verteilte kohärente Cacheumgebung, in der die eXtreme-Scale-Clients Daten an das Datengrid senden und Daten aus dem Datengrid empfangen. Das Datengrid kann automatisch mit einem Back-End-Datenspeicher synchronisiert werden. Der Cache ist kohärent, weil alle Clients dieselben Daten im Cache sehen. Jede einzelne Information wird im Cache eines einzigen beschreibbaren Servers gespeichert. Durch die Verwendung einer einzigen Kopie jeder Information werden unnötige Datensatzkopien verhindert, die potenziell verschiedene Versionen der Daten enthalten könnten. Ein kohärenter Cache nimmt immer mehr Daten auf, je mehr Server dem Datengrid hinzugefügt werden. Die Skalierung des Caches erfolgt linear zum Wachstum des Datengrids. Die Daten können für zusätzliche Fehlertoleranz auch repliziert werden.
Abbildung 1. Übergeordnete Topologie
Übergeordnete Topologie

WebSphere eXtreme Scale hat Server, so genannte Container-Server, die das speicherinterne Datengrid bereitstellen. Die Server können in WebSphere Application Server oder in einfachen J2SE-JVMs ausgeführt werden. Es können mehrere Container-Server auf einem einzigen physischen Server ausgeführt werden. Deshalb kann das speicherinterne Datengrid groß sein. Das Datengrid wird weder durch den Hauptspeicher oder Adressraum der Anwendung bzw. des Anwendungsservers beschränkt noch hat es Einfluss auf diesen. Der Hauptspeicher kann die Summe mehrerer Hundert oder Tausend Java Virtual Machines sein, die auf vielen verschiedenen physischen Servern ausgeführt werden.

Als speicherinterner Datenbankverarbeitungsbereich kann WebSphere eXtreme Scale durch eine Platte, eine Datenbank oder beides gestützt werden.

Obwohl eXtreme Scale mehrere Java-APIs bereitstellt, erfordern die meisten Anwendungsfälle keine Benutzerprogrammierung, sondern müssen lediglich in der WebSphere-Infrastruktur konfiguriert und implementiert werden.

Übersicht über das Datengrid

Die einfachste eXtreme-Scale-Programmierschnittstelle ist die Schnittstelle ObjectMap, die eine einfache Map-Schnittstelle ist, die folgendes bietet: eine Methode map.put(key,value), mit der ein Wert im Cache gespeichert werden kann, und eine Methode map.get(key), mit der der Wert später abgerufen werden kann.

Das grundlegende Datengridkonzept ist ein Schlüssel/Wert-Paar, in dem das Datengrid Werte (Java-Objekte) mit einem zugehörigen Schlüssel (einem weiteren Java-Objekt) speichert. Der Schlüssel wird später zum Abrufen des Werts verwendet. In eXtreme Scale setzt sich eine Map aus Einträgen solcher Schlüssel/Wert-Paare zusammen.

WebSphere eXtreme Scale bietet verschiedene Datengridkonfigurationen, angefangen von einem einzigen einfachen lokalen Cache bis hin zu einem großen verteilten Cache, mit mehreren JVMs und/oder Servern.

Zusätzlich zu einfachen Java-Objekten können Sie Objekte mit Beziehungen speichern. Zum Abrufen dieser Objekte können Sie eine Abfragesprache, die SQL gleicht, mit SELECT-, FROM-, und WHERE-Klauseln verwenden. Ein Bestellobjekt (Order) kann beispielsweise ein Kundenobjekt (Customer) und mehrere zugehörige Artikelobjekte (Item) haben. WebSphere eXtreme Scale unterstützt 1:1-, 1:n- und n:n-Beziehungen.

WebSphere eXtreme Scale unterstützt auch eine EntityManager-Programmierschnittstelle für das Speichern von Entitäten im Cache. Diese Programmierschnittstelle gleicht Entitäten in Java Enterprise Edition. Entitätsbeziehungen können automatisch über eine XML-Entitätsdeskriptordatei oder über Annotationen in Java-Klassen erkannt werden. Sie können eine Entität anhand des Primärschlüssels mit der Methode find in der Schnittstelle EntityManager aus dem Cache abrufen. Entitäten können innerhalb von Transaktionsgrenzen persistent im Datengrid festgeschrieben und aus diesem entfernt werden.

Stellen Sie sich eine verteilte Umgebung vor, in der der Schlüssel ein einfacher alphabetischer Name ist. Der Cache kann nach Schlüsseln in vier Partitionen aufgeteilt werden: Partition 1 für Schlüssel, die mit A-E beginnen, Partition 2 für Schlüssel, die mit F-L beginnen usw. Für die Verfügbarkeit besitzt eine Partition ein primäres Shard und ein Replikat-Shard. Änderungen an den Cachedaten werden am primären Shard vorgenommen und im Replikat-Shard repliziert. Sie konfigurieren die Anzahl der Server, die das Datengrid enthalten, und eXtreme Scale verteilt die Daten in Shards auf diese Serverinstanzen. Für die Verfügbarkeit werden Replikat-Shards auf anderen physischen Servern als die primären Shards gespeichert.

WebSphere eXtreme Scale verwendet einen Katalogservice, um das primäre Shard für jeden Schlüssel zu finden. Der Katalogserver verschiebt die Shards zwischen eXtreme-Scale-Servern, wenn die physischen Server ausfallen und später wiederhergestellt werden. Wenn beispielsweise der Server, der ein Replikat-Shards enthält, ausfällt, ordnet eXtreme Scale ein neues Replikat-Shard zu. Fällt ein Server aus, der ein primäres Shard enthält, wird das Replikat-Shard zum primären Shard hochgestuft. Wie zuvor wird ein neues Replikat-Shard erstellt.