Comment configurer le basculement et la haute disponibilité du regroupement réseau sur Linux

Ce tutoriel explique comment configurer le regroupement réseau sur un serveur Linux. Avant de commencer, laissez-moi expliquer ce qu’est le regroupement réseau et ce qu’il fait. Dans un environnement Windows, le regroupement réseau est appelé regroupement de réseau, c’est une fonctionnalité qui aide toute architecture de serveur à fournir une haute disponibilité et un basculement dans des scénarios où l’un des principaux câbles Ethernet a un dysfonctionnement ou est mal configuré.

Normalement, c’est une bonne pratique et une fonctionnalité indispensable à mettre en œuvre lorsque vous configurez un serveur à des fins de production. Bien que cette fonctionnalité puisse être réalisée dans une configuration d’environnement Linux, vous devez d’abord confirmer avec votre administrateur réseau pour vous assurer que les commutateurs liés à votre serveur prennent en charge le regroupement réseau. Il existe plusieurs modes de regroupement qui peuvent être mis en œuvre dans votre environnement serveur. Voici une liste des modes disponibles et ce qu’ils font :

• Balance-rr
  Ce mode fournit des fonctionnalités de répartition de charge et de tolérance aux pannes (basculement) via une politique de round-robin. Cela signifie qu’il transmet des paquets dans l’ordre séquentiel du premier esclave disponible au dernier.
• Active-Backup
  Ce mode fournit des fonctionnalités de tolérance aux pannes via une politique active-sauvegarde. Cela signifie qu’une fois que l’Ethernet de regroupement est actif, un seul des esclaves Ethernet est actif. L’autre esclave Ethernet ne deviendra actif que si l’esclave actif actuel échoue. Si vous choisissez ce mode, vous remarquerez que l’adresse MAC de regroupement est visible de l’extérieur sur un seul adaptateur réseau. Cela permet d’éviter de confondre le commutateur.
• Balance-xor
  Ce mode fournit une répartition de charge et une tolérance aux pannes. Il transmet en fonction de la politique de hachage de transmission sélectionnée. Des politiques de transmission alternatives peuvent être sélectionnées via l’option xmit_hash_policy.
• Broadcast
  Ce mode fournit uniquement une tolérance aux pannes. Il transmet tout sur toutes les interfaces Ethernet esclaves.
• 802.3ad
  Ce mode fournit une répartition de charge et une tolérance aux pannes. Il crée un groupe d’agrégation qui partage les mêmes paramètres de vitesse et de duplex. Il utilise toutes les interfaces Ethernet esclaves dans l’agrégateur actif, il est basé sur la spécification 802.3ad. Pour mettre en œuvre ce mode, l’outil ethtool doit prendre en charge les pilotes de base pour récupérer la vitesse et le mode duplex de chaque esclave. Le commutateur doit également prendre en charge l’agrégation de lien dynamique. Normalement, cela nécessite l’intervention d’un ingénieur réseau pour une configuration détaillée.
• Balance-TLB
  Ce mode fournit des capacités de répartition de charge comme le nom TLB représente répartition de charge de transmission. Pour ce mode, si la configuration tlb_dynamic_lb = 1, alors le trafic sortant est distribué en fonction de la charge actuelle sur chaque esclave. Si la configuration tlb_dynamic_lb = 0, alors la répartition de charge est désactivée, mais la charge est distribuée uniquement en utilisant la distribution de hachage. Pour ce mode, l’outil ethtool doit prendre en charge les pilotes de base pour récupérer la vitesse de chaque esclave.
• Balance-ALB
  Ce mode fournit des capacités de répartition de charge comme le nom TLB représente répartition de charge adaptative. Semblable à balance-tlb, sauf que le trafic d’envoi et de réception est regroupé. Il reçoit une répartition de charge en réalisant une négociation ARP. Le pilote de regroupement intercepte les réponses ARP envoyées par le système local sur leur chemin et écrase l’adresse matérielle source avec l’adresse matérielle unique de l’un des esclaves dans le regroupement. Pour ce mode, l’outil ethtool doit prendre en charge les pilotes de base pour récupérer la vitesse de chaque esclave.

1. Remarque préliminaire

Pour ce tutoriel, j’utilise Oracle Linux 6.4 dans la version 32 bits. Veuillez noter que même si la configuration est effectuée sous Oracle Linux, les étapes sont également applicables aux distributions CentOS et Red Hat et aux systèmes 64 bits également. Le résultat final de notre configuration d’exemple montrera que la connexion établie avec notre serveur de regroupement restera connectée même si j’ai désactivé l’un des réseaux Ethernet. Dans cet exemple, je vais montrer comment appliquer le regroupement réseau en utilisant le mode 1 qui est la politique active-sauvegarde.

2. Phase d’installation

Pour ce processus, aucune installation n’est nécessaire. Une installation Linux par défaut d’un serveur inclut tous les packages requis pour une configuration de regroupement réseau.

3. Phase de configuration

Avant de commencer la configuration, nous devons d’abord nous assurer que nous avons au moins 2 interfaces Ethernet configurées dans notre serveur. Pour vérifier cela, allez dans le dossier de configuration réseau et listez les interfaces Ethernet disponibles. Voici les étapes :

cd /etc/sysconfig/network-scripts/  
ls *ifcfg*eth*

Le résultat est :

ifcfg-eth0 ifcfg-eth1 

Remarquez que nous avons actuellement 2 interfaces Ethernet configurées dans notre serveur qui sont ETH0 et ETH1.

Maintenant, configurons une interface de regroupement appelée BOND0. Cette interface sera une interface Ethernet virtuelle qui contient les interfaces Ethernet physiques de ETH0 et ETH1. Voici les étapes :

vi ifcfg-bond0

DEVICE=bond0  
ONBOOT=yes  
MASTER=yes  
IPADDR=172.20.43.110  
NETMASK=255.255.255.0  
GATEWAY=172.20.43.1  
BONDING_OPTS="mode=1 miimon=100"  
TYPE=Ethernet 

Puis exécutez :

ls *ifcfg*bon*

Le résultat est :

ifcfg-bond0 

C’est tout. Veuillez noter qu’à l’intérieur de l’interface BOND0, j’ai inclus une adresse IP. Cette adresse IP sera la seule adresse IP connectée à notre serveur. Pour poursuivre le processus, nous devons modifier l’interface Ethernet physique liée à l’interface BOND0. Voici les étapes :

vi ifcfg-eth0

DEVICE=eth0  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 

vi ifcfg-eth1

DEVICE=eth1  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 

Fait. Nous avons modifié les interfaces ETH0 et ETH1. Remarquez que nous avons supprimé l’adresse IP à l’intérieur des deux interfaces et ajouté MASTER = bond0. Cela est nécessaire pour valider que les deux interfaces seront des interfaces virtuelles qui sont dédiées à l’interface Ethernet BOND0.

Pour poursuivre la configuration. Créons un fichier de configuration de regroupement nommé bonding.conf sous /etc/modprobe.d. Voici les étapes :

vi /etc/modprobe.d/bonding.conf

alias bond0 bonding  
options bond0 mode=1 miimon=100 

modprobe bonding 

Sur la base de la configuration ci-dessus, nous avons configuré un module de regroupement en utilisant l’interface BOND0. Nous avons également assigné la configuration de regroupement pour utiliser le mode = 1 qui est la politique active-sauvegarde. L’option miimon = 100 représente la fréquence de surveillance pour notre serveur de regroupement afin de surveiller l’état de l’interface en millisecondes. Comme décrit ci-dessus, ce mode fournira des fonctionnalités de tolérance aux pannes dans la configuration réseau du serveur.

Comme tout est configuré, redémarrons le service réseau afin de charger la nouvelle configuration. Voici les étapes :

service network restart

Arrêt de l'interface eth0 : [ OK ]  
Arrêt de l'interface eth1 : [ OK ]  
Arrêt de l'interface de bouclage : [ OK ]  
Activation de l'interface de bouclage : [ OK ]  
Activation de l'interface bond0 : [ OK ] 

Excellent, maintenant nous avons chargé la nouvelle configuration que nous avons faite ci-dessus. Vous remarquerez que la nouvelle interface appelée BOND0 sera affichée dans la liste réseau. Vous remarquerez également qu’aucune adresse IP n’est assignée aux interfaces ETH0 et ETH1, seule l’interface BOND0 affiche l’IP.

ifconfig

bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
internet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0  
internet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link  
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1  
RX packets:1723 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:147913 (144.4 KiB) TX bytes:108429 (105.8 KiB) 

eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB) 

eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:632 errors:0 dropped:0 overruns:0 frame:0  
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 KiB) 

lo Link encap:Local Loopback  
internet addr:127.0.0.1 Mask:255.0.0.0  
internet6 addr: ::1/128 Scope:Host  
UP LOOPBACK RUNNING MTU:16436 Metric:1  
RX packets:208 errors:0 dropped:0 overruns:0 frame:0  
TX packets:208 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB) 

Vous pouvez également vérifier l’état du regroupement via cette commande :

cat /proc/net/bonding/bond0

Driver de regroupement de canal Ethernet : v3.6.0 (26 septembre 2009) 

Mode de regroupement : tolérance aux pannes (active-sauvegarde)  
Esclave principal : Aucun  
Esclave actuellement actif : eth0  
État MII : actif  
Intervalle de sondage MII (ms) : 100  
Délai de montée (ms) : 0  
Délai de descente (ms) : 0 

Interface esclave : eth0  
État MII : actif  
Vitesse : 1000 Mbps  
Duplex : complet  
Nombre d'échecs de lien : 0  
Adresse HW permanente : 08:00:27:61:e4:88  
ID de file d'attente esclave : 0 

Interface esclave : eth1  
État MII : actif  
Vitesse : 1000 Mbps  
Duplex : complet  
Nombre d'échecs de lien : 0  
Adresse HW permanente : 08:00:27:c8:46:40  
ID de file d'attente esclave : 0 

Remarquez ci-dessus que nous avons réussi à convertir les interfaces ETH0 et ETH1 en une configuration de regroupement utilisant le mode actif-sauvegarde. Il est également indiqué maintenant que le serveur utilise l’interface ETH0, ETH1 sera comme interface de sauvegarde.

4. Phase de test

Maintenant que tout est configuré comme prévu. Faisons un test simple pour nous assurer que la configuration que nous avons faite est correcte. Pour ce test, nous allons nous connecter à un nouveau serveur (ou bureau Linux) et commencer à pinger notre serveur de regroupement pour voir s’il y a une connexion intermittente pendant le test. Voici les étapes :

login as: root  
[email protected]'s password:  
Dernière connexion : Mer Sep 14 12:50:15 2016 depuis 172.20.43.80

ping 172.20.43.110

PING 172.20.43.110 (172.20.43.110) 56(84) octets de données.  
64 octets de 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms  
64 octets de 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms  
64 octets de 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms  
64 octets de 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms  
64 octets de 172.20.43.110: icmp_seq=5 ttl=64 time=0.554 ms  
64 octets de 172.20.43.110: icmp_seq=6 ttl=64 time=0.443 ms  
64 octets de 172.20.43.110: icmp_seq=7 ttl=64 time=0.663 ms  
64 octets de 172.20.43.110: icmp_seq=8 ttl=64 time=0.961 ms  
64 octets de 172.20.43.110: icmp_seq=9 ttl=64 time=0.461 ms  
64 octets de 172.20.43.110: icmp_seq=10 ttl=64 time=0.544 ms  
64 octets de 172.20.43.110: icmp_seq=11 ttl=64 time=0.412 ms  
64 octets de 172.20.43.110: icmp_seq=12 ttl=64 time=0.464 ms  
64 octets de 172.20.43.110: icmp_seq=13 ttl=64 time=0.432 ms 

Pendant ce temps, retournons à notre serveur de regroupement et désactivons l’interface Ethernet ETH0. Voici les étapes :

ifconfig eth0

eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB) 

ifdown eth0 

Maintenant, nous avons désactivé les services pour l’interface réseau ETH0. Vérifions l’état du regroupement. Voici les étapes :

cat /proc/net/bonding/bond0

Driver de regroupement de canal Ethernet : v3.6.0 (26 septembre 2009) 

Mode de regroupement : tolérance aux pannes (active-sauvegarde)  
Esclave principal : Aucun  
Esclave actuellement actif : eth1  
État MII : actif  
Intervalle de sondage MII (ms) : 100  
Délai de montée (ms) : 0  
Délai de descente (ms) : 0 

Interface esclave : eth1  
État MII : actif  
Vitesse : 1000 Mbps  
Duplex : complet  
Nombre d'échecs de lien : 0  
Adresse HW permanente : 08:00:27:c8:46:40  
ID de file d'attente esclave : 0 

Vous remarquerez que maintenant l’interface ETH0 n’existe plus dans l’état de regroupement. Pendant ce temps, retournons au serveur de test précédent et vérifions le ping continu vers notre serveur de regroupement.

64 octets de 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms  
64 octets de 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms  
64 octets de 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms  
64 octets de 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms  
64 octets de 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms  
64 octets de 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms  
64 octets de 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms  
64 octets de 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms  
64 octets de 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms  
64 octets de 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms  
64 octets de 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms  
64 octets de 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms  
64 octets de 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms 

Super, maintenant vous verrez que même si nous avons éteint l’interface ETH0, nous sommes toujours capables de pinger et d’accéder à notre serveur de regroupement. Maintenant, faisons un test de plus. Rallumons l’interface ETH0 et éteignons l’interface ETH1.

ifup eth0  
cat /proc/net/bonding/bond0

Driver de regroupement de canal Ethernet : v3.6.0 (26 septembre 2009) 

Mode de regroupement : tolérance aux pannes (active-sauvegarde)  
Esclave principal : Aucun  
Esclave actuellement actif : eth1  
État MII : actif  
Intervalle de sondage MII (ms) : 100  
Délai de montée (ms) : 0  
Délai de descente (ms) : 0 

Interface esclave : eth1  
État MII : actif  
Vitesse : 1000 Mbps  
Duplex : complet  
Nombre d'échecs de lien : 0  
Adresse HW permanente : 08:00:27:c8:46:40  
ID de file d'attente esclave : 0 

Interface esclave : eth0  
État MII : actif  
Vitesse : 1000 Mbps  
Duplex : complet  
Nombre d'échecs de lien : 0  
Adresse HW permanente : 08:00:27:61:e4:88  
ID de file d'attente esclave : 0 

Comme l’interface ETH0 était déjà active, désactivons l’interface ETH1.

ifdown eth1

cat /proc/net/bonding/bond0

Driver de regroupement de canal Ethernet : v3.6.0 (26 septembre 2009) 

Mode de regroupement : tolérance aux pannes (active-sauvegarde)  
Esclave principal : Aucun  
Esclave actuellement actif : eth0  
État MII : actif  
Intervalle de sondage MII (ms) : 100  
Délai de montée (ms) : 0  
Délai de descente (ms) : 0 

Interface esclave : eth0  
État MII : actif  
Vitesse : 1000 Mbps  
Duplex : complet  
Nombre d'échecs de lien : 0  
Adresse HW permanente : 08:00:27:61:e4:88  
ID de file d'attente esclave : 0 

Maintenant, retournons au serveur de test et vérifions ce qui se passe avec le ping continu effectué vers notre serveur de regroupement.

64 octets de 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms  
64 octets de 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms  
64 octets de 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms  
64 octets de 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms  
64 octets de 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms  
64 octets de 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms  
64 octets de 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms  
64 octets de 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms  
64 octets de 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms  
64 octets de 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms  
64 octets de 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms  

Bravo ! Nous avons réussi à configurer et prouver que notre serveur de regroupement parvient à gérer le scénario de récupération après sinistre en cas de condition de basculement réseau.