Servicio de redundancia Daemon
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 servicio de redundancia (SRD) proporciona eventos configurables que pueden decidir cuándo se produce una redundancia en varias puertas de enlace en enrutadores de la serie MX con MS-MPC y MS-MIC. Esto le permite administrar los cambios de rol principal en función de un evento supervisado. Puede configurar la redundancia en función de eventos supervisados, entre los que se incluyen:
Vincular eventos.
Reinicios de FPC y PIC.
El demonio de protocolo de enrutamiento (rpd) finaliza y se reinicia.
Eventos de puerta de enlace de pares, incluidas las solicitudes para adquirir o liberar la función 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 supervisado que activa el srd para adquirir o liberar el rol principal para los pares de redundancia, o para activar eventos de solo advertencia y agregar o eliminar rutas de señal. Los eventos supervisados incluyen eventos de interfaz o vínculo inactivo, eventos de RPD y eventos de adquisición o liberación de roles principales de pares.
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ñales.
Redundancy Set: una 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 cualquier momento. Las políticas de redundancia definen las acciones que se deben realizar 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 agrega o elimina el srd en función de los cambios de estado de la función principal.
Routing Policies: políticas configuradas para anunciar rutas basadas en la existencia o inexistencia de rutas de señal mediante la
if-route-existscondición.VRRP (Virtual Router Redundancy Protocol) route tracking—Función VRRP de Junos OS estándar TA, pero componente SRD opcional, que rastrea si existe una ruta alcanzable 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 seguir es una ruta de señalización.
Restricciones del demonio de redundancia de servicio
Las siguientes restricciones se aplican a las configuraciones de procesamiento de 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 política de redundancia puede formar parte de un solo conjunto de redundancia, pero un conjunto de redundancia puede tener varias políticas de redundancia. Por ejemplo, el conjunto de redundancia RS1 puede incluir políticas de redundancia RP1 y RP2. Las políticas de redundancia RP1 y RP2 no se pueden incluir en conjuntos de redundancia distintos de RS1.
Un evento de redundancia puede formar parte de una sola política de redundancia, pero una política 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 distintas de 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 configurado con la dirección IP más baja, es el chasis principal y desactiva SRD en él, se produce una conmutación a la puerta de enlace 2. Si la puerta de enlace 2, el chasis configurado con la dirección IP más alta, es el chasis principal y desactiva SRD en él, no se produce una conmutación.
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. Monitorea continuamente los eventos de redundancia configurados.
Cuando se detecta un evento de redundancia, el srd:
Agrega o elimina rutas de señal especificadas en la política de redundancia.
Conmutadores 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 provocan:
La política de enrutamiento se conectó 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 los servicios.
| Plataforma |
Diferencia |
|---|---|
| serie MX |
El demonio de redundancia de servicio no está habilitado de forma predeterminada. Puede habilitar el daemon de redundancia de servicio mediante la instrucción services redundancy bring-up-on-any en la [edit] jerarquía. |
Configuración del daemon 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 par entre puertas de enlace que están habilitadas para intercambiar roles principal y en espera.
Utilice las siguientes instrucciones de configuración:
-
redundancy-policyen el nivel jerárquico[edit policy-options] -
redundancy-eventen el nivel jerárquico[edit event-options] -
redundancy-seten el nivel jerárquico[edit services]
Las acciones que se deben realizar cuando se producen eventos de redundancia configurados se definen en políticas de redundancia. Las directivas 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 grupos de redundancia mediante ID de grupo de redundancia. Los detalles del grupo de redundancia se definen mediante la configuración del demonio de protocolo de comunicación entre chasis subyacente (iccpd). Los conjuntos de servicios y los conjuntos de redundancia se asocian mediante la instrucción en la redundancy-sets configuración de conjuntos de servicios.
En los procedimientos siguientes, los eventos de redundancia configurados y asociados a una política de redundancia. La política de redundancia está asociada con un conjunto de redundancia para tomar las medidas adecuadas de liberación de rol principal o adquisición de rol principal. Si un evento está asociado con una política que toma la acción de liberación de 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 producirá un error en la acción de liberación de la función principal. Puede restaurar la comprobación de estado y ejecutar manualmente la acción de función principal de la versión.
Para liberar la función principal en cualquier caso, puede configurar la acción de la política como release-mastership-force o utilizar 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 de la CLI tiene prioridad y se libera la request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force función principal. Del mismo modo, si un evento de redundancia se configura con una política con una acción de adquisición de 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 tome medidas para corregirlo. Después de eso, cuando el estado de conjunto de redundancia vuelva a STANDBY, esta acción de cambio de rol principal se realiza 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 para las que puede cambiar la función principal.
- Configuración de eventos de redundancia
- Configuración de políticas de redundancia
- Configuración del conjunto y grupo de redundancia
- Configuración de políticas de enrutamiento que admiten la redundancia
- Configuración de conjuntos de servicios
Configuración de eventos de redundancia
Para configurar eventos de redundancia:
Configuración de políticas de redundancia
Las políticas de redundancia de servicio especifican acciones desencadenadas por eventos de redundancia supervisados.
Para configurar políticas de redundancia:
En el siguiente ejemplo, se muestra la configuración de políticas de redundancia para dos puertas de enlace par:
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 grupo de redundancia
Los ID de grupo de redundancia que utiliza srd se asocian con los configurados para el daemon ICCP (iccpd) mediante 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 políticas de enrutamiento que admiten la redundancia
Para configurar políticas 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 de MIB relacionada con servicios de la puerta de enlace mediante la ejecución de scripts de demonio de redundancia de servicio (SRD).
Antes de poder utilizar estas secuencias de comandos, debe habilitarlas:
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: