XML-Deskriptordatei für Implementierungsrichtlinie

Zum Konfigurieren einer Implementierungsrichtlinie verwenden Sie eine XML-Deskriptordatei für die Implementierungsrichtlinie.

In den folgenden Abschnitten finden Sie Definitionen der Elemente und Attribute in der XML-Deskriptordatei für Implementierungsrichtlinien. Das entsprechende XML-Schema für die Implementierungsrichtlinie finden Sie unter Datei deploymentPolicy.xsd.

Elemente in der Datei "deploymentPolicy.xml"
(1) <deploymentPolicy>
(2)		<objectgridDeployment objectGridName="blah">
(3)			<mapSet
(4)				name="mapSetName"
(5)				numberOfPartitions="numberOfPartitions"
(6)				minSyncReplicas="minimumNumber"
(7) 				maxSyncReplicas="maximumNumber"
(8)				maxAsyncReplicas="maximumNumber"
(9)				replicaReadEnabled="true|false"
(10)				numInitialContainers="numberOfInitialContainersBeforePlacement"
(11)				autoReplaceLostShards="true|false"
(12)				developmentMode="true|false"
(13)				placementStrategy="FIXED_PARTITION|PER_CONTAINER">
(14)				<map ref="backingMapReference" />
(15)
(16)			<zoneMetadata>
(17)				<shardMapping
(18)								shard="shardType"
(19)						zoneRuleRef="zoneRuleRefName" />
(20)				<zoneRule 
(21)						name="zoneRuleName"
(22)						exclusivePlacement="true|false" >
(23)						<zone name="ALPHA" />
(24)						<zone name="BETA" />
(25)						<zone name="GAMMA" />
(26)				</zoneRule>
(27)			</zoneMetadata>
(28)	 		</mapSet>
(29)		</objectgridDeployment>
(30)	</deploymentPolicy>

Element "deploymentPolicy" (Zeile 1)

Das Element "deploymentPolicy" ist das Ausgangselement der XML-Datei für Implementierungsrichtlinien. Dieses Element konfiguriert den Namespace der Datei und die Schemaposition. Das Schema wird in der Datei deploymentPolicy.xsd definiert.

Element "objectgridDeployment" (Zeile 2)

Das Element "objectgridDeployment" wird verwendet, um eine ObjectGrid-Instanz aus der ObjectGrid-XML-Datei zu referenzieren. Im Element "objectgridDeployment" können Sie Ihre Maps in MapSets unterteilen.
Attribute
objectgridName
Gibt den Namen der zu implementierenden ObjectGrid-Instanz an. Dieses Attribut referenziert ein objectGrid-Element, das in der ObjectGrid-XML-Datei definiert ist. (Erforderlich)
Das Attribut "objectgridName" ist beispielsweise mit CompanyGrid in der Datei "companyGridDpReplication.xml" definiert. Das Attribut "objectgridName" referenziert das CompanyGrid, das in der Datei "companyGrid.xml" definiert ist. Lesen Sie die Informationen zur ObjectGrid-XML-Deskriptordatei, die Sie mit der Datei für Implementierungsrichtlinien für jede ObjectGrid-Instanz koppeln müssen.

Element "mapSet" (Zeile 3)

