Nous avons mis une carte réseau Intel I340-T4 à 4 ports dans un serveur FreeBSD 9.3 1 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é. 2
Nous utilisons iperf3
pour tester cela sur un LAN tranquille. 3 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 iperf3
tests 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 lagg0
groupe 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 tshark
montre 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é. 3
Nous voyons ces voies aller de l'avant, aucune d'elles n'est attrayante:
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é.)Regardez la
lagg
configuration de FreeBSD un peu plus, en espérant que nous ayons raté quelque chose. 4Oubliez l'agrégation de liens et utilisez plutôt le DNS à tour de rôle pour effectuer l'équilibrage de charge.
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
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.
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 .
iperf3
est 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.Buggy ou mal conçu, peut-être, mais pas plus cassé qu'à sa sortie d'usine.
Je suis déjà allé de travers en faisant ça.