En plataformas z/OS, configure el recurso RACF (Resource
Access Control Facility) de modo que permita a los servidores de aplicaciones llamar a la
macro ATRSRV. La macro ATRSRV permite a un servidor confirmar y restituir las transacciones para otros servidores. Este proceso es diferente del soporte del reinicio y recuperación por igual, en el que se inicia otro servidor en otro sistema. El macro ATRSRV lo proporciona Resource Recovery Services (RRS) de MVS.
El ID de usuario bajo el que se ejecuta la región del controlador del servidor
de aplicaciones debe tener acceso ALTER al recurso
MVSADMIN.RRS.COMMANDS.
nombreg.
nombresis
de la clase FACILITY class, siendo
nombreg el grupo de
inicio de sesión RRS (generalmente el nombre SYSPLEX) y
nombresis el nombre del sistema. Para permitir el acceso a todos los grupos y sistemas de inicio de sesión, utilice comodines en el nombre de recurso, por ejemplo, MVSADMIN.RRS.COMMANDS.*.
Nota: Puesto que la región de
controlador se ejecuta como un espacio de direcciones autorizadas, de forma implícita tendrá
acceso ALTER a esta clase de recurso salvo que la configuración de RACF lo restrinja de forma explícita. Al permitir el acceso explícito a este recurso, no está confiando en el estado autorizado de la región del controlador.
Para obtener más información sobre la macro ATRSRV y cómo establecer los
permisos RACF adecuados, consulte el capítulo 8 de la publicación MVS Programming:
Resource Recovery, SA22-7616-02.
Configure los valores del directorio de registros cronológicos de la
transacción para cada servidor del clúster. Puede configurar la ubicación del directorio de registros cronológicos de la transacción mediante la consola administrativa o los mandatos. La
configuración se almacena en el archivo de configuración a nivel de nodo
serverindex.xml.
Cada servidor de un clúster debe poder acceder a los
directorios de registros cronológicos de otros servidores del mismo clúster. Por lo tanto, no deje este valor sin establecer. Si no establece un directorio, el
servidor de aplicaciones asumirá una ubicación predeterminada dentro del directorio de
perfiles correspondiente, que puede que no sea accesible para otros servidores del
clúster.
Cada servidor del clúster también debe tener un directorio único de registros cronológicos de transacciones para evitar
que varios servidores intenten acceder al mismo archivo de registros cronológicos. Por ejemplo,
puede utilizar el nombre de cada servidor como parte del nombre del directorio de registros cronológicos para dicho servidor.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
El mecanismo de almacenamiento que se utiliza para albergar los archivos de registros cronológicos (por ejemplo, puede utilizar IBM® NAS (Network Attached Storage) y unidades compartidas SCSI, pero no puede utilizar el espacio de red compartido) y para acceder a dicho mecanismo (por ejemplo, mediante una LAN) debe soportar la operación force basada en archivo que utiliza el servicio de registros cronológicos de recuperación para forzar el paso de datos a un disco.
El mecanismo de almacenamiento que se utiliza para albergar los archivos de registro de recuperación del host (por ejemplo, puede almacenar los archivos de registro en otro servidor IBM i, utilizando el sistema de archivos NetClient (QNTC) que proporciona acceso a datos en un sistema remoto utilizando el protocolo SMB (Server Message Block)), debe soportar la operación force basada en archivo que utiliza el servicio de registro de recuperación para forzar el paso de datos a un disco.
Asimismo, configure el mecanismo mediante el cual se accede a los archivos de registros cronológicos de recuperación remotos, para beneficiarse de cualquier tolerancia a las anomalías que pueda haber en el sistema de archivos subyacentes. Por ejemplo, si utiliza el sistema de archivos NFS (Network File System) y monta en el disco duro el directorio remoto que contiene los archivos de registros (mediante la opción -o hard del mandato nfsmount), el cliente NFS volverá a intentar una operación anómala hasta que el servidor NFS vuelva a estar disponible.
Para obtener más información
sobre la configuración de los directorios de registros cronológicos, consulte
Configuración de propiedades de transacciones para servidores de aplicaciones.
Nota: Si ha migrado
desde una versión anterior de
WebSphere
Application Server, tenga en cuenta que las versiones anteriores almacenaban la
configuración de los registros cronológicos de recuperación en el archivo de
configuración a nivel de servidor server.xml. Si ejecuta scripts existentes que configuran los valores originales de los registros cronológicos de recuperación, o migra los servidores de
aplicaciones de la Versión 5 a una versión posterior de WebSphere Application Server, se actualiza la configuración original
del directorio de registros cronológicos de transacciones en el archivo server.xml. La consola administrativa detecta esta condición y solicita que guarde
la configuración cuando visualice el panel de servicios de transacción. Esta
operación guarda la configuración modificada en el archivo serverindex.xml
y restablece los campos antiguos en el valor nulo. Cambie los scripts existentes
cuanto antes para que se dirijan al archivo serverindex.xml. Los nuevos
scripts también se deben dirigir al archivo serverindex.xml.