[z/OS]

Configuration du redémarrage et de la reprise sur un système homologue

Pour permettre le redémarrage du produit sur un autre système, les éléments suivants doivent être installés sur chaque système (celui d'origine ainsi que tout système destiné à la reprise) avant la reconfiguration des règles ARM pour permettre le redémarrage et la reprise sur un système homologue.

Avant de commencer

Fonctionnalité obsolète : La fonctionnalité PRR (Peer Restart and Recovery) est obsolète. A sa place, utilisez plutôt la prise en charge à haute disponibilité intégrée du sous-composant du service de transaction pour la récupération des transactions. Voir le sujet Prise en charge des transactions dans WebSphere Application Server pour plus d'informations sur la prise en charge intégrée de la haute disponibilité pour le sous-composant du service de transactions et sur la façon de le configurer pour la récupération homologue des transactions en cours de traitement sur un serveur d'applications en panne.

Assurez-vous en outre que tous les systèmes sur lesquels vous pouvez avoir à effectuer une reprise appartiennent au même groupe de connexion RRS.

  • z/OS® Version 1.2 ou plus
  • BCP APAR OA01584
  • RRS APARs OA02556 et OA2556
  • WebSphere® Application Server Version 5 ou supérieure

L'installation des mises à jour de services requis sur l'ensemble de ces systèmes ne nuit pas à l'environnement d'exécution actuel si vous ne souhaitez effectuer qu'un redémarrage standard. Si toutefois ce service n'est pas installé, le contrôleur peut ne pas réussir à revenir en arrière. OTS tente alors de redémarrer sur l'autre système et échoue. Si des unités de récupération ne sont pas résolues avec RRS lorsque cela se produit, le contrôleur n'est pas autorisé à redémarrer sur le premier système tant que RRS n'est pas annulé sur l'autre. Pour plus d'informations sur OTS et RRS, voir z/OS Programmation MVS : Reprise des ressources.

Si vous n'envisagez pas d'utiliser le redémarrage et la reprise sur un système homologue, il est inutile de suivre ces exigences fonctionnelles. Votre système utilisera la fonction de redémarrage en place.

Les produits qui suivent prennent tous en charge RRS. Individuellement ils assurent également le redémarrage et la reprise sur un système homologue, dès lors que tous les éléments requis répertoriés précédemment sont installés comme il convient :
  • DB2® Version 7 ou supérieure
  • IMS version 8 ou supérieure
  • CICS® Version 1.3 ou plus
  • Version MQSeries® 5.2 ou plus

En plus des produits précédents, de nombreux gestionnaires de ressources JTA XA peuvent être utilisés pour le redémarrage et la reprise sur un système homologue du produit. Consultez la documentation du gestionnaire de ressources JTA XA pour déterminer si le redémarrage sur un autre système est pris en charge.

Évitez les ennuis : Lors de la configuration de la stratégie ARM pour un sysplex, assurez-vous que les deux systèmes disposent du même niveau de serveur d'applications installé. Par exemple, vous ne pouvez pas utiliser un serveur d'applications qui exécute WebSphere Application Server Version 5.1 pour effectuer un redémarrage et une récupération homologue pour un serveur d'applications en cours d'exécution WebSphere Application Server Version 6.0.1.
Avant d'utiliser le redémarrage et la reprise sur un système homologue :
  • Vous devez vous assurer que le démon du service Localisation et l'agent de noeud fonctionnent déjà sur tous les systèmes pouvant être utilisés pour la reprise. Sinon, le système de reprise peut tenter la reprise sur un système sur lequel le démon du service Localisation et l'agent de noeud ne s'exécutent pas. Dans ce cas, le serveur ne démarre pas et la reprise échoue.

Les clients enregistrent une baisse des performances si les systèmes s'exécutent au maximum de leur capacité. Pour tenter de minimiser l'incidence sur la mémoire et l'unité centrale sur l'autre système, le bean enterprise et le conteneur Web ne sont pas relancés sur les systèmes fonctionnant en mode redémarrage sur système homologue. Les serveurs d'applications en cours de reprise ne peuvent donc accepter aucun travail entrant.

A propos de cette tâche

Une fois les éléments requis installés, le démarrage d'un serveur sur un système sur lequel il n'est pas configuré place de façon implicite ce serveur en mode de redémarrage et reprise sur un système homologue. Si le journal du partenaire XA est configuré pour écrire dans un système hiérarchique de fichiers non partagé, ou si vous utilisez un gestionnaire de ressources JTA XA, procédez comme suit avant de lancer le serveur :

Procédure

  1. (Obligatoire lors de l'utilisation d'un système hiérarchique de fichiers non partagé uniquement.) Activez le support de système hiérarchique de fichiers non partagé.
    Lors de l'utilisation d'un système hiérarchique de fichiers non partagé, les paramètres de configuration doivent être répliqués sur les différents systèmes du sysplex. Le gestionnaire de déploiement et l'agent de noeud effectuent cette opération automatiquement. Pour activer ce support, chaque agent de noeud de la configuration doit être défini en tant que noeud de reprise. Cette modification s'effectue dans la console d'administration :
    1. Dans la navigation de la console d'administration, sélectionnez Administration système > Agents de nœud.
    2. Sélectionnez un agent de noeud dans la liste.
    3. Dans la section Propriétés supplémentaires, sélectionnez Service de synchronisation de fichiers.
    4. Dans la section Propriétés supplémentaires, sélectionnez Propriétés personnalisées.
    5. Sélectionner Nouveau.
    6. EntrerrecoveryNode pour Nom, ettrue pour Valeur. La zone Description peut rester vide.
    7. Répétez les étapes 3 à 7 pour chaque agent de noeud de la configuration.
    8. Sauvegardez votre configuration.
  2. (Obligatoire lors de l'utilisation de gestionnaires de ressources JTA XA uniquement.) Vérifiez que les journaux et les classes appropriées sont disponibles sur l'autre système.
    Si vous envisagez d'utiliser le redémarrage et la reprise sur système homologue et que vos applications accèdent aux gestionnaires de ressources JTA XA, vérifiez que les journaux et les classes appropriés sont disponibles sur l'autre système.
    1. Faites pointer la variable TRANLOG_ROOT vers un système hiérarchique de fichiers partagé.
      La variable TRANLOG_ROOT doit pointer vers un système hiérarchique de fichiers partagé auquel tous les systèmes de la cellule peuvent accéder en écriture. Le journal du partenaire XA est stocké à cet emplacement et l'autre système doit pouvoir le lire et le mettre à jour.
      1. Dans la console d'administration, cliquez sur Serveurs > Types de serveur > Serveurs d'application WebSphere > nom_serveur.
      2. Sous Services de conteneur, cliquez sur Service de transactions.
      3. Entrez le répertoire du système HFS partagé dans la zone Répertoire du journal des transactions.
    2. Stockez le pilote (pilote JDBC, fournisseur JMS, adaptateur de ressources JCA, etc.) de chaque gestionnaire de ressources JTA XA d'un système hiérarchique de fichiers auquel tous les systèmes de la cellule peuvent accéder en lecture.
      Par exemple, si le connecteur est un pilote JDBC pour une base de données, il est probablement stocké dans un système hiérarchique de fichiers en lecture seule accessible par tous les systèmes du sysplex. L'autre système peut ainsi lire le chemin d'accès aux classes de la ressource et le régénérer lors d'un redémarrage.

      Si le connecteur utilisé pour accéder à un gestionnaire de ressources JTA XA n'est pas stocké dans un système hiérarchique de fichiers auquel tous les systèmes susceptibles d'être utilisés pour la reprise peuvent accéder en lecture, lors du redémarrage d'un serveur d'applications sur un autre système, soit il apparaît qu'il n'y aucune tâche de reprise XA à effectuer, soit qu'il est impossible de charger les classes nécessaires pour communiquer avec le gestionnaire de ressources JTA XA.

  3. Corrigez les unités en attente de validation.

    Lors d'une reprise, il est parfois nécessaire de procéder à une intervention manuelle pour corriger les unités en attente de validation. Tu devras utiliser des panneaux RRS pour cette intervention manuelle.