Zonen für die Verteilung von Replikaten konfigurieren

Die Zonenunterstützung ermöglicht fortgeschrittene Konfigurationen für die Verteilung von Replikaten auf Rechenzentren. Mit dieser Funktionalität können Grid mit Tausenden von Partitionen ohne großen Aufwand mit einer Handvoll optionaler Verteilungsregeln verwaltet werden. Ein Rechenzentrum kann auf verschiedene Stockwerke eines Gebäudes, verschiedene Gebäude oder selbst verschiedene Städte verteilt sein. Die Unterscheidungsmerkmale werden über Zonenregeln konfiguriert.

Flexibilität von Zonen

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 Zonen-ID gekennzeichnet werden. Die Implementierungsdatei kann jetzt eine oder mehrere Zonenregeln enthalten, und diese Zonenregeln werden einem Shard-Typ zugeordnet. Der folgende Abschnitt enthält eine Übersicht über die Zonennutzung. Weitere Einzelheiten finden Sie im Abschnitt Shardverteilung mit Zonen steuern. .

Verteilungszonen steuern, wie eXtreme Scale primäre Shards und Replikate zuordnet, um erweiterte Topologie zu konfigurieren.

Eine Java Virtual Machine kann mehrere Container, aber nur einen einzigen Server haben. Ein Container kann mehrere Shards aus einem einzigen ObjectGrid enthalten.

Diese Funktionalität ist hilfreich, um sicherzustellen, dass Replikate und primäre Shards für eine höhere Verfügbarkeit auf unterschiedliche Positionen oder Zonen verteilt werden. Normalerweise verteilt eXtreme Scale ein primäres Shard und ein Replikat-Shard nicht an Java Virtual Machines mit derselben IP-Adresse. Diese einfache Regel verhindert gewöhnlich, dass zwei eXtreme-Scale-Server auf demselben physischen Computer platziert werden. Möglicherweise benötigen Sie jedoch einen flexibleren Mechanismus. Sie verwenden beispielsweise zwei Blade-Gehäuse und möchten, das die primären Shards einheitenübergreifend auf beide Gehäuse verteilt werden und dass das Replikat jedes primären Shards nicht in demselben Gehäuse platziert wird wie das zugehörige primäre Shard.

Einheitenübergreifend verteilen bedeutet, dass die primären Shards in jeweils einer Zone und die zugehörigen Replikate in der jeweils anderen Zone platziert werden. Das primäre Shard 0 wird beispielsweise in Zone A und das synchrone Replikat 0 in Zone B platziert. Das primäre Shard 1 wird in Zone B und das synchrone Replikat 1 wird in Zone A platziert.

Der Gehäusename ist in diesem Fall der Zonenname. Alternativ können Sie Zonen nach den Stockwerken in einem Gebäude benennen und Zonen verwenden, um sicherzustellen, dass primäre Shards und Replikate derselben Daten auf unterschiedlichen Stockwerken gespeichert werden. Gebäude und Rechenzentren können ebenfalls verwendet werden. Es wurden Tests mit Zonen in Rechenzentren durchgeführt, um sicherzustellen, dass die Daten ordnungsgemäß zwischen den Rechenzentren repliziert werden. Wenn Sie den HTTP-Sitzungsmanager für eXtreme Scale verwenden, können Sie ebenfalls Zonen verwenden. Mit diesem Feature können Sie eine einzelne Webanwendung auf drei Rechenzentren verteilen und sicherstellen, dass HTTP-Sitzungen für Benutzer in den Rechenzentren repliziert werden, so dass die Sitzungen wiederhergestellt werden können, falls ein komplettes Rechenzentrum ausfällt.

WebSphere eXtreme Scale kennt den Bedarf, ein großes Grid über mehrere Datenzentren hinweg zu verwalten. Das Produkt kann sicherstellen, dass Sicherungen und primäre Shards für dieselbe Partition bei Bedarf auf unterschiedliche Rechenzentren verteilt werden. Es kann alle primären Shards im Rechenzentrum 1 platzieren und alle Replikate im Rechenzentrum 2, oder es kann die primären Shards und Replikate im Umlaufverfahren auf beide Datenzentren verteilen. Die Regeln sind so flexibel, dass zahlreiche Szenarien möglich sind. eXtreme Scale kann auch Tausende von Servern verwalten. Diese Funktionalität, kombiniert mit der vollständig automatischen Verteilung unter Berücksichtigung von Rechenzentren macht solch große Grids aus Verwaltungssicht kosteneffizient. Administratoren können ohne großen Aufwand und effizient festlegen, was sie möchten.

