Chapitre 5. Configuration de Network Teaming

5.1. Qu'est-ce que Network Teamning ?

La combinaison ou le regroupement de liens de réseau dans le but de fournir un lien logique avec un débit plus élevé, ou pour fournir une redondance, est connu sous plusieurs noms : « canal de liaison », « liaison Ethernet », « trunking de port », « regroupement de canaux ou canal teaming », « regroupement de cartes réseau », « agrégation de liens » et ainsi de suite. Ce concept qui avaient été initialement mis en place dans le noyau Linux correspond largement au « Collage ». Le terme regroupement de réseaux a été choisi pour désigner cette nouvelle implémentation du concept. Le pilote de liaison existant n'est pas affecté, le regroupement de réseaux est offert comme solution de rechange et ne remplace pas la liaison dans Red Hat Enterprise Linux 7.
Network Teaming, ou Team, est conçu pour mettre en oeuvre le concept d'une manière unique, en fournissant un petit pilote de noyau pour le traitement rapide des flux de paquets et de diverses applications de l'espace utilisateur pour pouvoir faire tout le reste en espace utilisateur. Le pilote a une Interface de programmation d'application (API), dénommée « Team Netlink API », qui actionne les communications Netlink. Les applications d'espace utilisateur peuvent utiliser cette API pour communiquer avec le pilote. Une bibliothèque, nommée « lib », est fournie pour regrouper les communications Team Netlink et les messages RT Netlink dans l'espace utilisateur. Un démon d'application, teamd, qui utilise Libteam lib est également fourni. Une seule instance de teamd peut contrôler une instance du pilote de Team. Le démon implémente la logique d'active-backup et l'équilibrage de la charge, comme round-robin, à l'aide de code supplémentaire « runners ». En séparant le code de cette manière, la mise en place de Network Teaming présente une solution facilement extensible et évolutive pour l'équilibrage des charge et les besoins de redondance. Par exemple, des runners personnalisés peuvent être écrits assez facilement pour mettre en œuvre la nouvelle logique via teamd, et même quand teamd est en option, les utilisateurs peuvent écrire leur propre application pour utiliser libteam.
Un outil qui sert à contrôler une instance d'exécution de teamd en utilisant D-bus est fourni par teamdctl. Il fournit un wrapper de D-Bus autour de l'API D-Bus teamd. Par défaut, teamd écoute et communique à l'aide de sockets de domaine Unix mais continue de surveiller le D-Bus. Il s'agit de veiller à ce que teamd puisse être utilisé dans des environnements où le D-Bus n'est pas présent ou n'a pas encore été chargé. Par exemple, lors de l'amorçage sur des liaisons teamd, D-Bus n'est pas encore téléchargé. L'outil teamdctl peut être utilisé pendant le temps d'exécution pour lire la configuration, l'état de link-watchers, pour extraire et modifier l'état des ports, pour ajouter et supprimer des ports, et pour changer des ports d'actifs en état de sauvegarde.
Team API Netlink communique avec les applications d'espace utilisateur à l'aide de messages Netlink. La bibliothèque d'espace-utilisateur libteam n'interagit pas directement avec l'API, mais utilise libnl ou teamnl pour interagir avec l'API du pilote.
Pour résumer, les instances du pilote de Team, en cours d'exécution dans le noyau, ne peuvent pas être configurées ou contrôlées directement. Toute la configuration se fait à l'aide des applications spatiales utilisateur, comme l'application teamd. L'application redirige ensuite la partie pilote du noyau en suivant par la suite.