Agrégation de liens FreeBSD pas plus rapide qu'un lien unique

Nous avons mis une carte réseau Intel I340-T4 à 4 ports dans un serveur FreeBSD 9.3 ¹ et l' avons configuré pour l' agrégation de liens en mode LACP afin de réduire le temps nécessaire pour mettre en miroir 8 à 16 To de données d'un serveur de fichiers maître à 2. 4 clones en parallèle. Nous nous attendions à obtenir jusqu'à 4 Gbit / s de bande passante agrégée, mais peu importe ce que nous avons essayé, il ne sort jamais plus vite que 1 Gbit / s agrégé. ²

Nous utilisons iperf3pour tester cela sur un LAN tranquille. ³ La première instance atteint presque un gigabit, comme prévu, mais lorsque nous en démarrons une seconde en parallèle, les deux clients chutent à environ ½ Gbit / sec. L'ajout d'un troisième client fait chuter les vitesses des trois clients à ~ ⅓ Gbit / s, etc.

Nous avons pris soin de configurer les iperf3tests que le trafic des quatre clients de test entre dans le commutateur central sur différents ports:

Nous avons vérifié que chaque machine de test a un chemin d'accès indépendant vers le commutateur de rack et que le serveur de fichiers, sa carte d'interface réseau et le commutateur ont tous la bande passante pour y parvenir en décomposant le lagg0groupe et en attribuant une adresse IP distincte à chacun des quatre interfaces de cette carte réseau Intel. Dans cette configuration, nous avons atteint une bande passante globale d'environ 4 Gbit / s.

Lorsque nous avons commencé dans cette voie, nous le faisions avec un ancien commutateur géré SMC8024L2 . (Fiche technique PDF, 1,3 Mo.) Ce n'était pas le commutateur le plus haut de gamme de son époque, mais il est censé être en mesure de le faire. Nous pensions que le commutateur était peut-être en cause, en raison de son âge, mais la mise à niveau vers un HP 2530-24G beaucoup plus performant n'a pas changé le symptôme.

Le commutateur HP 2530-24G affirme que les quatre ports en question sont en effet configurés en tant que jonction LACP dynamique:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Nous avons essayé le LACP passif et actif.

Nous avons vérifié que les quatre ports NIC reçoivent du trafic du côté de FreeBSD avec:

$ sudo tshark -n -i igb$n

Curieusement, cela tsharkmontre que dans le cas d'un seul client, le commutateur divise le flux de 1 Gbit / s sur deux ports, apparemment en ping-pong entre eux. (Les commutateurs SMC et HP ont tous deux montré ce comportement.)

Étant donné que la bande passante agrégée des clients ne se réunit qu'en un seul endroit - au niveau du commutateur dans le rack du serveur - seul ce commutateur est configuré pour LACP.

Peu importe le client dans lequel nous démarrons en premier ou l'ordre dans lequel nous les démarrons.

ifconfig lagg0 du côté de FreeBSD dit:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Nous avons appliqué autant de conseils dans le guide de réglage du réseau FreeBSD que cela a du sens dans notre situation. (Une grande partie n'est pas pertinente, comme les choses sur l'augmentation des FD max.)

Nous avons essayé de désactiver le déchargement de segmentation TCP , sans changement dans les résultats.

Nous n'avons pas de deuxième carte réseau de serveur à 4 ports pour configurer un deuxième test. En raison du succès du test avec 4 interfaces distinctes, nous partons du principe qu'aucun des composants matériels n'est endommagé. ³

Nous voyons ces voies aller de l'avant, aucune d'elles n'est attrayante:

1. Achetez un commutateur plus gros et plus dur, en espérant que l'implémentation LACP de SMC suce juste et que le nouveau commutateur sera meilleur. (La mise à niveau vers un HP 2530-24G n'a pas aidé.)

2. Regardez la laggconfiguration de FreeBSD un peu plus, en espérant que nous ayons raté quelque chose. ⁴

3. Oubliez l'agrégation de liens et utilisez plutôt le DNS à tour de rôle pour effectuer l'équilibrage de charge.

4. Remplacez la carte réseau du serveur et basculez à nouveau, cette fois avec 10 trucs GigE , à environ 4 fois le coût matériel de cette expérience LACP.

Notes de bas de page

1. Pourquoi ne pas passer à FreeBSD 10, demandez-vous? Parce que FreeBSD 10.0-RELEASE utilise toujours le pool ZFS version 28 et que ce serveur a été mis à niveau vers le pool ZFS 5000, une nouvelle fonctionnalité de FreeBSD 9.3. La ligne 10. x ne l'obtiendra que lorsque FreeBSD 10.1 sera expédié dans environ un mois . Et non, la reconstruction à partir de la source pour accéder au bord de fuite 10.0-STABLE n'est pas une option, car il s'agit d'un serveur de production.

2. Veuillez ne pas sauter aux conclusions. Nos résultats de test plus loin dans la question vous expliquent pourquoi ce n'est pas un double de cette question .

3. iperf3est un pur test de réseau. Bien que l'objectif final soit d'essayer de remplir ce tuyau d'agrégat de 4 Gbit / s à partir du disque, nous n'impliquons pas encore le sous-système de disque.

4. Buggy ou mal conçu, peut-être, mais pas plus cassé qu'à sa sortie d'usine.

5. Je suis déjà allé de travers en faisant ça.

Quel est l'algorithme d'équilibrage de charge utilisé à la fois sur le système et sur le commutateur?

Toute mon expérience avec ceci est sur Linux et Cisco, pas FreeBSD et SMC, mais la même théorie s'applique toujours.

Le mode d'équilibrage de charge par défaut sur le mode LACP du pilote de liaison Linux et sur les commutateurs Cisco plus anciens comme le 2950, ​​est d'équilibrer uniquement en fonction de l'adresse MAC.

Cela signifie que si tout votre trafic passe d'un système (serveur de fichiers) à un autre MAC (soit une passerelle par défaut ou une interface virtuelle commutée sur le commutateur), le MAC source et de destination seront les mêmes, donc un seul esclave pourra jamais être utilisé.

D'après votre diagramme, il ne semble pas que vous envoyiez du trafic vers une passerelle par défaut, mais je ne sais pas si les serveurs de test sont dans 10.0.0.0/24, ou si les systèmes de test se trouvent dans d'autres sous-réseaux et sont routés via une interface de couche 3 sur le commutateur.

Si vous routez sur le commutateur, voici votre réponse.

La solution consiste à utiliser un algorithme d'équilibrage de charge différent.

Encore une fois, je n'ai pas d'expérience avec BSD ou SMC, mais Linux et Cisco peuvent équilibrer en fonction des informations L3 (adresse IP) ou L4 (numéro de port).

Comme chacun de vos systèmes de test doit avoir une adresse IP différente, essayez un équilibrage basé sur les informations L3. Si cela ne fonctionne toujours pas, modifiez quelques adresses IP et voyez si vous modifiez le modèle d'équilibrage de charge.