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

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

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

El sistema supervisa 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 latido de control en ambos vínculos de control. Mientras se reciban latidos en uno de los vínculos de control, Junos OS considera que el otro nodo está vivo.

El producto de la opción y la heartbeat-interval opción definen el tiempo de espera antes de que se active la heartbeat-threshold 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 producirían un tiempo de espera de 5 segundos. Establecer el umbral de latido cardíaco en 4 y el intervalo de latidos en 1250 milisegundos también producirí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 latidos del clúster desde los 3 segundos predeterminados. A su máxima capacidad en un firewall SRX4600, SRX5400, SRX5600 o SRX5800, se recomienda aumentar el tiempo configurado antes de la conmutación por error a por lo menos 5 segundos.

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

Si se produce un error en el vínculo de control, Junos OS cambia el estado operativo del nodo secundario a no apto para una cuenta atrás de 180 segundos. Si el vínculo de estructura también falla durante los 180 segundos, Junos OS cambia el nodo secundario a primario; 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.

Un error en el vínculo de control se define como no recibir latidos a través del vínculo de control mientras los latidos se siguen recibiendo a través del vínculo de estructura.

En caso de que se produzca un error en un vínculo de control legítimo, el grupo de redundancia 0 sigue siendo primario en el nodo en el que es primario actualmente, los grupos de redundancia inactiva x del nodo principal se activan 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 un error en el vínculo de control legítimo, el sistema se basa en señales de vivacidad redundantes 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 enlace de la estructura y señales de latidos a través del enlace de control. Las sondas y las señales de latidos del corazón comparten un número de secuencia común que las asigna a un evento de tiempo único. Junos OS identifica un error de vínculo de control legítimo si se dan las dos condiciones siguientes:

• Se perdió el número umbral de latidos cardíacos.

• Se recibió al menos una sonda con un número de secuencia correspondiente al de una señal de latido cardíaco faltante en el enlace de la 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 atrás de 180 segundos llegue a cero, el nodo secundario se convierte en primario porque el sistema interpreta la pérdida de ambos vínculos para indicar que el otro nodo está muerto. Debido a que la pérdida simultánea de vínculos de control y estructura significa que los nodos ya no sincronizan estados ni comparan prioridades, ambos nodos podrían convertirse temporalmente en 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 se convierte en secundario y el clúster vuelve al funcionamiento normal.

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

• El grupo de redundancia 0 sigue siendo primario en el nodo en el que es actualmente primario (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 el principal, el nodo con el valor de prioridad más alto para el grupo de redundancia 0 es primario y su motor de enrutamiento está activo. (La prioridad para cada nodo se configura cuando se configura la instrucción para el redundancy-group grupo de redundancia 0.)

• El sistema deshabilita el nodo secundario.

  Para recuperar un dispositivo del modo deshabilitado, debe reiniciar el dispositivo. Al reiniciar 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 realizó cambios en la 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 condiciones siguientes:

• El tráfico entrante o saliente del host puede verse afectado durante un máximo de 3 segundos durante una falla del vínculo de control. Por ejemplo, considere un caso en el que el grupo de redundancia 0 es 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 se produce un error en el vínculo de control actualmente activo, la sesión de Telnet perderá paquetes durante 3 segundos, hasta que se detecte este error.

• Un error de vínculo de control que se produce mientras el proceso de confirmación se ejecuta en dos nodos puede provocar un error de confirmación. En esta situación, vuelva a ejecutar el comando commit después de 3 segundos.

Para los 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á en buen estado, emite un reinicio automático en el nodo deshabilitado. Cuando el nodo deshabilitado se reinicia, el nodo se une de nuevo al clúster.