Als Administrator verwenden Sie Verteilungszonen, um zu steuern, wo primäre Shards und Replikat-Shards platziert werden. Auf diese Weise können fortgeschrittene Topologien mit hoher Leistung und hoher Verfügbarkeit konfiguriert werden. Wie bereits erwähnt, können Sie eine Zone für jede logische Gruppierung von eXtreme-Scale-Prozessen definieren. Diese Zonen können physischen Workstationstandorten wie Rechenzentren, Stockwerken eines Rechenzentrums oder Blade-Gehäusen entsprechen. Sie können Daten einheitenübergreifend auf Zonen verteilen, was Ihnen eine höhere Verfügbarkeit bietet, oder Sie können die primären Shards und Replikate auf verschiedene Zonen aufteilen, wenn ein fehlertoleranter Modus erforderlich ist.

eXtreme-Scale-Server einer Zone zuordnen, die nicht WebSphere Extended Deployment verwendet

Wenn eXtreme Scale mit Java Standard Edition oder einem Anwendungsserver verwendet wird, der nicht auf WebSphere Extended Deployment Version 6.1 basiert, kann eine JVM, die ein Shard-Container ist, mit den folgenden Verfahren einer Zone zugeordnet werden.

Anwendungen, die das Script "startOgServer" verwenden

Das Script "startOgServer" wird verwendet, um eine eXtreme-Scale-Anwendung zu starten, wenn diese nicht in einen vorhandenen Server integriert ist. Mit dem Parameter -zone wird die Zone angegeben, die für alle Container im Server verwendet werden soll.

Zone beim Starten eines Containers über APIs angeben

Der Zonenname für einen Container kann gemäß der Beschreibung in der Dokumentation für Integrierte Server-API angegeben werden.

Knoten von WebSphere Extended Deployment Zonen zuordnen

Wenn Sie eXtreme Scale mit Java EE-Anwendungen von WebSphere Extended Deployment verwenden, können Sie die Knotengruppen von WebSphere Extended Deployment nutzen, um Server auf bestimmte Zonen zu verteilen.

In eXtreme Scale kann eine JVM nur zu einer einzigen Zone gehören. WebSphere lässt jedoch die Zugehörigkeit eines Knotens zu mehreren Knotengruppen zu. Sie können die Funktionalität von eXtreme-Scale-Zonen verwenden, wenn Sie sicherstellen, dass jeder Ihrer Knoten nur zu einer einzigen Zonenknotengruppe gehört.

Mit der folgenden Syntax können Sie Ihre Knotengruppe benennen, um sie als Zone zu deklarieren: Replikationszone<eindeutiges_Suffix>. Server, die auf einem Knoten ausgeführt werden, der zu einer solchen Knotengruppe gehört, werden in die Zone eingeschlossen, die über den Namen der Knotengruppe angegeben wird. Im Folgenden finden Sie eine Beschreibung einer Beispieltopologie.

Zuerst konfigurieren Sie vier Knoten, Knoten1, Knoten2, Knoten2 und Knoten4, mit jeweils zwei Servern. Anschließend erstellen Sie eine Knotengruppe mit dem Namen "ReplikationszoneA" und eine Knotengruppe mit dem Namen "ReplikationszoneB". Danach fügen Sie Knoten1 und Knoten2 der ReplikationszoneA und Knoten3 und Knoten4 der ReplikationszoneB hinzu.

Wenn die Server auf Knoten1 und Knoten2 gestartet werden, werden sie der ReplikationszoneA zugeordnet. Knoten3 und Knoten4 werden beim Starten der ReplikationszoneB zugeordnet.

Eine Grid-Member-JVM überprüft die Zonenzugehörigkeit nur beim Start. Das Hinzufügen einer neuen Knotengruppe und das Ändern der Zugehörigkeit haben nur Auswirkungen auf neu gestartete bzw. erneut gestartete JVMs.

Zonenregeln

Eine eXtreme-Scale-Partition hat ein einziges primäres Shard und kein oder mehrere Replikat-Shards. In diesem Beispiel wird die folgende Namenskonvention für diese Shards verwendet: P ist das primäre Shard, S ist ein synchrones Replikat und A ein asynchrones Replikat. Eine Zonenregeln besteht aus drei Komponenten:

  • Regelname,
  • Zonenliste,
  • Attribut inclusive oder exclusive.
