Considérations relatives à la migration de groupe central
La fonctionnalité gestionnaire de haute disponibilité et de groupe central est fournie dans la version 6 et ultérieure. Cette rubrique traite de la configuration des groupes centraux et des questions relatives à la topologie pouvant avoir une incidence sur la migration lorsqu'elle est effectuée à partir d'une version du produit qui ne contient pas cette fonctionnalité, telle que la version 5.1.
- Gestionnaire de haute disponibilité
- Cas d'utilisation d'un gestionnaire de haute disponibilité
- groupe central
- Transports du groupe central
- Coordinateur du groupe central
- Considérations relatives à l'administration du groupe central
- Remarques relatives au dimensionnement du groupe central
Des activités de planification et de migration spéciales pouvant s'avérer nécessaires pour votre environnement, avant de procéder à la migration d'une version du produit ne ne disposant pas d'un gestionnaire de haute disponibilité vers une version en disposant, vous devez pouvoir répondre aux questions suivantes :
- Quelle est la configuration de groupe central et la topologie appropriées à une cellule après sa migration vers la version 7.0 ?
- En environnement mixte, la cellule version 5.x est-elle configurée pour utiliser la réplication mémoire à mémoire ? Si c'est le cas, comment est migré l'environnement de réplication ? En quoi la réplication est-elle affectée pendant le processus de migration ?
- Le cas échéant, quel est le fournisseur JMS utilisé dans la cellule version 5.x ?
- Le cas échéant, quel est le fournisseur JMS utilisé dans la cellule version 7.0 ?
- Si le fournisseur de messagerie IBM® version 7.0 par défaut est utilisé dans la cellule version 7.0, doit-il être configuré pour être à haute disponibilité ?
- La reprise du journal de transactions doit-elle être configurée dans la cellule version 7.0 ?
Activités de migration relatives au groupe central par défaut
- Le gestionnaire de déploiement est migré vers la version 7.0.
- Pendant la migration, un profil de gestionnaire de déploiement version 7.0 et un groupe central nommé DefaultCoreGroup sont créés.
- Le nouveau processus du gestionnaire de déploiement est ajouté au groupe DefaultCoreGroup.
- Les noeuds version 5.x sont migrés l'un à la suite de l'autre vers la version 7.0. Lors de la migration de chaque noeud, l'agent de noeud et les serveurs d'applications sur les noeuds affectés sont ajoutés au groupe DefaultCoreGroup.
Lorsque la migration est terminée, tous les processus de la cellule version 5.x sont membres du groupe central DefaultCoreGroup version 7.0. Ce dernier étant configuré avec des valeurs par défaut pour tous les paramètres, le processus de migration ne configure pas de serveurs désignés comme coordinateurs favoris et ne partitionne pas le coordinateur sur plusieurs serveurs. De plus, aucune nouvelle règle de haute disponibilité n'est créée par le processus de migration qui ne permet par ailleurs aucune substitution de configuration de propriété personnalisée.
Planification de la topologie du groupe central
Dans la plupart des topologies version 5.x, une migration par défaut génère une topologie de groupe central version 7.0 appropriée et exploitable. Dans certains cas, vous pouvez être amené à apporter des modifications mineures à la topologie, telles que la création d'un transport autre que celui par défaut ou la configuration du groupe central pour la réplication. Si la cellule version 5.x est suffisamment importante pour nécessiter plusieurs groupes centraux dans la topologie version 7.0, une planification plus importante est nécessaire avant de lancer le processus de migration pour éviter l'arrêt des applications lors de la modification de la configuration des groupes centraux.
La migration vers la version 7.0 d'une grande cellule version 5.x pouvant nécessiter plusieurs groupes centraux peut s'avérer complexe. Lorsque la topologie version 7.0 nécessite plusieurs groupes centraux, plusieurs options s'offrent à vous pour la façon de partitionner la cellule en plusieurs groupes centraux et quand le faire. L'approche adoptée doit se baser sur le nombre de processus dans la cellule et la nécessité de disposer des applications sans interruption. Par exemple, alors que la recommandation courante consiste à limiter à environ 50 membres les groupes centraux, la limite pratique tend à être supérieure. Dans les topologies disposant d'un petit nombre d'applications installées sur des machines haut de gamme (unités centrales puissantes avec beaucoup de mémoire), les groupes centraux pouvant atteindre 200 membres. Si la cellule contient 150 processus et que la disponibilité des applications n'est pas un problème, une option consiste à migrer l'intégralité de la cellule vers la version 7.0, puis à créer des groupes centraux supplémentaires. Si la disponibilité des applications est au contraire importante, vous devez créer les groupes centraux supplémentaires pendant la migration pour ne pas avoir à arrêter et redémarrer les membres de ces groupes une fois la migration terminée.
- Taille des groupes centraux
- La taille du groupe central est le point le plus important de la planification. Par défaut, un groupe central est associé à chaque cellule. Les groupes centraux ne pouvant atteindre des tailles importantes, si la cellule version 5.x est grande, il peut s'avérer nécessaire de créer des groupes centraux supplémentaires pour la topologie version 7.0. Il peut également être nécessaire de configurer des passerelles si ces groupes centraux multiples doivent communiquer entre eux.
- Transport du groupe central
- Lorsqu'une modification est apportée à la configuration de transport du groupe central, tous les membres de ce dernier doivent être relancés pour que la modification soit prise en compte. Une planification est donc nécessaire pour minimiser l'incidence de la modification. En cas de modification du transport du groupe DefaultCoreGroup, le meilleur moment de le faire est immédiatement après la migration du gestionnaire de déploiement, car alors seul le gestionnaire de déploiement devra être relancé. Si d'autres groupes centraux sont créés, le transport doit être configuré correctement lors de leur création.
- Substitutions de configurations de propriétés personnalisées
- Un certain nombre de paramètres de configuration de groupes centraux peuvent être modifiés par
substitution de propriétés personnalisées. Ces dernières sont documentées dans d'autres articles du
centre de documentation de la présente section.
Lorsqu'une substitution de propriétés personnalisées est ajoutée, supprimée ou modifiée, tous les membres des groupes centraux doivent être relancés pour tenir compte de la modification. Une planification est donc nécessaire pour minimiser l'incidence de la modification des propriétés personnalisées. S'il est nécessaire de modifier des propriétés personnalisées dans le groupe DefaultCoreGroup, le mieux est de le faire immédiatement après la migration du gestionnaire de déploiement. Si d'autres groupes centraux sont créés, les propriétés personnalisées doivent être modifiées lors de leur création.
- Coordinateur du groupe central
- La configuration de serveurs favoris comme coordinateurs est une pratique conseillée. Le gestionnaire de haute disponibilité peut relire et appliquer de façon dynamique les modifications apportées à la configuration du coordinateur du groupe central, il n'est pas nécessaire de redémarrer tous les membres du groupe central pour qu'ils prennent en compte la modification.
Exemple : Migration d'une grande cellule
L'exemple suivant illustre certaines des réflexions qui accompagnent la planification et l'exécution de la migration d'une grande cellule version 5.x vers la version 7.0, dans laquelle plusieurs groupes centraux sont requis. Nous supposons dans cet exemple que la cellule version 5.x dispose des caractéristiques de topologie suivantes :
- La cellule contient huit noeuds nommés Node1, Node2, Node3, ..., Node8, sans compter le noeud du gestionnaire de déploiement.
- La cellule contient dix clusters, nommés Cluster1, Cluster2, Cluster3, ..., Cluster10.
- Les clusters Cluster1 à Cluster9 contiennent chacun 32 serveurs d'applications. Les membres de ces clusters sont répartis de façon symétrique, quatre serveurs d'applications par noeud, sur l'ensemble des noeuds.
- Cluster10 contient 28 serveurs d'applications. Il ne dispose d'aucun serveur d'applications sur Node1. Les serveurs d'applications de Cluster10 sont répartis de façon symétrique, quatre serveurs d'applications par noeud, sur les noeuds Node2 à Node8.
- Il existe en tout 316 serveurs d'applications, 8 agents de noeud et un gestionnaire de déploiement dans la cellule.
- Sur chaque cluster est déployée une application qui utilise des EJB et ces applications peuvent communiquer entre elles. Les informations de routage WLM (Work Load Management) doivent donc être disponibles en tout point dans la cellule.
- Les applications doivent rester disponibles pendant la migration.
- La migration s'effectue sur plusieurs jours ou plusieurs semaines.
La première chose à prendre en compte lors de la planification de la topologie de groupe central version 7.0 est la présence de 325 processus dans la cellule et la nécessité pour les applications de rester disponibles. Ces facteurs empêchent de procéder à la migration pure et simple de l'ensemble de la cellule suivie de la reconfiguration des groupes centraux. Vous devez répartir les processus que contient la cellule dans plusieurs groupes centraux pour la migration.
Lorsque vous décidez de la façon de répartir les processus des cellules version 5.x dans le nouveau groupe central, vérifiez que chaque groupe central se conforme aux règles suivantes relatives aux groupes centraux :
- Chaque groupe central doit contenir au moins un processus d'administration. La cellule de cet exemple contenant neuf processus d'administration, 8 agents de noeud et le gestionnaire de déploiement, le nombre maximum de groupes centraux possibles dans la topologie est de neuf.
- Tous les membres d'un cluster doivent être membres du même groupe central.
- Le nombre de processus dans chaque groupe central ne doit pas dépasser la taille recommandée d'environ 50 membres.
- Au moins un des groupes centraux doit contenir deux clusters car la cellule ne peut être divisée qu'en neuf groupes centraux au plus et que la cellule version 5.x contient dix clusters.
- Tout groupe central contenant plusieurs clusters comptera plus de 50 membres car chaque cluster contient 28 ou 32 serveurs d'applications.
Alors que le nombre de membres dans au moins un groupe central dépasse la limite recommandée, le nombre de membres reste dans la limite pratique et ne devrait pas poser de problème.
Les applications de cet exemple nécessitant les informations de routage WLM pour chaque cluster de la cellule, des passerelles de groupes centraux doivent être configurées pour permettre la communication entre tous les groupes centraux. (Voir la rubrique relative aux passerelles de groupes centraux si vous n'êtes pas familiarisés avec la configuration d'une passerelle de groupe central.) Une topologie de passerelle de groupe central appropriée pour cet exemple contient les éléments suivants :
- Un point d'accès de groupe central pour chaque groupe central. Chaque point d'accès contient l'ensemble des processus fournissant les interfaces de passerelle pour chaque groupe central. Les interfaces de passerelle sont les processus qui communiquent avec les processus des autres groupes centraux.
- Deux interfaces de passerelle pour chaque point d'accès pour éliminer la passerelle de groupe
central comme point de défaillance unique. Ces deux interfaces de passerelle sont en outre placées
sur des noeuds différents pour mieux garantir la disponibilité permanente.
Lorsque vous sélectionnez des processus devant servir d'interfaces de passerelle, n'oubliez pas que ces dernières ont besoin de plus de mémoire et de cycles de l'unité centrale. Généralement, les agents de noeud sont des processus qui conviennent pour les interfaces de passerelle car pendant le fonctionnement normal, un agent de noeud a une charge de travail moins importante qu'un gestionnaire de déploiement.
Dans cet exemple, toutefois, seuls huit agents de noeud peuvent servir d'interfaces de passerelle. La topologie nécessitant deux interfaces de passerelle par point d'accès, si vous utilisez uniquement des agents de noeud comme interfaces de passerelle, vous êtes limité à quatre points d'accès et par la même à quatre groupes centraux. Avant de lancer le processus de migration, vous pouvez donc souhaiter créer huit serveurs autonomes tenant lieu d'interfaces de passerelle et n'hébergeant aucune application. Chaque point d'accès contient alors un agent de noeud et un serveur d'interface de passerelle autonome. Cette configuration fournit au total huit points d'accès et huit groupes centraux.
- Un groupe unique de points d'accès de groupes centraux qui contient tous les points d'accès. Un
tel groupe garantit la communication directe entre tous les processus d'interface de passerelle. Ces
interfaces de passerelle forment un maillage entièrement connecté.
Une autre topologie consiste à utiliser plusieurs groupes de points d'accès donnant une topologie en chaîne. Avec cette dernière, la communication est acheminée d'une interface de passerelle à une autre en passant par des interfaces de passerelle intermédiaires le long de la chaîne.
Maintenant que vous avez déterminé le configuration des interfaces de passerelle de groupes centraux, vous pouvez décider de la distribution des dix clusters, huit agents de noeud, huit serveurs d'interface de passerelle autonomes et du gestionnaire de déploiement sur les huit groupes centraux. Les processus doivent être répartis de façon aussi équilibrée que possible entre les huit groupes centraux. La topologie suivante constitue un bon exemple de répartition équilibrée des processus de la cellule version 5.x :
- Le premier groupe central, DefaultCoreGroup, contient le gestionnaire de déploiement, l'agent de noeud du noeud Node1, le serveur de passerelle du noeud Node 2 et le cluster Cluster1.
- Le groupe central 2 contient l'agent de noeud du noeud Node2, le serveur de passerelle du noeud Node3 et le cluster Cluster2.
- Le groupe central 3 contient l'agent de noeud du noeud Node3, le serveur de passerelle du noeud Node4 et le cluster Cluster3.
Il est inutile de modifier le transport par défaut dans cet exemple.
Cet exemple n'indiquant pas que plusieurs coordinateurs sont nécessaires pour chaque groupe central, vous pouvez conserver la valeur par défaut 1 du paramètre de coordinateur. Vous pouvez toutefois souhaiter faire du serveur d'interface de passerelle autonome qui se trouve dans chaque groupe central le serveur de coordinateur favori pour ce groupe central. Ceci permet dans un premier temps de ne pas envoyer la charge de travail incombant au coordinateur aux serveurs d'applications en clusters sur lesquels s'exécutent les applications.
Plan de migration
Si, après analyse de l'exemple qui précède et après avoir effectué la planification initiale pour la cellule que vous migrez, vous déterminez que le flux de migration par défaut ne convient pas à la topologie version 7.0 cible, vous devez développer un plan du processus de migration. Ce plan doit contenir toutes les étapes supplémentaires nécessaires associées au groupe central pour la migration de la version 5.x vers la version 7.0 et répond aux questions suivantes :
- Quand seront créés les nouveaux groupes centraux ?
- Le meilleur moment pour créer les groupes centraux est immédiatement après la fin de la migration du gestionnaire de déploiement. Lors de la création des groupes centraux, vous devez configurer les propriétés personnalisées évoquées plus tôt. Vous pouvez utiliser la console d'administration ou la commande wsadmin createCoreGroup pour créer ces groupes centraux. Vous devez toutefois utiliser la console d'administration pour configurer les propriétés personnalisées.
- Quelles sont les actions qui doivent être effectuées lors de la migration des noeuds ?
- Pour la migration de chaque noeud, vous devez :
- Créer le serveur d'applications autonome qui constituera l'une des interfaces de passerelle de groupes centraux.
- Ajuster la taille de la mémoire tampon du transport sur tous les processus du noeud. Un script constitue la meilleure option pour effectuer cette action.
- Ajuster la taille de segment de l'agent de noeud et le serveur autonome, et activer la récupération de place prolixe pour ces processus.
- Quand et comment les processus sont-ils déplacés vers de nouveaux groupes centraux ?
- Par défaut, le processus de migration place tous les processus dans le groupe central nommé
DefaultCoreGroup. A un moment donné, le nombre de membres que contient ce groupe central dépasse
la limite fixée et vous devez répartir les processus vers d'autres groupes centraux. Il est
important de comprendre que les processus doivent être arrêtés avant de pouvoir être déplacés. Si
les applications doivent restées disponibles en permanence, vous devez planifier avec soin l'ordre
selon lequel vous allez déplacer les processus vers des groupes centraux différents.
Vous pouvez déplacer le gestionnaire de déploiement, les agents de noeud et le serveur d'applications autonome à l'aide de la console d'administration ou de la commande wsadmin moveServerToCoreGroup.
Le déplacement de serveurs d'applications en clusters est plus complexe. Dans des circonstances normales, vous pouvez déplacer des clusters à l'aide de la console d'administration ou de la commande wsadmin moveServerToCoreGroup. Cependant, pendant le processus de migration, le cluster à déplacer pouvant contenir des membres version 7.0 et version 5.x, les commandes normales échouent car un membre version 5.x du cluster n'est encore membre d'aucun groupe central. Pour déplacer un cluster mixte vers un nouveau groupe central, utilisez la commande wsadmin moveClusterToCoreGroup avec le paramètre facultatif checkConfig.
Supposons, par exemple, que le cluster Cluster0 dispose des membres A, B, C et D. Le membre A se trouve sur un noeud ayant migré vers la version 7.0 et est membre du groupe DefaultCoreGroup, alors que les membres B, C et D se trouvent encore sur des noeuds version 5.x. Pour déplacer le cluster Cluster0 vers le groupe central CG1, utilisez la commande suivante : ”$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1 –clusterName Cluster0 –checkConfig false}
Lors de la migration d'un serveur d'applications en clusters, les utilitaires de migration déterminent si d'autres membres du cluster ont déjà été migrés et placent automatiquement le membre migré dans le même groupe central que les autres membres du même cluster déjà migrés.
Dans l'exemple précédent, le membre A a été déplacé vers le groupe central CG1. Lorsque les noeuds contenant les membres B, C et D sont migrés, la migration place ces membres de cluster dans le groupe CG1 au lieu du groupe DefaultCoreGroup. Il est donc nécessaire d'exécuter la commande moveClusterToCoreGroup une seule fois pour chaque cluster.
- Quand faut-il configurer les passerelles de groupe central ?
- Lorsque vous déplacez les processus vers plusieurs groupes centraux, des passerelles de groupes centraux doivent être configurées et en cours d'exécution. Cela signifie que les processus que vous souhaitez utiliser comme interfaces de passerelle dans la topologie version 7.0 cible peuvent ne pas être disponibles la première fois qu'ils sont requis faute d'avoir été migrés à partir des noeuds version 5.x. Pour que les applications restent disponibles en permanence, vous devez donc configurer des serveurs d'applications en clusters comme interfaces de passerelle temporaires pendant que la migration se poursuit. Lorsque tous les processus ont été migrés vers la version 7.0, vous pouvez ajuster la configuration de la passerelle de groupe central en fonction de la topologie version 7.0 souhaitée.
Autres considérations de planification
Si la configuration version 7.0 cible nécessite plusieurs passerelles de groupes centraux, utilisez la propriété personnalisée IBM_CS_WIRE_FORMAT_VERSION pour implémenter les améliorations de mise à l'échelle.
Par ailleurs, si tous les groupes centraux sont reliés entre eux et qu'ils partagent les informations de routage, la quantité de données partagées entre les membres de groupes centraux est susceptible d'être très supérieure à la normale. Vous devez donc utiliser les paramètres de mémoire de groupe central suivants pour permettre le transfert plus efficace des données :
- Associez la valeur 100 à la propriété IBM_CS_DATASTACK_MEG.
- Définissez une taille de mémoire tampon de transport de 100 pour tous les processus.
Vous devez aussi envisager d'ajuster des facteurs tels que les tailles de segment JVM pour des agents de noeud ou des serveurs d'applications utilisés comme interface de passerelle et tout serveur autonome utilisé comme coordinateur. Il est recommandé de commencer par porter la taille de segment de 512 mégaoctets. Vous pouvez aussi activer le contrôle de la récupération de place prolixe pour ces processus de façon à pouvoir ajuster ces tailles de segment au fil du temps.
Flux de migration possibles
Vous pouvez implémenter plusieurs flux de migration pour réussir la migration. Les flux suivants supposent que la migration du gestionnaire de déploiement est terminée sur un point de départ commun et que les groupes centraux ont été créés, mais qu'aucune autre action n'a été entreprise.
- Flux de migration 1
- Dans ce flux, les règles sont rigoureusement respectées. Le flux n'est pas satisfaisant pour
plusieurs raisons. Lors de la migration de chaque noeud, des clusters doivent être déplacés. Ceci
nécessite l'arrêt de tous les membres de cluster. Il peut en résulter la non disponibilité de
certaines applications. Les passerelles doivent en outre être reconfigurées à chaque étape.
- Migrez le noeud Node1. Le groupe DefaultCoreGroup contient le gestionnaire de déploiement et tous les processus du noeud Node1. Ce groupe contenant moins de 50 membres, aucune action supplémentaire n'est requise.
- Migrez le noeud Node2. Le groupe DefaultCoreGroup contient désormais un nombre de processus supérieur au nombre recommandé. Equilibrez les processus sur deux groupes centraux en déplaçant la moitié des clusters et l'agent de noeud de Node2 dans le groupe CoreGroup2. Plusieurs groupes centraux étant désormais utilisés, vous devez configurer la passerelle de groupe central. Créez des serveurs d'interfaces de passerelle sur les noeuds Node1 et Node2. Configurez la passerelle de groupe central pour relier les deux groupes centraux.
- Migrez le noeud Node3. Equilibrez les processus sur 3 groupes centraux en déplaçant certains clusters des groupes DefaultCoreGroup et CoreGroup2 vers le groupe CoreGroup3. Déplacez l'agent de noeud du noeud Node3 vers le groupe CoreGroup3. Créez un serveur d'interfaces de passerelle sur le noeud Node3. Reconfigurez la passerelle de groupe central pour créer une passerelle entre les trois groupes centraux.
- Continuez la migration des noeuds jusqu'à ce qu'elle soit terminée. Pour chacune d'elle, un rééquilibrage et une reconfiguration de la passerelle de groupes centraux peut s'avérer nécessaire.
- Flux de migration 2
- Dans ce flux, les règles sont momentanément ignorées. Il donne de meilleurs résultats car il
est inutile d'arrêter les serveurs d'applications en cours d'exécution pour les déplacer vers un
autre groupe central. Pendant la migration, certains groupes centraux ne contiendront aucun
processus d'administration pendant un certain temps. Il s'agit d'une violation technique des
règles, mais cela reste acceptable tant que la configuration du groupe central n'est pas modifiée
pendant la migration.
- Migrez le noeud Node1. Il contient des membres de tous les clusters sauf Cluster10.
- Déplacez tous les clusters possibles vers le groupe central identifié dans la topologie cible finale. Le gestionnaire de déploiement, l'agent de noeud de Node1 et Cluster1 se trouvent déjà dans le groupe DefaultCoreGroup, aucune autre action les concernant n'est donc requise. Déplacez le cluster Cluster2 vers le groupe CoreGroup2, le cluster Cluster3 vers le groupe CoreGroup3 etc. Créez le serveur de passerelles pour le noeud Node1 et placez-le dans le groupe CoreGroup2.
- Configurez la passerelle de groupe central pour créer une passerelle entre les huit groupes centraux. Pour plus de simplicité, nous allons momentanément configurer une interface de passerelle unique pour chaque point d'accès. (Ceci introduit un point de défaillance unique pendant la migration) La plupart des interfaces de passerelle de la topologie finale étant encore en version 5.x, vous devez utiliser des serveurs d'applications comme interfaces de passerelle temporaires dans 6 des 8 groupes centraux. Ceci peut nécessiter une augmentation temporaire de la taille de segment des serveurs d'applications sélectionnés.
- Migrez le noeud Node2. La migration déplace automatiquement les serveurs d'applications en clusters du noeud Node2 vers les groupes centraux appropriés. Le cluster Cluster10 ne disposant d'aucun serveur d'applications sur le noeud Node1, déplacez-le manuellement vers le groupe CoreGroup8. Déplacez l'agent de noeud du noeud Node2 vers le groupe CoreGroup2. Créez le serveur de passerelles sur le noeud Node2. Vous pouvez éventuellement reconfigurer la passerelle de groupe central de sorte que certains des serveurs d'interface de passerelle se trouvent sur le noeud Node2 pour aider à répartir la charge sur les deux noeuds.
- Poursuivez la migration des noeuds de la même façon jusqu'à ce que tous les noeuds soient migrés.
- Lorsque la migration de tous les noeuds est effectuée, configurez des serveurs de coordinateurs favoris. Reconfigurez les interfaces de passerelle en fonction de la topologie cible final (avec deux serveurs d'interface de passerelle à chaque point d'accès). Arrêtez et relancez les serveurs servant d'interfaces de passerelle temporaires. Relancez les nouveaux serveurs d'interface de passerelle.
- Flux de migration 3
- Ce flux est une variante du flux 2. Il présente l'avantage de répartir la charge initiale de la
passerelle sur trois noeuds au lieu d'un seul. L'inconvénient est que la redistribution initiale
des clusters vers les groupes centraux se produit après la migration du noeud Node3. Les serveurs
qui s'exécutent sur les noeuds Node1 et Node2 doivent donc être arrêtés pour que le déplacement
puisse se produire. La disponibilité des applications peut s'en trouver affectée.
- Migrez le noeud Node1. Une fois cette étape terminée, le groupe DefaultCoreGroup contient 38 processus et reste donc dans les limites autorisées.
- Migrez le noeud Node2. Une fois cette étape terminée, le groupe DefaultCoreGroup contient 79 processus. Ce nombre est supérieur à la taille recommandée, mais reste néanmoins dans les limites pratiques.
- Migrez le noeud Node3. Déplacez tous les clusters vers le groupe central identifié dans la topologie finale. Déplacez le cluster Cluster2 vers le groupe CoreGroup2, le cluster Cluster3 vers le groupe CoreGroup3 etc. Déplacez les trois agents de noeud vers les groupes centraux qui conviennent. Créez et déplacez les trois serveurs d'interface de passerelle vers les groupes centraux appropriés.
- Sélectionnez des serveurs d'applications en clusters devant servir de passerelles temporaires aux groupes centraux ne contenant pas encore d'interfaces de passerelle désignées. Ajustez momentanément les tailles de segments de ces serveurs. Configurez la passerelle de groupe central pour créer une passerelle entre les huit groupes centraux.
- Poursuivez la migration des noeuds jusqu'à ce qu'ils soient tous migrés.
- Lorsque la migration de tous les noeuds est effectuée, configurez des coordinateurs favoris. Reconfigurez les interfaces de passerelle en fonction de la topologie cible finale. Arrêtez et redémarrez les processus selon les besoins.