Das Element "mapSet" wird verwendet, um Maps zu gruppieren. Die Maps in einem Element "mapSet" werden ähnlich partitioniert und repliziert. Jede Map darf nur zu einem einzigen Element "mapSet" gehören.
Attribute
name
Gibt den Namen des MapSets an. Dieses Attribut muss innerhalb des Elements "objectgridDeployment" eindeutig sein. (Erforderlich)
numberOfPartitions
Gibt die Anzahl der Partitionen für das Element "mapSet" an. Der Standardwert ist 1. Die Anzahl muss für die Anzahl der Container-Server, in denen die Partitionen enthalten sind, angemessen sein. (Optional)
minSyncReplicas
Gibt die Mindestanzahl synchroner Replikate für jede Partition im MapSet an. Der Standardwert ist 1. Es werden erst Shards verteilt, wenn die Domäne die Mindestanzahl synchroner Replikate unterstützen kann. Für die Unterstützung des minSyncReplicas-Werts benötigen Sie einen Container-Server mehr, als der minSyncReplicas-Wert angibt. Wenn die Anzahl synchroner Replikate unter den Wert von minSyncReplicas fällt, werden keine Schreiboperationen für diese Partition mehr zugelassen. (Optional)
maxSyncReplicas
Gibt die maximale Anzahl synchroner Replikate für jede Partition im MapSet an. Der Standardwert ist 0. Es werden keine weiteren synchronen Replikate für eine Partition verteilt, wenn eine Domäne diese Anzahl synchroner Replikate für diese bestimmte Partition erreicht. Das Hinzufügen von Container-Servern, die dieses ObjectGrid unterstützen, kann zu einer höheren Anzahl synchroner Replikate führen, wenn der Wert von maxSyncReplicas noch nicht erreicht ist. (Optional)
maxAsyncReplicas
Gibt die maximale Anzahl asynchroner Replikate für jede Partition im MapSet an. Der Standardwert ist 0. Nachdem das primäre Shard und alle synchronen Replikate für eine Partition verteilt wurden, werden asynchrone Replikate verteilt, bis der Wert von maxAsyncReplicas erreicht ist. (Optional)
replicaReadEnabled
Wenn Sie dieses Attribut auf true setzen, werden Leseanforderungen an die primären Shards und die Replikate einer Partition verteilt. Wenn Sie das Attribut "replicaReadEnabled" auf false setzen, werden Leseanforderungen nur an das primäre Shard weitergeleitet. Der Standardwert ist "false". (Optional)
numInitialContainers
Gibt die Anzahl der Container-Server an, die erforderlich sind, bevor eine Erstverteilung für die Shards in diesem mapSet-Element vorgenommen wird. Der Standardwert ist 1. Mit diesem Attribut kann Verarbeitungszeit und Netzbandbreite eingespart werden, wenn eine ObjectGrid-Instanz über einen Kaltstart online gebracht wird. (Optional)
Sie können auch die Eigenschaft placementDeferralInterval und den Befehl xscmd -c suspendBalancing verwenden, um die Erstverteilung der Shards auf die Container-Server zu verzögern.
Beim Starten eines Container-Servers sendet ein Ereignis an den Katalogservice. Sobald die Anzahl aktiver Container-Server dem numInitialContainers-Wert für ein mapSet-Element entspricht, verteilt der Katalogservice die Shards aus dem MapSet, sofern der minSyncReplicas-Wert ebenfalls erreicht ist. Wenn der numInitialContainers-Wert erreicht ist, kann jedes Ereignis des Typs "Container-Server-Start" eine Neuverteilung noch nicht verteilter und bereits verteilter Shards auslösen. Wenn Sie in etwa wissen, wie viele Container-Server für dieses mapSet-Element gestartet werden, können Sie für numInitialContainers einen Wert festlegen, der dieser Zahl nahe kommt, um eine Neuverteilung nach jedem Containerstart zu vermeiden. Die Verteilung findet nur statt, wenn der im mapSet-Element angegebene numInitialContainers-Wert erreicht wird.

Wenn der Wert von numInitialContainers beim Durchführen von Wartungsarbeiten an Servern überschrieben werden muss, die Verteilung der Shards aber fortgesetzt werden soll, können Sie den Befehl xscmd -c triggerPlacement verwenden. Diese Überschreibung ist temporär und wird angewendet, wenn Sie den Befehl ausführen. Nach der Ausführung des Befehls wird bei allen nachfolgenden Verteilungsläufen der numInitialContainers-Wert verwendet.

