Configuration de zones pour le positionnement de fragments réplique

La prise en charge des zones permet la configuration avancée du positionnement de réplique pour plusieurs centres de données. Grâce à cette fonctionnalité, des grilles de milliers de partitions peuvent être facilement gérées à l'aide de plusieurs règles de positionnement facultatives. Un centre de données peut correspondre à plusieurs étages d'un bâtiment, plusieurs bâtiments, plusieurs villes ou d'autres distinctions, selon la configuration des règles de zone.

Flexibilité des zones

Il est possible de placer des fragments dans des zones. Cette fonction permet de mieux contrôler la manière dont eXtreme Scale place les fragments dans une grille. Les machines virtuelles Java qui hébergent un serveur eXtreme Scale peuvent être marquées à l'aide d'un identificateur de zone. Le fichier de déploiement peut désormais inclure une ou plusieurs règles de zone, qui sont associées à un type de fragment. La section suivante présente l'utilisation des zones. Pour plus d'informations, voir Contrôle du placement avec des zones. .

Les zones de positionnement contrôlent la manière dont eXtreme Scale assigne les fragments primaires et les fragments réplique pour configurer les topologies avancées.

Une machine virtuelle Java peut posséder plusieurs conteneurs mais un seul serveur. Un conteneur peut héberger plusieurs fragments d'un seul objet ObjectGrid.

Cette fonctionnalité permet de s'assurer que les fragments réplique et les fragments primaires sont placés dans différents emplacements ou zones et que leur haute disponibilité est optimale. Généralement, eXtreme Scale ne place pas de fragment principal et de fragment réplique dans les machines virtuelles Java possédant une adresse IP identique. Cette règle simple empêche généralement deux serveurs eXtreme Scale d'être placés sur le même ordinateur physique. Toutefois, vous pouvez avoir besoin d'un mécanisme plus flexible. Par exemple, vous souhaitez utiliser deux châssis lame sur lesquels segmentés les fragments primaires et vous voulez que le fragment réplique de chaque fragment primaire soit positionné sur le châssis de l'autre fragment primaire.

Les fragments primaires à bandes désignent les fragments primaires placés dans chaque zone. La réplique de chacun de ces fragments primaires est située dans la zone opposée. Par exemple, le fragment primaire 0 se trouve dans la zone A, et le fragment réplique synchronisé 0 dans la zone B. Le fragment primaire 1 se trouve dans la zone B, et le fragment réplique synchronisé 1 dans la zone A.

Dans ce cas, le nom du châssis correspond à celui de la zone. Vous pouvez également nommer les zones en fonction des étages d'un bâtiment et utiliser les zones pour vous assurer que les fragments primaires et les fragments réplique correspondant aux mêmes données se situent à des étages différents. Vous pouvez également utiliser des bâtiments et des centres de données. Des tests effectués sur les centres de données à l'aide de zones ont permis de s'assurer que les données sont répliquées de manière appropriée entre les centres de données. Si vous utilisez HTTP Session Manager pour eXtreme Scale, vous pouvez également utiliser des zones. Cette fonction vous permet de déployer une seule application Web sur les trois centres de données et de vous assurer que les sessions HTTP des utilisateurs sont répliquées dans les centres de données afin que les sessions puissent être récupérées en cas de défaillance d'un centre de données entier.

WebSphere eXtreme Scale prend en compte la nécessité de gérer une grille volumineuse dans plusieurs centres de données. Il est possible de s'assurer que les sauvegardes et les fragments primaires de la même partition sont situés dans des centres de données différents, le cas échéant. Il permet de placer tous les fragments primaires dans le centre de données 1 et tous les fragments réplique dans le centre de données 2. Il peut également permuter de manière circulaire les fragments primaires et les fragments réplique entre les deux centres de données. Les règles sont flexibles de sorte que de nombreux scénarios sont possibles. eXtreme Scale peut également gérer des milliers de serveurs. Cette fonctionnalité, combinée au positionnement automatique en fonction des centres de données, rend ces grilles volumineuses plus économiques d'un point de vue administratif. Les administrateurs peuvent spécifier ce qu'ils veulent faire de manière simple et efficace.

