Connecteur de transport ActiveMQ HTTP à charge équilibrée avec HAProxy

Connecteur de transport ActiveMQ HTTP à charge équilibrée avec HAProxy

Premier billet d’une série consacrée au courtier de messages ActiveMQ. Nous aborderons, dans ces lignes, les spécificités liées au cloud et notamment Active MQ HTTP / HAProxy. Bonne lecture !

Adaptation de l’article :  « ActiveMQ HTTP transport connector load balanced with HAProxy» du blog Nanthrax écrit par Jean-baptiste Onofré (Technical Advisor)

yupiik-apache-activemq

Si vous utilisez ActiveMQ, vous utilisez certainement le connecteur de transport TCP (configuré par défaut) dans le fichier conf/activemq.xml :

<transportConnectors>
    <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
</transportConnectors>

ActiveMQ fournit également d’autres connecteurs de transport pour certains protocoles particuliers (amqp, mqtt, stomp) ou des transports particuliers.

En particulier, il supporte un connecteur de transport très pratique pour passer au travers de pare-feu : le connecteur de transport http (et étendu de http comme https, etc.).

Il est donc possible d’équilibrer la charge des connexions HTTP. Cependant, nous ne pourrons pas équilibrer les messages : nous avons besoin d’un réseau de courtiers à cet effet, (voir d’autres articles du blog à ce sujet).

Toutefois, le transport HTTP est basé sur le protocole openwire. Il ne s’agit donc pas seulement d’une requête HTTP pour envoyer un message : le client doit envoyer plusieurs requêtes HTTP pour établir la connexion.

Fondamentalement, le client fait d’abord une requête HEAD HTTP (pour obtenir l’option du connecteur de transport, comme si la compression Gzip est supportée ou non). Ensuite, il envoie une série de requêtes GET HTTP. Pour chaque requête GET, le courtier ActiveMQ répondra à la version du protocole openwire, à la topologie du broker, etc.

La corrélation entre chaque requête HTTP est basée sur un en-tête HTTP : le clientID. Le connecteur HTTP ActiveMQ maintient une carte des clients, avec leur état actuel, basée sur le clientID.

Si nous voulons équilibrer les requêtes HTTP, nous ne pouvons pas utiliser un simple round-robin sur chaque requête. Au lieu de cela, nous devons trouver un équilibre entre les deux :

  1. l’adresse IP du client: toutes les requêtes entrantes pour une adresse IP seront acheminées au même broker ActiveMQ.
  2. Le header clientID : toutes les requêtes entrantes avec le même header clientID seront acheminés au même broker ActiveMQ

Nous allons utiliser le header HTTP clientID avec HAProxy.

Imaginez donc que vous ayez deux brokers ActiveMQ. Chaque courtier expose un connecteur de transport HTTP. Cela signifie que vous avez :

  • amq1 est en cours d’exécution sur 192.168.134.2, avec le connecteur de transport HTTP lié à 8282 par exemple
  • amq2 est en cours d’exécution sur 192.168.134.3, avec le connecteur de transport HTTP lié à 8282 par exemple

Nous pouvons « façader » ces deux brokers ActiveMQ avec HAProxy. La configuration HAProxy ressemble à ceci :

listen balance
  bind *:80
  mode http
  balance hdr(clientID)
  server amq1 192.168.134.2:8282
  server amq2 192.168.134.3:8282

La plus grande part de configuration est celle de la balance, où vous pouvez voir l’utilisation du header clientID pour l’affinité d’équilibrage

Dans le prochain article, nous verrons comment utiliser Hazelcast pour traiter l’affinité clientID.

Bloqué dans vos roadmaps ?

Vous souhaitez former vos équipes ?

fr_FRFrançais
en_GBEnglish (UK) fr_FRFrançais