Cuándo se debe utilizar el gestor de alta disponibilidad
Un gestor de alta disponibilidad consume valiosos recursos del sistema, como ciclos de CPU, memoria de almacenamiento dinámico y sockets. Estos recursos los consumen tanto el gestor de alta disponibilidad como los componentes del producto que utilizan los servicios que proporciona el gestor de alta disponibilidad. La cantidad de recursos que consumen tanto el gestor de alta disponibilidad como estos componentes de producto aumenta exponencialmente a medida que aumenta el tamaño del grupo principal.
Para grupos principales grandes, la cantidad de recursos que consume el gestor de alta disponibilidad puede llegar a ser significativa. La inhabilitación del gestor de alta disponibilidad libera estos recursos. No obstante, antes de que inhabilite el gestor de alta disponibilidad, debe investigar a fondo las necesidades actuales y futuras del sistema para asegurarse de que la inhabilitación del gestor de alta disponibilidad no inhabilita otras funciones que se utilizan y que necesitan el gestor de alta disponibilidad. Por ejemplo, tanto la memoria como la duplicación de sesión de memoria y el asignador de peticiones remotas (RRD) requieren la habilitación del gestor de alta disponibilidad.
La posibilidad de inhabilitar el gestor de alta disponibilidad es más útil para topologías donde no se utiliza ninguno de los servicios proporcionados por el gestor de alta disponibilidad. En determinadas topologías, sólo algunos procesos utilizan los servicios que proporciona el gestor de alta disponibilidad. En estas topologías, puede inhabilitar el gestor de alta disponibilidad en cada proceso individual, lo que optimiza la cantidad de recursos que utiliza el gestor de alta disponibilidad.
No inhabilite el gestor de alta disponibilidad en procesos administrativos, como en los agentes de nodos y el gestor de despliegue, a menos que el gestor de alta disponibilidad esté inhabilitado en todos los procesos del servidor de aplicaciones de ese grupo principal.
Algunos de los servicios que proporciona el gestor de alta disponibilidad están basados en clúster. Por lo tanto, dado que los miembros del clúster deben ser homogéneos, si se inhabilita el gestor de alta disponibilidad en un miembro de un clúster, deberá inhabilitarlo en los demás miembros de dicho clúster.
- Réplica de memoria a memoria
- Sustitución por anomalía singleton
- Direccionamiento de gestión de carga de trabajo


Réplica de memoria a memoria
La duplicación de memoria a memoria es un servicio basado en clúster que se configura o habilita en el nivel de servidor de aplicaciones. Si la duplicación de memoria a memoria está habilitada en algún miembro del clúster, el gestor de alta disponibilidad debe estar habilitado en todos los miembros de dicho clúster. La duplicación de memoria a memoria se habilita automáticamente si:
- La réplica de memoria a memoria está habilitada para las sesiones HTTP de contenedor Web.
- La duplicación de memoria caché está habilitada para el servicio de memoria caché dinámica.
- La sustitución por anomalía de beans de sesión con estado de EJB está habilitada para un servidor de aplicaciones.
Sustitución por anomalía singleton
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- El clúster está configurado para utilizar el gestor de alta disponibilidad para gestionar la recuperación de anotaciones cronológicas de transacciones.
- Se han configurado una o varias instancias del proveedor de mensajería predeterminado para ejecutarse en el clúster. El proveedor de mensajería predeterminado que se proporciona con el producto se denomina también bus de integración de servicios.
La sustitución por anomalía singleton es un servicio basado en clúster.
El gestor de alta disponibilidad debe estar habilitado en todos los miembros de un clúster si se han configurado una o más instancias del proveedor de mensajería predeterminado para que se ejecuten en el clúster. El proveedor de mensajería predeterminado es el motor de mensajería que se proporciona
con el producto.
Gestión de carga de trabajo
Información de direccionamiento del tráfico IIOP de enterprise bean.
- Información de direccionamiento para el motor de mensajería predeterminado, denominado también bus de integración de servicios.
- Solicitudes HTTP de direccionamiento a través del servidor proxy de IBM® WebSphere Application Server.
- solicitudes WSA (Routing Web Services Addressing) mediante el servidor proxy de IBM WebSphere Application Server.
- Solicitudes SIP (Session Initiation Protocol) de direccionamiento.
WLM utiliza el gestor de alta disponibilidad propagar la información de direccionamiento y hacer que sea fácilmente accesible. Aunque la información de direccionamiento de WLM generalmente se aplica a los recursos en clúster, también se puede aplicar a recursos que no estén en clúster, como por ejemplo los motores de mensajería autónoma. Generalmente, debe dejar habilitado el gestor de alta disponibilidad en cualquier servidor de aplicaciones que genera o consume información de direccionamiento IIOP o del motor de mensajería.
- El generador de información de direccionamiento es una aplicación de enterprise bean que reside en el clúster 1.
- El consumidor de información de direccionamiento es un servlet que reside en el clúster 2.
Cuando el servlet del clúster 2 llama a la aplicación de enterprise bean del clúster 1, el gestor de alta disponibilidad debe estar habilitado en todos los servidores de ambos clústeres.
Los MBeans de gestión de carga de trabajo, ClusterMgr y Cluster, pueden devolver información básica sobre un clúster. Sin embargo, si High Availability Manager está inhabilitado en cualquier parte de la topología, no puede modificar los valores actuales y propagar las modificaciones a todos los miembros del clúster.
La gestión de carga de trabajo proporciona una opción para crear y exportar de forma estática tablas de direccionamiento al sistema de archivos. Utilice esta opción para eliminar la dependencia del gestor de alta disponibilidad.

Por ejemplo, debido a que no hay ninguna réplica de datos entre los miembros de un clúster de servidores proxy, no se admite la migración tras error entre servidores proxy en el clúster. Si un servidor proxy está inactivo, todas las conexiones activas propiedad del servidor proxy desaparecen y, por lo tanto, las solicitudes entrantes fallan. Sin embargo, tanto los servidores proxy como los clústeres de proxy, dan soporte a la alta disponibilidad y la migración tras error de los servidores de fondo, de modo que el servidor proxy puede detectar si un servidor de fondo está inactivo y enviar a continuación las peticiones a un servidor que tiene una réplica de la sesión.
gotchaSalida de ejemplo:
myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)