En tant qu'administrateur, utilisez les zones de positionnement pour définir les emplacements des fragments primaires et des fragments réplique. Vous pouvez ainsi configurer des topologies avancées hautes performances et haute disponibilité. Vous pouvez définir une zone dans tout groupement logique de processus eXtreme Scale, comme indiqué ci-dessus : ces zones peuvent correspondre à des emplacements de stations de travail physiques, tels qu'un centre de données, un étage d'un centre de données ou un châssis lame. Vous pouvez segmenter les données dans les zones, afin de bénéficier d'une disponibilité accrue. Vous pouvez également diviser les fragments primaires et les fragments réplique en zones distinctes si un secours automatique est nécessaire.

Association d'un serveur eXtreme Scale à une zone qui n'utilise pas WebSphere Extended Deployment

Si eXtreme Scale est utilisé avec Java Standard Edition ou un serveur d'application qui n'est pas basé sur WebSphere Extended Deployment version 6.1, il est possible d'associer une JVM utilisée comme conteneur de fragments à une zone, si vous utilisez les méthodes suivantes.

Applications utilisant le script startOgServer

Le script startOgServer permet de démarrer une application eXtreme Scale lorsqu'elle n'est pas en cours d'intégration dans un serveur existant. Le paramètre -zone permet de spécifier la zone à utiliser pour tous les conteneurs du serveur.

Spécification de la zone lors du démarrage d'un conteneur à l'aide d'API

Le nom de zone d'un conteneur peut être spécifié comme décrit dans la documentation de API de serveurs intégrés.

Association de noeuds WebSphere Extended Deployment à des zones

Si vous utilisez eXtreme Scale avec des applications WebSphere Extended Deployment Java EE, vous pouvez utiliser les groupes de noeuds WebSphere Extended Deployment pour placer les serveurs dans des zones spécifiques.

Dans eXtreme Scale, une JVM ne peut être membre que d'une seule zone. Toutefois, WebSphere autorise un noeud à faire partie de plusieurs groupes. Vous pouvez utiliser cette fonctionnalité des zones eXtreme Scale si vous vous assurez que chacun des noeuds se trouve uniquement dans un groupe de noeuds de zone.

Utilisez la syntaxe suivante pour nommer un groupe de noeuds afin de le déclarer en tant que zone : ReplicationZone<UniqueSuffix>. Les serveurs exécutés sur un noeud faisant partie d'un tel groupe sont inclus dans la zone spécifiée par le nom du groupe. Vous trouverez ci-dessous la description d'un exemple de topologie.

Tout d'abord, vous devez configurer quatre noeuds : node1, node2, node3 et node4, chaque noeud possédant deux serveurs. Ensuite, vous créez deux groupes de noeuds que vous nommez ReplicationZoneA et ReplicationZoneB. Vous ajoutez node1 et node2 à ReplicationZoneA , et node3 et node4 à ReplicationZoneB.

Lors du démarrage des serveurs de node1 et node2, ils font partie de ReplicationZoneA. De la même manière, les serveurs de node3 et node4 font partie de ReplicationZoneB.

Une machine virtuelle Java membre de grille vérifie l'appartenance aux zones uniquement lors du démarrage. L'ajout d'un nouveau groupe de noeuds ou la modification de l'appartenance a une incidence uniquement sur les machines virtuelles Java démarrées ou redémarrées.

Règles de zone

Une partition eXtreme Scale possède un fragment primaire et aucune réplique ou plus. Pour cet exemple, considérons les conventions d'attribution de nom suivantes pour les fragments. P est le fragment primaire ; S est une réplique synchrone et A une réplique asynchrone. Une règle de zone comporte trois composants :

  • un nom de règle
  • une liste de zones
  • un indicateur inclusif ou exclusif
Le nom de zone d'un conteneur peut être spécifié comme décrit dans la documentation de API de serveurs intégrés. Une règle de zone spécifie l'ensemble de zones dans lequel un fragment peut être placé. L'indicateur inclusif indique que le positionnement d'un fragment dans une zone de la liste entraîne le positionnement de tous les autres fragments dans la même liste. Un paramètre exclusif indique que chaque fragment d'une partition est placé dans une zone différente de la liste. Par exemple, si vous utilisez un paramètre exclusif et s'il existe trois fragments (un fragment primaire et deux répliques synchrones), la liste doit alors contenir trois zones.

Chaque fragment peut être associé à une règle de zone. Une règle de zone peut être partagée par deux fragments. Lorsqu'une règle est partagée, l'indicateur inclusif ou exclusif s'applique aux fragments de tout type qui partagent une règle unique.

Exemples

Vous trouverez ci-dessous des exemples illustrant les différents scénarios et la configuration de déploiement permettant d'implémenter ces derniers.

Segmentation des fragments primaires et des fragments réplique dans les zones

