Verteilte Implementierungen konfigurieren

Verwenden Sie die XML-Deskriptordatei für die Implementierungsrichtlinie und die ObjectGrid-XML-Deskriptordatei, um Ihre Topologie zu verwalten.

Die Implementierungsrichtlinie wird als XML-Datei codiert, die dem Container-Server von eXtreme Scale bereitgestellt wird. Die XML-Datei enthält die folgenden Informationen:
  • die Maps, die zu den einzelnen MapSets gehören,
  • die Anzahl der Partitionen,
  • die Anzahl synchroner und asynchroner Replikate.
Die Implementierungsrichtlinie steuert auch die folgenden Verteilungsverhalten:
  • die Mindestanzahl aktiver Container-Server, bevor die Verteilung stattfindet,
  • die automatische Verteilung verloren gegangener Shards,
  • die Verteilung jedes Shards einer einzelnen Partition an eine jeweils andere Maschine.

Endpunktinformationen werden in der dynamischen Umgebung nicht vorkonfiguriert. Es sind keine Servernamen oder Informationen zur physischen Topologie in der Implementierungsrichtlinie enthalten. Alle Shards in einem Datengrid werden automatisch vom Katalogservice an die Container-Server verteilt. Der Katalogservice verwendet die in der Implementierungsrichtlinie definierten Vorgaben, um die Verteilung der Shards automatisch zu verwalten. Mit dieser automatischen Shard-Verteilung lassen sich große Datengrids ohne großen Aufwand konfigurieren. Sie können der Umgebung bei Bedarf auch Server hinzufügen.

Einschränkung: In einer Umgebung mit WebSphere Application Server werden Stammgruppen mit mehr als 50 Membern nicht unterstützt.

Während des Starts wird eine XML-Implementierungsrichtliniendatei an einen Container-Server übergeben. Eine Implementierungsrichtlinie muss zusammen mit einer ObjectGrid-XML-Datei verwendet werden. Die Implementierungsrichtlinie ist zum Starten eines Container-Servers zwar nicht erforderlich, aber empfehlenswert. Die Implementierungsrichtlinie muss mit der verwendeten ObjectGrid-XML-Datei kompatibel sein. Für jedes Element "objectgridDeployment" in der Implementierungsrichtlinie müssen Sie ein entsprechendes Element "objectGrid" in die ObjectGrid-XML-Datei einfügen. Die Maps im objectgridDeployment-Element müssen mit den backingMap-Elementen in der ObjectGrid-XML konsistent sein. Jedes backingMap-Element darf nur in einem einzigen mapSet-Element referenziert werden.

Im folgenden Beispiel soll die Datei companyGridDpReplication.xml mit der entsprechenden Datei companyGrid.xml gepaart werden:
companyGridDpReplication.xml
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org./2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">

	<objectgridDeployment objectgridName="CompanyGrid">
		<mapSet name="mapSet1" numberOfPartitions="11"
			minSyncReplicas="1" maxSyncReplicas="1"
			maxAsyncReplicas="0" numInitialContainers="4">
			<map ref="Customer" />
			<map ref="Item" />
			<map ref="OrderLine" />
			<map ref="Order" />
		</mapSet>
	</objectgridDeployment>

</deploymentPolicy>
companyGrid.xml
<?xml version="1.0" encoding="UTF-8"?>
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
	xmlns="http://ibm.com/ws/objectgrid/config">

	<objectGrids>
<objectGrid name="CompanyGrid">
			<backingMap name="Customer" />
			<backingMap name="Item" />
			<backingMap name="OrderLine" />
			<backingMap name="Order" />
		</objectGrid>
	</objectGrids>

</objectGridConfig>

