Uso de ruta múltiple de igual coste (ECMP)

Mediante el mecanismo ECMP (Equal Cost Múltiple Path) en una implementación de clúster, los nodos de clúster activos anuncian las direcciones IP del servidor virtual. El nodo del clúster que recibe el tráfico anunciado dirige el tráfico al nodo que debe procesar el tráfico. Puede haber una dirección redundante en servidores virtuales manchados y parcialmente seccionados. Por lo tanto, a partir de NetScaler 11, las direcciones IP del servidor virtual detectada y parcialmente rayada anuncian los nodos propietarios, lo que reduce la dirección redundante.

Debe tener un conocimiento detallado de los protocolos de enrutamiento para usar ECMP. Para obtener más información, consulte Configuración de Rutas Dinámicas. Para obtener más información sobre el enrutamiento en un clúster, consulte Enrutamiento en un clúster.

Para utilizar ECMP, primero debe realizar lo siguiente:

  • Habilite el protocolo de enrutamiento requerido (OSPF, RIP, BGP o ISIS) en la dirección IP del clúster.
  • Enlazar las interfaces y la dirección IP detectada (con enrutamiento dinámico habilitado) a una VLAN.
  • Configure el protocolo de enrutamiento seleccionado y redistribuya las rutas del kernel en los ZebOS mediante el shell vtysh.

Debe realizar configuraciones similares en la dirección IP del clúster y en el dispositivo de conexión externo.

Nota

  • Asegúrese de que las licencias del clúster admiten enrutamiento dinámico; de lo contrario, ECMP no funciona.
  • ECMP no es compatible con servidores virtuales comodín, ya que RHI necesita una dirección VIP para anunciarse a un router y los servidores virtuales comodín no tienen direcciones VIP asociadas.

Imagen 1. Topología ECMP

Imagen localizada

Como se ve en la figura anterior, el enrutador ECMP puede llegar a la dirección VIP a través de SNIP0, SNIP1 o SNIP2.

Para configurar ECMP en el clúster mediante la interfaz de línea de comandos

  1. Inicie sesión en la dirección IP del clúster.

  2. Habilite el protocolo de enrutamiento.

    > enable ns feature <feature>
    

    Ejemplo: Para habilitar el protocolo de enrutamiento OSPF.

    > enable ns feature ospf
    
  3. Agregue una VLAN.

    > add vlan <id>
    

    Ejemplo

    > add vlan 97
    
  4. Enlace las interfaces de los nodos del clúster a la VLAN.

    > bind vlan <id> -ifnum <interface_name>
    

    Ejemplo

    > bind vlan 97 -ifnum 0/1/2 1/1/2 2/1/2
    
  5. Agregue una dirección SNIP detectada para cada nodo y habilite el enrutamiento dinámico en él.

    > add ns ip <SNIP> <netmask> -ownerNode <positive_integer> -dynamicRouting ENABLED
    

    Ejemplo

    > add ns ip 97.131.0.1 255.0.0.0 -ownerNode 0 -dynamicRouting ENABLED -type SNIP
    
    > add ns ip 97.131.0.2 255.0.0.0 -ownerNode 1 -dynamicRouting ENABLED -type SNIP
    
    > add ns ip 97.131.0.3 255.0.0.0 -ownerNode 2 -dynamicRouting ENABLED -type SNIP
    
  6. Enlazar una de las direcciones SNIP detectada a la VLAN. Cuando vincula una dirección SNIP detectada a una VLAN, todas las demás direcciones SNIP detectada definidas en el clúster de esa subred se vinculan automáticamente a la VLAN.

    > bind vlan <id> -IPAddress <SNIP> <netmask>
    

    Ejemplo

    > bind vlan 97 -ipAddress 97.131.0.1 255.0.0.0
    

    Nota

    Puede usar direcciones NSIP de los nodos del clúster en lugar de agregar direcciones SNIP. Si es así, no tiene que realizar los pasos 3 a 6.

  7. Configure el protocolo de enrutamiento en ZebOS mediante el shell vtysh.

    Ejemplo:

    Para configurar el protocolo de enrutamiento OSPF en los ID de nodo 0, 1 y 2.

    > vtysh
      ! interface vlan97 !
       router ospf   owner-node 0
       ospf router-id 97.131.0.1   exit-owner-node
       owner-node 1    ospf router-id 97.131.0.2
       exit-owner-node
       owner-node 2
       ospf router-id 97.131.0.3   exit-owner-node   redistribute kernel network 97.0.0.0/8 area 0  !
    

    Nota

    Para que las direcciones VIP se publiquen, la configuración de RHI debe realizarse mediante el parámetro VServerRhiLevel de la siguiente manera:

    add ns ip <IPAddress> <netmask> -type VIP -vserverRHILevel <vserverRHILevel>
    

    Para la configuración de RHI específica de OSPF, hay configuraciones adicionales que se pueden hacer de la siguiente manera:

    add ns ip <IPAddress> <netmask> -type VIP -ospfLSAType ( TYPE1 | TYPE5 ) -ospfArea <positive_integer>
    

    Utilice el comando add ns ip6 para realizar los comandos anteriores en direcciones IPv6.

  8. Configure ECMP en el conmutador externo. Se proporcionan las siguientes configuraciones de ejemplo para el conmutador Cisco® Nexus 7000 C7010 Release 5.2 (1). Se deben realizar configuraciones similares en otros conmutadores.

    //For OSPF (IPv4 addresses)  Global config:  Configure terminal  feature ospf    Interface config:  Configure terminal  interface Vlan10      no shutdown      ip address 97.131.0.5/8    Configure terminal  router ospf 1  network 97.0.0.0/8 area 0.0.0.0  ---------------------------------
    
    //For OSPFv3 (IPv6 addresses)  Global config:  Configure terminal  feature ospfv3    Configure terminal  interface Vlan10      no shutdown      ipv6 address use-link-local-only      ipv6 router ospfv3 1 area 0.0.0.0    Configure terminal  router ospfv3 1
    

Nodos de clúster de supervisión de enrutadores en la implementación de ECMP

En una configuración de clúster, en un nodo propietario que tiene una configuración de dirección SNIP detectada, ahora puede inhabilitar la opción OwnerDownResponse. De forma predeterminada, la opción está habilitada, lo que permite que el nodo responda a una solicitud ICMP/ARP/ICMP6/ND6 procedente del router ascendente. Ahora puede inhabilitar esta opción para permitir que el enrutador supervise si un nodo de clúster está activo o inactivo. Cuando el router envía una solicitud, si la opción está inhabilitada, identifica que el nodo propietario está inactivo y no está disponible para la distribución del tráfico.

Para configurar ECMP para la distribución de tráfico de rutas estáticas mediante la interfaz de línea de comandos

add ns ip <ipddress> <netmask> -ownernode <node-id> —ownerDownResponse disable