autoReplaceLostShards
Gibt an, ob verloren gegangene Shards an andere Container-Server verteilt werden. Der Standardwert ist true. Wenn ein Container-Server gestoppt wird oder ausfällt, gehen die Shards, die im Container-Server ausgeführt werden, verloren. Wenn ein primäres Shard verloren geht, wird eines seiner Replikat-Shards als primäres Shard für die entsprechende Partition hochgestuft. Aufgrund dieser Hochstufung geht eines der Replikate verloren. Wenn verloren gegangene Shards nicht automatisch ersetzt werden sollen, setzen Sie das Attribut "autoReplaceLostShards" auf false. Diese Einstellung hat keine Auswirkung auf die Hochstufungskette, sondern nur auf die Neuverteilung des letzten Shards in der Kette. (Optional)
developmentMode
Mit diesem Attribut können Sie die Verteilung eines Shards in Relation zu dessen Peer-Shards beeinflussen. Der Standardwert ist "true". Wenn Sie das Attribut "developmentMode" auf false setzen, werden nie zwei Shards derselben Partition an dieselbe Maschine verteilt. Denn Sie das Attribut "developmentMode" auf true setzen, können Shards derselben Partition an dieselbe Maschine verteilt werden. Für beide Fälle gilt jedoch, dass zwei Shards derselben Partition nie an denselben Container-Server verteilt werden. (Optional)
placementStrategy
Es gibt zwei Verteilungsstrategien. Die Standardstrategie ist FIXED_PARTITION. Bei dieser Strategie entspricht die Anzahl primärer Shards, die auf verfügbare Container-Server verteilt wird, der Summe aus Anzahl definierter Partionen und Anzahl der Replikate. Die alternativ Strategie ist PER_CONTAINER. Bei dieser Strategie entspricht die Anzahl primärer Shards, die auf jeden Container-Server verteilt wird, der Anzahl der definierten Partitionen mit einer entsprechenden Anzahl an Replikaten, die auf andere Container-Server verteilt werden. (Optional)

Element "map" (Zeile 14)

Jedes Element "map" in einem Element "mapSet" referenziert eines der backingMap-Elemente, die in der entsprechenden ObjectGrid-XML-Datei definiert sind. Jede Map in einer verteilten Instanz von eXtreme Scale kann nur zu einem einzigen Element "mapSet" gehören.
Attribute
ref
Das Attribut enthält eine Referenz auf ein backingMap-Element in der ObjectGrid-XML-Datei. Jede Map in einem mapSet-Element muss auf ein backingMap-Element aus der ObjectGrid-XML-Datei verweisen. Der Wert des Attributs "ref" muss dem Attribut "name" eines der backingMap-Elemente in der ObjectGrid-XML-Datei entsprechen, wie im folgenden Code-Snippet gezeigt. (Erforderlich)

Element "zoneMetadata" (Zeile 16)

Sie können Shards auf Zonen verteilen. Diese Funktion gibt Ihnen mehr Kontrolle darüber, wie eXtreme Scale Shards in einem Grid verteilt. Java™ Virtual Machines, die einen eXtreme-Scale-Server enthalten, können mit einer Zonenkennung gekennzeichnet werden. Die Implementierungsdatei kann eine oder mehrere Zonenregeln enthalten, und diese Zonenregeln werden einem Shard-Typ zugeordnet. Das Element "zoneMetadata" ist ein "Behälter" für Zonenkonfigurationselemente. Mit dem Element "zoneMetadata" können Sie Zonen definieren und das Verhalten der Shard-Verteilung beeinflussen.

Weitere Hintergrundinformationen finden Sie unter Zonen für die Verteilung von Replikaten konfigurieren.

Attribute: Keine

Element "shardMapping" (Zeile 17)

Das Element "shardMapping" wird verwendet, um einer Zonenregel einen Shard-Typ zuzuordnen. Die Verteilung der Shards wird durch die Zonenregelzuordnung beeinflusst.
Attribute
shard
Geben Sie den Namen eines Shards an, dem die Zonenregel zugeordnet werden soll. (Erforderlich)
zoneRuleRef
Geben Sie den Namen einer Zonenregel an, die dem Shard zugeordnet werden soll. (Optional)

Element "zoneRule" (Zeile 20)

