J’ai eu le plaisir de suivre une formation chez Oracle University à Colombes (Paris). En tant que stagiaire, le cours s’intitulait Oracle WebLogic Administration Essential. Ce post traite de la notion de cluster WebLogic. J’y expose les avantages du clustering WebLogic, les principaux éléments à connaître ainsi qu’un exemple de configuration via la console d’administration.

Cluster weblogic :

Un cluster WebLogic est composé de 1 ou plusieurs instances weblogic qui peuvent être déposées sur 1 ou plusieurs machines différentes. Chaque instance prend en charge des fonctionnalités qui permettent d’assurer une haute disponibilité pour des serveurs entiers, des services et application Web, des applications EJB, des ressources JDBC ou encore JMS.

Les avantages de la clusterisation :

  • l’évolutivité architecturale
  • l’équilibrage de la charge (load balancer)
  • le basculement en cas d’incident

Le mode actif/actif utilisé par weblogic permet d’assurer la disponibilité, met à profit la puissance de calcul ainsi que la “scalability” (monté en charge). Les notions de cluster horizontal (disponibilité) et vertical (profit de la puissance de calcul) sont ainsi mis à profit par ce mode.

Equilibrage de la charge :

WebLogic prend en charge les algorithmes d’équilibrage de la charge tel que Round-robin, de pondération (weight based), aléatoire (random), ainsi que la notion d’affinité.

WlsAdmin1001

Création d’un cluster dans WebLogic.

La mise en place d’un cluster dans WebLogic se fait directement depuis la console d’administration ou via les outils de script WLST basés sur le language Jython. Nous décrirons ici la mise en place d’un cluster directement depuis la console d’administration :

Pour notre exemple, les éléments suivants doivent être préalablement créés

  • Serveurs gérés
  • Machines
  • Les affectations de machines et serveurs gérés
  • Les gestionnaires de noeud pour chaque machine.

Les gestionnaires de noeuds doivent préalablement être configurés pour pouvoir gérer les serveurs gérés et les redémarrer automatiquement si nécessaires.

WlsAdmin1002

Dans notre exemple, nous allons créer deux cluster hébergés sur des machines différentes. Ainsi, lorsque le cluster 1 est appelé par les requêtes des clients, celui-ci va les dispatcher entre les serveurs ManServ1 et ManServ2. Si l’un deux n’est pas disponible, les requêtes des clients seront routés vers l’autre serveur.  Les notions tels que les affinités et les réplications  ne sont pas traités dans ce post. Le but est de présenté succinctement les clusters Weblogic.

Le cluster2 peut héberger des applications et services consommés par les applications du cluster1 ou d’autres applications et services d’autres cluster.

Pour créer un cluster, depuis la console d’administration de WebLogic, selectionnez cluster dans Domain Structure :

WlsAdmin1003

Dans la liste des clusters, cliquez sur new pour ajouter un nouveau cluster

WlsAdmin1004

Donnez un nom à votre cluster et indiquez le mode de communication (par défaut unicast)

WlsAdmin1005

Cliquez sur ok et validez les changements.
Pour terminer, il faut encore lui assigner les serveurs qui feront partie du cluster nouvellement créé.

Pour se faire, sélectionnez le cluster et dans la page de propriétés onglet configuration/servers, cliquez sur add.

WlsAdmin1006

Le formulaire suivant permet d’affecter un serveur. Vous pouvez soit choisir un serveur existant ou directement en créer un nouveau:

WlsAdmin1007

Vous pouvez également affecter un serveur à un cluster si celui-ci est déjà créé depuis les propriétés du serveur géré :

WlsAdmin1008

Pour contrôler, cliquer sur le lien serveur depuis Domain Structure

WlsAdmin1009

Dans la liste des serveurs, vous avez un résumé des clusters affectés aux serveurs, les machines les hébergeant ainsi que leurs statuts.

WlsAdmin1010

Lorsque l’on démarre les serveurs, le message en vert ci-après démontre l’utilité du gestionnaire de noeud qui est chargé du démarrage des serveurs ainsi que leurs redémarrages en cas d’incident.

WlsAdmin1011

Architecture “clustérisée” :

Dans une architecture clustérisée, la mise en cluster des serveurs WebLogic ne suffit pas pour assurer une disponibilité la plus élevé possible des fonctionnalités offertes dans WebLogic car d’autres composants essentiels sont mis en amont. Dans une architecture web, il faut obligatoirement un composant capable d’interpréter les requêtes http et les rediriger à destination des services offerts par les serveurs weblogic mis en cluster. Nous parlerons ici de serveur web frontal muni d’un plugin WebLogic, d’un proxy serveur ou même d’un dispatcher capable de transmettre les requêtes aux serveurs WebLogic. C’est la configuration de ceux-ci qui détermineront les clusters WebLogic. ces composants seront eux-même mis en cluster ou multiplié pour palier au incident qui peuvent survenir (défaillance, panne, surcharge, etc.). De plus, lors de la mise en cluster de WebLogic, d’autres notions tels que les affinités de session viennent s’ajouter (persistance de l’état).

Le choix d’une architecture appropriée pour la mise en cluster doit tenir compte des facteurs suivants :

  • Performances
  • Efficacité de la persistance de l’état (par réplication ou tout autre moyen) – affinité de session
  • Optimisation de l’équilibrage de la charge
  • Efficacité du basculement en cas d’incident
  • Fiabilité de la communication

Nous pouvons donc citer les composants suivants :

  • Proxy inversé (proxy serveur tel que Apache, SQUID)
  • Server Web frontal (Apache + WLS plugin ou Oracle HTTP Serveur – OHS)
  • Dispatcher (load Balancer – Cisco, Alteon (env. 100’000 Euro)

Voici un petit récapitulatif établi pendant le cours, résumant les fonctionnalités de chaques composants :

WlsAdmin1012

Il est important pour un administrateur weblogic de connaître toutes les possibilités afin d’assurer une disponibilité la plus élevée possible d’un serveur, d’une application, d’un service, etc.