MQ High-Availability AIX - Linux Guide MQ – 26/09/2017 Guillaume GELB

Sommaire Introduction HA sur couche OS HA sur couche Middleware HA sur couche Applicative Dans la pratique

Introduction La notion de HA n'a, pour moi, de sens que lorsqu'on identifie : Le risque que l'on souhaite écarter La réelle granularité de criticité des flux que l'on transporte porte Le niveau de service que l'on souhaite offrir Les moyens que l'on souhaite se donner Une bonne pratique est souvent de mixer les designs

HA sur couche OS Nature du risque : Conséquence : Perte de la machine / centre de calcul Conséquence : Unexpected End du QMGR Redémarrage du QMGR nécessaire sur l'autre OS Indisponibilité du service Gestion du failover / failback : Au niveau Système Au niveau Middleware (si non automatique) Failback souvent manuel

Version 1 (AIX) Installation des binaires MQ sur les 2 machines 1 seule IP applicative pour le groupe 1 seule création de QMGR sur storage SAN PowerHA / HACMP gère le trigger Bascule de l'IP sur l'autre AIX Détachement / Attachement des VG contenant : /var/mqm LogPath DataPath Auto-Restart MQ au boot de la machine passive

Version 2 (AIX) Installation des binaires MQ sur 1 seule des machines 1 seule IP applicative pour le groupe 1 seule création de QMGR sur storage SAN PowerHA / HACMP gère le trigger Bascule de l'IP sur l'autre AIX Détachement / Attachement des VG contenant : /var/mqm /usr/mqm /etc/opt/mqm/mqinst.ini LogPath DataPath Auto-Restart MQ au boot de la machine passive

Inconvénients Inconvénient : V1 → 2 installations = 2 fixes, 2 montées de version… Nécessité d'un paramétrage de reconnexion client automatique (WAS, DataPower …) Certaines connections échouent, car même si l'IP a basculé, elles gardent en cache la route vers l'ancien host. Redémarrage manuel nécessaire du composant client

HA sur couche Middleware Depuis la version 7.0.1 Prérequis storage GPFS – NFS v4

MQ Multi-Instance Nature du risque : Conséquence : Perte de la machine / centre de calcul Crash du QMGR Perte de visibilité du disque partagé par l'actif Conséquence : Messages erreur dans les clients Gestion du failover / failback : Automatique au niveau Middleware Failback manuel si pas de trigger sur l'absence de process

MQ Multi-Instance 2 installations de binaires 2 IPs Applicatives 1 seule création de QMGR et une « déclaration » FS Partagé Gestion des commandes légèrement différente Double adressage à paramétrer

Inconvénients 2 installations = 2 fixes, 2 montées de version… Interventions sur le GPFS – NFS compliquée si mutualisé

HA sur couche Applicative Clustering MQ, avec définitions multiples Nature du risque : Crash du QMGR Conséquence : Perte du QMGR impacté ainsi que des messages y étant physiquement localisés Gestion du failover / failback : N/A Il ne s'agit pas de haute disponibilité à proprement parler, mais plutôt d'une fonctionnalité permettant d'améliorer la montée en charge et la tolérance à la panne. A combiner avec un autre design HA réel

Dans la pratique Nos vieux QMGRs de prod en OS V1 Nos nouveaux QMGRs de prod en OS V2 Nos QMGRs critiques en MQ HA Nos QMGRS IIB en OS V2 + Cluster Queues