Puede configurar la cantidad de tiempo entre las comprobaciones de sistema para los servidores que han fallado con el valor de intervalo de pulsaciones. La opción -heartbeat es un parámetro para el mandato startOGserver, y sólo se aplica a los servidores de catálogo.
Acerca de esta tarea
La configuración de la migración tras error varía en función del tipo de entorno que utiliza. Si utiliza un entorno autónomo, puede configurar una migración tras error con la línea de mandatos. Si utiliza un entorno
WebSphere Application Server Network Deployment, debe configurar la migración tras error en la consola de administración de
WebSphere Application Server Network Deployment.
Procedimiento
- Configure la migración tras error para los entornos autónomos.
Puede configurar los intervalos de pulsación en la línea de mandatos utilizando el parámetro -heartbeat en el archivo de script startOgServer. Establezca este parámetro en uno de los siguientes valores:
Tabla 1. Intervalos de pulsacionesValor |
Acción |
Descripción |
0 |
Típica (valor predeterminado) |
Las migraciones tras error se detectan normalmente en 30 segundos. |
-1 |
Agresiva |
Las migraciones tras error se detectan normalmente en 5 segundos. |
1 |
Relajada |
Las migraciones tras error se detectan normalmente en 180 segundos. |
Un intervalo de pulsaciones agresivo puede ser útil cuando los procesos y la red son estables.
Si la red o los procesos no se han configurado de forma óptima, es posible que las pulsaciones se pierdan, lo que comportará en una detección de anomalía falsa.
- Configure la migración tras error para los entornos WebSphere Application Server.
Puede configurar WebSphere Application Server Network Deployment versión
6.0.2 y posterior para permitir a WebSphere eXtreme
Scale que realice la migración tras error muy rápidamente. El tiempo de migración tras error predeterminado para las anomalías graves es aproximadamente de 200 segundos. Una anomalía grave es un bloqueo del servidor o sistema físico, una desconexión del cable de red o un error del sistema operativo.
Las anomalías debidas a cuelgues del proceso o a anomalías leves normalmente realizan la migración tras error en menos de un segundo.
La detección de anomalías correspondientes a anomalías leves sucede cuando el sistema operativo cierra automáticamente los sockets de red del proceso inactivo para el servidor que aloja el proceso.
Configuración de pulsaciones de grupo principal
WebSphere eXtreme
Scale que se ejecuta en un proceso WebSphere Application Server hereda las características de migración tras error de los valores del grupo principal del servidor de aplicaciones. Las siguientes secciones describen cómo configurar los valores de pulsación del grupo principal para distintas versiones de WebSphere Application
Server Network Deployment:
- Actualice los valores de grupo principal para WebSphere Application Server Network Deployment versión
6.x y 7.x:
Especifique el intervalo de pulsación en segundos en las versiones de WebSphere Application Server de la versión 6.0 a la versión 6.1.0.12 o en milisegundos a partir de la versión
6.1.0.13. También debe especificar el número de pulsaciones que faltan. Este valor indica cuántas pulsaciones pueden perderse antes de que se considere anómala una Máquina virtual Java (JVM) de igual.
El tiempo de detección de anomalías graves es aproximadamente el producto del intervalo de pulsaciones y el número de pulsaciones perdidas.
Estas propiedades se especifican utilizando las propiedades personalizadas en el grupo principal a través de la consola administrativa de WebSphere. Consulte
Propiedades personalizadas del grupo principal para obtener detalles sobre la configuración.
Estas propiedades deben especificarse para todos los grupos principales que la aplicación utiliza:
- El intervalo de pulsación se especifica utilizando la propiedad personalizada IBM_CS_FD_PERIOD_SEC
para segundos o la propiedad personalizada IBM_CS_FD_PERIOD_MILLIS para milisegundos (requiere la Versión 6.1.0.13 o posterior).
- El número de pulsaciones perdidas se especifica utilizando la propiedad personalizada IBM_CS_FD_CONSECUTIVE_MISSED.
El valor predeterminado para la propiedad IBM_CS_FD_PERIOD_SEC es 20 y para la propiedad IBM_CS_FD_CONSECUTIVE_MISSED es 10. Si se especifica la propiedad IBM_CS_FD_PERIOD_MILLIS, altera temporalmente cualquier conjunto de propiedades personalizadas IBM_CS_FD_PERIOD_SEC. Los valores de estas propiedades son valores enteros positivos.
Utilice los siguientes valores para conseguir un tiempo de detección de anomalías de
1500 ms para los servidores
WebSphere Application Server Network Deployment versión
6.x:
- Establezca IBM_CS_FD_PERIOD_MILLIS = 750 (WebSphere Application Server Network Deployment V6.1.0.13
y posterior)
- Establezca IBM_CS_FD_CONSECUTIVE_MISSED = 2
Actualice los valores de grupo principal para WebSphere Application Server Network Deployment versión 7.0
WebSphere Application Server Network Deployment versión
7.0 proporciona dos valores de grupo principal que se pueden ajustar para aumentar o reducir la detección de migración tras error:
- Periodo de transmisión de pulsación. El valor predeterminado es 30000 milisegundos.
- Periodo de tiempo de espera de pulsación. El valor predeterminado es 180000 milisegundos.
Si desea más detalles sobre cómo cambiar estos valores, consulte el centro de información de WebSphere Application Server Network Deployment: Valores de descubrimiento y detección de errores.
Utilice los valores siguientes para conseguir un tiempo de detección de anomalías de
1500 ms para los servidores WebSphere Application Server Network Deployment versión 7:
- Establezca el periodo de transmisión de pulsaciones en 750 milisegundos.
- Establezca el periodo de tiempo de espera de pulsaciones en 1500 milisegundos.
Qué hacer a continuación
Cuando estos valores se modifican para proporcionar tiempos de migración tras error cortos, se debe tener
en cuenta algunas cuestiones relativas al ajuste del sistema. En primer lugar, Java no es un entorno de tiempo real.
Es posible que las hebras se demoren si
JVM está sufriendo tiempos de recogida de basura de larga duración. Las hebras también podrían demorarse si la máquina que aloja la JVM tiene mucha carga (debido a la propia JVM o a otros procesos que se ejecutan en la máquina). Si las hebras se retrasan, es posible que las pulsaciones no se envíen a tiempo. En el peor de los casos, podrían demorarse el tiempo de migración tras error necesario. Si las hebras se demoran, se producen detecciones de anomalías falsas. El sistema se debe ajustar y se debe modificar su tamaño para asegurarse de que las detecciones de anomalías falsas no se producen en un entorno de producción.
La mejor manera de garantizarlo es utilizando una carga adecuada durante la fase de prueba.
Nota: La versión actual de eXtreme Scale soporta WebSphere Real
Time.