Eine Zonenregel gibt die gültige Gruppe von Zonen an, an die ein Shard verteilt werden kann. Das Element "zoneRule" wird verwendet, um eine Gruppe von Zonen anzugeben, auf die eine Gruppe von Shard-Typen verteilt werden kann. Eine Zonenregel kann auch verwendet werden, um mit dem Attribut "exclusivePlacement" festzulegen, wie Shards in den Zonen gruppiert werden.
Attribute
name
Geben Sie den Namen der zuvor definierten Zonenregel als zoneRuleRef in einem Element "shardMapping" an. (Erforderlich)
exclusivePlacement
Die Einstellung "exclusive" zeigt an, dass jeder Shard-Typ, der dieser Zonenregel zugeordnet wird, an eine andere Zone in der Zonenliste verteilt wird. Die Einstellung "inclusive" zeigt an, dass nach der Verteilung eines Shards an eine Zone aus der Liste die andere Shard-Typen, die dieser Zonenregel zugeordnet sind, ebenfalls an diese Zone verteilt werden. Wenn Sie die Einstellung "exclusive" verwenden und drei Shards existieren, die derselben Zonenregel zugeordnet sind (primäres Shard und zwei synchrone Replikate), sind mindestens drei Zonen erforderlich, damit alle anderen Shards verteilt werden können. (Optional)

Element "zone" (Zeilen 23 bis 25)

Das Element "zone" wird verwendet, um eine Zone in einer Zonenregel zu benennen. Jede benannte Zone muss einer Zone entsprechen, die zum Starten von Servern verwendet wird.

Beispiel

Im folgenden Beispiel wird das Element "mapSet" verwendet, um eine Implementierungsrichtlinie zu konfigurieren. Der Wert wird auf mapSet1 gesetzt und in 10 Partitionen eingeteilt. Jede dieser Partitionen muss mindestens ein verfügbares synchrones Replikat und darf nicht mehr als zwei synchrone Replikate haben. Außerdem hat jede Partition ein asynchrones Replikat, wenn dies von der Umgebung unterstützt werden kann. Alle synchronen Replikate werden vor den asynchronen Replikaten verteilt. Der Katalogservice versucht auch erst dann, die Shards für das Element "mapSet1" zu verteilen, wenn die Domäne in der Lage ist, den minSyncReplicas-Wert zu unterstützen. Für die Unterstützung des minSyncReplicas-Werts sind mindestens zwei Container-Server erforderlich: einer für das primäre Shard und zwei für das synchrone Replikat:
<?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="10"
			minSyncReplicas="1" maxSyncReplicas="2"	maxAsyncReplicas="1"
		 	numInitialContainers="10" autoReplaceLostShards="true"
			developmentMode="false" replicaReadEnabled="true">
			<map ref="Customer"/>
			<map ref="Item"/>
			<map ref="OrderLine"/>
			<map ref="Order"/>
		</mapSet>
	</objectgridDeployment>

</deploymentPolicy>
Obwohl nur zwei Container-Container erforderlich sind, um die Replikationseinstellungen zu erfüllen, erfordert das Attribut "numInitialContainers" 10 verfügbare Container-Server, bevor der Katalogservice versucht, Shards aus diesem mapSet-Element zu verteilen. Sobald die Domäne 10 Container-Server hat, die das ObjectGrid "CompanyGrid" unterstützen können, werden alle Shards in Element "mapSet1" verteilt.

Da das Attribut "autoReplaceLostShards" auf "true" gesetzt ist, werden alle Shards in diesem mapSet-Element, die aufgrund eines Container-Server-Ausfalls verloren gegangen sind, automatisch in anderen Container-Servern ersetzt, sofern ein Container-Server verfügbar ist, der das verloren gegangene Shard aufnehmen kann. Shards derselben Partition können für das Element "mapSet1" nicht an dieselbe Maschine verteilt werden, weil das Attribut "developmentMode" auf false gesetzt ist. Reine Leseanforderungen werden auf das primäre Shard und dessen Replikate jeder Partition verteilt, weil "replicaReadEnabled" den Wert true hat.

Die Datei "companyGridDpMapSetAttr.xml" verwendet das Attribut "ref" in der Map, um auf die backingMap-Elemente aus der Datei "companyGrid.xml" zu verweisen.

Beispiele mit Zonenkonfigurationen finden Sie unter Routing an bevorzugte Zonen.