Die Datei companyGridDpReplication.xml enthält ein mapSet-Element , das in 11 Partitionen eingeteilt ist. Jede Partition muss genau ein synchrones Replikat haben. Die Anzahl der synchronen Replikate wird über die Attribute "minSyncReplicas" und "maxSyncReplicas" festgelegt. Da das Attribut "minSyncReplicas" auf 1 gesetzt ist, muss jede Partition im mapSet-Element mindestens ein verfügbares synchrones Replikat für die Verarbeitung von Schreiboperationen haben. Da das Attribut "maxSyncReplicas" auf 1 gesetzt ist, darf jede Partition maximal ein einziges synchrones Replikat haben. Die Partitionen in diesem mapSet-Element haben keine asynchronen Replikate.

Das Attribut "numInitialContainers" weist den Katalogservice an, die Verteilung zu verzögern, bis vier Container-Server für die Unterstützung dieser ObjectGrid-Instanz verfügbar sind. Das Attribut "numInitialContainers" wird ignoriert, sobald die angegebene Anzahl an Container-Servern erreicht ist.

Sie können auch die Eigenschaft placementDeferralInterval und den Befehl xscmd -c suspendBalancing verwenden, um die Verteilung der Shards auf die Container-Server zu verzögern.

Die Datei companyGridDpReplication.xml ist nur ein Basisbeispiel. Eine Implementierungsrichtlinie bietet Ihnen jedoch die vollständige Kontrolle über Ihre Umgebung.

Verteilte Topologie

Verteilte kohärente Caches bieten eine höhere Leistung, Verfügbarkeit und Skalierbarkeit, die Sie konfigurieren können.

WebSphere eXtreme Scale führt eine automatische gleichmäßige Verteilung der Server durch. Sie können weitere Server hinzufügen, ohne WebSphere eXtreme Scale erneut starten zu müssen. Das Hinzufügen zusätzlicher Server ohne Neustart von eXtreme Scale ermöglicht Ihnen die Verwendung einfacher Implementierungen und Implementierungen in Terabytegröße, in denen Tausende von Servern benötigt werden.

Diese Implementierungstopologie ist flexibel. Mit dem Katalogservice können Sie Server hinzufügen und entfernen, um Ressourcen besser zu nutzen, ohne den gesamten Cache entfernen zu müssen. Sie können die Befehle startOgServer und stopOgServer verwenden, um Container-Server zu starten und zu stoppen. Beide Befehle erfordern die Angabe der Option -catalogServiceEndPoints. Alle Clients der verteilten Topologie kommunizieren mit dem Katalogservice über Internet Interoperability Object Protocol (IIOP). Alle Clients verwenden die Schnittstelle "ObjectGrid", um mit Servern zu kommunizieren.

Mit den dynamischen Konfigurationsfunktionen von WebSphere eXtreme Scale können dem System Ressourcen ohne großen Aufwand hinzugefügt werden. Container enthalten die Daten, und der Katalogservice ermöglicht Clients die Kommunikation mit dem Container-Server-Grid. Der Katalogservice leitet Anforderungen weiter, reserviert Speicherplatz in den Host-Container-Servern und verwaltet den Status und die Verfügbarkeit des Gesamtsystems. Clients stellen eine Verbindung zu einem Katalogservice her, rufen eine Beschreibung der Container-Server-Topologie ab und kommunizieren dann direkt mit jedem Server. Wenn sich die Servertopologie ändert, weil neue Server hinzugefügt werden oder weil Server ausfallen, leitet der Katalogservice Clientanforderungen automatisch an den entsprechenden Server weiter, der die Daten enthält.

Ein Katalogservice existiert gewöhnlich in einem eigenen Grid von Java Virtual Machines. Ein einziger Katalogserver kann mehrere Server verwalten. Sie können einen Container-Server in einer JVM eigenständig starten oder den Container-Server in eine beliebige JVM mit anderen Container-Servern für verschiedene Server laden. Ein Client kann in jeder JVM ausgeführt werden und mit einem oder mehreren Servern kommunizieren. Ein Client kann auch in derselben JVM wie ein Container-Server ausgeführt werden.

Sie können eine Implementierungsrichtlinie auch über das Programm erstellen, wenn Sie einen Container-Server in einen vorhandenen Java-Prozess oder in eine vorhandene Anwendung integrieren. Weitere Informationen finden Sie in der Dokumentation zur API DeploymentPolicy.