Descripción general del clúster de chasis
Un clúster de chasis ofrece alta disponibilidad en dispositivos serie SRX, en los que dos dispositivos funcionan como un solo dispositivo. El clúster de chasis incluye la sincronización de archivos de configuración y los estados de sesión de tiempo de ejecución dinámico entre los dispositivos serie SRX, que forman parte de la instalación del clúster de chasis.
Descripción general del clúster de chasis
El Junos OS alta disponibilidad en dispositivos serie SRX mediante la agrupación en clústeres del chasis. Las puertas de enlace de servicios serie SRX se pueden configurar para funcionar en modo de clúster, donde se puede conectar un par de dispositivos y configurarse para funcionar como un solo nodo, lo que proporciona redundancia de dispositivo, interfaz y nivel de servicio.
En el caso de los dispositivos serie SRX, que actúan como firewalls con estado, es importante conservar el estado del tráfico entre dos dispositivos. En la configuración de un clúster de chasis, en caso de error, se requiere la perseverancia de la sesión para que no se descartan las sesiones establecidas, incluso si el dispositivo con errores reenvía el tráfico.
Cuando se configura como un clúster de chasis,los dos nodos se copian entre sí, con un nodo que actúa como dispositivo principal y el otro como secundario, lo que garantiza la conmutación por error con estado de los procesos y servicios en caso de falla del sistema o del hardware. Si se produce un error en el dispositivo principal, el secundario se encarga del procesamiento del tráfico. Los nodos del clúster se conectan junto con dos vínculos denominados vínculo de control y vínculo de estructura y dispositivos en un clúster de chasis sincronizan los estados de sesión de configuración, kernel y PFE en todo el clúster para facilitar la alta disponibilidad, conmutación por error de servicios de estado y equilibrio de carga.
No es necesaria ninguna licencia independiente para activar el clúster de chasis. Sin embargo, algunas Junos OS de software requieren una licencia para activar la función. Para obtener más información, consulte Descripción de requisitos de licencia de clúster de chasis,Instalación de licencias en dispositivos serie SRX en un clúster de chasis y Verificación de licencias en un dispositivo de la serie SRX en un clúster de chasis. Consulte la Guía de Juniper licencias para obtener información general acerca de la administración de licencias. Consulte las hojas de datos del producto en las puertas de enlace de servicios serie SRX para obtener más información, o póngase en contacto con su equipo Juniper cuenta o Juniper asociado.
- Beneficios del clúster de chasis
- Funcionalidad del clúster de chasis
- Modos de clúster de chasis
- ¿Cómo funciona la agrupación en clústeres de chasis?
- Compatibilidad con la agrupación en clústeres IPv6
Beneficios del clúster de chasis
Previene fallas en un solo dispositivo que da como resultado una pérdida de conectividad.
Proporciona alta disponibilidad entre los dispositivos cuando se conectan vínculos de sucursales y sitios remotos a oficinas corporativas más grandes. Mediante el aprovechamiento de la función de clúster de chasis, las empresas pueden garantizar la conectividad en caso de falla en el dispositivo o el vínculo.
Funcionalidad del clúster de chasis
La funcionalidad del clúster de chasis incluye:
Arquitectura de sistema resistente, con un único plano de control activo para todo el clúster y varios motores de reenvío de paquetes. Esta arquitectura presenta una vista de dispositivo único del clúster.
Sincronización de los estados de configuración y tiempo de ejecución dinámico entre nodos dentro de un clúster.
Supervisión de interfaces físicas y conmutación por error si los parámetros de falla cruzan un umbral configurado.
Modos de clúster de chasis
Un clúster de chasis se puede configurar en un modo activo/activo o activo/pasivo.
Active/passive mode: en modo activo/pasivo, el tráfico de tránsito pasa por el nodo principal mientras el nodo de respaldo solo se usa en caso de error. Cuando ocurre un error, el dispositivo de respaldo se convierte en principal y se encarga de todas las tareas de reenvío.
Active/active mode: en modo activo/activo, tiene tráfico de tránsito que pasa a través de ambos nodos del clúster todo el tiempo.
¿Cómo funciona la agrupación en clústeres de chasis?
Los puertos de control de los respectivos nodos se conectan para formar un plano de control que sincroniza la configuración y el estado del kernel para facilitar la alta disponibilidad de interfaces y servicios.
El plano de datos en los nodos respectivos está conectado a través de los puertos de estructura para formar un plano de datos unificado.
Al crear un clúster de chasis, los puertos de control de los nodos respectivos se conectan para formar un plano de control que sincroniza la configuración y el estado del kernel para facilitar la alta disponibilidad de interfaces y servicios.
De forma similar, el plano de datos de los nodos respectivos está conectado a través de los puertos de estructura para formar un plano de datos unificado.
El vínculo de estructura permite la administración del procesamiento de flujo entre nodos y la administración de redundancia de sesión.
El software del plano de control funciona en modo activo o de respaldo. Cuando se configura como un clúster de chasis, los dos nodos se copian entre sí, con un nodo que actúa como dispositivo principal y el otro como secundario, lo que garantiza la conmutación por error con estado de los procesos y servicios en caso de falla del sistema o del hardware. Si se produce un error en el dispositivo principal, el secundario se encarga del procesamiento del tráfico.
El software del plano de datos funciona en modo activo/activo. En un clúster de chasis, la información de la sesión se actualiza a medida que el tráfico atraviesa cualquiera de los dispositivos y esta información se transmite entre los nodos a través del vínculo de estructura para garantizar que no se descartan las sesiones establecidas cuando se produce una conmutación por error. En el modo activo/activo, es posible que el tráfico ingrese el clúster en un nodo y salida del otro nodo. Cuando un dispositivo se une a un clúster, se convierte en un nodo de ese clúster. A excepción de la configuración de nodos únicos y las direcciones IP de administración, los nodos de un clúster comparten la misma configuración.
En un momento dado, un clúster puede encontrarse en uno de los siguientes estados: retención, principal, retención secundaria, secundaria, inelegibilidad y deshabilitada. Una transición de estado se puede activar debido a cualquier evento, como monitoreo de interfaces, supervisión de SPU, fallas y conmutación por error manual.
Compatibilidad con la agrupación en clústeres IPv6
Los dispositivos serie SRX que ejecutan IP versión 6 (IPv6) se pueden implementar en configuraciones de clúster de chasis activo/activo (conmutación por error), además de la compatibilidad existente de configuraciones de clúster de chasis activo/pasivo (conmutación por error). Una interfaz se puede configurar con una dirección IPv4, una dirección IPv6 o ambas. Las entradas de la libreta de direcciones pueden incluir cualquier combinación de direcciones IPv4, direcciones IPv6 y nombres de sistema de nombres de dominio (DNS).
El clúster de chasis admite túneles de encapsulación de enrutamiento genérico (GRE) utilizados para enrutar tráfico IPv4/IPv6 encapsulado mediante una interfaz interna, gr-0/0/0. Esta interfaz se crea mediante Junos OS en el arranque del sistema y se usa solo para procesar túneles GRE. Consulte la Guía del usuario de interfaces para dispositivos de seguridad.
Limitaciones del clúster de chasis
Los dispositivos serie SRX tienen las siguientes limitaciones de clúster de chasis:
Chassis Cluster
No se admite VPN de grupo.
En todos los dispositivos de la serie SRX en un clúster de chasis, se admite el monitoreo de flujo de las versiones 5 y 8. Sin embargo, no se admite la supervisión de flujo para la versión 9.
Cuando un dispositivo de la serie SRX funciona en modo de clúster de chasis y encuentra cualquier problema de acceso de chip de IA en una SPC o una tarjeta de E/S (IOC), se activa una alarma FPC leve para activar la conmutación por error del grupo de redundancia.
En SRX5400, SRX5600 y SRX5800 dispositivos, los datos de estadísticas de pantalla se pueden recopilar únicamente en el dispositivo principal.
En los dispositivos SRX4600, SRX5400, SRX5600 y SRX5800, en configuraciones de clúster de chasis de gran tamaño, si se utilizan más de 1000 interfaces lógicas, se recomienda aumentar los temporizadores de latidos del clúster a partir del tiempo de espera predeterminado antes de activar la conmutación por error. En una implementación de capacidad completa, recomendamos aumentar la espera a 8 segundos mediante la modificación de los valores
heartbeat-threshold
heartbeat-interval
y en la[edit chassis cluster]
jerarquía.El producto de los
heartbeat-threshold
valores y define el tiempo antes de laheartbeat-interval
conmutación por error. Los valores predeterminados (heartbeat-threshold
de 3 latidos yheartbeat-interval
de 1000 milisegundos) producen un tiempo de espera de 3 segundos.Para cambiar el tiempo de espera, modifique los valores de opción para que el producto sea igual a la configuración deseada. Por ejemplo, establecer el en 8 y mantener el valor predeterminado
heartbeat-threshold
para los (1000 milisegundos) genera un tiempo de espera deheartbeat-interval
8 segundos. Del mismo modo, establecerheartbeat-threshold
el valor de 4 y 2000 milisegundos también genera un tiempo de esperaheartbeat-interval
de 8 segundos.En SRX5400, SRX5600 y SRX5800, las configuraciones de ocho colas no se reflejan en la interfaz del clúster de chasis.
Flow and Processing
Si utiliza la captura de paquetes en interfaces reth, se crean dos archivos, uno para paquetes de entrada y el otro para paquetes de salida basados en el nombre de interfaz reth. Estos archivos se pueden combinar fuera del dispositivo mediante herramientas como Wireshark o Mergecap.
Si utiliza la sipesma de puertos en interfaces de reth, la interfaz reth no se puede configurar como la interfaz de salida. Debe usar una interfaz física como interfaz de salida. Si configura la interfaz reth como una interfaz de salida mediante el comando, se mostrará
set forwarding-options port-mirroring family inet output
el siguiente mensaje de error.Port-mirroring configuration error
.Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config
Cuando un dispositivo de la serie SRX funciona en modo de clúster de chasis y encuentra cualquier chip de IA (chip IA es parte de Juniper SPC1 y IOC1. Tiene un impacto directo en el problema de acceso del plano de control SPC1/IOC1) en una SPC o una tarjeta de E/S (IOC), se activa una alarma FPC leve para activar la conmutación por error del grupo de redundancia.
En los dispositivos serie SRX en un clúster de chasis, cuando se configuran dos sistemas lógicos, el límite de escala cruza 13 000, lo que está muy cerca del límite de escala estándar de 15 000 y un tiempo de convergencia de 5 minutos. Este problema se produce porque el aprendizaje de rutas de multidifusión tarda más tiempo en aumentar la cantidad de rutas.
En los dispositivos SRX4600, SRX5400, SRX5600 y SRX5800 en un clúster de chasis, si el nodo principal que ejecuta el proceso LACP (lacpd) experimenta un reinicio sin problemas o sin gracia, el lacpd en el nuevo nodo principal podría tardar unos segundos en iniciar o restablecer las interfaces y las máquinas de estado para recuperar resultados sincrónicos inesperados. Además, durante la conmutación por error, cuando el sistema procesa paquetes de tráfico o paquetes internos de alta prioridad (eliminar sesiones o restablecer tareas), los paquetes LACP de prioridad media del par (conmutador) se insertan en las colas de espera, lo que provoca mayor retraso.
La supervisión de flujo se admite en SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M y SRX1500 remoto.
Installation and Upgrade
Para los dispositivos SRX300, SRX320, SRX340, SRX345, SRX380 y SRX550M, el parámetro no está disponible, ya que los dispositivos de un clúster se reinician automáticamente después de una actualización de clúster en banda
reboot
(ICU).
Interfaces
En la interfaz lsq-0/0/0, no se admiten los servicios de vínculo MLPPP, MLFR y CRTP.
En la interfaz lt-0/0/0, no se admite CoS para RPM.
No se admite la interfaz del marcador 3G.
No se admite la cola en la interfaz ae.
Layer 2 Switching
En la conmutación por error de dispositivos de la serie SRX, los puntos de acceso en el reinicio del conmutador de capa 2 y todos los clientes inalámbricos pierden conectividad de 4 a 6 minutos.
MIBs
No se admite BIA de clúster de chasis.
Monitoring
La cantidad máxima de IP de supervisión que se pueden configurar por clúster es 64 para SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M y SRX1500.
En SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M y SRX1500 dispositivos, los registros no se pueden enviar a NSM cuando el registro se configura en el modo de transmisión. No se pueden enviar registros porque el registro de seguridad no admite la configuración de la dirección IP de origen de la interfaz fxp0 y el destino del registro de seguridad en modo de transmisión no se puede enrutar a través de la interfaz fxp0. Esto implica que no puede configurar el servidor de registro de seguridad en la misma subred que la interfaz fxp0 y enrutar el servidor de registro a través de la interfaz fxp0.
IPv6
No se admite la supervisión de direcciones IP del grupo de redundancia para destinos IPv6.
GPRS
En SRX5400, SRX5600 y SRX5800 dispositivos, una APN o un filtro IMSI deben estar limitados a 600 para cada perfil de GTP. El número de filtros es directamente proporcional a la cantidad de entradas de prefijo IMSI. Por ejemplo, si una APN está configurada con dos entradas de prefijo IMSI, el número de filtros es dos.
MIBs
No se admite BIA de clúster de chasis.
Nonstop Active Routing (NSR)
-
NSR puede conservar la información de interfaz y kernel, y guardar la información del protocolo de enrutamiento ejecutando el proceso de protocolo de enrutamiento (RPD) en el servidor de motor de enrutamiento. Sin embargo, la mayoría de las plataformas SRX aún no admiten NSR. Entonces, en el nodo secundario, no existe un demonio RPD. Después de que se produzca la conmutación por error de RG0, el nuevo maestro RG0 tendrá un nuevo RPD y deberá volver a negociar con el dispositivo par. Solo las plataformas SRX5000 con versiones 17.4R2 o superior pueden admitir NSR.
A partir de Junos OS versión 12.1X45-D10 y posteriores, se admiten funciones de toma de muestras como la supervisión de flujo, la captura de paquetes y la creación de reflejo de puertos en interfaces de reth.