Consideraciones sobre el escalado de grupos principales

La cantidad de recursos del sistema, por ejemplo, la CPU y la memoria que consume el gestor de alta disponibilidad no aumenta de forma lineal como lo hace un grupo principal. Por ejemplo, el VSP (View Synchrony Protocol) que el gestor de alta disponibilidad utiliza requiere una gran cantidad de estos recursos para mantener una correspondencia estricta entre los miembros de grupo principal. Por lo tanto, la cantidad de recursos que consume un grupo principal grande puede ser considerable.

Los requisitos de recursos de VSP (View Synchrony Protocol) pueden varias considerablemente para distintos grupos principales del mismo tamaño. La cantidad de recursos que View Synchrony Protocol utiliza para un grupo principal viene determinado por:
  • El número de aplicaciones en ejecución.
  • El tipo de aplicaciones en ejecución.
  • Los servicios de gestor de alta disponibilidad utilizados.

Al configurar el escalado de grupos principales, debe asegurarse de que:

Considere la implementación de una o más de las siguientes técnicas de escalabilidad para escalar el gestor de alta disponibilidad en células grandes, incluso si el sistema funciona correctamente. Las dos técnicas más básicas son:

Ajuste del tamaño de un grupo principal

El tamaño de grupo principal afecta directamente a tres aspectos del proceso de gestor de alta disponibilidad que tienen un impacto sobre el uso de recursos:
  • El primer aspecto y el más importante es el establecimiento de VSP (View Synchrony Protocol) a través de un conjunto de miembros de grupo principal activos. Esta actividad es conocida comúnmente como cambio de vista.
  • El segundo aspecto son las tareas de descubrimiento y de detección de anomalías planificadas regularmente que el gestor de alta disponibilidad ejecuta de fondo.
  • El tercer aspecto es la utilización de recursos que se produce cuando otros componentes del producto utilizan los servicios proporcionados por el gestor de alta disponibilidad.
Cambios de vista

VSP (View Synchrony Protocol) crea una nueva vista siempre que detecta que hay un cambio en los miembros de grupo principal activos. Un cambio de vista se produce generalmente siempre que un miembro de grupo principal se inicia o se detiene. Cuando se inicia un miembro de grupo principal, se abre una conexión con todos los demás miembros de grupo principal en ejecución. Cuando un miembro de grupo principal se detiene, los demás miembros de grupo principal detectan que se cierran sus conexiones abiertas con el miembro detenido. En ambos casos, VSP (View Synchrony Protocol) necesita dar cuenta de este cambio. En el caso de un miembro recién iniciado, VSP (View Synchrony Protocol) debe establecer una vista que incluya el nuevo miembro. En el caso de un miembro detenido, VSP (View Synchrony Protocol) debe establecer una nueva vista para los miembros de grupo principal supervivientes que excluya el miembro detenido.

El establecimiento de una nueva vista es una actividad importante pero utiliza muchos recursos del sistema, especialmente para grupos principales grandes.
  • Todos los miembros de grupo principal en ejecución debe comunicar su estado actual a los demás miembros de grupo principal, incluida la información sobre los mensajes enviados o recibidos en la vista actual.
  • Todos los destinatarios deben recibir y reconocer todos los mensajes enviados en una determinada vista antes de que se pueda instalar una nueva vista. En condiciones normales de funcionamiento, la recepción de estos mensajes se reconoce lentamente. La finalización de mensajes en el límite de cambio de vista en el momento correspondiente requiere un reconocimiento agresivo y la retransmisión.
  • Todos los miembros de grupo principal deben transmitir los datos relacionados con su estado actual, por ejemplo, el conjunto de los demás miembros de grupo principal con los que se pueden comunicar activamente.

A medida que aumenta el número de miembros activos, la instalación de una nueva vista requiere un mayor aumento temporal no lineal de la utilización de la CPU del gestor de alta disponibilidad. Es significativamente más costoso añadir o eliminar un único miembro cuando existen otros 50 miembros de grupo principal que cuando existen 20.

