Concepts HA WMQ

Depuis plusieurs années, la Haute Disponibilité MQ dans les environnements Windows et Unix est basée sur les éléments suivants :

• Deux serveurs distincts, avec le logiciel WMQ installé
• Un stockage externe (type baie SSA, baie SAN, ...)
• Une configuration spécifique du Queue Manager, pour stocker les files d’attente et les logs sur le stockage externe
• Des outils comme un logiciel de Haute Dispo (HACMP, MSCS, Veritas, ...) et/ou des scripts (Support Pack MC91 par exemple)

Ces outils permettent :

• de détecter la perte du QM sur le serveur nominal
• de basculer les volumes disques vers le serveur de backup
• de basculer l’adresse IP (VIP) vers le serveur de backup
• de relancer le QM sur le serveur de backup

Apports de la version 7.0.1

La version 7.0.1 de WMQ apporte la fonction de QM de standby, avec bascule automatique. De plus, de nouveaux paramètres dans la définition du canal permettent à un QM partenaire d’atteindre soit le QM nominal, soit le QM de backup, sans avoir à basculer l’IP.
Sur un plan matériel, il est toujours nécessaire de disposer de deux serveurs distincts et d’un stockage réseau. Ce stockage doit se conformer à un certain nombre de spécifications, comme la capacité à libérer les fichiers verrouillés en cas d’arrêt de l’application qui les verrouille. Un exemple est NFS4.

Pour un QM partenaire, l’existence d’un QM de bascule est paramétrée en indiquant dans le CONNAME du canal sender les deux hostnames, séparés par une virgule si le QM partenaire est en 7.0.1. Exemple :

Si le QM partenaire est en 6.0, l’utilisation du SupportPack MR01 a un effet identique.

Mise en œuvre

Le principe de la mise en œuvre est le suivant :

Vérification de la compatibilité du file system
La première étape consiste à vérifier la compatibilité du système de fichiers utilisé avec le multi-instance.

• Sur chaque serveur, on lance la commande :

Ceci permet de vérifier la capacité du système de fichiers à supporter les locks demandés par WMQ

• Ensuite, simultanément sur les deux serveurs, on lance la commande :

Ceci permet d’effectuer un test d’écriture concurrente.

Création du Queue Manager
Cette création n’est à effectuer que sur un des serveurs. On commence par créer les systèmes de fichiers pour MQ, par exemple :

On crée ensuite le Queue Manager avec la commande classique, sans oublier de spécifier des logs linéaires !

Création de l’instance de backup
Sur le deuxième serveur, il faut créer le Queue Manager de backup, mais avec la commande addmqinf.
Le plus simple est d’utiliser la commande dspmqinf sur le premier serveur, qui donne la syntaxe à utiliser pour créer l’instance de backup sur le deuxième serveur :

Démarrage du Queue Manager
Sur un des serveurs (n’importe lequel en fait), démarrer le Queue Manager en mode fail-over :

Sur l’autre serveur, démarrer le Queue Manager en mode fail-over :

Vérification du fonctionnement

Vérification sur le premier serveur :

Vérification sur le deuxième serveur :

Bascule fail-over

Sur le premier serveur :

Vérification sur le premier serveur :

Vérification sur le deuxième serveur :

Arrêt du Queue Manager

Sur le serveur où le Queue Manager s’exécute :

Ceci arrête le QM actif ET l’instance de backup.

Conclusion

Cette nouvelle fonction apportée par la version 7.0.1 de WebSphere MQ permet de mettre en œuvre, relativement facilement, un mécanisme de Haute Disponibilité MQ entre deux serveurs.
Le niveau de fonctionnalité obtenu est certes moins élevé qu’avec des logiciels spécialisés comme HACMP, mais pour la plupart des cas cela est suffisant.