Hervé GERARD's JEE, MDA, SOA blog

J’ai lu l’autre jour que les EAI offraient plus de valeurs métier que les ESB. Outre que ce n’est certainement pas faux puisque je ne pense pas qu’un ESB isolé apporte la moindre fonctionnalité métier (excepté peut-être de la traçabilité ou le passage d’une logique batch à une logique temps réel), je suis tout de même surpris de vouloir comparer deux briques techniques dans des domaines où elles ne sont pas maîtresses.

ESB et SOA

Pourtant, je vais tout de même me risquer à commenter cette phrase. Pour moi, les ESB, s’il n’apporte effectivement pas de réelles fonctions métier, se mettent en place avec une démarche de type SOA. C’est ici je pense la principale différence entre les EAI et les ESB. Ces derniers se focalisent sur les différents niveaux de services dans un système d’information et sur leur réutilisation. Pour ce faire, les ESB viennent avec une démarche d’identification de services et une architecture fonctionnelle urbanisée globale, où chaque silo applicatif est défini principalement pour un métier de l’entreprise. C’est ici que résident leur réalité économique avec finalement la capacité d’offrir par exemple des applications composites. Pour ma part, je ne pense pas que les EAI viennent avec ce type de démarche ou de préoccupations. La finalité étant de pouvoir connecter deux applications entre-elles afin de pouvoir récupérer des données et non de réutiliser des services.

Au final, si on compare non pas les ESB et les EAI mais la démarche globale d’introduction d’un ESB et les EAI, je pense que c’est cette démarche SOA qui apporte le plus de valeur métier.

Si le BPM est l’élément central de délégation (oui, une explication est certainement nécessaire…) et le BRMS l’élément central fonctionnel, les bus représentent les éléments centraux techniques. S’ils n’apportent aucune plus-value métier (oui une explication…) ils sont en revanche nécessaires pour organiser et superviser les services offerts par l’ensemble des silos métier. (BPM et BRMS inclus). Pour cela, nous devons assurer la disponibilité maximale de cet élément technique. Si Petals offre la capacité à constituer des clusters par ses topologies, la ferme constituée contient un SPOF qui est le nœud maître. Sous Linux, nous pouvons rapidement paramétrer un cluster Actif/Passif sur le nœud maître à l’aide des logiciels Pacemaker et Corosync de la communauté LinuxHA. Je vous propose une petite installation de ces soft avec Petals sous Fedor 12. Elle n’est bien sûr pas parfaite (ah bon, l’utilisation de root n’est pas une bonne idée !?) mais offre déjà une bonne base pour la suite… et est particulièrement performante. Toute idée d’amélioration est donc la bienvenue !!

1. Télécharger Petals 3.0.5
2. En root : yum install -y openais pacemaker

Sont installés : pacemaker 1.0.7, openais 1.1.3

1. En root, unzip petals-platform-3.0.5.zip -d /opt/
2. chown "user" -R /opt/petals-platform-3.0.5/
3. Fixer dans le fichier .bashrc la variable JAVA_HOME : export JAVA_HOME=/etc/alternatives/jre
4. Bien démarrer , Petals en démon : startup.sh -D
   1. Pour l'instant, ne pas démarrer Petals, c'est pacemaker qui le fera.
   2. Bien paramétrer les firewall sur chaque machine (je les ai supprimés….) et le niveau de SELinux (que j'ai mis en permissif)
5. Renommer le fichier /etc/corosync/corosync.conf.example en corosync.conf et remplacer les éléments suivants (le premier est vraiment contextuel) :
   1. bindnetaddr : 192.168.56.0
   2. mcastaddr : 226.94.1.1
   3. mcastport : 5405
6. Renseigner le fichier /etc/hosts avec l'ensemble des adresse et des noms des nœuds du cluster
7. Paramétrer les fichiers /etc/hosts pour prendre en compte les noms réseaux
8. Demander à corosync de démarrer Pacemaker en créant un fichier pcmck sous /etc/corosync/service.d

@@service {

        # Load the Pacemaker Cluster Resource Manager
        name: pacemaker
        ver:  0
}

@@

1. Démarrer openais : /etc/init.d/corosync start
2. Vérifier dans /var/log/messages si les deux nœuds se voient bien

grep CLM /var/log/messages

1. Vérifier avec crm configuration show
   1. il faut que Pacemaker soit démarré pour cela.
   2. Pacemaker a besoin d'avoir un fichier hosts renseigné avec le nom et l'adresse des nœuds sur chacun des nœuds.
2. Comme il n'y a pas de synchronisation de données entre les nœuds, Stonith peut être désactivé :
   1. crm configure property stonith-enabled=false
3. Avec crm_mon, on affiche l'état du cluster
4. On peut maintenant créer une adresse IP virtuelle pour effectuer notre cluster Actif / Passif :
   1. crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params ip=192.168.56.50 cidr_netmask=32 op monitor interval=30s
   2. Pour un cluster actif/passif avec 2 nœuds, il est nécessaire de demander à Pacemaker de ne pas activer le principe de quorum : crm configure property no-quorum-policy=ignore
   3. On peut ensuite vérifier sur quelle machine l'adresse IP est active : crm resource status ClusterIP
5. Lors d'un arrêt puis un redémarrage d'un nœud du cluster, il peut être intéressant de demander à Pacemaker de laisser la ressource lancer sur le backup actif et de ne pas arrêter le backup pour activer la ressource initiale lors de son redémarrage. C'est particulièrement utile pour des ressources lentes à démarrer (Oracle) ou qui nécessitent des jeux de sticky session (tomcat).
   1. Pour laisser la ressource active sur le même serveur, il faut spécifier que le coût d'un arrêt n'est pas nul : crm configure rsc_default resource-stickiness=100
6. Pour attacher la supervision de pacemaker et de Petals, il faut utiliser l'agent "anything"
   1. Petals doit être installé sur les deux nœuds.
   2. Repositionner JAVA_HOME dans setenv.sh (??)
   3. Le script "petals-esb" doit fournir son pid :
      1. Echo $! > /opt/petals-platform-3.0.5/logs/petals.pid
      2. A positionner juste après le démarrage du service
   4. crm configure primitive esbPetals ocf:heartbeat:anything params binfile="/opt/petals-platform-3.0.5/bin/petals-esb" pidfile="/opt/petals-platform-3.0.5/logs/petals.pid" logfile="/var/log/esbPetals.log" cmdline_options="start" op monitor interval="15s"
   5. Bien s'assurer que l'adresse IP tourne sur la même machine que le bus
      1. crm configure colocation esb-with-vip INFINITY: esbPetals ClusterIP
      2. crm configure order petals-after-ip mandatory: ClusterIP esbPetals

Ce qu'il reste comme axes d'amélioration :

1. Si on fait un kill -9 sur corosync sur le nœud actif, Petals démarre bien sur l'autre nœud mais ne s'arrête pas sur le premier nœud. Ce n'est pas si gênant car l'adresse IP virtuelle pointe bien sur l'autre nœud. De plus, au redémarrage de corosync sur le premier nœud, Petals est bien arrêté puis redémarré proprement. (vive le pid de Petals ?)
2. Il faudrait spécifier une machine préférée pour les ressources (pour un cluster à 2 nœuds, le chiffre 50 est arbitraire…)
   1. crm configure location prefer-fedoraesb esbPetals 50: fedoraesb.telsendomain
3. Démarrer avec root n'est pas génial…
4. Les fichiers de log de petals ne sont pas vidés
5. Reste un message d'erreur dans la console crm_mon
   1. Failed actions: esbPetals_monitor_0 (node=esbBackup, call=3 rc=1 status=complete): unknown error