5.12. Configurez les runners de teamd

Pour configurer le runner de diffusion, à l'aide d'un éditeur, en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
 "device": "team0",
 "runner": {"name": "broadcast"},
 "ports": {"em1": {}, "em2": {}}
}

Veuillez consulter la page manteamd.conf(5) pour plus d'informations.

Le runner dynamique se comporte de la même façon que le runner roundrobin.

Pour configurer le runner dynamique, à l'aide d'un éditeur, en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
 "device": "team0",
 "runner": {"name": "random"},
 "ports": {"em1": {}, "em2": {}}
}

Veuillez consulter la page manteamd.conf(5) pour plus d'informations.

Pour configurer le runner roundrobin, à l'aide d'un éditeur, en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
 "device": "team0",
 "runner": {"name": "roundrobin"},
 "ports": {"em1": {}, "em2": {}}
}

Configuration de base de roundrobin

Veuillez consulter la page manteamd.conf(5) pour plus d'informations.

Le runner activebackup peut utiliser tous les link-watchers afin de déterminer l'état des liens dans un regroupement. L'un des exemples suivants peut être ajouté au fichier de configuration au format JSON du regroupement :

{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool"
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true
      },
      "em2": {
         "prio": 100
      }
   }
}

L'exemple de configuration utilise le runner active-backup avec ethtool comme link watcher. Le port em2 a une plus grande priorité. Le drapeau em1 (sticky) est rendu actif, et le demeurre tant que le lien est actif lui-même.

{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool"
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true,
         "queue_id": 4
      },
      "em2": {
         "prio": 100
      }
   }
}

L'exemple de configuration ajoute un ID de file d'attente correspondant à 4. Il utilise le runner active-backup avec ethtool comme link watcher. Le port em2 a une plus grande priorité. Le drapeau em1 (sticky) est rendu actif, et le demeurre tant que le lien est actif.

Pour configurer le runner activebackup, à l'aide d'ethtool comme link-watcher et y appliquer un délai, en utilisant un éditeur en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool",
      "delay_up": 2500,
      "delay_down": 1000
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true
      },
      "em2": {
         "prio": 100
      }
   }
}

L'exemple de configuration utilise le runner active-backup avec ethtool comme link watcher. Le port em2 a une plus grande priorité. Le drapeau sticky veille à ce que si em1 est rendu actif, il le demeure quand le lien est actif. Les changements de liens ne sont pas propagés par le runner immédiatement, mais des délais s'appliquent.

Veuillez consulter la page manteamd.conf(5) pour plus d'informations.

Ce runner peut être utilisé pour deux types d'équilibrage de charge, en mode actif et passif. En mode actif, un rééquilibrage constant du trafic s'effectue en utilisant des statistiques de trafic récents pour répartir le trafic aussi uniformément que possible. En mode statique, les flux de trafic sont répartis au hasard sur les liens disponibles. Cela favorise la vitesse d'exécution en raison de la réduction de la charge de traitement. C'est dans les applications de trafic de haut volume que c'est souvent apprécié, car le trafic est généralement constitué de plusieurs flux de données distribués au hasard entre les liens disponibles, et de cette manière, le partage des charges s'effectue sans intervention de la part de teamd.

Pour configurer le runner d'équilibrage des charges en transmission passive (Tx), à l'aide d'un éditeur, en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
 "device": "team0",
 "runner": {
   "name": "loadbalance",
   "tx_hash": ["eth", "ipv4", "ipv6"]
 },
 "ports": {"em1": {}, "em2": {}}
}

Configuration de l'équilibrage des charges de transmission passive (Tx) basé hachage.

Pour configurer le runner d'équilibrage des charges en transmission active (Tx), à l'aide d'un éditeur, en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
   "device": "team0",
   "runner": {
     "name": "loadbalance",
     "tx_hash": ["eth", "ipv4", "ipv6"],
     "tx_balancer": {
       "name": "basic"
     }
   },
   "ports": {"em1": {}, "em2": {}}
}

Configuration de l'équilibrage des charges de transmission active (Tx) à l'aide d'un équilibreur des charges de base.

Veuillez consulter la page manteamd.conf(5) pour plus d'informations.

Pour configurer le runner LACP, à l'aide d'ethtool comme link-watcher, en utilisant un éditeur en tant qu'utilisateur root, ajouter ce qui suit dans le fichier de configuration au format JSON du regroupement :

{
   "device": "team0",
   "runner": {
       "name": "lacp",
       "active": true,
       "fast_rate": true,
       "tx_hash": ["eth", "ipv4", "ipv6"]
   },
     "link_watch": {"name": "ethtool"},
     "ports": {"em1": {}, "em2": {}}
}

La configuration de la connexion à un homologue pouvant utiliser le protocole link aggregation control protocol (LACP). Le runner LACP doit utiliser ethtool pour surveiller l'état d'un lien. Il ne sert à rien d'utiliser n'importe quelle autre méthode de surveillance des liens, mise à part ethtool parce que, par exemple, dans le cas de arp_ping, le lien n'apparaissait pas ; la raison étant que le lien doit être tout d'abord établi, et seulement après, les paquets, ARP inclus, peuvent passer. L'utilisation de ethtool empêche cela, car il surveille chaque couche de liens individuellement.

L'équilibrage des charges actif est possible dans ce runner de la même façon qu'il est possible dans le runner d'équilibrage des charges. Pour activer l'équilibrage des charges de transmission active (Tx), ajouter la section suivante :

"tx_balancer": {
       "name": "basic"
}

Veuillez consulter la page manteamd.conf(5) pour plus d'informations.

Les méthodes suivantes de surveillance des états de liens sont disponibles. Pour implémenter une des méthodes, ajouter la chaîne de format JSON au fichier de configuration de format JSON de Team, à l'aide de l'éditeur, en tant qu'utilisateur root.

"link_watch": {
       "name": "ethtool",
       "delay_up": 2500
}

"link_watch": {
       "name": "ethtool",
       "delay_down": 1000
}

{
       "device": "team0",
       "runner": {"name": "activebackup"},
       "link_watch":{
           "name": "arp_ping",
           "interval": 100,
           "missed_max": 30,
           "source_host": "192.168.23.2",
           "target_host": "192.168.23.1"
       },
         "ports": {
             "em1": {
               "prio": -10,
               "sticky": true
             },
             "em2": {
               "prio": 100
             }
         }
}

~]# port config update em2 JSON-config-file

{
  "device": "team0",
    "runner": {"name": "activebackup"},
    "link_watch": {
    "name": "nsna_ping",
    "interval": 200,
    "missed_max": 15,
    "target_host": "fe80::210:18ff:feaa:bbcc"
    },
      "ports": {
        "em1": {
          "prio": -10,
          "sticky": true
        },
        "em2": {
          "prio": 100
        }
      }
}

"link_watch": {
    "name": "nsna_ping",
    "interval": 200
}

"link_watch": {
    "name": "nsna_ping",
    "missed_max": 15
}

"link_watch": {
    "name": "nsna_ping",
    "target_host": "MyStorage"
}

Le port physique qui transmet une image est normalement sélectionné par la partie du noyau du pilote de l'agrégat (team) et n'est pas pertinent à l'utilisateur ou à l'administrateur système. Le port de sortie est sélectionné à l'aide des politiques du mode d'agrégat sélectionné (teamd runner), À l'occasion, toutefois, il est utile de diriger certaines classes de trafic sortant vers certaines interfaces physiques pour appliquer des politiques un peu plus complexes. Par défaut, le pilote team est sensible aux files d'attente multiples et 16 files d'attente sont créées lors de l'initialisation du pilote. Si on souhaite davantage ou moins de files d'attente, l'attribut tx_queues peut être utilisé pour modifier cette valeur lors de la création d'instance de pilote team.

L'ID de file d'attente d'un port peut être défini par l'option de configuration du port queue_id comme suit :

{
  "queue_id": 3
}

Ces ID de files d'attente peuvent être utilisées en conjonction à l'utilitaire tc afin de configurer une discipline de file d'attente pour files multiples, et des filtres destinés à certains trafics devant être transmis à des périphériques de port particuliers. Ainsi, si vous souhaitez utiliser la configuration ci-dessus et que vous souhaitiez forcer tout le trafic lié à 192.168.1.100, pour utiliser eth1 dans l'équipe (team) faisant office de périphérique de sortie, exécutez la commande en tant qu'utilisateur root sous le format suivant :

~]# tc qdisc add dev team0 handle 1 root multiq
~]# tc filter add dev team0 protocol ip parent 1: prio 1 u32 match ip dst \
  192.168.1.100 action skbedit queue_mapping 3

Ce mécanisme de remplacement de logique de runner afin de relier le trafic à un port particulier peut être utilisé avec n'importe quel runner.

L'équilibrage des charges et les runners LACP utilisent les hachages de paquets pour trier les flux de trafic réseau. Le mécanisme de calcul de hachage est basé sur le code Berkeley Packet Filter (BPF). Le code BPF est utilisé pour générer un hachage au lieu de prendre une décision politique au sujet des paquets sortants. La longueur de hachage est de 8 bits, ce qui donne 256 variantes. Cela signifie que différents tampons socket (SKB) peuvent avoir le même hachage et donc faire passer le trafic sur un même lien. L'utilisation d'un hachage court est un moyen rapide de trier le trafic en flux divers à but d'équilibrage des charges sur des liens multiples. En mode statique, le hachage sert uniquement à décider à partir de quel port le trafic doit être envoyé. En mode actif, le runner redéfinira continuellement les hachages de ports différents pour tenter de parvenir à un équilibre parfait.

Les types de chaînes ou de fragments suivants peuvent être utilisés pour le calcul d'un hachage Tx de paquet :

Ces chaînes peuvent être utilisées en ajoutant une ligne au format suivant au runner d'équilibrage des charges : exemple

"tx_hash": ["eth", "ipv4", "ipv6"]

See Section 5.12.5, « Configuration du runner d'équilibrage des charges ».