Agrupación en clúster: utilización de las recomendaciones de REFRESH CLUSTER

Ejecute REFRESH CLUSTER sólo si verdaderamente lo necesita

La tecnología de clúster de IBM® MQ garantiza que cualquier cambio en la configuración de clúster, como un cambio en una cola en clúster, se conozca automáticamente por cualquier miembro del clúster que necesite conocer la información. No es necesario realizar más pasos administrativos para lograr esta propagación de información.

Si esta información no llega a los gestores de colas del clúster cuando es necesario, por ejemplo, si otro gestor de colas del clúster no conoce una cola de clúster cuando una aplicación intenta abrirla por primera vez, se produce un problema en la infraestructura del clúster. Por ejemplo, es posible que un canal no pueda iniciarse entre un gestor de colas y un gestor de colas de repositorio completo. Por lo tanto, las situaciones donde se observen incoherencias deben investigarse. Si es posible, resuelva la situación sin utilizar el mandato REFRESH CLUSTER.

En raras circunstancias que se documentan en otras partes de la documentación de este producto, o cuando lo solicite el Soporte de ' IBM, puede utilizar el comando ' REFRESH CLUSTER ' para descartar toda la información mantenida localmente sobre un cluster y reconstruir esa información desde los repositorios completos del cluster.

La actualización en un clúster de gran tamaño puede afectar al rendimiento y la disponibilidad del clúster

El uso del mandato REFRESH CLUSTER puede ser perjudicial para el clúster mientras está en curso, por ejemplo, creando un aumento repentino del trabajo para los repositorios completos a medida que procesan la repropagación de los recursos del clúster del gestor de colas. Si está actualizando un clúster de gran tamaño (es decir, de varios cientos de gestores de colas) debe evitar el uso del mandato en el trabajo diario, si es posible, y utilizar métodos alternativos para corregir incoherencias específicas. Por ejemplo, si una cola de clúster no se propaga correctamente en el clúster, una técnica de investigación inicial de actualizar la definición de cola de clúster ,por ejemplo, modificando su descripción), vuelve a propagar la configuración de la cola en el clúster. Este proceso permite identificar el problema y posiblemente resolver una incoherencia temporal.

Si no se pueden utilizar métodos alternativos y tiene que ejecutar REFRESH CLUSTER en un clúster grande, debe hacerlo en horas de menor actividad o durante una ventana de mantenimiento para evitar el impacto en las cargas de trabajo del usuario. También debe evitar renovar un clúster grande en un solo lote y, en su lugar, escalonar la actividad tal como se explica en Evitar problemas de rendimiento y disponibilidad cuando los objetos de clúster envían actualizaciones automáticas.

Evitar problemas de rendimiento y disponibilidad cuando los objetos de clúster envían actualizaciones automáticas

Después de que se defina un nuevo objeto de clúster en un gestor de colas, se genera una actualización para este objeto cada 27 días desde el momento de la definición, y se envía a cada repositorio completo en el clúster y a otros gestores de colas de interesados. Cuando emite el mandato REFRESH CLUSTER a un gestor de colas, restablece el reloj para esta actualización automática en todos los objetos definidos localmente en el clúster especificado.

Si actualiza un clúster de gran tamaño (es decir, de varios cientos de gestores de colas) en un único lote, o en otras circunstancias como volver a crear un sistema a partir de la copia de seguridad de la configuración, después de 27 días, todos los gestores de colas volverán a anunciar todas sus definiciones de objetos en los repositorios completos al mismo tiempo. Esto podría volver a ralentizar de forma significativa la ejecución del sistema o incluso que éste no estuviera disponible, hasta que se hayan completado todas las actualizaciones. Por lo tanto, cuando haya que renovar o volver a crear varios gestores de colas en un clúster grande, habrá que escalonar la actividad durante varias horas o varios días, de modo que las actualizaciones automáticas sucesivas no penalicen el rendimiento del sistema de forma periódica.

La cola del historial del clúster del sistema

Cuando se emite un mandato REFRESH CLUSTER, el gestor de colas realiza una instantánea del estado del clúster antes de la renovación y la almacena en SYSTEM.CLUSTER.HISTORY.QUEUE (SCHQ) si está definido en el gestor de colas. Esta instantánea sólo es para fines de servicio de IBM , en caso de problemas posteriores con el sistema.

La cola SCHQ se define de forma predeterminada en los gestores de colas distribuidos durante el proceso de arranque. Para la migración de z/OS® , SCHQ debe definirse manualmente.

Los mensajes de la SCHQ caducan al cabo de tres meses.