Configuration des propriétés de transaction pour une reprise homologue

Le reprise homologue pour le service de transactions permet aux serveurs d'un cluster d'effectuer le travail en attente à la place d'un membre défaillant du cluster. Suivez les étapes de cette rubrique pour configurer les propriétés de transactions requises pour une reprise homologue des serveurs d'applications défaillants d'un cluster.

Avant de commencer

Pour activer une reprise homologue de transactions entre serveurs, vous devez disposer d'une configuration commune des fournisseurs de ressources entre les membres du serveur participant. Le traitement de la reprise homologue ne peut donc avoir lieu qu'entre des membres d'un même cluster. Bien qu'un cluster puisse contenir des serveurs dont les versions de WebSphere Application Server diffèrent, vous ne devez activer et configurer la haute disponibilité que si tous les serveurs disposent de la version 6 ou d'une version ultérieure.

Pourquoi et quand exécuter cette tâche

[z/OS]La reprise homologue complète le support de redémarrage et de reprise homologue utilisé pour lancer un redémarrage sur le système homologue d'un sysplex. Pour plus d'informations concernant le redémarrage et la reprise homologue, voir Configuration du redémarrage et de la reprise homologue.

La configuration des propriétés de transaction requises pour la reprise homologue fait partie de la configuration globale d'un cluster pour recourir au support de haute disponibilité.

Procédure

  1. [z/OS]Sur des plateformes z/OS, configurez RACF (Resource Access Control Facility) pour permettre aux serveurs d'applications d'appeler la macro ATRSRV.

    La macro ATRSRV permet à un serveur de valider et d'annuler des transactions pour d'autres serveurs. Ce processus diffère du redémarrage homologue et du support de reprise, où l'autre serveur est démarré sur un système distinct. La macro ATRSRV est fournie par les services RRS (Resource Recovery Services) de MVS.

    L'ID utilisateur sous lequel la région du contrôleur du serveur d'applications s'exécute, doit avoir un accès ALTER à la ressource MVSADMIN.RRS.COMMANDS.gname.sysname dans la classe FACILITY, où gname est le nom du groupe de consignation RRS (normalement, le nom SYSPLEX) et sysname le nom du système. Pour permettre l'accès à tous les groupes de consignation et systèmes, utilisez des caractères génériques dans le nom de la ressource, comme MVSADMIN.RRS.COMMANDS.*.
    Remarque : Etant donné que la région du contrôleur s'exécute en tant qu'espace adresse autorisé, elle dispose d'un accès ALTER implicite à cette classe de ressources à moins que la configuration RACF n'en restreigne explicitement l'accès. En autorisant explicitement l'accès à cette ressource, vous ne vous basez pas sur l'état autorisé de la région du contrôleur.

    Pour plus d'informations sur la macro ATRSRV et la définition des autorisations RACF appropriées, voir le chapitre 8 de MVS Programming: Resource Recovery, SA22-7616-02.

  2. Configurez le paramètre du répertoire des journaux de transaction pour chaque serveur dans le cluster. Vous pouvez configurer l'emplacement du répertoire de consignation de transaction à l'aide de la console d'administration ou de commandes. La configuration est stockée dans le fichier de configuration au niveau du noeud serverindex.xml.

    Chaque serveur d'un cluster doit avoir accès aux répertoires des fichiers journaux des autres serveurs du même cluster. C'est pourquoi vous devez définir ce paramètre. Si vous ne définissez aucun répertoire, le serveur d'applications imagine un emplacement par défaut dans le répertoire du profil approprié, qui pourrait ne pas être accessible aux autres serveurs du cluster.

    Chaque serveur du cluster doit également posséder un journal des transactions unique pour éviter que plusieurs serveurs ne tentent d'accéder au même journal. Par exemple, vous pourriez utiliser le nom de chaque serveur dans le nom du répertoire du journal de ce serveur.

    [AIX Solaris HP-UX Linux Windows][z/OS]Le mécanisme de stockage utilisé pour héberger des fichiers journaux de reprise (par exemple, vous pouvez utiliser IBM® NAS et des unités SCSI partagées, mais pas de partage réseau simple) et l'accès à ce mécanisme (par exemple, via un réseau local), doivent prendre en charge l'opération d'interruption provoquée basée sur les fichiers utilisée par le service de consignation de reprise pour forcer des données sur le disque.

    [IBM i]Le mécanisme de stockage employé pour héberger des fichiers journaux de reprise et l'accès à ce mécanisme (par exemple, vous pouvez stocker les journaux sur un autre serveur IBM i à l'aide du système QNTC NetClient, qui donne accès aux données sur un système distant à l'aide du protocole SMB), doivent prendre en charge l'opération d'interruption provoquée basée sur les fichiers et employée par le service de consignation de reprise pour forcer des données sur le disque.

    En outre, configurez le mécanisme d'accès aux fichiers journaux distants pour exploiter toute tolérance aux pannes dans le système de fichiers sous-jacent. Par exemple, en utilisant le système NFS (Network File System) et en montant sur disque dur le répertoire distant contenant les fichiers journaux (à l'aide de l'option -o hard de la commande NFS mount), le client NFS retente l'opération qui a échoué jusqu'à ce que le serveur NFS soit à nouveau disponible.

    Pour plus d'informations sur la configuration des répertoires de journal des transactions, voir Configuration des propriétés de transaction pour un serveur d'applications.

    Remarque : Si vous avez migré d'une version antérieure de WebSphere Application Server, notez que les versions antérieures stockaient la configuration du journal de reprise dans le fichier de configuration au niveau du serveur server.xml. Si vous exécutez un script qui configure les paramètres du journal de reprise d'origine ou migrez des serveurs d'applications version 5 vers une version ultérieure de WebSphere Application Server, la configuration du répertoire du journal de transaction d'origine du fichier server.xml est mise à jour. La console d'administration détecte cette situation et vous invite à enregistrer la configuration au moment de l'affichage du service de transaction. Cet enregistrement conserve la configuration modifiée dans le fichier serverindex.xml et restaure les anciennes zones à la valeur null. Modifiez votre programme de script existant de façon qu'il cible serverindex.xml dès que la première opportunité se présente. Les nouveaux programmes de script doivent également cibler le fichier serverindex.xml.
  3. Activez la fonction de haute disponibilité pour le cluster en accomplissant les étapes suivantes à partir du panneau de configuration du cluster de la console d'administration de WebSphere Application Server :
    1. Dans la console d'administration, cliquez sur Serveurs > Clusters > Clusters de WebSphere application server > nom_cluster.
    2. Sélectionnez l'option Activer le basculement de la reprise sur incident du journal des transactions.
    3. Cliquez sur OK.
    Pour plus d'informations sur l'activation de la fonction de haute disponibilité pour un cluster, voir Paramètres des clusters de serveurs.
  4. Décidez du type de reprise homologue de transaction à utiliser en vous reportant à Comment choisir entre la reprise de transaction homologue automatisée et manuelle.
  5. Effectuez une des actions suivantes en fonction de la configuration dont vous avez besoin.

Que faire ensuite

Vous devez également configurer l'emplacement des journaux de compensation. Chaque serveur doit posséder un répertoire unique de journaux de compensation et les journaux de compensation doivent être accessibles par un chemin similaire aux journaux de transactions.

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=tjta_cfgpeer
Nom du fichier : tjta_cfgpeer.html