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
Fonction 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. Pour plus d'information
sur la prise en charge à haute disponibilité intégrée au sous-composant de service de transaction et sur la façon de
la configurer pour la reprise homologue des transactions en cours de traitement sur un serveur d'applications défaillant,
consultez
Prise en charge des transactions dans WebSphere
Application Server.
depfeat
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 versions 1.2 ou ultérieures
- BCP APAR OA01584
- RRS APARs OA02556 et OA2556
- WebSphere
Application Server version 5 ou ulté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, consultez Programmation z/OS 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 versions
7 ou ultérieures
- IMS versions
8 ou ultérieures
- CICS versions
1.3 ou ultérieures
- MQSeries versions
5.2 ou ultérieures
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.
Eviter les incidents: Lors de la configuration de la règle ARM pour un
sysplex, assurez-vous que le même niveau de serveur d'applications est installé sur les
deux systèmes. Par exemple, vous ne pouvez pas utiliser un serveur d'applications qui
exécute
WebSphere
Application Server version
5.1 pour effectuer le redémarrage et la reprise sur un système homologue
pour un serveur d'applications qui exécute
WebSphere
Application Server version
6.0.1.
gotcha
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.
Pourquoi et quand exécuter 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
- (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 :
- Dans l'arborescence de navigation de la console d'administration, choisissez .
- Sélectionnez un agent de noeud dans la liste.
- Dans la section Propriétés supplémentaires, choisissez Service de synchronisation de fichiers.
- Dans la section Propriétés supplémentaires choisissez .
- Sélectionnez .
- Entrez recoveryNode dans la zone Nom et true dans la zone Valeur. La zone Description peut rester vide.
- Répétez les étapes 3 à 7 pour chaque agent de noeud de la configuration.
- Sauvegardez votre configuration.
- (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.
- 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.
- Dans la console d'administration, cliquez sur nom_serveur.
- Sous Services de conteneur, cliquez sur Service de transactions.
- Entrez le répertoire du système HFS partagé dans la zone Répertoire du journal des transactions.
- Stockez le pilote (pilote JDBC, fournisseur JMS ou 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.
- 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. Pour ce faire, utilisez les panneaux RRS.