[z/OS]

Arrêt d'un serveur d'applications pour procéder à la mise à jour manuelle d'une application à haute disponibilité

Pour le déploiement manuel des applications, le routage de la charge de travail est contrôlé en arrêtant le serveur d'applications sur lequel réside le membre de cluster mis à jour. Ce serveur est alors mis au repos. Toutes les demandes existantes qui se trouvent déjà sur le serveur peuvent aller jusqu'à leur terme, mais aucune nouvelle demande n'est acceptée. Le distributeur sysplex et le plug-in du serveur Web de WebSphere Application Server redirigent le travail du serveur mis en repos. Une fois le travail terminé, vous commencez la procédure de mise à jour des applications sur ce serveur.

Avant de commencer

Déterminez les serveurs d'applications qui hébergent les membres de cluster qui doivent être mis à jour.

Pourquoi et quand exécuter cette tâche

Si vous disposez d'une application à haute disponibilité dont vous souhaitez contrôler manuellement les mises à jour, vous pouvez utiliser ce processus ou utiliser la commande MVS Modify pour arrêter les programmes d'écoute es serveurs d'applications affectés. Consultez les informations sur la mise en pause d'un serveur d'applications afin de mettre à jour manuellement une application de haute disponibilité.

Pour contrôler manuellement le déploiement des applications et le routage de la charge de travail en environnement de haute disponibilité :

