Aujourd’hui, nous allons présenter l’architecture Weblogic en cluster et par là-même démystifier les concepts de l’Unicast ou Multicast.
Les servers inscrits dans un cluster Weblogic communiquent les uns avec les autres par messages.
Ces messages permettent de notifier leurs états respectifs, de partager la session, la distribution JMS, l’équilibrage de charges, etc.
La notion d’Unicast ou de Multicast décrit la technologie de diffusion de ces messages :

• Lorsque la diffusion est Unicast, le cluster gère la diffusion des messages vers chaque nœud inscrit. Cette gestion est déléguée à des serveurs « leader » qui reçoivent les notifications des membres de son groupe et qui transmet l’information aux autres chefs de groupes. Plusieurs groupes sont créés pour consolider les serveurs et un leader est désigné pour chaque groupe. Le leader reçoit donc les notifications des autres serveurs de son groupe puis communique l’état à un autre leader qui gère son propre groupe. On peut donc traduire cette notion par « monodiffusion ».

• Lorsque la diffusion est Multicast, chaque serveur communique individuellement avec chacun des autres membres du cluster : il transmet donc ses notifications aux autres serveurs. Le premier serveur envoie son message à tous les autres serveurs, le second fait de même et ainsi de suite. La diffusion Multicast peut se traduire littéralement par « multidiffusion ».

Première remarque

La fréquence de communication en mode monodiffusion est similaire à celle de la multidiffusion.

Seconde remarque

En communication Multicast, l’envoi des « ping » est beaucoup plus nombreux qu’en Unicast, ce qui peut entrainer une charge importante pouvant à aller jusqu’à la saturation du tampon de diffusion, la non-transmission de paquets et peut donc amener le cluster à rejeter des instances de serveur qui ne sont alors plus accessibles au cluster.

Troisième remarque

A ce stade, le Multicast semble s’imposer : si un paquet est envoyé au cluster contre un paquet (environ) par serveur en Unicast, c’est évidement plus simple : il devrait y avoir moins de trafic réseau… En fait, pas nécessairement et c’est lié intrinsèquement et directement au concept de l’architecture multidiffusion : la notion d’abonnement. En fait, le Multicast permet à plusieurs applications de s’abonner à une adresse IP et à un numéro de port pour écouter les messages. En multidiffusion, l’exigence matérielle est donc plus forte (réseau, datagrammes UDP, membres du cluster sur le même segment de réseau, …) et une configuration spécifique est à faire. En Unicast, les messages sont routés (sockets TCP/IP).

« Faut-il utiliser Unicast plutôt que Multicast dans un cluster WebLogic ? »
Et bien, il n’y a pas de réponse immédiate car cela va dépendre de beaucoup de paramètres :

• Le premier est bien entendu votre réseau où l’Unicast peut être une réponse aux pertes de paquets.
• Cela dépend également des contraintes de compatibilité où Unicast est rétrocompatibilité avec les versions Weblogic anciennes (<10).
• Multicast est aussi plus compliqué à configurer.
• Multicast est aussi privilégié avec un grand nombre de servers (>10).
• …

« L’article a vulgarisé les concepts Unicat vs. Multicast mais ne m’a pas permis de poser un choix ! »
En effet, l’arbitrage n’est pas automatique.
La technologie est passionnante et permet de comprendre le fonctionnement interne du cluster Weblogic.
Je vous invite à approfondir le sujet en vous documentant et en partageant avec des experts.
« Oui, mais je veux démarrer sur les architecture cluster Weblogic et ses technologies ».

Lancez-vous !

Out of the box, l’installation de votre cluster Weblogic se fera en Unicast qui est le protocole par défaut. Il est susceptible de répondre à la majorité des besoins. L’élection du chef de groupe se fera automatiquement. Une fois les notions intégrées, il sera bien temps de passer à un cluster Multicast.

Oracle supporte les deux architectures et Easyteam peut vous accompagner dans leurs mises en œuvre.