Exemple de configuration de Nexus 7000 Intelligent Traffic Director

Options de téléchargement

  • PDF     (185.9 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (117.7 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (114.1 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:4 mai 2015
ID du document:118950

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document décrit les étapes de base pour dépanner et vérifier Intelligent Traffic Director (ITD) sur le Nexus 7000. Ce document utilise un déploiement d'équilibrage de charge de serveur afin d'illustrer les concepts liés à ITD.

Pour plus d'informations sur la DTI, reportez-vous aux ressources suivantes :

Conditions préalables

Conditions requises

Cisco vous recommande d'avoir des connaissances en ITD.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Commutateur de la gamme Cisco Nexus 7000
  • Cisco NX-OS version 6.2(10)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

ITD est utilisé pour équilibrer la charge du trafic qui entre dans une interface de couche 3 spécifique entre un certain nombre de périphériques configurés en tant que noeuds ITD.

  • ITD est pris en charge sur le Nexus 7000 dans NX-OS version 6.2(8) et ultérieure et possède de nouvelles fonctionnalités significatives dans la version 6.2(10).
  • La technologie ITD peut être mise en oeuvre indépendamment des composants matériels (types de cartes de ligne, type de châssis, etc.).
  • ITD n'ajoute aucune charge au processeur du module de supervision.

Flux de trafic avec ITD

Les informations de ce document sont basées sur cette topologie. Dans ce scénario, l'effet souhaité est que le trafic provenant des hôtes du VLAN 10 adressés aux serveurs Web du VLAN 40 soit équilibré en charge entre le serveur 100 et le serveur 101.

  • ITD utilise le routage basé sur des stratégies afin de mettre en oeuvre l'équilibrage de charge dans le matériel sur le Nexus 7000. Lorsque ITD est configuré, des listes d'accès et un mappage de route sont créés dynamiquement afin de transférer le trafic en fonction de votre politique d'équilibrage de charge définie dans ITD.
  • Ces listes d'accès sont créées et appliquées à l'interface d'entrée configurée dans la configuration ITD. Dans ce cas, le trafic qui entre sur le VLAN 20 atteint « bucket_1 » ou « bucket_2 » en fonction du bit significatif du dernier octet défini par le masque de liste d'accès :
    N7k-2(config)# show ip access-lists

    IP access list TEST_itd_vip_1_bucket_1
            10 permit ip 1.1.1.0 255.255.255.127 192.168.30.1/32
    IP access list TEST_itd_vip_1_bucket_2
            10 permit ip 1.1.1.128 255.255.255.127 192.168.30.1/32
  • Le mappage de route transfère ensuite le trafic en fonction de la clause à laquelle le trafic entrant correspond. Cet exemple montre que le trafic qui atteint « bucket_1 » est transféré au noeud 192.168.40.100 et que le trafic qui atteint « bucket_2 » est transféré au noeud 192.168.40.101.
    N7k-1(config)# show route-map TEST_itd_pool
    route-map TEST_itd_pool, permit, sequence 0
    Description: auto generated route-map for ITD service TEST
      Match clauses:
        ip address (access-lists): TEST_itd_vip_1_bucket_1
      Set clauses:
        ip next-hop verify-availability 192.168.40.100 track 2 [ UP ]
    route-map TEST_itd_pool, permit, sequence 1
    Description: auto generated route-map for ITD service TEST
      Match clauses:
        ip address (access-lists): TEST_itd_vip_1_bucket_2
      Set clauses:
        ip next-hop verify-availability 192.168.40.101 track 2 [ UP ]
  • L'adresse IP n'est pas traduite par ITD. Le trafic qui sort du Nexus 7000 vers les noeuds a une adresse de destination 192.168.30.1 et conserve l'adresse IP source d'origine.
  • Le trafic de retour est en monodiffusion vers l'expéditeur d'origine avec une adresse source du VIP ITD 192.168.30.1.

Astuce : Une seule instance de routage basé sur des stratégies (PBR) est prise en charge par famille d'adresses par interface d'entrée. Si vous définissez une interface en tant qu'interface d'entrée ITD, vous ne pourrez pas configurer d'instances PBR supplémentaires sur cette interface, car ITD utilise PBR pour implémenter l'algorithme d'équilibrage de charge.

Configuration

Ces fonctions doivent être activées dans le VDC (Virtual Device Context) dans lequel vous configurez ITD :

N7k-1(config-itd)# show run | i feature
feature pbr
feature sla sender
feature sla responder
feature itd

Étape 1 : Configurer le groupe de périphériques ITD

Le groupe de périphériques ITD se compose des noeuds entre lesquels le trafic sera équilibré en charge, tels que les serveurs Web, les pare-feu, etc. Le groupe de périphériques est configuré comme suit :

N7k-1(config)# itd device-group TAC-device-group
N7k-1(config-device-group)# node ip 192.168.40.100
N7k-1(config-device-group)# node ip 192.168.40.101
N7k-1(config-device-group)# probe icmp

Configuration de la sonde

La configuration de la sonde vous permet de définir ces types de sonde :

icmp Envoie une requête d'écho ICMP (Internet Control Message Protocol) et écoute une réponse. Si le serveur renvoie une réponse, ITD marque le serveur comme transmis. 
dns Envoie une requête à un serveur de noms de domaine (DNS) qui transmet un domaine configuré au serveur. Si le serveur répond avec une adresse IP configurée pour ce domaine, ITD marque l'adresse comme up. 
udp Envoie un paquet UDP à un serveur et marque le serveur comme ayant échoué uniquement si le serveur renvoie un message ICMP Port Unreachable.
tcp Lance une connexion TCP en trois étapes et attend du serveur qu’il envoie une réponse. Si la connexion est réussie, ITD envoie un FIN afin de mettre fin à la session. Si la réponse n'est pas valide ou s'il n'y a pas de réponse, ITD marque le serveur comme ayant échoué. 

Généralement, les sondes DNS, UDP et TCP sont utilisées pour évaluer la disponibilité de services spécifiques qui s'exécutent sur les serveurs de noeud.

La configuration de la sonde vous permet également de définir ces paramètres :

  • Fréquence : ITD envoie des requêtes ping au noeud toutes les x secondes
  • Délai d'attente - ITD attend une réponse du noeud dans les y secondes.
  • retry-down-count : nombre de fois où sonder le noeud avant qu'il ne soit marqué comme « Échec de la sonde » et que l'échec soit exécuté
  • retry-up-count : combien de fois sonder le noeud avant qu'il ne soit marqué comme OK et réajouté au pool ?

Par exemple, considérez cette configuration (il s'agit de la configuration par défaut lorsque vous configurez probe icmp) :

  1. Envoyez une requête ping au noeud toutes les 10 secondes.
  2. Attendez 5 secondes que le noeud réponde.
  3. Une fois que le noeud n'a pas répondu 3 fois, marquez le noeud comme « Échec de la recherche ».
  4. Après avoir répondu 3 fois dans une ligne, marquez le noeud comme OK.

Dans cette configuration, ITD réagit à un noeud qui devient inaccessible après au moins 35 secondes (fréquence 3 x + délai d'attente).

Niveau de noeud en veille

Un noeud peut être configuré en veille au niveau du noeud ou du groupe de périphériques. Une veille de niveau noeud reçoit le trafic uniquement si son noeud actif associé échoue. Une veille de niveau groupe de périphériques reçoit le trafic en cas de défaillance de l'un des noeuds actifs. 

La configuration de secours au niveau du périphérique est la suivante :

7k-1(config-device-group)# node ip 192.168.40.100 standby 192.168.40.103

La configuration de secours du groupe de périphériques est la suivante :

7k-1(config-device-group)# node ip 192.168.40.106 mode hot-standby

Étape 2 : Configurer le service ITD

Dans cette étape, le service ITD est défini, c'est-à-dire le trafic que vous voulez équilibrer la charge et comment.

Configurer le service ITD

N7k-1(config)# itd TAC-ITD-service

Définir le groupe de périphériques

Référez-vous au groupe de périphériques précédemment configuré :

N7k-1(config-itd)# device-group TAC-device-group

Configurer l'interface d'entrée

Le trafic entrant sur cette interface est équilibré en charge par ITD. L'interface d'entrée doit être une interface de couche 3 (interface physique, portchannel ou interface virtuelle commutée (SVI)).

N7k-1(config-itd)# ingress interface vlan 20

Chaque interface de couche 3 ne peut être affectée qu'en tant qu'interface d'entrée pour une instance d'ITD.

Attention : L'interface d'entrée ITD doit être une interface de couche 3.

Configuration de l'adresse IP virtuelle ITD

L'adresse IP virtuelle (VIP) ITD doit se trouver dans un sous-réseau différent des hôtes et des noeuds :

N7k-1(config-itd)# virtual ip 192.168.30.1 255.255.255.255 advertise enable

Le VIP ITD est essentiellement une interface fictive du point de vue du Nexus 7000. Par exemple, le commutateur ne répond pas aux requêtes ping adressées au VIP. Il est utilisé pour faire correspondre le trafic avec le mappage de route qui est automatiquement créé et appliqué à l'interface d'entrée ITD.

Astuce : Vous ne pourrez pas envoyer de requête ping au VIP ITD tant que les noeuds finaux ne seront pas configurés avec l'adresse VIP.

Définir la méthode ITD Load-Balance

load-balance method src ip buckets 2

La méthode d'équilibrage de charge vous permet de définir votre mécanisme de hachage d'équilibrage de charge. Ces options sont disponibles :

src ip Adresse IP source
src ip-l4port Port IP source et port L4
dst ip Adresse IP de destination
dst ip-l4port Port IP et L4 de destination

Astuce : Le service ITD doit être à l'état d'arrêt afin de modifier le service ITD ou la configuration de groupe de périphériques.

Étape 3 : Définir le comportement de basculement

Vous devez configurer un comportement de basculement, sinon ITD ne réagira pas à une panne de noeud :

N7k-1(config-itd)# failaction node reassign

Afin d'afficher la configuration associée à ITD, entrez la commande show run services :

N7k-2# show run services

!Command: show running-config services
!Time: Wed Apr 22 00:15:11 2015

version 6.2(10)
feature itd


itd device-group TAC
 node ip 192.168.40.100
 node ip 192.168.40.101
 probe icmp frequency 10 timeout 5 retry-down-count 1 retry-up-count 1


itd TEST
 device-group TAC
 virtual ip 192.168.30.1 255.255.255.255 advertise enable
 ingress interface Vlan20
 failaction node reassign
 load-balance method src ip buckets 2
 no shut

Étape 4 : Configurer le VIP ITD en tant qu'interface de bouclage sur les serveurs de noeud

Pour que les serveurs servent le trafic adressé au VIP ITD, ils doivent être configurés en tant qu'alias IP sur l'interface de bouclage du serveur. Le serveur accepte les requêtes pour l'adresse de destination VIP et obtient la réponse à partir de l'adresse VIP ITD.

Configuration de l'interface réseau virtuelle sous Linux 

Comment installer la carte de bouclage Microsoft sous Windows 

Note: La configuration IDT VIP sur le serveur n'est requise que dans le cas d'un retour direct de serveur (DSR). Dans le cas de l'équilibrage de charge de l'appareil (tel que l'équilibrage de charge de l'appareil de sécurité adaptatif Cisco (ASA)), la configuration VIP n'est pas requise.

Autres options de configuration

Affecter des poids aux noeuds

La méthode d'équilibrage de charge vous permet également de définir le nombre de compartiments dans lesquels le trafic doit être fractionné. La configuration du groupement est facultative. Par défaut, le nombre de compartiments est égal au nombre de noeuds configurés. Si vous voulez configurer le nombre de compartiments, la valeur doit être égale à 2 (2, 4, 8, 16, 32, etc.). La configuration est la suivante :

N7k-2(config-itd)# load-balance method src ip buckets 16

Par défaut, les segments sont attribués aux noeuds actifs dans un modèle de robinet rond. Cependant, vous pouvez pondérer certains noeuds avec plus de compartiments, ce qui en fait pondère le trafic pour favoriser un ou plusieurs périphériques. Vous attribuez un poids sous la configuration du groupe de périphériques. Dans cette configuration, le serveur 101 reçoit deux fois plus de trafic que le serveur 100.

N7k-1(config)# itd device-group TAC-device-group
N7k-1(config-device-group)# node ip 192.168.40.100 weight 33
N7k-1(config-device-group)# node ip 192.168.40.101 weight 66
N7k-1(config-device-group)# probe icmp

Vous pouvez vérifier les affectations de groupement avec la sortie de la commande show itd :

N7k-2(config-itd)# show itd

Name           Probe LB Scheme  Status   Buckets
-------------- ----- ---------- -------- -------
TEST           TCP   src-ip     ACTIVE   16

Device Group                                         VRF-Name
-------------------------------------------------- -------------
TAC

Pool                           Interface    Status Track_id
------------------------------ ------------ ------ ---------
TEST_itd_pool                  Vlan20       UP       3

Virtual IP                              Netmask/Prefix Protocol     Port
------------------------------------------------------ ------------ ----------
192.168.20.1 / 255.255.255.255                         IP           0

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  1     192.168.40.100      Active       33     OK           1         10001

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_1
        TEST_itd_vip_1_bucket_3
        TEST_itd_vip_1_bucket_5
        TEST_itd_vip_1_bucket_7
        TEST_itd_vip_1_bucket_9
        TEST_itd_vip_1_bucket_16

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  2     192.168.40.101      Active       66     OK           2         10002

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_2
        TEST_itd_vip_1_bucket_4
        TEST_itd_vip_1_bucket_6
        TEST_itd_vip_1_bucket_8
        TEST_itd_vip_1_bucket_10
        TEST_itd_vip_1_bucket_11
        TEST_itd_vip_1_bucket_12
        TEST_itd_vip_1_bucket_13
        TEST_itd_vip_1_bucket_14
        TEST_itd_vip_1_bucket_15

Configuration de l'échec

Lorsqu'un noeud tombe en panne, la sonde le détecte et le place dans l'état « Sonde échouée ». Par défaut, ITD continue à transférer le trafic vers le noeud défaillant. Pour qu'ITD détourne le trafic d'un noeud défaillant, vous devez configurer ceci :

itd TEST
 failaction node reassign

Que se passe-t-il lorsqu’un noeud devient inaccessible :

  • Si la réaffectation du noeud de panne est configurée - ITD place le noeud inaccessible en mode Échec de la recherche et achemine le trafic vers d'autres noeuds du groupe de périphériques.
  • Si la réaffectation du noeud d'échec n'est PAS configurée :

    Scénario 1 : Noeud de sonde configuré/veille configuré : trafic dirigé vers le premier noeud de secours disponible.

    Scénario 2 : Sonde configurée, aucun noeud de secours configuré : trafic non réaffecté, est routé.

    Scénario 3 : Aucune sonde configurée : ITD ne peut pas détecter la défaillance, le trafic continue d'être transféré à un noeud non disponible.

  • Si tous les noeuds sont inaccessibles, le trafic est routé.

Vérification

Cette section décrit comment vérifier la configuration et le fonctionnement de base de l'ITD.

Vérifier les services ITD

Afin d'afficher l'état de l'ITD, entrez la commande show itd.

  • Vérifiez que le service est dans l'état ACTIVE.
  • Vérifiez que le pool de périphériques est à l'état UP.
  • Vérifiez que les noeuds sont dans l'état OK.
N7k-2(config-itd)# show itd

Name           Probe LB Scheme  Status   Buckets
-------------- ----- ---------- -------- -------
TEST           TCP   src-ip     ACTIVE   16

Device Group                                         VRF-Name
-------------------------------------------------- -------------
TAC

Pool                           Interface    Status Track_id
------------------------------ ------------ ------ ---------
TEST_itd_pool                  Vlan20       UP       3

Virtual IP                              Netmask/Prefix Protocol     Port
------------------------------------------------------ ------------ ----------
192.168.20.1 / 255.255.255.255                         IP           0

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  1     192.168.40.100      Active       33     OK           1         10001

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_1
        TEST_itd_vip_1_bucket_3
        TEST_itd_vip_1_bucket_5
        TEST_itd_vip_1_bucket_7
        TEST_itd_vip_1_bucket_9
        TEST_itd_vip_1_bucket_16

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  2     192.168.40.101      Active       66     OK           2         10002

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_2
        TEST_itd_vip_1_bucket_4
        TEST_itd_vip_1_bucket_6
        TEST_itd_vip_1_bucket_8
        TEST_itd_vip_1_bucket_10
        TEST_itd_vip_1_bucket_11
        TEST_itd_vip_1_bucket_12
        TEST_itd_vip_1_bucket_13
        TEST_itd_vip_1_bucket_14
        TEST_itd_vip_1_bucket_15

Vérifier les listes d'accès et le mappage de route créés dynamiquement

Cette configuration est créée dynamiquement lorsque vous configurez ITD :

  • Il y aura une entrée de liste d'accès et de carte de routage par compartiment configuré.
  • Les mappages de route et les listes d'accès sont créés avec le nom de service ITD préfixé (tel que, <nom du service>_itd_vip_1_bucket_1).
N7k-2(config)# show ip access-lists

IP access list TEST_itd_vip_1_bucket_1
        10 permit ip 1.1.1.0 255.255.255.127 192.168.20.1/32
IP access list TEST_itd_vip_1_bucket_2
        10 permit ip 1.1.1.128 255.255.255.127 192.168.20.1/32

N7k-2(config)# sho route-map TEST_itd_pool
route-map TEST_itd_pool, permit, sequence 0
Description: auto generated route-map for ITD service TEST
  Match clauses:
    ip address (access-lists): TEST_itd_vip_1_bucket_1
  Set clauses:
    ip next-hop verify-availability 192.168.30.2 track 2 [ UP ]
route-map TEST_itd_pool, permit, sequence 1
Description: auto generated route-map for ITD service TEST
  Match clauses:
    ip address (access-lists): TEST_itd_vip_1_bucket_2
  Set clauses:
    ip next-hop verify-availability 192.168.30.2 track 2 [ UP ]

Vérification de la configuration de l'interface d'entrée

Vérifiez que le mappage de route est appliqué à l'interface d'entrée ITD :

N7k-2(config-itd)# show run int vlan 20
!Command: show running-config interface Vlan20
!Time: Thu Apr 23 00:42:41 2015
version 6.2(10)
interface Vlan20no shutdown
ip address 192.168.20.1/24
ip policy route-map TEST_itd_pool

Vérifier la configuration des sondes

Vérifiez que la fréquence de la sonde est programmée dans ce résultat à partir de cette commande :

N7k-2# show run | i probe
 probe icmp frequency 5

N7k-2# show run sla sender

!Command: show running-config sla sender
!Time: Tue Apr 28 18:04:02 2015

version 6.2(10)
feature sla sender

ip sla 10001
  icmp-echo 192.168.40.100
    frequency 5
ip sla schedule 10001 life forever start-time now
ip sla 10002
  icmp-echo 192.168.40.101
    frequency 5
ip sla schedule 10002 life forever start-time now

Les objets IPSLA (Internet Protocol Service Level Agreement) sont créés dynamiquement lorsque ITD est configuré. Ces objets sont référencés dans le mappage de route ITD.

Dépannage

Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
04-May-2015
Première publication
TAC Authored

Contribution d’experts de Cisco

  • Dez Hill
    Cisco TAC Engineer.

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco