Configuración de parámetros de conmutación por error de clúster

Descripción de los latidos del vínculo de control del clúster del chasis

Puede especificar el umbral de latido y el intervalo de latido al configurar el clúster de chasis.

El sistema monitorea el estado del vínculo de control de forma predeterminada.

Para los vínculos de control dual, que se admiten en líneas SRX5600 y SRX5800, el proceso del protocolo de redundancia de servicios de Juniper (jsrpd) envía y recibe los mensajes de latidos de control en ambos vínculos de control. Mientras se reciben latidos en uno de los vínculos de control, Junos OS considera que el otro nodo está vivo.

El producto de la heartbeat-threshold opción y la opción definen el heartbeat-interval tiempo de espera antes de que se active la conmutación por error. Los valores predeterminados de estas opciones producen un tiempo de espera de 3 segundos. Un umbral de latido de 5 y un intervalo de latidos de 1000 milisegundos darían un tiempo de espera de 5 segundos. Establecer el umbral de latidos en 4 y el intervalo de latidos en 1250 milisegundos también daría un tiempo de espera de 5 segundos.

En un entorno de clúster de chasis, si se utilizan más de 1000 interfaces lógicas, se recomienda aumentar los temporizadores de latido del clúster desde el valor predeterminado de 3 segundos. Con la capacidad máxima en un dispositivo SRX4600, SRX5400, SRX5600 o SRX5800, recomendamos que aumente el tiempo configurado antes de la conmutación por error a al menos 5 segundos.

Descripción de la recuperación y la falla del vínculo de control del clúster del chasis

Si se produce un error en el vínculo de control, Junos OS cambia el estado operativo del nodo secundario para que no sea elegible para una cuenta regresiva de 180 segundos. Si el vínculo de estructura también falla durante los 180 segundos, Junos OS cambia el nodo secundario a principal; de lo contrario, después de 180 segundos el estado del nodo secundario cambia a deshabilitado.

Cuando el vínculo de control está inactivo, se genera un mensaje de registro del sistema.

Una falla del vínculo de control se define como no recibir latidos a través del vínculo de control mientras los latidos aún se reciben a través del vínculo de estructura.

En caso de un error de vínculo de control legítimo, el grupo de redundancia 0 sigue siendo principal en el nodo en el que es principal actualmente, los grupos de redundancia inactivo x en el nodo principal se vuelven activos y el nodo secundario entra en un estado deshabilitado.

Cuando el nodo secundario está deshabilitado, aún puede iniciar sesión en el puerto de administración y ejecutar diagnósticos.

Para determinar si se ha producido una falla legítima del vínculo de control, el sistema depende de señales redundantes de livelines enviadas tanto a través del vínculo de control como del vínculo de estructura.

El sistema transmite periódicamente sondas a través del vínculo de estructura y señales de latidos a través del vínculo de control. Las sondas y las señales de latido comparten un número de secuencia común que las asigna a un evento de tiempo único. Junos OS identifica un error legítimo del vínculo de control si existen las dos condiciones siguientes:

• Se perdió el umbral de latidos.

• Se recibió al menos un sondeo con un número de secuencia correspondiente al de una señal de latido faltante en el vínculo de estructura.

Si se produce un error en el vínculo de control, comienza la cuenta atrás de 180 segundos y el estado del nodo secundario no es elegible. Si el vínculo de estructura falla antes de que la cuenta regresiva de 180 segundos llegue a cero, el nodo secundario se convierte en principal porque el sistema interpreta la pérdida de ambos vínculos para indicar que el otro nodo está muerto. Dado que la pérdida simultánea de vínculos de control y estructura significa que los nodos ya no sincronizan estados ni comparan prioridades, por lo que ambos nodos podrían pasar a ser temporalmente primarios, lo que no es un estado operativo estable. Sin embargo, una vez que se restablece el vínculo de control, el nodo con el valor de prioridad más alto se convierte automáticamente en primario, el otro nodo pasa a ser secundario y el clúster vuelve a la operación normal.

Cuando se produce un error de vínculo de control legítimo, se aplican las siguientes condiciones:

• El grupo de redundancia 0 sigue siendo principal en el nodo en el que es actualmente principal (y, por lo tanto, su motor de enrutamiento permanece activo), y todos los grupos de redundancia x en el nodo se convierten en primarios.

  Si el sistema no puede determinar qué motor de enrutamiento es principal, el nodo con el valor de prioridad más alto para el grupo de redundancia 0 es principal y su motor de enrutamiento está activo. (Puede configurar la prioridad para cada nodo al configurar la instrucción para el redundancy-group grupo de redundancia 0.)

• El sistema deshabilita el nodo secundario.

  Para recuperar un dispositivo desde el modo deshabilitado, debe reiniciar el dispositivo. Cuando reinicie el nodo deshabilitado, el nodo sincroniza su estado dinámico con el nodo principal.

Si realiza algún cambio en la configuración mientras el nodo secundario está deshabilitado, ejecute el comando commit para sincronizar la configuración después de reiniciar el nodo. Si no ha realizado cambios de configuración, el archivo de configuración permanece sincronizado con el del nodo principal.

No puede habilitar la preferencia para el grupo de redundancia 0. Si desea cambiar el nodo principal para el grupo de redundancia 0, debe realizar una conmutación por error manual.

Cuando utilice vínculos de control dual (compatibles con dispositivos SRX5600 y SRX5800), tenga en cuenta las siguientes condiciones:

• El tráfico de entrada o salida del host puede verse afectado durante hasta 3 segundos durante una falla del vínculo de control. Por ejemplo, considere un caso en el que el grupo de redundancia 0 es el principal en el nodo 0 y hay una sesión telnet en el motor de enrutamiento a través de un puerto de interfaz de red en el nodo 1. Si el vínculo de control activo actualmente falla, la sesión telnet perderá paquetes durante 3 segundos, hasta que se detecte este error.

• Una falla del vínculo de control que se produce mientras el proceso de confirmación se ejecuta en dos nodos puede dar lugar a una falla de confirmación. En esta situación, ejecute el comando commit de nuevo después de 3 segundos.

Para dispositivos SRX5600 y SRX5800, los vínculos de control dual requieren un segundo motor de enrutamiento en cada nodo del clúster de chasis.

Puede especificar que el sistema realice automáticamente la recuperación del vínculo de control estableciendo la control-link-recovery instrucción. En este caso, una vez que el sistema determina que el vínculo de control está funcionando, se reinicia automáticamente el nodo deshabilitado. Cuando el nodo deshabilitado se reinicia, el nodo se une al clúster de nuevo.