Mise en cluster de publication / abonnement: meilleures pratiques

L'utilisation de rubriques en cluster facilite l'extension du domaine de publication / abonnement entre les gestionnaires de files d'attente, mais peut entraîner des problèmes si les mécanismes et les implications ne sont pas parfaitement compris. Il existe deux modèles pour le partage d'informations et le routage des publications. Implémentez le modèle qui répond le mieux à vos besoins métier individuels et qui est le plus performant sur le cluster que vous avez choisi.

Les informations sur les meilleures pratiques dans les sections suivantes ne fournissent pas une solution unique, mais partagent plutôt des approches communes pour résoudre des problèmes communs. Il suppose que vous ayez une connaissance de base des clusters IBM® MQ et de la messagerie par publication/abonnement, et que vous soyez familiarisé avec les informations contenues dans Réseaux distribués par publication/abonnement et Conception de clusters par publication/abonnement.

Lorsque vous utilisez un cluster pour la messagerie point-à-point, chaque gestionnaire de files d'attente du cluster fonctionne sur la base d'un besoin de connaissance. En d'autres termes, il détecte uniquement les autres ressources de cluster, telles que les autres gestionnaires de files d'attente du cluster et les files d'attente en cluster, lorsque les applications qui s'y connectent demandent à les utiliser. Lorsque vous ajoutez une messagerie de publication / abonnement à un cluster, un niveau accru de partage d'informations et de connectivité entre les gestionnaires de files d'attente de cluster est introduit. Pour pouvoir suivre les meilleures pratiques pour les clusters de publication / abonnement, vous devez bien comprendre les implications de ce changement de comportement.

Pour vous permettre de créer la meilleure architecture, en fonction de vos besoins précis, il existe deux modèles de partage d'informations et de routage de publication dans les clusters de publication / abonnement: routage direct et routage via un hôte de rubrique. Pour faire le bon choix, vous devez comprendre les deux modèles et les différentes exigences que chaque modèle satisfait. Ces exigences sont examinées dans les sections suivantes, en liaison avec la planification de votre réseau distribué de publication et d'abonnement :

Raisons de limiter le nombre de gestionnaires de files d'attente de cluster impliqués dans l'activité de publication / abonnement

Il existe des considérations relatives à la capacité et aux performances lorsque vous utilisez la messagerie de publication / abonnement dans un cluster. Par conséquent, il est recommandé de prendre soigneusement en compte la nécessité d'une activité de publication / abonnement dans les gestionnaires de files d'attente et de la limiter au nombre de gestionnaires de files d'attente qui en ont besoin. Une fois que l'ensemble minimal de gestionnaires de files d'attente qui doivent publier et s'abonner à des rubriques est identifié, ils peuvent devenir membres d'un cluster qui ne contient que ces derniers et aucun autre gestionnaire de files d'attente.

Cette approche est particulièrement utile si vous disposez d'un cluster établi qui fonctionne déjà bien pour la messagerie point-à-point. Lorsque vous transformez un grand cluster existant en un cluster de publication / abonnement, il est préférable de créer initialement un cluster distinct pour le travail de publication / abonnement où les applications peuvent être essayées, plutôt que d'utiliser le cluster en cours. Vous pouvez utiliser un sous-ensemble de gestionnaires de files d'attente existants qui se trouvent déjà dans un ou plusieurs clusters point-à-point et rendre ce sous-ensemble membre du nouveau cluster de publication / abonnement. Toutefois, les gestionnaires de files d'attente de référentiel complet de votre nouveau cluster ne doivent pas être membres d'un autre cluster ; cela isole la charge supplémentaire des référentiels complets de cluster existants.

Si vous ne pouvez pas créer de nouveau cluster et que vous devez transformer un grand cluster existant en un cluster de publication / abonnement, n'utilisez pas de modèle de routage direct. Le modèle d'hôte de rubrique routé est généralement plus performant dans les clusters plus grands, car il limite généralement le partage d'informations de publication / abonnement et la connectivité à l'ensemble des gestionnaires de files d'attente qui effectuent activement des travaux de publication / abonnement, en se concentrant sur les gestionnaires de files d'attente hébergeant les rubriques. La seule exception à cette règle est si une actualisation manuelle des informations d'abonnement est appelée sur un gestionnaire de files d'attente hébergeant une définition de rubrique, auquel cas le gestionnaire de files d'attente hôte de rubrique se connecte à chaque gestionnaire de files d'attente du cluster. Voir Resynchronisation des abonnements de proxy.

Si vous établissez qu'un cluster ne peut pas être utilisé pour la publication / l'abonnement en raison de sa taille ou de sa charge actuelle, il est recommandé d'éviter que ce cluster ne soit transformé de manière inattendue en un cluster de publication / abonnement. Utilisez la propriété de gestionnaire de files d'attente PSCLUS pour arrêter quiconque ajoute une rubrique en cluster sur un gestionnaire de files d'attente du cluster. Voir Inhibition de la publication/souscription en grappe.

Comment choisir les rubriques à mettre en cluster

Il est important de choisir avec soin les rubriques qui sont ajoutées au cluster: plus l'arborescence de rubriques est élevée, plus leur utilisation est répandue. Cela peut entraîner la propagation d'un plus grand nombre d'informations d'abonnement et de publications que nécessaire. S'il existe plusieurs branches distinctes de l'arborescence de rubriques, où certaines doivent être regroupées en cluster et d'autres non, créez des objets de rubrique gérés à la racine de chaque branche qui doit être mise en cluster et ajoutez-les au cluster. Par exemple, si les branches /A, /B et /C ont besoin de la mise en cluster, définissez des objets de rubrique en cluster distincts pour chaque branche.

Remarque: Le système vous empêche d'imbriquer des définitions de rubrique en cluster dans l'arborescence de rubriques. Vous n'êtes autorisé à regrouper des rubriques qu'à un seul point de l'arborescence de rubriques pour chaque sous-branche. Par exemple, vous ne pouvez pas définir d'objets de rubrique en cluster pour /A et pour /A/B. L'imbrication de rubriques en cluster peut entraîner une confusion quant à l'objet en cluster qui s'applique à tel ou tel abonnement, en particulier lorsque les abonnements utilisent des caractères génériques. Cela est encore plus important lorsque vous utilisez le routage d'hôte de sujet, où les décisions de routage sont précisément définies par votre allocation d'hôtes de sujet.

Si des rubriques en cluster doivent être ajoutées en haut de l'arborescence de rubriques, mais que certaines branches de l'arborescence sous le point en cluster ne nécessitent pas le comportement en cluster, vous pouvez utiliser les attributs de portée d'abonnement et de publication pour réduire le niveau d'abonnement et de partage de publication pour d'autres rubriques.

Vous ne devez pas placer le noeud racine de rubrique dans le cluster sans tenir compte du comportement observé. Rendez les rubriques globales évidentes lorsque cela est possible, par exemple en utilisant un qualificatif de haut niveau dans la chaîne de rubrique: /global ou /cluster.

Il existe une autre raison pour laquelle vous ne souhaitez pas que le noeud de rubrique racine soit mis en cluster. En effet, chaque gestionnaire de files d'attente possède une définition locale pour le noeud racine, l'objet de rubrique SYSTEM.BASE.TOPIC . Lorsque cet objet est mis en cluster sur un gestionnaire de files d'attente du cluster, tous les autres gestionnaires de files d'attente en sont informés. Cependant, lorsqu'une définition locale du même objet existe, ses propriétés remplacent l'objet de cluster. Ainsi, les gestionnaires de files d'attente agissent comme si la rubrique n'était pas mise en cluster. Pour résoudre ce problème, vous devez mettre en cluster chaque définition de SYSTEM.BASE.TOPIC. Vous pouvez effectuer cette opération pour les définitions routées directement, mais pas pour les définitions routées par l'hôte de rubrique, car chaque gestionnaire de files d'attente devient un hôte de rubrique.

Comment dimensionner votre système

Les clusters de publication / abonnement génèrent généralement un modèle de canaux de cluster différent de la messagerie point-à-point dans un cluster. Le modèle point-à-point est un "opt-in", mais les clusters de publication / abonnement ont un caractère plus indiscriminé avec une distribution d'abonnement, en particulier lors de l'utilisation de rubriques acheminées directement. Par conséquent, il est important d'identifier les gestionnaires de files d'attente d'un cluster de publication / abonnement qui utiliseront des canaux de cluster pour se connecter à d'autres gestionnaires de files d'attente et dans quelles circonstances.

Le tableau suivant répertorie l'ensemble type de canaux émetteurs et récepteurs de cluster attendus pour chaque gestionnaire de files d'attente d'un cluster de publication / abonnement en cours d'exécution normale, en fonction du rôle de gestionnaire de files d'attente dans le cluster de publication / abonnement.

Tableau 1. Canaux émetteurs et récepteurs de cluster pour chaque méthode de routage.
Rôle de gestionnaire de files d'attente	Récepteurs de cluster directs	Expéditeurs de cluster direct	Récepteurs de cluster de rubriques	Expéditeurs de cluster de rubriques
Référentiel complet	AllQmgrs	AllQmgrs	AllQmgrs	AllQMgrs
Hôte de définition de rubrique	Non applicable	Non applicable	AllSubs+AllPubs (1)	AllSubs (1)
Abonnements créés	AllPubs (1)	AllQMgrs	AllHosts	AllHosts
Diffuseurs de publications connectés	AllSubs (1)	AllSubs (1)	AllHosts	AllHosts
Aucun diffuseur de publications ni abonné	AllSubs (1)	Aucun (1)	Aucun (2)	Aucun (2)

Clé :

AllQmgrs: Un canal vers et depuis chaque gestionnaire de files d'attente du cluster.
AllSubs: Un canal vers et depuis chaque gestionnaire de files d'attente où un abonnement a été créé.
AllPubs: Un canal vers et depuis chaque gestionnaire de files d'attente où une application de publication a été connectée.
AllHosts: Canal à destination et en provenance de chaque gestionnaire de files d'attente dans lequel une définition de l'objet de rubrique en cluster a été configurée.
Aucun: Aucun canal vers ou depuis d'autres gestionnaires de files d'attente du cluster dans le seul but de la messagerie de publication / abonnement.

Remarques :

Si une régénération de gestionnaire de files d'attente des abonnements de proxy est effectuée à partir de ce gestionnaire de files d'attente, un canal vers et depuis tous les autres gestionnaires de files d'attente du cluster peut être créé automatiquement.
Si une régénération de gestionnaire de files d'attente des abonnements de proxy est effectuée à partir de ce gestionnaire de files d'attente, un canal vers et à partir de tout autre gestionnaire de files d'attente du cluster qui héberge une définition d'une rubrique en cluster peut être automatiquement créé.

Le tableau précédent montre que le routage via l'hôte de rubrique utilise généralement beaucoup moins de canaux émetteurs et récepteurs de cluster que le routage direct. Si la connectivité des canaux est un problème pour certains gestionnaires de files d'attente dans un cluster, pour des raisons de capacité ou de capacité à établir certains canaux (par exemple, via des pare-feux), le routage via l'hôte de rubrique est donc une solution préférée.

Emplacement de l'éditeur et de l'abonnement

La fonction de publication / abonnement en cluster permet aux messages publiés sur un gestionnaire de files d'attente d'être distribués aux abonnements sur n'importe quel autre gestionnaire de files d'attente du cluster. Comme pour la messagerie point-à-point, le coût de la transmission de messages entre les gestionnaires de files d'attente peut être préjudiciable aux performances. Par conséquent, vous devez envisager de créer des abonnements à des rubriques sur les mêmes gestionnaires de files d'attente que lorsque des messages sont publiés.

Lorsque vous utilisez le routage via un hôte de rubrique dans un cluster, il est important de prendre également en compte l'emplacement des abonnements et des diffuseurs de publications par rapport aux gestionnaires de files d'attente d'hébergement de rubrique. Lorsque le diffuseur de publications n'est pas connecté à un gestionnaire de files d'attente qui est un hôte de la rubrique en cluster, les messages publiés sont toujours envoyés à une rubrique hébergeant le gestionnaire de files d'attente. De même, lorsqu'un abonnement est créé sur un gestionnaire de files d'attente qui n'est pas un hôte de rubrique pour une rubrique en cluster, les messages publiés à partir d'autres gestionnaires de files d'attente du cluster sont toujours envoyés à un gestionnaire de files d'attente d'hébergement de rubrique en premier. Plus spécifiquement, si l'abonnement se trouve sur un gestionnaire de files d'attente qui héberge la rubrique, mais qu'il existe un ou plusieurs autres gestionnaires de files d'attente qui hébergent également la même rubrique, une proportion de publications provenant d'autres gestionnaires de files d'attente est acheminée via ces autres gestionnaires de files d'attente hébergeant la rubrique. Pour plus d'informations sur la conception d'un cluster de publication / abonnement routé par un hôte de rubrique afin de réduire la distance entre les diffuseurs de publications et les abonnements, voir Routage d'hôte de rubrique à l'aide de diffuseurs de publications ou d'abonnés centralisés .

Trafic de publication

Les messages publiés par une application connectée à un gestionnaire de files d'attente dans un cluster sont transmis aux abonnements sur d'autres gestionnaires de files d'attente à l'aide de canaux émetteurs de cluster.

Lorsque vous utilisez le routage direct, les messages publiés prennent le chemin le plus court entre les gestionnaires de files d'attente. C'est-à-dire qu'ils vont directement du gestionnaire de files d'attente de publication vers chacun des gestionnaires de files d'attente avec des abonnements. Les messages ne sont pas transmis aux gestionnaires de files d'attente qui ne disposent pas d'abonnements pour la rubrique. Voir Abonnements de proxy dans un réseau de publication / abonnement.

Lorsque le débit des messages de publication entre un gestionnaire de files d'attente et un autre du cluster est élevé, l'infrastructure du canal de cluster entre ces deux points doit être en mesure de maintenir le débit. Cela peut impliquer l'optimisation des canaux et de la file d'attente de transmission utilisés.

Lorsque vous utilisez le routage via un hôte de rubrique, chaque message publié sur un gestionnaire de files d'attente qui n'est pas un hôte de rubrique est transmis à un gestionnaire de files d'attente hôte de rubrique. Cela est indépendant du fait qu'un ou plusieurs abonnements existent ailleurs dans le cluster. Cela introduit d'autres facteurs à prendre en compte lors de la planification:

Le temps d'attente supplémentaire de l'envoi préalable de chaque publication à un gestionnaire de files d'attente hôte de rubrique est-il acceptable?
Chaque gestionnaire de files d'attente hôte de rubrique peut-il supporter le débit de publication entrant et sortant? Prenons l'exemple d'un système avec des diffuseurs de publications sur de nombreux gestionnaires de files d'attente différents. S'ils envoient tous leurs messages à un très petit ensemble de gestionnaires de files d'attente d'hébergement de rubrique, ces hôtes de rubrique peuvent devenir un goulot d'étranglement dans le traitement de ces messages et leur routage vers les gestionnaires de files d'attente d'abonnement.
Est-il prévu qu'une proportion importante des messages publiés n'auront pas d'abonné correspondant? Si tel est le cas et que le débit de publication de ces messages est élevé, il peut être préférable de faire du gestionnaire de files d'attente du diffuseur de publications un hôte de rubrique. Dans ce cas, tout message publié dans lequel aucun abonnement n'existe dans le cluster ne sera pas transmis à d'autres gestionnaires de files d'attente.

Ces problèmes peuvent également être résolus en introduisant plusieurs hôtes de rubrique, afin de répartir la charge de publication entre eux:

Lorsqu'il existe plusieurs rubriques distinctes, chacune avec une proportion du trafic de publication, envisagez de les héberger sur des gestionnaires de files d'attente différents.
Si les rubriques ne peuvent pas être séparées sur des hôtes de rubrique différents, envisagez de définir le même objet de rubrique sur plusieurs gestionnaires de files d'attente. Il en résulte un équilibrage de la charge de travail des publications sur chacune d'elles pour le routage. Toutefois, cela n'est approprié que lorsque l'ordre des messages de publication n'est pas requis.

Modification d'abonnement et chaînes de rubrique dynamiques

Une autre considération est l'effet sur les performances du système pour la propagation des abonnements de proxy. Généralement, un gestionnaire de files d'attente envoie un message d'abonnement de proxy à certains autres gestionnaires de files d'attente du cluster lorsque le premier abonnement pour une chaîne de rubrique en cluster spécifique (et pas seulement un objet de rubrique configuré) est créé sur ce gestionnaire de files d'attente. De même, un message de suppression d'abonnement de proxy est envoyé lorsque le dernier abonnement d'une chaîne de rubrique en cluster spécifique est supprimé.

Pour le routage direct, chaque gestionnaire de files d'attente avec des abonnements envoie ces abonnements de proxy à tous les autres gestionnaires de files d'attente du cluster. Pour le routage via un hôte de rubrique, chaque gestionnaire de files d'attente avec des abonnements envoie uniquement les abonnements de proxy à chaque gestionnaire de files d'attente qui héberge une définition pour cette rubrique en cluster. Par conséquent, avec le routage direct, plus il y a de gestionnaires de files d'attente dans le cluster, plus le temps système de gestion des abonnements de proxy est élevé. En revanche, avec le routage via un hôte de rubrique, le nombre de gestionnaires de files d'attente dans le cluster n'est pas un facteur.

Dans les deux modèles de routage, si une solution de publication / abonnement consiste en un grand nombre de chaînes de rubrique uniques auxquelles vous êtes abonné, ou si les rubriques d'un gestionnaire de files d'attente du cluster sont fréquemment abonnées et désabonnées, une surcharge importante est constatée sur ce gestionnaire de files d'attente, due à la génération constante de messages distribuant et supprimant les abonnements de proxy. Avec le routage direct, cela est aggravé par la nécessité d'envoyer ces messages à chaque gestionnaire de files d'attente du cluster.

Si le taux de modification des abonnements est trop élevé pour être adapté, même au sein d'un système routé par un hôte de rubrique, voir Performances des abonnements dans les réseaux de publication / abonnement pour plus d'informations sur les moyens de réduire le temps système d'abonnement du proxy.