Utilisez le fichier XML descripteur de la stratégie de déploiement et le fichier XML descripteur d'ObjectGrid pour gérer votre topologie.
Les informations sur les points de contact ne sont pas préconfigurées dans l'environnement dynamique. La règle de déploiement ne contient pas de noms de serveur ou d'informations sur la topologie physique. Tous les fragments dans une grille de données sont placés automatiquement dans les serveurs de conteneur par le service de catalogue. Ce dernier utilise les contraintes définies par la règle de déploiement pour gérer automatiquement le positionnement des fragments. Ce placement automatique des fragments facilite la configuration des grilles de données volumineuses. Vous pouvez également ajouter des serveurs à votre environnement, si nécessaire.
Un fichier XML descripteur de stratégie de déploiement est transmis au serveur de conteneur lors du démarrage. Une règle de déploiement doit être utilisée avec un fichier XML d'ObjectGrid. La stratégie de déploiement n'est pas nécessaire pour démarrer un serveur de conteneur, mais elle est recommandée. La règle de déploiement doit être compatible avec le fichier XML d'ObjectGrid qui lui est associé. Pour chaque élément objectgridDeployment de la règle de déploiement, vous devez inclure un élément objectGrid correspondant dans votre fichier XML d'ObjectGrid. Les mappes de l'élément objectgridDeployment doivent être cohérentes avec les éléments backingMap du XML d'ObjectGrid. Chaque mappe de sauvegarde backingMap doit être référencée sans un seul élément mapSet.
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>
Le fichier companyGridDpReplication.xml contient un élément mapSet divisé en 11 partitions. Chaque partition doit posséder exactement une réplique synchrone. Le nombre de fragments réplique synchrones est spécifié par les attributs minSyncReplicas et maxSyncReplicas. L'attribut minSyncReplicas ayant la valeur 1, chaque partition de l'élément mapSet doit disposer d'au moins une réplique synchrone disponible pour traiter les transactions d'écriture. Etant donné que l'attribut maxSyncReplicas a la valeur 1, chaque partition ne peut dépasser une réplique synchrone. Les partitions de cet élément mapSet ne possèdent pas de fragments réplique asynchrones.
L'attribut numInitialContainers indique au service de catalogue de retarder le placement jusqu'à ce que quatre serveurs soient disponibles pour prendre en charge cette instance ObjectGrid. L'attribut numInitialContainers est ignoré lorsque le nombre de serveurs de conteneur est atteint.
Vous pouvez également utiliser la propriété placementDeferralInterval et la commande xscmd -c suspendBalancing pour retarder le placement des fragments sur les serveurs de conteneur.
Bien que le fichier companyGridDpReplication.xml soit un exemple simple, une règle de déploiement peut vous permettre de contrôler intégralement votre environnement.
WebSphere eXtreme Scale équilibre automatiquement les serveurs. Vous pouvez inclure des serveurs supplémentaires sans redémarrer WebSphere eXtreme Scale. L'ajout de serveurs supplémentaires sans avoir à redémarrer eXtreme Scale permet d'avoir des déploiements simples, mais également des déploiements de grande taille se chiffrant en téraoctets et comptant plusieurs milliers de serveurs.
Cette topologie de déploiement est flexible. A l'aide du service de catalogue, vous pouvez ajouter et supprimer des serveurs afin de mieux utiliser les ressources sans supprimer l'intégralité du cache. Vous pouvez utiliser les commandes startOgServer et stopOgServer pour démarrer et arrêter les serveurs de conteneur. Ces deux commandes nécessitent de spécifier l'option -catalogServiceEndPoints. Tous les clients d'une topologie répartie communiquent avec le service de catalogue via le protocole IIOP (Internet Interoperability Object Protocol). Tous les clients utilisent l'interface ObjectGrid pour communiquer avec les serveurs.
La fonctionnalité de configuration dynamique de WebSphere eXtreme Scale facilite l'ajout de ressources au système. Les conteneurs hébergent les données et le service de catalogue permet aux clients de communiquer avec la grille de serveurs de conteneur. Le service de catalogue transmet les demandes, alloue de l'espace dans les serveurs de conteneur hôtes et gère l'état et la disponibilité de l'ensemble du système. Les clients se connectent à un service de catalogue, extraient la description de la topologie des serveurs de conteneur et communiquent directement avec chaque serveur. Lorsque la topologie des serveurs change suite à l'ajout de serveurs ou de la défaillance d'autres serveurs, le service de catalogue achemine automatiquement les demandes client au serveur approprié qui héberge les données.
Un service de catalogue existe dans sa propre grille de machines virtuelles Java. Un même serveur de catalogues peut gérer plusieurs serveurs. Vous pouvez démarrer un serveur de conteneur dans une machine virtuelle Java seule ou le charger dans une machine virtuelle Java arbitraire avec d'autres serveurs de conteneur pour différents serveurs. Un client peut exister dans une machine virtuelle Java et communiquer avec un ou plusieurs serveurs. Un client peut également exister dans la même machine virtuelle Java qu'un serveur de conteneur.
Vous pouvez également créer une stratégie de déploiement à l'aide d'un programme lorsque vous intégrez un serveur de conteneur dans un processus ou une application Java. Pour plus d'informations, consultez la documentation de l'API DeploymentPolicy.