Procédure

  1. Désactivez toutes les formes de synchronisation automatique sur tous les noeuds de la cellule et enregistrez les modifications. Effectuez pour cela l'une des opérations suivantes :
    • Dans la console d'administration :
      1. Click System Administration > Node agents > node_agent_name > File Synchronization Service.
      2. Désactivez les options Synchronisation automatique et Synchronisation au démarrage.
      3. Sélectionnez l'option Synchroniser les modifications avec les noeuds.
      4. Cliquez sur Sauvegarder.
    • Utilisez les scripts wsadmin pour définir les commandes suivantes, puis relancez tous les agents de noeud affectés :
      set node NODE
      set na_id [$AdminConfig getid /Node:$node/Server:nodeagent/]  
      set syncServ [$AdminConfig list ConfigSynchronizationService $na_id]  
      $AdminConfig modify $syncServ {{autoSynchEnabled false}}  
      $AdminConfig modify $syncServ {{synchOnServerStartup false}}
      $AdminConfig save
      
      set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*] 
      $AdminControl invoke $nodeSync sync 
      Eviter les incidents Eviter les incidents: En environnement de production, il est raisonnable de toujours exécuter l'agent de noeud avec la synchronisation automatique désactivée. Il est toutefois conseillé d'avoir la Synchronisation au démarrage activée pour l'agent de noeud pour qu'il puisse acquérir les mises à jour de configuration ayant été effectuées pendant qu'il ne fonctionnait pas. Startup Synchronization can remain enabled provided that you ensure that you will not restart the node agent manually, through automation, or through automatic restart manager during the application update process. gotcha
  2. Mettez à jour l'application dans le référentiel de configuration maître sur le serveur du gestionnaire de déploiement. Effectuez pour cela l'une des opérations suivantes :
    • Dans la console d'administration :
      1. Click Applications > Enterprise Applications.
      2. Sélectionnez l'application à mettre à jour.
      3. Procédez à la mise à jour de l'application.
      4. Sauvegardez les modifications de la configuration principale. NE sélectionnez PAS l'option Synchroniser les modifications avec les noeuds.
    • Utilisez les scripts wsadmin pour émettre la commande suivante :
      set app_loc /path/to/app
      set app_options {application options ie: -appname app}
      set options [list -update]  lappend options $app_options 
      $AdminApp install $app_loc $options
      $AdminConfig save

      A ce stade, la version de l'application (App v2 dans la figure qui suit) est mise à jour dans la configuration maîtresse. La version originale de l'application (App v1 dans la figure qui suit) continue toutefois de s'exécuter dans le cluster avec des membres de cluster sur LPAR1 et LPAR2.

      Figure 1. Installez la mise à jour de l'application. Cette figure illustre la première étape de la mise à jour d'une application dans un environnement de haute disponibilité.Installer la mise à jour de l'application
  3. Arrêtez le serveur d'applications sur LPAR1 et synchronisez manuellement le noeud avec la version mise à jour de l'application. Cette étape peut prendre un certain temps à s'effectuer car le serveur doit attendre que tous les éléments de travail qui sont affectés soient terminés avant de s'arrêter.

    Effectuez pour cela l'une des opérations suivantes :

    • Dans la console d'administration :
      1. Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere.
      2. Sélectionnez le membre de cluster à arrêter et mettez-le à jour. Il doit se trouver sur LPAR1.
      3. Cliquez sur Arrêter. La méthode d'arrêt de cluster ne doit pas être utilisée, car elle arrête tous les serveurs au sein du cluster et l'application n'est plus disponible.
    • Utilisez les scripts wsadmin pour exécuter les commandes suivantes :
      set node NODE 
      set server SERVER 
      $AdminControl stopServer $server $node 
    • Exécutez la commande à partir de la console MVS :
       STOP nom_abrégé_serveur
      Exemple :
      STOP BBOS001
  4. Synchronisez le noeud. Effectuez pour cela l'une des opérations suivantes :
    • Dans la console d'administration :
      1. Click System Administration > Node agents.
      2. Sélectionnez le noeud à synchroniser et cliquez sur Resynchronisation complète.
    • Utilisez les scripts wsadmin pour exécuter les commandes suivantes :
      set node NODE 
      set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*] 
      $AdminControl invoke $nodeSync sync 

    Comme le montre la figure qui suit, la version mise à jour de l'application (App v2) réside désormais dans le noeud sur LPAR1.

    Figure 2. Mettez à jour le noeud sur LPAR1. Cette figure illustre la première étape de la mise à jour d'une application dans un environnement de haute disponibilité avec deux LPAR.Mettre à jour le noeud sur LPAR1
  5. Redémarrez le serveur sur LPAR1. Effectuez pour cela l'une des opérations suivantes :
    • Dans la console d'administration :
      1. Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere.
      2. Sélectionnez le serveur à démarrer et cliquez sur Démarrer.
    • Utilisez les scripts wsadmin pour exécuter les commandes suivantes :
      set node NODE 
      set server SERVER 
      $AdminControl startServer $server $node
    • Exécutez la commande à partir de la console MVS :
      START nom_procédure,JOBNAME=nom_abrégé_serveur.ENV=nom_abrégé_cellule.nom_abrégé_noeud.nom_abrégé_serveur 
      Par exemple :
      START BBO6ACR,JOBNAME=BBOS001,ENV=PLEX1.SY1.BBOS001
    Lorsque ce serveur redémarre, il exécute la nouvelle version de l'application (App v2)
    Figure 3. Redémarrer le serveur sur LPAR1. Cette figure illustre l'achèvement de la première phase de la mise à jour d'une application en environnement à haute disponibilité.Redémarrer le serveur sur LPAR1
  6. Avec la nouvelle version de l'application qui s'exécute sur LPAR1, répétez les trois étapes précédentes sur les autres partitions logiques du cluster pour les mettre à jour avec la nouvelle version de l'application. La figure suivante illustre ce à quoi ressemble la configuration dans un cluster à deux partitions logiques.
    Figure 4. Mettez à jour le noeud sur LPAR2. Cette figure illustre la deuxième étape de la mise à jour d'une application en environnement à haute disponibilité.Mettre à jour le noeud sur LPAR2

Résultats

La procédure de mise à jour de l'application est terminée lorsque la nouvelle version de l'application s'exécute sur tous les membres du cluster. La figure suivante illustre ce à quoi ressemble un cluster à deux partitions logiques après le redémarrage du serveur sur LPAR2.
Figure 5. Redémarrer le serveur sur LPAR2. Cette figure illustre ce à quoi ressemble un cluster à deux partitions logiques après le redémarrage du serveur sur LPAR2.Mettre à jour le noeud sur LPAR2

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_ha_approllout
Nom du fichier : trun_ha_approllout.html