Red Hat Training
A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform
18.13.4. Équilibrage des charges côté serveur
Il y a une topologie de clusterisation importante :
- Cluster symétrique : dans un cluster symétrique, chaque noeud de cluster est connecté directement à chaque noeud du cluster. Pour créer un cluster symétrique, chaque noeud du cluster définit une connexion de cluster avec l'attribut
max-hops
défini sur 1.Note
Dans un cluster symétrique, chaque nœud connaît toutes les files d'attente qui existent sur tous les autres nœuds et les consommateurs qu'ils ont. Avec ces connaissances, il peut déterminer comment équilibrer la charge et redistribuer les messages vers les nœuds.
18.13.4.1. Configuration des connexions du cluster
Les connexions du cluster sont configurées dans les fichiers de configuration du serveur (
Lorsque vous créez des connexions entre les noeuds d'un cluster pour former une connexion de cluster, HornetQ utilise un cluster utilisateur et un mot de passe de cluster qui est défini dans les fichiers de configuration de serveur (
standalone.xml
et domain.xml
) dans l'élément cluster-connection
. Il peut y avoir zéro ou plusieurs connexions définies par serveur HornetQ.
<cluster-connections> <cluster-connection name="my-cluster"> <address>jms</address> <connector-ref>netty-connector</connector-ref> <check-period>1000</check-period> <connection-ttl>5000</connection-ttl> <min-large-message-size>50000</min-large-message-size> <call-timeout>5000</call-timeout> <retry-interval>500</retry-interval> <retry-interval-multiplier>1.0</retry-interval-multiplier> <max-retry-interval>5000</max-retry-interval> <reconnect-attempts>-1</reconnect-attempts> <use-duplicate-detection>true</use-duplicate-detection> <forward-when-no-consumers>false</forward-when-no-consumers> <max-hops>1</max-hops> <confirmation-window-size>32000</confirmation-window-size> <call-failover-timeout>30000</call-failover-timeout> <notification-interval>1000</notification-interval> <notification-attempts>2</notification-attempts> <discovery-group-ref discovery-group-name="my-discovery-group"/> </cluster-connection> </cluster-connections>Le tableau suivant décrit les attributs configurables :
Tableau 18.13. Attributs configurables de connexions de cluster
Attribut | Description | Par défaut |
---|---|---|
address | Chaque connexion de cluster ne s'applique qu'aux messages envoyés à une adresse qui commence par cette valeur. L'adresse peut être n'importe quelle valeur et vous pouvez avoir plusieurs connexions au cluster avec des valeurs différentes des adresses, équilibrant simultanément les messages de ces adresses, potentiellement à différents clusters de serveurs. Cela n'utilise pas de correspondance de wild-card. | |
connector-ref | C'est un attribut obligatoire qui fait référence à un connecteur envoyé dans d'autres noeuds du cluster pour qu'ils adoptent la topologie de cluster qui convient. | |
check-period | Il s'agit d'une durée (en millisecondes) utilisée pour vérifier si une connexion de cluster a manqué des pings en provenance d'un autre cluster. | 30 000 millisecondes |
connection-ttl | Indique la durée pendant laquelle une connexion de cluster doit rester vivante s'il cesse de recevoir des messages en provenance d'un noeud spécifique du cluster. | 60 000 millisecondes |
min-large-message-size | Si la taille du message (en octets) est plus élevée que cette valeur, alors il sera divisé en plusieurs segments après avoir été envoyé à d'autres membres du cluster du réseau. | 102400 octets |
call-timeout | Indique la durée (en millisecondes) pendant laquelle un paquet envoyé sur une connexion de cluster doit attendre (une réponse) avant de lancer une exception. | 30 000 millisecondes |
retry-interval | Si la connexion de cluster est créée entre les noeuds d'un cluster et que le noeud cible n'a pas été démarré ou doit être redémarré, les connexions de cluster d'autres nœuds retenteront de se reconnecter à la cible jusqu'à ce qu'il revienne. Le paramètre retry-interval définit l'intervalle (en millisecondes) entre les tentatives. | 500 millisecondes |
retry-interval-multiplier | Utilisé pour incrémenter retry-interval après chaque tentative | 1 |
max-retry-interval | Se réfère à la durée maximum (en millisecondes) des nouvelles tentatives | 2000 millisecondes |
reconnect-attempts | Définit le nombre de fois que le système va essayer de connecter un noeud au cluster | -1 (infinite retries) |
use-duplicate-detection | Les connexions au cluster utilisent des ponts pour relier les nœuds, et les ponts peuvent être configurés pour ajouter une propriété id en double dans chaque message qui est transmis. Si le nœud cible du pont se bloque et puis récupère, les messages peuvent être renvoyés à partir du nœud de la source. En permettant la détection des doublons, tous les messages en double vont être filtrés et ignorés lors de la réception au niveau du nœud cible. | True |
forward-when-no-consumers | Ce paramètre détermine si oui ou non les messages seront distribués de façon alternée entre d'autres nœuds du cluster indépendamment du fait qu'ils puissent correspondre à un consommateur sur d'autres nœuds | False |
max-hops | Détermine comment les charges de messages sont équilibrées sur d'autres serveurs HornetQ connectés à ce serveur. | -1 |
confirmation-window-size | La taille (en octets) de la fenêtre utilisée pour envoyer des confirmations du serveur connecté à | 1048576 |
call-failover-timeout | Utilisé quand un appel est fait lors d'une tentative de basculement | -1 (no timeout) |
notification-interval | Détermine la fréquence (en millisecondes) à laquelle la connexion du cluster doit se diffuser quand elle s'attache au cluster. | 1000 millisecondes |
notification-attempts | Définit le nombre de fois que la connexion du cluster doit se diffuser quand elle se connecte au cluster. | 2 |
discovery-group-ref | Ce paramètre détermine quel groupe discovery est utilisé pour obtenir la liste des autres serveurs du cluster vers laquelle la connexion de cluster va faire des connexions |
standalone.xml
et domain.xml
) :
<cluster-user>HORNETQ.CLUSTER.ADMIN.USER</cluster-user> <cluster-password>NEW USER</cluster-password>
Avertissement
Il est important de changer les valeurs par défaut de ces informations d'identification pour empêcher les clients distants d'effectuer les connexions au serveur en utilisant les valeurs par défaut.