![[UNIX, Linux, Windows, IBM i]](ngmulti.gif)
A propos des clusters uniformes
L'objectif d'un déploiement de cluster uniforme est que les applications puissent être conçues pour l'échelle et la disponibilité et qu'elles puissent se connecter à n'importe quel gestionnaire de files d'attente au sein du cluster uniforme. Cela permet de supprimer toute dépendance sur un gestionnaire de files d'attente spécifique, ce qui améliore la disponibilité et l'équilibrage de la charge de travail du trafic de messagerie.
Les clusters uniformes ne sont pas disponibles surIBM® MQ for z/OS® ; Les groupes de partage de files d'attente offrent de nombreuses fonctionnalités d'un cluster uniforme.
Les clusters uniformes sont un modèle spécifique d'un cluster IBM MQ qui fournit une petite collection de gestionnaires de files d'attente à haute disponibilité et échelonnée horizontalement. Ces gestionnaires de files d'attente sont configurés de manière presque identique, de sorte qu'une application puisse interagir avec eux en tant que groupe unique. Il est ainsi plus facile de s'assurer que chaque gestionnaire de files d'attente du cluster est utilisé, en s'assurant automatiquement que les instances d'application sont réparties de manière égale entre les gestionnaires de files d'attente.
Les clusters uniformes suppriment certaines des étapes manuelles qu'un administrateur doit effectuer pour créer et administrer un groupe de gestionnaires de files d'attente indépendants et interconnectés. Ils déplacent une logique de connexion client du client vers le gestionnaire de files d'attente, où les informations sur les niveaux d'activité de l'application peuvent éclairer les décisions des clients quant aux gestionnaires de files d'attente auxquels ils doivent se connecter.
Vous pouvez simplifier la création initiale d'un cluster uniforme, puis conserver la configuration identique entre les membres du cluster uniforme, à l'aide de la configuration automatique et de la prise en charge de la mise en cluster automatique. Lorsque vous utilisez cette fonction, un fichier de configuration décrit le cluster et un autre représente la configuration MQSC à appliquer à tous les gestionnaires de files d'attente du cluster uniforme. A chaque redémarrage du gestionnaire de files d'attente, la configuration est réappliquée et le cluster se forme automatiquement. Voir Créer un cluster uniforme pour plus de détails sur l’utilisation de cette fonctionnalité.
Pour tirer pleinement parti d'un cluster uniforme, chaque application doit également être mise à l'échelle en plusieurs instances correspondantes, de préférence avec au moins autant d'instances que de gestionnaires de files d'attente, si ce n'est pas le cas.
- Répertoire de toutes les ressources de mise en cluster, reconnaissable par n'importe quel membre d'un cluster
- Création automatique de canal et connectivité
- Mise à l'échelle horizontale sur plusieurs files d'attente correspondantes, à l'aide de l'équilibrage de charge de message
- Routage dynamique des messages, en fonction de la disponibilité
- Les clusters uniformes comportent généralement un plus petit nombre de gestionnaires de files d'attente dans le cluster. Vous ne devez pas créer un cluster uniforme avec plus de 10 gestionnaires de files d'attente.
- Chaque membre du cluster possède une configuration quasi identique.
- Le cluster est généralement utilisé par une seule application ou un groupe d'applications associées.
- Le nombre d'instances d'application qui se connectent au cluster doit être supérieur ou égal au nombre de gestionnaires de files d'attente.
Dans un modèle de cluster uniforme, tous les gestionnaires de files d'attente du cluster offrent les mêmes services de messagerie. Par exemple, vous pouvez configurer tous les membres du cluster pour qu'ils aient les mêmes files d'attente locales définies et permettre aux applications client de se connecter à n'importe quel membre du cluster. Vous pouvez également avoir les mêmes canaux de connexion serveur définis, et éventuellement les mêmes enregistrements de droits d'accès, les mêmes règles d'authentification de canal, etc. Toutefois, les membres du cluster peuvent encore présenter certaines différences dans les objets et la configuration. Par exemple, certaines applications peuvent créer des files d'attente dynamiques temporaires lorsqu'elles sont connectées à un gestionnaire de files d'attente. En outre, certaines mises à jour de configuration peuvent être déployées dans les membres sur une période donnée ; par exemple, des certificats nouveaux ou mis à jour. Comme avec les clusters IBM MQ standard, deux des gestionnaires de files d'attente nécessitent une configuration supplémentaire pour en faire des gestionnaires de files d'attente de référentiel complet.
Le diagramme suivant montre que les gestionnaires de files d'attente ont des configurations similaires. Ils définissent la même file d'attente appelée Q1 et le même canal de connexion serveur SVRCONN1.

Notez que pour que plusieurs gestionnaires de files d'attente avec des noms de canal de connexion serveur identiques fonctionnent avec une seule table de définition de canal du client (CCDT), vous devez utiliser le format CCDT mis à jour introduit dans IBM MQ 9.1.2. Voir Configurer un CCDT au format JSON.
Noms d'application et instances d'application
Un nom d'application s'affiche en tant qu'attribut APPLTAG de la commande DISPLAY CONN(*) TYPE CONN . Depuis la IBM MQ 9.1.2, il y a un changement dans la façon dont le nom de l'application est défini.
Une instance d'application est un ensemble de connexions étroitement liées qui fournissent une unité d'exécution pour cette application. En règle générale, il s'agit d'un processus de système d'exploitation unique, qui peut comporter un certain nombre d'unités d'exécution et des connexions IBM MQ associées.
Pour plus d'informations sur le nom d'application et les instances d'application, voir Concepts de développement d'application.
Clients reconnectables
Les clients reconnectables peuvent être déplacés afin d'obtenir une distribution de charge de travail uniforme alors que, par définition, un client non reconnectable ne peut pas être reconnecté à un autre gestionnaire de files d'attente. Cependant, il peut encore y avoir une bonne raison de connecter un client non reconnectable à un cluster uniforme: par exemple, le client crée une forme d'état persistant et un autre mécanisme est utilisé pour s'assurer que des instances de l'application sont en cours d'exécution dans chacun des gestionnaires de files d'attente.
Applications liées localement
Les clusters uniformes doivent avoir des applications IBM MQ qui se connectent en tant qu'applications client, plutôt que des applications liées localement. Les applications liées localement ne sont pas empêchées de se connecter à des membres de cluster uniformes, mais les clusters uniformes ne peuvent même pas distribuer la charge de travail avec des applications liées localement, car ils ne peuvent pas se connecter à un autre membre du cluster.