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.
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]](../images/dist.gif)
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.
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.