Utilisation d’un chemin ECMP

En utilisant le mécanisme ECMP (Equal Cost Multiple Path) sur un déploiement de cluster, les nœuds de cluster actifs annoncent les adresses IP du serveur virtuel. Le nœud de cluster qui reçoit le trafic annoncé dirige le trafic vers le nœud qui doit traiter le trafic. Il peut y avoir une direction redondante dans les serveurs virtuels repérés et partiellement entrelacés. Par conséquent, à partir de NetScaler 11, les adresses IP de serveurs virtuels spotted et striped partiels annoncent les nœuds propriétaires, ce qui réduit la direction redondante.

Vous devez avoir une connaissance détaillée des protocoles de routage pour utiliser ECMP. Pour de plus amples informations, consultez la section Configuration d’itinéraires dynamiques. Pour plus d’informations sur le routage dans un cluster, reportez-vous à la section Routage dans un cluster.

Pour utiliser ECMP, vous devez d’abord effectuer les opérations suivantes :

  • Activez le protocole de routage requis (OSPF, RIP, BGP ou ISIS) sur l’adresse IP du cluster.
  • Liez les interfaces et l’adresse IP spotted (avec le routage dynamique activé) à un VLAN.
  • Configurez le protocole de routage sélectionné et redistribuez les routes du noyau sur les ZebOS à l’aide du shell vtysh.

Vous devez effectuer des configurations similaires sur l’adresse IP du cluster et sur le périphérique de connexion externe.

Remarque

  • Assurez-vous que les licences du cluster prennent en charge le routage dynamique, sinon ECMP ne fonctionne pas.
  • ECMP n’est pas pris en charge pour les serveurs virtuels génériques car RHI a besoin d’une adresse VIP pour annoncer à un routeur et que les serveurs virtuels génériques n’ont pas d’adresses VIP associées.

Figure 1. Topologie ECMP

image localisée

Comme vu dans la figure ci-dessus, le routeur ECMP peut atteindre l’adresse VIP via SNIP0, SNIP1 ou SNIP2.

Pour configurer ECMP sur le cluster à l’aide de l’interface de ligne de commande

  1. Connectez-vous à l’adresse IP du cluster.

  2. Activez le protocole de routage.

    > enable ns feature <feature>
    

    Exemple : pour activer le protocole de routage OSPF.

    > enable ns feature ospf
    
  3. Ajoutez un VLAN.

    > add vlan <id>
    

    Exemple

    > add vlan 97
    
  4. Liez les interfaces des nœuds de cluster au VLAN.

    > bind vlan <id> -ifnum <interface_name>
    

    Exemple

    > bind vlan 97 -ifnum 0/1/2 1/1/2 2/1/2
    
  5. Ajoutez une adresse SNIP spotted pour chaque nœud et activez le routage dynamique sur celui-ci.

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

    Exemple

    > 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. Liez l’une des adresses SNIP spotted au VLAN. Lorsque vous liez une adresse SNIP spotted à un VLAN, toutes les autres adresses SNIP spotted définies sur le cluster dans ce sous-réseau sont automatiquement liées au VLAN.

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

    Exemple

    > bind vlan 97 -ipAddress 97.131.0.1 255.0.0.0
    

    Remarque

    Vous pouvez utiliser les adresses NSIP des nœuds de cluster au lieu d’ajouter des adresses SNIP. Si oui, vous n’avez pas à effectuer les étapes 3 à 6.

  7. Configurez le protocole de routage sur ZeBos en utilisant vtysh shell.

    Exemple :

    Pour configurer le protocole de routage OSPF sur les ID de nœud 0, 1 et 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  !
    

    Remarque

    Pour que les adresses VIP soient annoncées, le paramètre RHI doit être fait à l’aide du paramètre vServerRhiLevel comme suit :

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

    Pour les paramètres RHI spécifiques à OSPF, il existe d’autres paramètres qui peuvent être effectués comme suit :

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

    Utilisez la commande add ns ip6 pour exécuter les commandes ci-dessus sur les adresses IPv6.

  8. Configurez ECMP sur le commutateur externe. Les exemples de configuration suivants sont fournis pour le commutateur Cisco® Nexus 7000 C7010 version 5.2(1). Des configurations similaires doivent être effectuées sur d’autres commutateurs.

    //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
    

Noeuds de cluster de surveillance de routeur dans le déploiement ECMP

Dans une configuration de cluster, sur un nœud propriétaire qui possède une configuration d’adresse SNIP spotted, vous pouvez maintenant désactiver l’option OwnerDownResponse. Par défaut, l’option est activée, permettant au nœud de répondre à une requête ICMP/ARP/ICMP6/ND6 provenant du routeur en amont. Vous pouvez maintenant désactiver cette option pour permettre au routeur de surveiller si un nœud de cluster est actif ou inactif. Lorsque le routeur envoie une demande, si l’option est désactivée, il identifie le nœud propriétaire comme étant inactif et indisponible pour la distribution du trafic.

Pour configurer ECMP pour la distribution du trafic des routes statiques à l’aide de l’interface de ligne de commande

add ns ip <ipddress> <netmask> -ownernode <node-id> —ownerDownResponse désactiver