Demonio de redundancia de servicio
Descripción general del demonio de redundancia de servicio
- Introducción al demonio de redundancia de servicio
- Componentes del demonio de redundancia de servicio
- Restricciones del demonio de redundancia de servicio
- Operación del demonio de redundancia de servicio
Introducción al demonio de redundancia de servicio
El demonio de redundancia de servicio (srd) proporciona eventos configurables que pueden decidir cuándo se produce redundancia en varias puertas de enlace en enrutadores serie MX con MS-MPC y MS-MIC. Esto le permite administrar cambios de roles principales en función de un evento supervisado. Puede configurar la redundancia en función de los eventos supervisados, incluidos:
Vincular eventos.
Reinicio de FPC y PIC.
El demonio de protocolo de enrutamiento (rpd) finaliza y se reinicia.
Eventos de puerta de enlace del mismo nivel, incluidas las solicitudes para adquirir o liberar el rol principal, o para difundir advertencias.
Componentes del demonio de redundancia de servicio
Los siguientes componentes configurables controlan el procesamiento de srd:
Redundancy Event: un evento crítico monitoreado que activa el srd para adquirir o liberar el rol principal para pares de redundancia, o para activar eventos de solo advertencia, y para agregar o eliminar rutas de señal. Los eventos supervisados incluyen eventos de interfaz o vínculo caído, eventos rpd y eventos de rol principal de adquisición o liberación de pares similares.
Redundancy Policy: una política que define el conjunto de acciones que se realizan cuando se produce un evento de redundancia. Las acciones disponibles incluyen la adquisición o liberación de la función principal, y la adición o eliminación de rutas de señal.
Redundancy Set: colección de uno o más conjuntos de servicios con una o varias políticas de redundancia comunes. Un conjunto de redundancia se aplica a dos o más puertas de enlace del sistema. Solo una de las puertas de enlace es principal y el par o pares están en espera en todo momento. Las políticas de redundancia definen las acciones que deben tomarse para un conjunto de redundancia cuando el SRD detecta un evento desencadenante.
Redundancy Group: existe una relación uno a uno entre un conjunto de redundancia y un grupo de redundancia. Un conjunto de redundancia puede formar parte de un solo grupo de redundancia.
Signal routes: rutas estáticas que el srd agrega o elimina en función de los cambios de estado del rol principal.
Routing Policies: políticas configuradas para anunciar rutas basadas en la existencia o inexistencia de rutas de señal mediante la
if-route-exists
condición.VRRP (Virtual Router Redundancy Protocol) route tracking—Función VRRP de Junos OS estándar de TA, pero componente srd opcional, que rastrea si existe una ruta accesible en la tabla de enrutamiento de la instancia de enrutamiento incluida en la configuración y cambia dinámicamente la prioridad del grupo VRRP en función de la accesibilidad de la ruta rastreada, lo que desencadena una nueva elección de enrutador principal. La ruta a rastrear es una ruta de señal.
Restricciones del demonio de redundancia de servicio
Las siguientes restricciones se aplican a las configuraciones de procesamiento srd:
Existe una relación uno a uno entre un conjunto de redundancia y un grupo de redundancia. Un conjunto de redundancia puede formar parte de un solo grupo de redundancia.
Una directiva de redundancia puede formar parte de un solo conjunto de redundancia, pero un conjunto de redundancia puede tener varias directivas de redundancia. Por ejemplo, el conjunto de redundancia RS1 puede incluir directivas de redundancia RP1 y RP2. Las políticas de redundancia RP1 y RP2 no se pueden incluir en conjuntos de redundancia que no sean RS1.
Un evento de redundancia puede formar parte de una sola directiva de redundancia, pero una directiva de redundancia puede tener varios eventos de redundancia. Por ejemplo, la política de redundancia RP1 puede incluir eventos de redundancia RE1 y RE2. Los eventos de redundancia RE1 y RE2 no se pueden incluir en políticas de redundancia que no sean RP1.
Una interfaz o vínculo supervisado puede formar parte de un solo evento de redundancia, pero un evento de redundancia puede tener varias interfaces supervisadas.
Un conjunto de servicios puede formar parte de un solo conjunto de redundancia, pero un conjunto de redundancia puede tener varios conjuntos de servicios.
Si la puerta de enlace 1, el chasis que está configurado con la dirección IP inferior, es el chasis principal y desactiva SRD en él, se produce un cambio a la puerta de enlace 2. Si la puerta de enlace 2, el chasis que está configurado con la dirección IP superior, es el chasis principal y desactiva SRD en él, no se produce un cambio.
Un conjunto de redundancia determinado puede estar activo en una sola puerta de enlace, pero no todos los conjuntos de redundancia tienen que estar activos en la misma puerta de enlace. Por ejemplo, el conjunto de redundancia A puede estar activo en la puerta de enlace 1, mientras que el conjunto de redundancia B está activo en la puerta de enlace 2.
Operación del demonio de redundancia de servicio
El srd funciona de la siguiente manera:
El srd se ejecuta en el motor de enrutamiento. Supervisa continuamente los eventos de redundancia configurados.
Cuando se detecta un evento de redundancia, el comando srd:
Agrega o quita rutas de señal especificadas en la directiva de redundancia.
Cambia los servicios a la siguiente puerta de enlace en espera preferida.
Actualiza los roles de sincronización con estado según sea necesario.
Los cambios de ruta resultantes causan:
La directiva de enrutamiento conectada a esta ruta para anunciar rutas de manera diferente.
VRRP para cambiar las prioridades anunciadas.
Para resumir el proceso de cambio:
Se produce un evento crítico.
SRD agrega o elimina una ruta de señal.
Una política de enrutamiento anuncia las rutas de manera diferente. VRRP cambia las prioridades anunciadas.
Los servicios cambian a la siguiente puerta de enlace en espera preferida.
La sincronización de estado se actualiza en consecuencia.
El orden de las prioridades de enrutamiento debe coincidir con el orden de la función principal de servicios.
Configuración del demonio de redundancia de servicio
Antes de configurar el procesamiento de SRD, le recomendamos que se familiarice con Configuración de ICCP para MC-LAG, que explica las relaciones del mismo nivel entre puertas de enlace habilitadas para intercambiar roles principales y en espera.
Utilice las instrucciones de configuración siguientes:
-
redundancy-policy
en el[edit policy-options]
nivel jerárquico -
redundancy-event
en el[edit event-options]
nivel jerárquico -
redundancy-set
en el[edit services]
nivel jerárquico
Las acciones que se deben realizar cuando se producen eventos de redundancia configurados se definen en las directivas de redundancia. Las políticas de redundancia están asociadas con conjuntos de redundancia; Son análogas a las reglas asociadas con los conjuntos de servicios. Los conjuntos de redundancia se asocian a los grupos de redundancia mediante identificadores de grupo de redundancia. Los detalles del grupo de redundancia se definen mediante la configuración subyacente del demonio de protocolo de comunicación entre chasis (iccpd). Los conjuntos de servicios y los conjuntos de redundancia se asocian mediante la instrucción en la configuración de conjuntos de redundancy-sets
servicios.
En los procedimientos siguientes, eventos de redundancia configurados y asociados a una directiva de redundancia. La política de redundancia está asociada con un conjunto de redundancia para tomar las medidas adecuadas de liberación del rol principal o adquisición del rol principal. Si un evento está asociado a una política que realiza la acción de liberación del rol principal, srd comprueba si el estado del par de redundancia está listo o advertido. Si el modo de espera está en estado de advertencia, se produce un error en la acción de liberación del rol principal. Puede restaurar la comprobación de estado y ejecutar manualmente la acción del rol principal de liberación.
Para liberar el rol principal en cualquier caso, puede configurar la acción de directiva como release-mastership-force
o usar el request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force
comando en la CLI operativa. Incluso si su configuración especifica la release-mastership-force
opción, el uso del comando CLI tiene prioridad y se libera el request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force
rol principal. Del mismo modo, si se configura un evento de redundancia con una política con una acción de adquirir rol principal, srd comprueba el estado del conjunto de redundancia local. En el caso de un estado de espera, se produce un error en la acción a menos que utilice el comando de la request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force
CLI. Le recomendamos que determine por qué se produce un error en las comprobaciones de estado y que tome medidas para corregirlo. Después de eso, cuando el estado del conjunto de redundancia vuelva a STANDBY, esta acción de cambio de rol principal se realizará correctamente.
Un conjunto de redundancia determinado puede estar activo en una sola puerta de enlace, pero no todos los conjuntos de redundancia tienen que estar activos en la misma puerta de enlace. Por ejemplo, el conjunto de redundancia A puede estar activo en la puerta de enlace 1, mientras que el conjunto de redundancia B está activo en la puerta de enlace 2.
Para configurar SRD, realice las siguientes tareas de configuración en la secuencia recomendada. Se muestran las configuraciones de dos puertas de enlace cuyo rol principal puede cambiar.
- Configuración de eventos de redundancia
- Configuración de directivas de redundancia
- Configuración del conjunto y el grupo de redundancia
- Configuración de directivas de enrutamiento compatibles con la redundancia
- Configuración de conjuntos de servicios
Configuración de eventos de redundancia
Para configurar eventos de redundancia:
Configuración de directivas de redundancia
Las políticas de redundancia de servicio especifican acciones desencadenadas por eventos de redundancia supervisados.
Para configurar directivas de redundancia:
En el ejemplo siguiente se muestra cómo configurar directivas de redundancia para dos puertas de enlace del mismo nivel:
user@gateway1# edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events ACQU_MSHIP_MANUAL_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-event ACQU_MSHIP_MANUAL_EV then] user@gateway1# set acquire-mastership add-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway1# top user@gateway1# edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then [edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then] user@gateway1# set release-mastership-force delete-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE
user@gateway2# edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events ACQU_MSHIP_MANUAL_EV then] user@gateway2# set release-mastership-force add-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway2# top user@gateway2# edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events PEER_MSHIP_RELS_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events PEER_MSHIP_RELS_EV then] user@gateway2# set acquire-mastership delete-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway2# top user@gateway2# edit policy-options redundancy-policy WARN_POL redundancy-events WARN_EV then [edit policy-options redundancy-policy WARN_POL redundancy-events WARN_EV then] user@gateway2# set broadcast-warning
Configuración del conjunto y el grupo de redundancia
Los ID de grupo de redundancia que usa srd están asociados con los configurados para el demonio ICCP (iccpd) a través de la jerarquía de configuración ICCP existente mediante el mismo ID de grupo de redundancia en la configuración del grupo de redundancia de servicios.
iccp { local-ip-addr 10.1.1.1; peer 10.2.2.2 { redundancy-group-id-list 1; liveness-detection { minimum-interval 1000; } } }
Para configurar conjuntos de redundancia:
Configuración de directivas de enrutamiento compatibles con la redundancia
Para configurar directivas de enrutamiento que admitan la redundancia:
Configuración de conjuntos de servicios
Especifique la sincronización con estado de los servicios para un conjunto de servicios.
[edit] user@gateway1# set services service-set service-set-name redundancy-set-id redundancy-set
Por ejemplo:
[edit] user@gateway1# set services service-set CGN4_SP-7-0-0 redundancy-set-id 1
Uso de scripts de demonio de redundancia de servicio para ver y cambiar el estado de una puerta de enlace
Puede determinar el estado de una puerta de enlace, deshabilitar o habilitar todas las interfaces de la puerta de enlace o extraer información MIB relacionada con los servicios de la puerta de enlace ejecutando scripts de demonio de redundancia de servicio (SRD).
Antes de poder usar estos scripts, debe habilitarlos:
Habilite los scripts srd.
[edit] user@host# set system scripts op file sdg-inservice.slax user@host# set system scripts op file sdg-oos.slax user@host# set system scripts op file services-oids.slax user@host# set system scripts op file srd-status.slax user@host# set system scripts op max-datasize 512m
Utilice los scripts srd como usuario raíz: