Guide WAS / MQ

Guide
WAS / MQ
Présentation de l’architecture OSEO
(Interconnexion WAS / MQ)
Avril 2010
Sommaire
• Rappel MQ et SiBUS
• Contexte
• Architecture Technique
• Architecture Technique Détaillé / Config
• Haute Disponibilité
• Retour expérience Oséo
• Débats, Questions…
2
Rappel des éléments
• WebSphere MQ :
WebSphere MQ est un service de messagerie inter-applicative
articulé autour Gestionnaires de files (Queue manager), Channels , Files d’attentes,
process, etc …permet l’échange d’informations et l’exécution de transactions entre un
grand nombre de plates-formes d’exploitation différentes (Windows, Unix, Linux, IBM
mainframe et moyens systèmes)
• SiBUS : depuis la v6 en 2005, WAS intègre son propre moteur de
messages parfois appelé :
SiBUS (Service intégrateur BUS)
Default Messaging Provider
Messaging Bus
SIBus fournit un support natif dans WAS pour l’échange de messages JMS, il comprend 1
à n Messaging Engine (ME) qui gère les ressources : les destinations « queues »
3
Rappel des éléments
Le Serveur de messagerie applicative ou Messaging Engine (ME)
Le Messaging Engine est un nouveau module disponible avec la version 6 de WAS. Il se comporte, de
manière externe, comme un Queue Manager, avec ses channels sender, receiver, client. On peut y définir
des files d’attentes locales ou éloignées.
WAS v6.1 ajoute la possibilité de définir un « MQServer »
Attention ! Le WAS « MQServer » s’appuie sur….. Un MQ Client !
4
Contexte
Différentes configurations possibles s’offrent à WAS :
1) SIBus « pur » - messages restent dans le monde SIBus
2) SIBus communiquant avec MQ – MQLink, MQServer, Foreign bus
3) WAS s’appuyant sur MQ Queue Manager local, dit mode « bindings »
4) S’appuyant sur MQ Client : WAS, batch, client MQ
Le Service integration buses (SIBus)
Infrastructure évolué pour les applications orienté service ou messages
Ensemble de serveurs interconnectés à un bus message (Messaging Bus)
Facilite l’échange des messages inter applicatifs
Fourni une fonction intégrée pour les messages asynchrones
Connectivité MQ améliorée
Topologie transparente pour les applications
5
Contexte
Offrir une architecture inter opérable entre les différentes applications :
Flux applicatif
Serveur d’appli
jndi locale/ distante
File d’entrée
ME ou MQ
File de sortie
ME ou MQ
Serveur d’appli
MDB
ME
ME ou MQ
Serveur de Batch
MQ
ME ou MQ
Client
MQ
ME ou MQ
6
Contexte
WebSphere MQ
Plates-formes
supportées
Langages de
développement
Env. gestionnaires
de Transaction
Fonctionnalités
Les principaux (z/OS,i5/OS, AIX,
Linux,Solaris, HP-UX,Windows) + 30
d’autres (eg. OpenVMS, Tandem,TPF,
VSE, etc.)
Les principaux (z/OS,i5/OS,
AIX, Linux,Solaris, HPUX,Windows)
Java (JMS + base), C, C++, PL/I,
COBOL,Assembler, GAP, VB,etc…
Java (JMS WAS)
WAS, IMS, CICS, MQ
WAS
Bcp d’options : segmentation, group,
messages, compression, convertion, etc
…
Message < 100 Mo
Persistance
Milieu
SIBus
Message < 40 Mo
DB par JDBC (et fichiers à
partir dev6.1)
Fichiers
Hétérogène
J2EE
7
Architecture Technique
Cellule WebSphere
Client MQ
SIBus
Serveur A
Cluster MQ
Frontal MQ Cluster MSCS
Serveur MQ 1
ME
MESSAGING ENGINE
(Actif)
BASE DE
DONNEES
MESSAGES
HA Manager
Serveur B
Serveur MQ
MVS
QMGR 1
(Actif)
WAS
MQLink
+
Exits MQ
MR01
Serveur MQ
Windows
Serveur MQ 2
QMGR 1
(Passif)
ME
MESSAGING ENGINE
(Passif)
SAN
Serveur MQ
Windows
Serveur MQ
Windows
Données
QMGR 1
Serveur MQ
Windows
Choix d’un seul Sibus pour tous les
clusters WAS.
8
Configurations – Coté WAS
- Un Bus externe sur le SiBUS
9
Configurations – Coté WAS
- Un MQLink vers ME appelé ici « ME »
ME
10
Configurations – Coté WAS
- Un Canal Recepteur et Emetteur
QMGR1.ME
QMGR1.ME
ME.QMGR1
MQ_HOSTNAME
XXXX
11
Configurations – Coté MQ
1) Support Pack MR01 : Créé un
HA link entre WebSphere MQ et
un Service Integration Bus.
DEFINE CHANNEL(‘QMGR1.ME') +
CHLTYPE(SDR) +
CONNAME(‘hostname5(5560)') +
XMITQ(‘ME') +
MSGEXIT('mr01exit(ChannelExit)') +
MSGDATA('C:\WMQ\exits\mr01exit.txt')
DEFINE CHANNEL(‘ME.QMGR1') +
CHLTYPE(RCVR)
DEFINE QLOCAL('ME') +
USAGE(XMITQ) +
TRIGGER +
INITQ('SYSTEM.CHANNEL.INITQ') +
TRIGDATA('QMGR1.ME')
2) exemple config MR01 :
05
hostname1(5559)
hostname2(5559)
hostname3(5559)
hostname4(5559)
hostname5(5560)
hostname6(5560)
…
12
Haute Disponibilité
Le High Availability Manager (HA Manager)
HA Manager assure la haute disponibilité de certains services de type « singleton »,par
exemple : Le Transaction manager ou le Messaging provider (JMS).
HA manager à la capacité à utiliser des systèmes de stockage à tolérance de panne
(ex : NAS) et peut fonctionner en mode réparti ou principal/secours. La mise en œuvre
de HA Manager peut entraîner un « overhead ».
Le ME bénéficie des capacités du HA Manager et du Service integration buses :
• Redémarre automatiquement sur un nœud disponible
• Le contenu des queues est stocké en mémoire puis si trop volumineux dans une
base de données, locale ou distante ou fichier depuis WAS 6.1.
Le Cluster MSCS + SAN + Cluster MQ
Coté MQ, le cluster Windows assure la haute dispo via une VIP entre deux serveurs
MQ ayant une DATA commune sur le SAN.
L’exit MQ : MR01
Assure la haute dispo du lien de MQ vers WAS.
13
Retour Expérience Oseo
Nous utilisons le SIBUS dans plusieurs cas de figure :
Utilisation de files locales consommées par des applications Web ou des
MDB.
Utilisation de files distantes pour communiquer avec d’autres système ou
des applications non J2EE (Batch, MVS, Banque de France, … )
50 destinations actuellement en production sur le SiBUS
400 Files d’attentes sur WebSphere MQ
soit 450 files d’attentes au total en Prod.
14
Retour Expérience Oséo
Suivi & Administration en Production
MQ : par des scripts runmqsc, MQExplorer et Tivoli.
WAS : par des scripts Jython pour lecture, suppression et possibilité
d’agir sur une spécification d’activation (Stop/resume)
Suivi étude & Assistance Hors Production
Application « Sib Destination Handler » par IBM, permet l’injection,
import/export, suppression, lecture, déplacement de files , ..
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24021439
Ceci afin de pouvoir contrôler en un point unique les actions sur les
destinations, proscrire l’utilisation d’outil tel que JmsClient et fermer un
certain nombre de port d’écoute sur les jvm du cluster du SIbus qui sont
potentiellement des failles de sécurité.
Support Pack MO71
15
Retour Expérience Oséo
Version Client Java ou appli Web :
« Sib Destination Handler »
<?xml version="1.0" encoding="UTF-8"?>
<SIBDestHandler>
<SIBConnection bus="BUS01r"
providerEndpoints="hostname:port:BootstrapBasicMessaging"
targetTransportChain="InboundBasicMessaging">
<Queue name="NomQueueLocaleSiBUS">
<Rule>
<MatchAnyMessage/>
<DeleteAction/>
</Rule>
</Queue>
</SIBConnection>
</SIBDestHandler>
16
Retour Expérience Oséo
L’outil Java d’IBM : « Sib Explorer »
Suivi architecte :
Permet d’avoir une vision
globale de l’ensemble.
Configuration difficile
avec une cellule
sécurisée mais bien utile
par la suite.
Permet de lire, supprimer
1 à n messages.
PS : Gestion de plusieurs
environnements au sein
d’un seul outil.
http://www.alphaworks.ibm.com/tech/sibexplorer
17
Retour Expérience Oséo
Après 3 ans d’expérience, dans notre cas d’utilisation, le stockage des
messages dans une base de données n’est pas forcément justifié. Le
stockage sur fichiers en NAS semble plus approprié car plus simple à
maintenir.
Problèmes rencontrés en production :
Tablespace plein sur la base db2 stockant les messages.
Après sauvegarde de la base, mauvaise gestion du verrou excusif du
Messaging Engine sur la base.
Aucun problème de fonctionnement à la charge, en tout cas la notre :-)
PS : Attention aux messages poisons !!
18
Questions ?
Merci de votre attention…
19