Vous disposez de trois châssis lame et souhaitez y répartir les fragments primaires, en plaçant une réplique synchrone dans un châssis différent du fragment primaire. Définissez chaque châssis en tant que zone en les nommant ALPHA, BETA et GAMMA. Exemple de syntaxe XML de déploiement :

<?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>

Cette syntaxe de déploiement XML contient une grille appelée "library" (bibliothèque) qui contient une mappe unique appelée "book". Elle utilise quatre partitions avec une seule réplique synchrone. La clause des métadonnées de zone affiche la définition d'une seule règle de zone et l'association des règles de zone à des fragments. Les fragments primaires et synchrones sont associés à la règle de zone "stripeZone". La règle de zone contient les trois zones et utilise le positionnement exclusif. D'après cette règle, si le fragment primaire de la partition 0 est placé dans ALPHA, le fragment réplique de la partition 0 sera placée dans BETA ou dans GAMMA. De la même manière, les fragments primaires des autres partitions sont placés dans d'autres zones que les fragments réplique.

Réplique asynchrone dans une zone différente de celle du fragment primaire et du fragment réplique synchrone

Dans cet exemple, une connexion avec un temps d'attente élevé existe entre deux bâtiments. Vous souhaitez une haute disponibilité sans perte de données pour tous les scénarios. Toutefois, l'incidence de la réplication synchrone sur les performances entre les bâtiments nécessite un compromis. Vous souhaitez un fragment primaire avec une réplique synchrone dans un bâtiment et une réplique asynchrone dans l'autre bâtiment. Généralement, les défaillances qui se produisent sont des arrêts de JVM ou des blocages de l'ordinateur plutôt que des problèmes à grande échelle. Cette topologie permet d'éviter la perte de données en cas de défaillance normale. La perte d'un bâtiment est suffisamment rare pour qu'une perte de données soit acceptable dans ce cas-là. Vous pouvez créer deux zones, une pour chaque bâtiment. Fichier XML de déploiement :

<?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>

Le fragment primaire et le fragment réplique synchrone partagent une règle de zone primaySync avec un paramètre d'indicateur exclusif défini sur "false". Après le positionnement dans une zone du fragment primaire ou de son fragment réplique synchrone, l'autre est placé dans la même zone. La réplique asynchrone utilise une deuxième règle de zone avec les mêmes zones que la règle de zone primarySync mais elle utilise l'attribut exclusivePlacement défini sur "true". L'attribut indique qu'un fragment ne peut être placé dans une zone contenant un fragment issu d'une même partition. Par conséquent, le fragment réplique asynchrone n'est pas placé dans la même zone que le fragment primaire ou les fragments réplique synchrones.

Placement de tous les fragments primaires dans une zone et de tous les fragments réplique dans une autre

Dans ce cas, tous les fragments primaires se trouvent dans une zone spécifique et tous les fragments réplique dans une autre zone. Nous obtenons un fragment primaire et une réplique asynchrone unique. Tous les fragments réplique seront placées dans la zone A et les fragments primaires dans la 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>
Cet exemple contient deux règles, l'une pour les fragments primaires (P), l'autre pour le fragment réplique (A).

Zones correspondant à des réseaux étendus (WAN)

Vous pouvez souhaiter déployer une instance unique de eXtreme Scale dans plusieurs bâtiments ou centres de données où les interconnexions réseau sont plus lentes. La lenteur accrue des connexions réseau entraîne la réduction de la bande passante et l'augmentation des temps d'attente pour les connexions. Dans ce mode, des partitions réseau sont plus susceptibles de se produire en raison de la congestion du réseau et d'autres facteurs. eXtreme Scale aborde cet environnement difficile de deux manières.

Signal de présence limité entre les zones

Les machines virtuelles Java assemblées en groupes centraux assurent le signal de présence entre elles. Lorsque le service de catalogue organise les machines virtuelles Java en groupes, ces derniers ne s'étendent pas aux zones. Dans ce groupe, un leader transmet les informations d'appartenance au service de catalogue. Ce dernier vérifie les défaillances signalées avant d'entreprendre une action. Pour ce faire, il tente de se connecter aux machines virtuelles Java suspectes. Si le catalogue trouve une fausse détection de défaillance, il n'entreprend pas d'action car la partition de groupe central fonctionnera à nouveau correctement après un court délai.

Le service de catalogue assurera régulièrement le signal de présence des leaders du groupe central à un rythme lent afin de gérer l'isolement du groupe central.