Der Zonenname für einen Container kann gemäß der Beschreibung in der Dokumentation für Integrierte Server-API angegeben werden. Eine Zonenregel gibt die gültige Gruppe von Zonen an, an die ein Shard verteilt werden kann. Das Attribut "inclusive" zeigt an, dass nach der Verteilung eines Shards an eine Zone aus der Liste alle anderen Shards ebenfalls an diese Zone verteilt werden. Die Einstellung "exclusive" zeigt an, dass jedes Shard für eine Partition an eine jeweils andere Zone aus der Zonenliste verteilt wird. Die Verwendung der Einstellung "exclusive" bedeutet beispielsweise, dass die Zonenliste bei drei Shards (primäres Shard und zwei synchrone Replikate) drei Zonen enthalten muss.

Jedem Shard kann eine einzige Zonenregel zugeordnet werden. Eine Zonenregel kann von zwei Shards gemeinsam verwendet werden. Wenn eine Regel gemeinsam genutzt wird, gilt das Attribut "inclusive" bzw. "exclusive" für die Shards aller Typen, die eine Regel gemeinsam nutzen.

Beispiele

Es folgen diverse Beispiele, die verschiedene Szenarien und die entsprechende Konfiguration für die Implementierung des jeweiligen Szenarios veranschaulichen.

Primäre Shards und Replikate einheitenübergreifend auf Zonen verteilen

Sie haben drei Blade-Gehäuse und möchten, dass die primären Shards auf alle drei Gehäuse verteilt werden und dass jeweils ein einziges Replikat auf einem jeweils anderen Gehäuse als das zugehörige primäre Shard platziert wird. Definieren Sie jedes Gehäuse als Zone mit den Gehäusenamen ALPHA, BETA und GAMMA. Im Folgenden sehen Sie die zugehörige Implementierungs-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="library">
			<mapSet name="ms1" numberOfPartitions="37" minSyncReplicas="1"
maxSyncReplicas="1" maxAsyncReplicas="0">
			<map ref="book" />
			<zoneMetadata>
				<shardMapping shard="P" zoneRuleRef="stripeZone"/>
				<shardMapping shard="S" zoneRuleRef="stripeZone"/>
				<zoneRule name ="stripeZone" exclusivePlacement="true" >
					<zone name="ALPHA" />
					<zone name="BETA" />
					<zone name="GAMMA" />
				</zoneRule>
			</zoneMetadata>
		</mapSet>
	</objectgridDeployment>
</deploymentPolicy>

Diese Implementierungs-XML enthält ein Grid mit dem Namen "library" mit einer einzigen Map mit dem Namen "book". Es werden vier Partitionen mit einem einzigen synchronen Replikat verwendet. Die Klausel für die Zonenmetadaten zeigt die Definition einer einzigen Zonenregel und die Zuordnung von Zonenregeln zu Shards. Die primären und synchronen Shards werden der Zonenregel "stripeZone" zugeordnet. Die Zonenregel umfasst alle drei Zonen und verwendet eine exklusive Verteilung. Diese Regel bedeutet Folgendes: Wenn das primäre Shard für die Partition 0 in Zone ALPHA platziert wird, dann wird das Replikat für die Partition 0 in Zone BETA oder GAMMA platziert. Die primären Shards für andere Partitionen werden in anderen Zonen platziert und die zugehörigen Replikate dann in einer jeweils anderen als das entsprechende primäre Shard.

Asynchrones Replikat in einer anderen Zone als das primäre Shard und das synchrone Replikat

In diesem Beispiel gibt es zwei Gebäude, die über eine Verbindung mit hoher Latenzzeit miteinander verbunden sind. In allen Szenarien möchten Sie eine hohe Verfügbarkeit, um einen Datenverlust zu vermeiden. Der Einfluss der synchronen Replikation zwischen den Gebäuden auf die Leistung drängt Sie jedoch zu einem Kompromiss. Sie möchten ein primäres Shard mit einem synchronen Replikat in einem Gebäude und ein asynchrones Replikat in einem anderen Gebäude. Normalerweise sind Ausfälle auf JVM-Abstürze oder Computerausfälle und nicht auf Probleme mit der Größe zurückzuführen. Mit dieser Topologie können Sie normale Ausfälle ohne Datenverlust bewältigen. Der Verlust eines Gebäudes tritt so selten auf, dass in diesem Fall ein gewisser Datenverlust akzeptabel ist. Sie können zwei Zonen erstellen, eine für jedes Gebäude. Im Folgenden sehen Sie die zugehörige XML-Implementierungsdatei:

