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) ofrece eventos configurables que pueden decidir cuándo ocurre la redundancia en varias puertas de enlace en enrutadores serie MX con MS-MPC y MS-MIC. Esto le permite administrar conmutadores de rol principal en función de un evento supervisado. Puede configurar la redundancia según eventos supervisados, entre los que se incluyen los siguientes:
Eventos de enlace abajo.
Reinicios de FPC y PIC.
El demonio de protocolo de enrutamiento (rpd) termina y se reinicia.
Eventos de puerta de enlace par, 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 supervisado 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 abajo, eventos rpd y adquirir o publicar eventos de rol principal de pares.
Redundancy Policy: una política que define el conjunto de acciones que se toman 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— Una recopilación de uno o más conjuntos de servicios con una política o 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 de activación.
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 según los cambios de estado de función principal.
Routing Policies— Políticas configuradas para anunciar rutas basadas en la existencia o inexistencia de rutas de señal que utilizan la
if-route-existscondición.VRRP (Virtual Router Redundancy Protocol) route tracking—La función VRRP de Ta Junos OS, pero componente de 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 según la accesibilidad de la ruta rastreada, lo que desencadena una nueva elección de enrutador principal. La ruta que se rastreará es una ruta de señal.
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 que no sean RS1.
Un evento de redundancia puede formar parte de una sola política de redundancia, pero una 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 supervisados 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 solo un 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 se desactiva el 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 se desactiva el 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 deben 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 quita rutas de señal especificadas en la política de redundancia.
Cambie los servicios a la siguiente puerta de enlace de espera preferida.
Actualiza las funciones de sincronización de estado según sea necesario.
Los cambios de ruta resultantes causan:
La política de enrutamiento conectada a esta ruta para anunciar rutas de manera diferente.
VRRP para cambiar las prioridades anunciadas.
Para resumir el proceso de conmutación:
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. Los cambios de VRRP anunciaron las prioridades.
Los servicios cambian a la siguiente puerta de enlace de 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.
Configurar el demonio de redundancia de servicio
Antes de configurar el procesamiento de srd, recomendamos que esté familiarizado con la configuración de ICCP para MC-LAG, que explica las relaciones de pares entre puertas de enlace que están habilitadas para intercambiar roles primarios y de espera.
Utilice las siguientes instrucciones de configuración:
-
redundancy-policyen el[edit policy-options]nivel de jerarquía -
redundancy-eventen el[edit event-options]nivel de jerarquía -
redundancy-seten el[edit services]nivel de jerarquía
Las acciones que se deben realizar cuando se producen eventos de redundancia configurados se definen en las políticas de redundancia. Las policías 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 los IDENTIFICA de grupo de redundancia. Los detalles del grupo de redundancia están definidos por la configuración subyacente del demonio (iccpd) del protocolo de comunicación entre chasis. Los conjuntos de servicios y los conjuntos de redundancia se asocian a través de la instrucción en la redundancy-sets configuración de conjuntos de servicio.
En los procedimientos siguientes, los eventos de redundancia que se configuran y se asocian a una política de redundancia. La política de redundancia se asocia con un conjunto de redundancia para tomar las medidas adecuadas de la versión de rol principal o adquirir el rol principal. Si un evento se asocia con una política que toma la acción de versión del rol principal, srd comprueba si el estado del par de redundancia está listo o se le advierte. Si la espera se encuentra en un estado de advertencia, se produce un error en la acción de versión del rol principal. Puede restaurar la comprobación de estado y ejecutar manualmente la acción de rol principal de la versión.
Para liberar el rol principal en cualquier caso, puede configurar la acción de política 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 la configuración especifica la release-mastership-force opción, el uso del comando de CLI request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force tiene prioridad y se libera el rol principal. De manera similar, si un evento de redundancia está configurado con una política con una acción adquirir rol principal, srd comprueba el estado del conjunto de redundancia local. En el caso de un estado de espera, la acción falla a menos que utilice el comando de CLI request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force . Recomendamos que determine por qué las comprobaciones de estado fallan y que tome medidas para corregir el error. Después de eso, cuando el estado de conjunto de redundancia vuelve a LA ESPERA, esta acción de cambio de rol principal tiene éxito.
Un conjunto de redundancia determinado puede estar activo en una sola puerta de enlace, pero no todos los conjuntos de redundancia deben 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 en las que la función principal puede cambiar.
- Configuración de eventos de redundancia
- Configuración de políticas de redundancia
- Configuración de conjunto y grupo de redundancia
- Configuración de políticas de enrutamiento que admiten 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 del servicio especifican las acciones que se activan por los eventos de redundancia supervisados.
Para configurar políticas de redundancia:
En el ejemplo siguiente 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 de conjunto y grupo de redundancia
Los ID de grupo de redundancia que utiliza 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 uso del 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 redundancia
Para configurar políticas de enrutamiento compatibles con redundancia:
Configuración de conjuntos de servicios
Especifique la sincronización de 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 servicios de la puerta de enlace mediante la ejecución de 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: