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.

Al determinar si debe dejar habilitado el gestor de alta disponibilidad en un proceso del servidor de aplicaciones, considere si el proceso requiere alguno de los siguientes servicios del gestor de alta disponibilidad:
  • Réplica de memoria a memoria
  • Sustitución por anomalía singleton
  • Direccionamiento de gestión de carga de trabajo
Avoid trouble Avoid trouble: Muchos componentes internos emplean la infraestructura del gestor de alta disponibilidad se basan o se basan en los servicios que emplean el gestor de alta disponibilidad. Por lo tanto, los servicios listados el gestor de alta disponibilidad de no son necesariamente una lista que integre todos los servicios afectados por la inhabilitación del gestor de alta disponibilidad. Además, la lista está sujeta a cambios debido a que es posible que, en cualquier momento, es posible que más servicios pasen a utilizar el gestor de alta disponibilidad. gotcha
Best practice Best practice: En lugar de inhabilitar el gestor de alta disponibilidad, cree varias células o particione la célula en varios grupos principales y cree puentes. Incluso si no utiliza actualmente un componente que requiera el gestor de alta disponibilidad, es posible que requiera uno posteriormente. bprac

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][IBM i]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:
  • 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.

[z/OS]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

La Gestión de carga de trabajo (WLM) propaga las siguientes clases o tipos de direccionamiento de información:
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.

Por ejemplo, si:
  • 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.

Avoid trouble Avoid trouble: Un clúster de servidores proxy no tiene todas las funciones que tiene un clúster de servidores de aplicaciones.

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.

gotcha

Salida de ejemplo:

myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_ham_required
File name: crun_ha_ham_required.html