<?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="library">
		<mapSet name="ms1" numberOfPartitions="13" minSyncReplicas="1"
			maxSyncReplicas="1" maxAsyncReplicas="1">
			<map ref="book" />
			<zoneMetadata>
				<shardMapping shard="P" zoneRuleRef="primarySync"/>
				<shardMapping shard="S" zoneRuleRef="primarySync"/>
				<shardMapping shard="A" zoneRuleRef="aysnc"/>
				<zoneRule name ="primarySync" exclusivePlacement="false" >
						<zone name="BldA" />
						<zone name="BldB" />
				</zoneRule>
				<zoneRule name="aysnc" exclusivePlacement="true">
						<zone name="BldA" />
						<zone name="BldB" />
				</zoneRule>
			</zoneMetadata>
		</mapSet>
	</objectgridDeployment>
</deploymentPolicy>

Das primäre Shard und das synchrone Replikat-Shard verwenden beide die Zonenregel "primaySync" mit der Einstellung "false" für das Attribut "exclusive". Wenn das primäre Shard oder das synchrone Replikat in einer Zone platziert wird, wird deshalb das jeweils andere Shard in derselben Zone platziert. Das asynchrone Replikat verwendet eine zweite Zonenregel mit denselben Zonen wie die Zonenregel "primarySync", verwendet aber die Einstellung "true" für das Attribut exclusivePlacement. Dieses Attribut gibt an, dass ein Shard nicht zusammen mit einem anderen Shard aus derselben Partition in einer Zone platziert werden kann. Deshalb wird das asynchrone Replikat nicht in derselben Zone platziert wie das primäre Shard bzw. das synchrone Replikat.

Alle primären Shards an eine Zone und alle Replikate an eine andere Zone verteilen

In diesem Szenario befinden sich alle primären Shards in einer bestimmten Zone und alle Replikate in einer anderen Zone. Es gibt ein primäres Shard und ein einziges asynchrones Replikat. Alle Replikate befinden sich in Zone A und alle primären Shards in Zone B.

<?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="library">
			<mapSet name="ms1" numberOfPartitions="13" minSyncReplicas="0"
				maxSyncReplicas="0" maxAsyncReplicas="1">
				<map ref="book" />
				<zoneMetadata>
					<shardMapping shard="P" zoneRuleRef="primaryRule"/>
					<shardMapping shard="A" zoneRuleRef="replicaRule"/>
					<zoneRule name ="primaryRule">
						<zone name="A" />
					</zoneRule>
					<zoneRule name="replicaRule">
						<zone name="B" />
							</zoneRule>
						</zoneMetadata>
					</mapSet>
			</objectgridDeployment>
	</deploymentPolicy>
In diesem Beispiel sehen Sie zwei Regeln, eine für die primären Shards (P) und eine andere für die Replikate (A).

Zonen über Weitverkehrsnetze (WANs)

Sie können eine einzige Instanz von eXtreme Scale über mehrere Gebäude oder Rechenzentren hinweg mit langsameren Netzverbindungen untereinander implementieren. Langsamere Netzverbindungen führen zu einer geringeren Bandbreite und zu einer höheren Latenzzeit. Das Risiko von Netzpartitionen ist in diesem Modus aufgrund der Netzüberlastung und anderen Faktoren ebenfalls erhöht. eXtreme Scale nähert sich diesen ungeeigneten Umgebungsbedingungen auf die folgenden Arten.

Begrenzter Austausch von Überwachungssignalen zwischen Zonen

Java Virtual Machines, die in Stammgruppen zusammengefasst sind, tauschen Überwachungssignale miteinander aus. Wenn der Katalogservice die Java Virtual Machines in Gruppen organisiert, können sich diese Gruppen nicht über mehrere Zonen erstrecken. Ein führendes Member dieser Gruppe überträgt die Zugehörigkeitsdaten mit Push an den Katalogservice. Der Katalogservice prüft alle gemeldeten Fehler, bevor er Maßnahmen ergreift. Dazu versucht er, eine Verbindung zu den fehlerverdächtigen Java Virtual Machines herzustellen. Wenn der Katalogservice eine falsche Fehlererkennung feststellt, ergreift er keine Maßnahmen, da die Stammgruppenpartition in kurzer Zeit wiederhergestellt ist.

Außerdem sendet der Katalogservice in regelmäßigen Abständen Überwachungssignale an das führende Member jeder Stammgruppe, um Fälle von Stammgruppenisolation zu behandeln.