La instalación de una nueva vista también desencadena cambios de estado en los componentes del producto que utilizan el gestor de alta disponibilidad. Por ejemplo, es posible que sea necesario actualizar las tablas de direccionamiento para reflejar el miembro iniciado o detenido o que sea necesario reiniciar un servicio singleton en un nuevo miembro.

El resultado final es que la instalación de una nueva vista genera un pico temporal significativo de utilización de la CPU. Si los tamaños de grupo principal se vuelven de demasiado grandes, se produce una degradación de las condiciones de sincronización de red en el límite de cambio de vista. Estas condiciones generalmente generan una anomalía durante el intento de instalación de una nueva vista. La recuperación ante esta anomalía también hace un uso intensivo de la CPU. Cuando no existe suficiente CPU disponible, se pueden multiplicar las anomalías con rapidez.

Tareas de fondo

El gestor de alta disponibilidad ejecuta periódicamente un número de tareas de fondo, por ejemplo, la comprobación del buen funcionamiento de los servicios singleton de alta disponibilidad que esté ejecutando. La mayoría de estas tareas de fondo consumen cantidades insignificantes de CPU. Las excepciones son los protocolos de descubrimiento y para la detección de anomalías planificados regularmente.

El protocolo de descubrimiento intenta establecer las comunicaciones entre los miembros de grupo principal que no están conectados actualmente, incluidos los procesos que no están en ejecución. Para un determinado grupo principal que contenga N miembros de grupo principal, de los cuales M estén actualmente en ejecución, cada periodo de descubrimiento resultará en M x (N – M) mensajes de descubrimiento aproximadamente. De esto modo, se crea un gran número de procesos que nunca generan efectos adversos en la utilización de la CPU del Protocolo de descubrimiento.

De modo parecido, cuando se ejecuta el Protocolo para la detección de anomalías, todos los miembros de grupo principal envían pulsaciones a todas las conexiones establecidas con otros miembros de grupo principal. Para M miembros activos, se envían M x (M-1) mensajes de pulsaciones. Si es necesaria la detección de anomalía agresiva, el tamaño del grupo principal puede tener un efecto adverso en la cantidad de utilización de la CPU que consumen las pulsaciones entre miembros de grupo principal.

Unos grupos principales de menor tamaño tienen un efecto positivo en la cantidad de utilización de la CPU que consumen estos dos protocolos. Por ejemplo, si un grupo principal contiene 100 miembros activos, se envían 9900 mensajes de pulsaciones durante cada periodo de detección de anomalía. La división del grupo principal de 100 miembros en cinco grupos principales más pequeños de 20 miembros reduce el número de mensajes a 1900, que representa una reducción significativa.

Uso externo
Otros componentes del producto como, por ejemplo, WLM (Work Load Management) y ODC (On Demand Configuration) utilizan los servicios proporcionados por el gestor de alta disponibilidad como el intercambio de estado de servidor para mantener la información de direccionamiento. La cantidad de utilización de la CPU que consumen estos componentes está enlazada con el tamaño de grupo principal. Por ejemplo, la utilización del intercambio de estado de servidor activo para generar información de direccionamiento de alta disponibilidad está enlazada con el tamaño del grupo principal.

Distribución de procesos entre varios grupos principales

Puede utilizar dos técnicas básicas para minimizar la cantidad de recursos que la sincronización de vista y los protocolos relacionados consumen:
  • Puede inhabilitar el gestor de alta disponibilidad en los procesos donde los servicios que éste proporciona no se utilizan.
  • Puede mantener los tamaños de grupo principal reducidos.

La clave para limitar la utilización de la CPU del gestor de alta disponibilidad consiste en limitar el tamaño del grupo principal. Varios grupos principales pequeños son mucho mejor que un grupo principal grande. Si tiene células grandes, cree varios grupos principales.

El hardware donde ejecute el producto también es un factor para terminar el tamaño de grupo principal adecuado para el entorno.

Divida los grupos principales grandes en varios grupos principales más pequeños. Si los grupos principales resultantes requieren compartir la información direccionamiento, puede utilizar puentes de grupo principal para crear un puente entre los grupos principales.

Tamaños de los grupos principales

Puede determinar los tamaños de los grupos principales siempre que realice inicialmente las siguientes actividades de ajuste:
  • Cuando habilita la propiedad personalizada de grupo principal IBM_CS_WIRE_FORMAT_VERSION en un valor de 6.1.0, puede obtener mejoras del protocolo de grupo principal interno. Estas mejoras sólo están disponibles en la versión 6.1 y posterior.
  • Cuando habilita la propiedad personalizada de grupo principal IBM_CS_HAM_PROTOCOL_VERSION en un valor de 6.0.2.31, puede obtener mejoras importantes en el uso de memoria y en las características de migración tras error de los puentes de grupos principales.
  • Puede ajustar los valores de memoria de transporte. Existen dos valores de tamaño de memoria y de almacenamiento intermedio asociados al transporte del grupo principal. Los valores predeterminados para estos valores son suficientes para pequeños grupos principales de 50 miembros o menos. Para grupos principales de más de 50 miembros, estos valores se deben aumentar a partir de los valores predeterminados.
    Nota: Aumentar el valor de estos valores de transporte de memoria no significa que High Availability Manager tenga de forma directa más memoria asignada estáticamente o más uso de memoria a largo plazo.
Siempre que WebSphere Application Server Network Deployment se despliegue en un hardware relativamente moderno, la CPU y la memoria no estén restringidas, las aplicaciones tengan un comportamiento correcto, la red sea estable y se tengan en cuenta los factores que afectan la estabilidad de los grupos principales, tales como los problemas de red y de memoria, los siguientes tamaños de grupos principales pueden tenerse en consideración.
  • Los grupos principales de hasta 100 miembros deben funcionar sin problemas.
  • Los grupos principales que contienen más de 100 miembros deben funcionar sin problema en muchas topologías. No se recomienda que un grupo principal supere los 200 miembros.

Ajuste de grupos principales individuales en función de la combinación de aplicaciones y los servicios utilizados

Es posible que necesite ajustar todavía más los grupos principales individuales basándose en la combinación de aplicaciones y los servicios de alta disponibilidad que los grupos de miembro principal utilizan.

  • Ajuste la frecuencia con la que el protocolo de descubrimiento y el protocolo para la detección de anomalías se ejecutan si los valores predeterminados no son adecuados.
  • Configure el coordinador de grupos principales para ejecutarse en un proceso específico o conjunto de procesos.
  • Particione el coordinador entre varias instancias si el consumo de recursos por parte del proceso del coordinador es visible.
  • Configure la cantidad de memoria que estará disponible para los componente DCS (Distribution and Consistency Services) y RMM (Reliable Multicast Messaging) para enviar mensajes de red cuando se detecte cualquier congestión. La congestión puede ocurrir en ciertas condiciones, incluso si no se utiliza la duplicación de memoria a memoria.

Ajuste de rangos de puertos efímeros

El número de sockets que utiliza un grupo de principal generalmente no representa un gran problema. Cada miembro de grupo principal debe establecer una conexión con cada uno de los demás miembros de ese grupo principal. Por lo tanto, el número de conexiones crece exponencialmente (n elevado al cuadrado) ya que cada conexión requiere dos sockets, uno en cada extremo de la conexión. Como generalmente se ven implicadas varias máquinas, normalmente no debe preocuparse acerca del número de sockets que un grupo principal utiliza. No obstante, si tiene un número desproporcionado de miembros de grupo principal que se ejecuten en una única máquina, es posible que tenga que ajustar los parámetros del sistema operativo relacionados con los rangos de puertos. La mayoría de los sistemas operativos tienen un comportamiento por omisión distinto para los rangos de puertos efímeros.

Best practice Best practice: Evite utilizar puertos en un rango de puertos temporales. Aunque no sea una configuración incorrecta, si define puertos en este rango, puede obtener un comportamiento impredecible en la comunicación miembro a miembro del grupo principal. bprac

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_cgscale
File name: crun_ha_cgscale.html