Déterminer le statut d’un QMMI via REST

Depuis plus de 10 ans (MQ version 7.0.1), il est possible de configurer un Queue Manager en mode multi-instance (QMMI) :

• Sur le serveur 1, le Queue Manager est en statut « actif », et assure les fonctions de messaging

• Sur le serveur 2, le Queue Manager est en statut « stand-by », prêt à prendre la relève de l’instance active si nécessaire.

Les logs et files d’attente sont stockées sur un espace disque partagé :

Cette solution technique, une fois bien configurée, fonctionne parfaitement et apporte de nombreux avantages :

• En cas d’arrêt du serveur 1, le serveur 2 reprend la production dans un délai très court (< 1 mn)

• En cas de maintenance (matériel ou logicielle), il est possible d’intervenir sur l’un des serveur, tandis que la production se fait sur l’autre. Pratique pour installer les fixpacks MQ ou les correctifs OS en journée.

• Les canaux DQM et MQ Client, s’ils sont bien configurés, basculent automatiquement vers l’instance active.

Il y a quand même quelques inconvénients :

• Lorsque l’on doit passer une commande MQSC sur le Queue Manager, il faut au préalable déterminer quel est le nœud actif

• Si le nœud actif tombe, le Queue Manager bascule automatiquement sur le nœud standby. Mais il faut une opération manuelle pour relancer une instance standby sur le premier nœud.
  Il faut donc mettre en place une procédure qui permet :
  • de déterminer quel est le nœud actif
  • de vérifier qu’il y a bien une instance active et une instance standby pour le Queue Manager

La première solution est de se connecter, via SSH ou TSE, sur les deux nœuds, et de lancer la commande dspmq -x.
Ce n’est pas très pratique à réaliser, ni forcément possible pour des raisons de sécurité.

J’ai recherché une solution basée sur l’utilisation d’un client MQ, et d’une commande runmqsc -c (mode client).
Cette commande permet de déterminer le nœud actif, mais malheureusement ne permet pas de distinguer un Queue Manager en statut standby d’un statut stopped.
Ce n’est donc pas la bonne solution.

En poursuivant mes tests, j’ai vu que l’API REST admin d’IBM MQ permettait de récupérer le statut des Queue Managers, à condition d’avoir une instance du serveur mqweb configurée et démarrée sur le serveur hébergeant les Queue Managers..

mqweb, disponible depuis la version 9.1, est un petit serveur d’applications, basé sur Liberty, qui permet d’administrer IBM MQ via une console web (MQ Console) ou des API REST.

Parmi les API disponibles, il est possible d’interroger l’état du ou des Queue Managers présents sur un serveur. Ceci peut être fait à distance, par exemple depuis un poste d’administrateur ou un serveur dédié à la surveillance de l’infrastructure.

Une des solutions pour manipuler ces API est l’utilisation du package open source cURL, disponible sur Linux et Windows : https://curl.se/

Par exemple la commande :

curl -k https://grim:9443/ibmmq/rest/v2/admin/qmgr -X GET -u mqadmin:mqadmin

renvoie :

{"qmgr": [
{
"name": "DC101",
"state": "running"
},
{
"name": "LMD915",
"state": "endedImmediately"
},
{
"name": "DCKT01",
"state": "running"
},
{
"name": "DCKT02",
"state": "ended"
}
]}

On voit qu’il y a ici 4 Queue Managers, 2 en status « running« , un en statut « endedImmediately » et le dernier en statut « ended« .

Il est possible d’interroger le statut d’un Queue Manager spécifique :

curl -k https://grim:9443/ibmmq/rest/v2/admin/qmgr/DC101 -X GET -u mqadmin:mqadmin

Réponse :

{"qmgr": [{
"name": "DC101",
"state": "running"
}]}

Le résultat est en format json, qui s’il est lisible, n’est pas très pratique à afficher. Il faut donc parser le résultat pour récupérer la valeur de l’attribut « state ».

L’outil généralement utilisé pour parser du json est « jq » (https://stedolan.github.io/jq/), autre outil open-source disponible entre autres sous linux & Windows.

En pipant le résultat du curl dans un filtre jq :

curl -k –silent https://grim:9443/ibmmq/rest/v2/admin/qmgr/DC101 -X GET -u mqadmin:mqadmin | jq « .qmgr | .[0] | .[\ »state\ »]? »

On obtient:

"running"

Ce qui est le résultat attendu.

Les différents status possibles pour un Queue Manager sont :

running
ended
endedImmediately
endedPreemptively
endedUnexpectedly
starting
quiescing
endingImmediately
endingPreemptively
beingDeleted
stateNotAvailable
runningAsStandby
runningElsewhere

Dans le cas du Queue Manager multi-instance, il faut donc vérifier que sur l’un des nœuds, le Queue Manager est en statut « running« , et que sur l’autre nœud, il est en statut « runningAsStandby« .

Si le statut est différent, cela signifie qu’en cas d’arrêt de l’instance MQ sur le premier serveur, le second serveur ne prendra pas la relève et que la production sera affecté.

L’extrait de script ci-dessous (syntaxe Windows) interroge le statut d’un QMMI sur les deux nœuds de la configuration, et affiche le résultat de manière lisible :

echo *** Determination du statut d'un QMMI ****
set QM=DCXR01
set IP1=https://192.168.50.86:9443
set IP2=https://192.168.50.87:9443
echo Status of %QM% on %IP1% :
curl -k --silent %IP1%/ibmmq/rest/v2/admin/qmgr/%QM% -X GET -u mqadmin:mqadmin | jq ".qmgr | .[0] | .[\"state\"]?"
echo ***
echo Status of %QM% on %IP2% :
curl -k --silent %IP2%/ibmmq/rest/v2/admin/qmgr/%QM% -X GET -u mqadmin:mqadmin | jq ".qmgr | .[0] | .[\"state\"]?"
echo ***

Résultat de la commande :

On voit donc que l’API REST d’IBM MQ est une alternative intéressante pour administrer IBM MQ en général, mais dans ce cas précis de déterminer l’instance active d’un QMMI.

Cette même approche est d’ailleurs utilisée dans certains produits comme Centreon dans le cadre d’outils de monitoring.