Architecture Haute Disponibilité : WebLogic Whole Server Migration

Whole Server Migration…de quoi s’agit-il ?
Le Whole Server Migration est une des principales caractéristiques du serveur Weblogic qui permet la haute disponibilité. Il offre un fonction de migration manuelle ou automatique d’une instance JVM d’un serveur Weblogic vers une différente machine physique. Il est utile lorsque :

  • Un serveur Managé est migré vers un autre serveur physique suite à une panne
  • Il faut récupérer les services JMS et JTA Transaction


Le Whole server migration nécessite le Node Manager pour :

  1. le démarrage initial des serveurs migrables (Migratable : une caractéristique du Weblogic Whole Server Migration).
  2. Suspendre, arrêter ou forcer l’arrêt des serveurs migrables
  3. Redémarrer, après l’expiration d’un certain délai, un serveur migrable dans la machine où il se trouve suite à une panne.

Mise en œuvre du processus « Whole Server Migration »
Les pré-requis sont les suivants :

  • Adressage IP dynamique : un couple unique (@IP, n° port) pour chaque instance de serveur
  • Node Manager : un par machine physique
  • Un canal réseau : pas plus d’un canal réseau par instance de serveur
  • Un espace de stockage persistant et partagé : un mécanisme de haute disponibilité partagé pour stocker l’état du serveur.

Les étapes de configuration :
Etape 1 : Création du domaine Weblogic
Dans le but de tester la migration, le domaine Weblogic doit avoir la configuration minimale suivante :
–         Machine 1

  • Admin Server *
  • Managed Server 1

–         Machine 2

  • Managed Server 2

* = seule la migration manuelle est possible pour l’Admin Server
De plus les points suivants doivent être vérifiés :

  • Chaque machine physique pointe vers une unique instance du Node Manager
  • Chaque Managed Server doit disposer d’une @IP dynamique unique
  • L’Admin Server doit disposer d’une @IP dynamique si on veut procéder à une migration manuelle de l’Admin Server.

Etape 2 : Configuration du Node Manager
Mise à jour du fichier nodemanager.properties pour chaque instance de Node Manager en indiquant le netmask et l’interface à utiliser pour migrer les serveurs candidat à la migration.
Exemple:
Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true
Typiquement le fichier nodemanager.properties se trouve sous : FMW_HOME/wlserver_10.3/common/nodemanager
Etape 3 : Mise en oeuvre du processus de Leasing
Le Leasing est le mécanisme Weblogic qui permet d’assurer qu’un cluster ou un Managed Server est actif  que dans une unique machine physique à instant donné. Le Leasing permet d’éviter au Node Manager de démarrer un Manager Server qui tourne déjà sur une autre machine.
Il existe deux types de configuration de Leasing
–         Consensus Leasing : L’information de Leasing est stockée en mémoire au sein d’un membre du cluster.
–         High-Availability Database Leasing : L’information de Leasing est stockée dans une base de donnée en haute disponibilité telle que Oracle RAC.
Le Consensus Leasing ne nécessite aucune étape de configuration (activation au niveau de Weblogic).
Le High-Availability Database Leasing nécessite les étapes de configuration suivantes:
a.)    Création d’un tablespace pour l’information de Leasing

      create tablespace leasing logging datafile size 32m autoextend
      on next 32m maxsize 2048m extent management local;

b.)    Assigner un schéma/utilisateur au tablespace de Leasing

      create user leasing identified by welcome1;
      grant create table to leasing;
      grant create session to leasing;
      alter user leasing default tablespace leasing;
      alter user leasing quota unlimited on leasing;

c.)    Création d’une table au sein du schéma leasing

      CREATE TABLE ACTIVE (
      SERVER VARCHAR2(150) NOT NULL,
      INSTANCE VARCHAR2(100) NOT NULL,
      DOMAINNAME VARCHAR2(50) NOT NULL,
      CLUSTERNAME VARCHAR2(50) NOT NULL,
      TIMEOUT DATE,
      PRIMARY KEY (SERVER, DOMAINNAME, CLUSTERNAME));

Une fois qu’on a mis en place la base de Leasing, un JDBC Multi-Data source doit être configuré au niveau du Weblogic pour assurer l’accès à la base de données.
Etape 4 : Fournir les droits du super utilisateur au script WLSIFCONFIG
Weblogic fait appel  à ce script pour le plumbing et le unplumbing des @IP dynamiques.
Etape 5 : Activation de la migration du serveur
L’activation de la migration se fait via la console du Weblogic Admin Server :

  1. Configure the WebLogic cluster(s):
    1. From the Summary of Clusters screen, select the cluster requiring “Whole Server Migration” configuration, then select the Migration tab
    2. Under Candidate Machines For Migratable Servers select the machines you wish to be migration candidates from the Available box and move them to the Chosen box
    3. Set the Migration Basis as required ("Consensus" or "Database"). If using "Database" for Migration Basis, set the Data Source For Automatic Migration to the previously created leasing Multi-Data Source
    4. Configure the WebLogic servers:
      1. From the Summary of Servers screen, select the managed server requiring ”Whole Server Migration” configuration, then select the Migration tab
      2. Tick the Automatic Server Migration Enabled check box
      3. Under Candidate Machines select the machines you wish to migrate to from the Available box and move them to the Chosen box

Opération terminée !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *