La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Iperf => Discussion démarrée par: scavenger le 16 juin 2012 à 14:49:13
-
bonjour :)
je veux tout d'abord remercier les auteurs d'iPerf : vraiment ça change la life :D
c'est un outil simple, efficace, qui ne ment pas, et gratuit. MERCI !
:-\ ensuite voici la raison de ma venue : je suis en réseau double câblage avec un NAS qui potentiellement transfert à 90MB/s mais j’obtiens au mieux 56MB/s vers le NAS, et 37MB/s vers le PC, en samba (partages Windows classiques)
Comme je n'arrive pas à poster quoi que ce soit sur le forum NetGear, je tente ici
=> la vitesse de transfert est différente dans les 2 sens : plus rapide vers le NAS en samba
=> le taux de transfert donné par iPerf est exactement l'inverse : plus rapide vers le PC
=> load balancing ou 802.3ad donnent les mêmes performances
=> MTU 1500, 4096 ou 9014 c'est pareil
ma config :
PC Windows XP64 + SSD + HP NC360T mode load balancing MTU 1500
NAS N5550 RAID5 5 disques mode load balancing MTU 1500
L2 switch NetGear GS108T avec un LAG 2 ports par membre, pas de VLAN, MTU 9216 max partout
les tests :
1) NAS serveur :
iperf -c 192.168.0.100 -P 1 -i 1 -p 5001 -l 8K -f M -t 5 -m -L 5001
root@N5550:/raid/data/share # iperf -s -P 1 -i 1 -m -p 5001 -f M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 0.08 MByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.100 port 5001 connected with 192.168.0.1 port 2283
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 36.9 MBytes 36.9 MBytes/sec
[ 4] 1.0- 2.0 sec 31.9 MBytes 31.9 MBytes/sec
[ 4] 2.0- 3.0 sec 31.9 MBytes 31.9 MBytes/sec
[ 4] 3.0- 4.0 sec 44.9 MBytes 44.9 MBytes/sec
[ 4] 4.0- 5.0 sec 44.6 MBytes 44.6 MBytes/sec
[ 4] 0.0- 5.0 sec 190 MBytes 38.0 MBytes/sec
[ 4] MSS size 1460 bytes (MTU 1500 bytes, ethernet)
2) NAS client :
iperf -s -P 1 -i 1 -m -p 5001 -f M
root@N5550:/raid/data/share # iperf -c 192.168.0.1 -P 1 -i 1 -p 5001 -l 8K -f M -t 5 -m -L 5001
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 0.02 MByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.100 port 43696 connected with 192.168.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 86.9 MBytes 86.9 MBytes/sec
[ 3] 1.0- 2.0 sec 78.3 MBytes 78.3 MBytes/sec
[ 3] 2.0- 3.0 sec 58.3 MBytes 58.3 MBytes/sec
[ 3] 3.0- 4.0 sec 80.4 MBytes 80.4 MBytes/sec
[ 3] 4.0- 5.0 sec 65.9 MBytes 65.9 MBytes/sec
[ 3] 0.0- 5.0 sec 370 MBytes 74.0 MBytes/sec
[ 3] MSS size 1460 bytes (MTU 1500 bytes, ethernet)
:o comment peut-on avoir des taux de transferts aussi différents suivant le sens ???
:o pourquoi ai-je des valeurs aussi fluctuantes ?
>:( comment configurer mon switch et mes cartes pour obtenir 90MB/s sachant qu'un double câblage doit pouvoir support 112MB/s ?
merci à ceux et celles qui m'aideront !
-
Oui, IPERF est un très bon logiciel de test de débit (je n'en suis pas l'auteur, j'ai juste compilé des versions pour ceux qui n'ont pas le courage de le faire sur le site https://iperf.fr (https://iperf.fr)). Pour le downlaod, j'aime bien wget -O /dev/null mais pour l'upload, Iperf est le seul à pouvoir faire des tests a 1 Gb/s.
Bon, ma réponse va être assez simple : pour envoyer des données a 1 Gb/s, il faut quand même pas mal de CPU, je ne pense pas que ton NAS arrive à suivre. Par contre, quand il reçoit les données, opération plus simple, cela lui pose moins de problème et le débit est plus élevé.
Pourrais-tu re-faire les tests en regardant le % d'utilisation du CPU sur ton NAS (par exemple avec la commande top)
Tu pourra voir mes tests de débits avec un Celeron 600 Mhz (moins performant que ton NAS, je n'ai pas dit le contraire)
=> Test de perf avec un Celeron 600 Mhz (https://lafibre.info/les-messages-a-lire-les-bugs-et-critiques/test-de-perf-avec-un-celeron-600-mhz/)
-
Bon, ma réponse va être assez simple : pour envoyer des données a 1 Gb/s, il faut quand même pas mal de CPU, je ne pense pas que ton NAS arrive a suivre. Par contre, quand il reçoit les données, opération plus simple, cela lui pose moins de problème et le débit et plus élevé.
Ben justement, il me semble bien que c'est l'inverse qu'on voit dans ses traces : ~40 Mo/s en réception contre ~80 Mo/s en émission.
À titre de comparaison, un échange avec les mêmes paramètres entre mon Mac mini (Core2 Duo) et une de mes Cubox (processeur ARM v7 800 MHz, plus ou moins équivalent en puissance à un Atom single core) me donne ~65 Mo/s en réception contre ~55 Mo/s en émission (avec une unique interface Ethernet Gigabit sur chacun).
La petite boite arrive donc bien à recevoir ~10 Mo/s de plus que ce qu'elle est capable d'envoyer.
Et entre le Mac et mon NAS (Atom D525) : ~70 Mo/s en émission et ~110 Mo/s en réception (même pas besoin d'un double câblage ^^).
Edit : apparemment, le Thecus N5500 est équipé d'un processeur Celeron M 1.86GHz - ça ne doit pas aider ...
Edit 2 : SmallNetBuilders (http://www.smallnetbuilder.com/nas/nas-reviews/30898-thecus-n5500-reviewed?showall=&start=3) indique avoir obtenu des taux de transferts de fichiers de 70 Mo/s avec le bestiau. Le proc est donc sans doute suffisamment bien taillé.
-
iperf -c est la partie qui èmet les paquets.
iperf -s est la partie qui reçoit les paquets.
-
C'est bien ce que je dis.
Tiens-t'en aux traces, et pas à leurs intitulés (trompeurs, car partiellement inversés).
Dans les deux cas, la commande iperf est lancée depuis le NAS :
root@N5550:/raid/data/share # iperf -s -P 1 -i 1 -m -p 5001 -f M
(...)
[ 4] 0.0- 5.0 sec 190 MBytes 38.0 MBytes/sec~40 Mo/s en réception.
root@N5550:/raid/data/share # iperf -c 192.168.0.1 -P 1 -i 1 -p 5001 -l 8K -f M -t 5 -m -L 5001
(...)
[ 3] 0.0- 5.0 sec 370 MBytes 74.0 MBytes/sec~80 Mo/s en émission.
-
oui, c'est l'inverse, je me suis emmêlé les pinceaux.
Réception du NAS : 38 Mio/s
Émission du NAS : 74 Mio/s
C'est le cas aussi avec iperf sans les options (dont beaucoup sont a la valeur par défaut) ?
Un truc simple du genre iperf -s -i 2 et iperf -c 192.168.0.1 -i 2
-
Mio/s. C'est vrai que iperf indique des Mo/s, mais que la conversion est réalisée en base 1024.
C'est le cas aussi avec iperf sans les options (dont beaucoup sont a la valeur par défaut) ?
Je doute que ça change quelque chose, j'obtiens chez moi les mêmes résultats en ne conservant que l'option "-f M".
scavenger, il y a clairement un truc qui cloche dans ta configuration.
Avant de te faire du mal avec le débogage de port-trunking/link-aggregation/load-balancing/jumbo-frames et consorts, je t'encourage vivement à remettre tous tes équipements en configuration basique (1 seul lien GbE connecté par équipement, MTU standard), et de refaire des tests afin de savoir ce que tu es capable d'en tirer dans ces conditions.
Si ça se trouve (j'ai déjà été confronté à ce cas avec mon précédent NAS), ça sera bien plus performant en standard qu'en mode usine à gaz (d'après les tests réalisés par SmallNetBuilders, tu arriveras péniblement à saturer un seul lien GbE : alors, pourquoi t'emmerder à en monter deux ?).
-
merci des commentaires ^^
1) je suis repassé en 802.3ad des 2 côtés
2) j'ai repassé la MTU à 9000 des 2 côtés
3) j'ai refait le test avec le NAS en mode serveur et le PC client qui fait l'aller-retour, c'est plus simple :
PC : iperf -c n5550 -i 1 -f M -t 5 -r
NAS : root@N5550:/root # iperf -s -i 1 -m -p 5001 -f M
nmon─14g──────[H for help]───Hostname=N5550────────Refresh= 1secs ───23:10.26──
│ CPU Utilisation ─────────────────────────────────────────────────────────────
│---------------------------+-------------------------------------------------+
│CPU User% Sys% Wait% Idle|0 |25 |50 |75 100|
│ 1 3.0 6.9 0.0 90.1|Usss > |
│ 2 3.0 12.0 0.0 85.0|Ussssss > |
│ 3 3.0 6.0 0.0 91.0|Usss > |
│ 4 4.0 10.9 0.0 85.1|Usssss > |
│---------------------------+-------------------------------------------------+
│Avg 3.5 8.9 0.0 87.6|Ussss > |
│---------------------------+-------------------------------------------------+
la CPU (Atom D2550 quad core 1.86Ghz) est clairement peu utilisée pendant le test : les pics (>) représentent la réception, les valeurs (Usss) représente l'émission.
quand aux résultats :
[ 5] local 192.168.0.100 port 5001 connected with 192.168.0.1 port 2432
[ 5] 0.0- 1.0 sec 0.23 MBytes 0.23 MBytes/sec
[ 5] 1.0- 2.0 sec 0.05 MBytes 0.05 MBytes/sec
[ 5] 2.0- 3.0 sec 0.05 MBytes 0.05 MBytes/sec
[ 5] 3.0- 4.0 sec 0.05 MBytes 0.05 MBytes/sec
[ 5] 4.0- 5.0 sec 0.05 MBytes 0.05 MBytes/sec
[ 5] 0.0- 5.6 sec 0.45 MBytes 0.08 MBytes/sec
[ 5] MSS size 8960 bytes (MTU 9000 bytes, unknown interface)
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 0.31 MByte (default)
------------------------------------------------------------
[ 5] local 192.168.0.100 port 54370 connected with 192.168.0.1 port 5001
[ 5] 0.0- 1.0 sec 119 MBytes 119 MBytes/sec
[ 5] 1.0- 2.0 sec 118 MBytes 118 MBytes/sec
[ 5] 2.0- 3.0 sec 118 MBytes 118 MBytes/sec
[ 5] 3.0- 4.0 sec 117 MBytes 117 MBytes/sec
[ 5] 4.0- 5.0 sec 118 MBytes 118 MBytes/sec
[ 5] 0.0- 5.0 sec 590 MBytes 118 MBytes/sec
J'ai bien à un moment du 118 MB/s comme attendu vu ma config, mais uniquement en émission du NAS. J'ai remarqué également sur mes 2 cartes réseau sur le NAS, que eth0 était utilisée uniquement en émission, et l'autre eth1 uniquement en réception.
4) Ceci est absolument discordant avec les taux de transfert que j'ai en samba : 52MB/s en réception et 37MB/s en émission. C'est tout le contraire.
exactement comme les tests du début, en mode load balancing.
- Pendant tous les tests la CPU n'a jamais dépassé 30% et les disques n'ont jamais dépassé 75% d'utilisation en R/W
- j'utilise un ramdisk pour les transferts samba, pour éviter les bottlenecks SATA
J'ai évidemment un souci dans ma config mais je n'arrive pas à mettre le doigt dessus. Il y a un bottleneck quelque part.
Je vais suivre vos conseils et repasser en 1 seul câble des deux côtés et préparer un plan de tests complets.
:P Également si vous connaissez des forums avec des geeks furieux du réseau, je suis toute ouïes ! Je ne connais dans mon entourages que des experts DBA ou JEE, en réseau je ne connais personne ^^
A part vous lol
mais merci déjà
-
J'ai bien à un moment du 118 MB/s comme attendu vu ma config, mais uniquement en émission du NAS. J'ai remarqué également sur mes 2 cartes réseau sur le NAS, que eth0 était utilisée uniquement en émission, et l'autre eth1 uniquement en réception.
Si tu as deux interfaces agrégées, et qu'elles sont bien configurées en actif-actif, tu devrais pouvoir dépasser 200 Mio/s.
Ils fonctionnent sous Linux, les Thecus, il me semble ?
Si oui, peux-tu passer la commande suivante dessus :
cat /proc/net/bonding/bond0
-
Etherchannel - Bonding :
Coté Linux, Etherchannel s'appelle bondind et se matérialise sous la forme d'un module disponible en standard dans le noyau. Comme pour le switch, on regroupe plusieurs interfaces physiques (ethx) sur une interface logique (nommée bondx, x est le numéro de l'interface). Les solutions offertes par le bonding sont nombreuses :
- Mode 0 : Round Robin (équilibrage de charge) : Ce mode augmente la bande passante et gère la tolérance de panne. Groupement de ports pour load balancing et Failover : Le trafic sortant de l'interface est émis alternativement sur chacune des interfaces. Les ports du switch sont groupés avec Etherchannel. Par contre la configuration est statique sans protocole PagP ou LACP (802.3ad).
- Mode 1 : Active - passive / Active backup : Failover seulement : Seule une des interfaces physique est active et répond au requêtes arp. Pas de propriétés particulière sur le switch.
- Mode 2 : Balance-XOR : Groupement de ports pour load balancing et Failover : Le switch est configuré en Etherchannel. Dans le sens sortant, le serveur Linux choisit l'interface physique en fonction de l'adresse mac (source ou destination, ou XOR sur les deux). Sur le switch Cisco, Etherchannel fonctionne aussi sur ce principe (le load balancing effectué sur le switch concerne le trafic entrant sur le serveur Linux). Ainsi les transferts sont parallélisés et le choix de l'interface suit la règle : (Adresse MAC de la source XOR Adresse MAC de la destination) modulo nombre d'interfaces.
- Mode 3 : Broadcast : Failover seulement : Le trafic est transmis sur toutes les interfaces physiques.
- Mode 4 : IEEE 802.3ad (https://fr.wikipedia.org/wiki/IEEE_802.3ad) : Groupement de ports pour load balancing et Failover : Fonctionne les switchs Ethernet qui supportent cette norme. Le mécanisme de load blancing est similaire à celui du mode Balance-XOR.Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. Cela implique que le switch gère le 802.ad et que les interfaces soient compatibles mii-tool et/ou ethtool.
La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments sélectionnables suivants :
- niveau 2 (adresses MAC source et adresses MAC destination) ;
- niveau 3 (IP source et IP destination) ;
- niveau 4 (port source et port destination).
Tous les ports d'un groupe doivent obligatoirement être paramétrés à la même vitesse, même duplex (full/half), même VLAN, même mode (access/trunk).
- Mode 5 : Adaptive transmit load balancing (balance-tlb) : Load balancing dans le sens sortant uniquement : Le trafic sortant de l'interface est émis de sur l'une ou l'autre des interfaces physique en fonction de le charge. Dans le sens entrant, une seule des interfaces physique répond au requêtes ARP. Aucune configuration particulière n'est nécessaire sur le switch. Les drivers de la carte ethernet sur le serveur Linux doivent être compatibles ethool.
- Mode 6 : Adaptative load balancing (balance-alb) : Load balancing dans les deux sens. Reprend le mécanisme balance-tlb dans le sens sortant. Dans le sens entrant, le bonding intercepte les requêtes ARP pour renvoyer alternativement l'adresse des interfaces physiques.
Adaptive load balancing : ce mode inclut en plus du tlb un load balancing sur le flux entrant et seulement pour un trafic IPV4. L'équilibrage est réalisé au niveau ARP. Le module intercepte les réponses pour y réécrire l'adresse MAC de l'une des interfaces du bond tout en tenant compte des spécificités du protocole ARP. La répartition entre les différentes interfaces, se fait de façon séquentielle ( round robin ).
Tous ces modes sont listés et expliqués dans la documentation du module bonding qui est livrée avec les sources du noyau.
Le mode 4 IEEE 802.3ad est conseillé avec des switch Cisco.
Exemple de fichier de configuration en mode IEEE 802.3ad avec Ubuntu :
(mode 4 - conseillé avec un switch Cisco)
- Vérifier que le paquet pour gérer le bonding est bien installé (c'est généralement le cas avec les distributions serveur) :
apt install ifenslave-2.6
- Définition du type de bonding a utiliser :
nano -w /etc/modprobe.d/aliase-bond.conf
alias bond0 bonding
options bonding mode=4 xmit_hash_policy=layer3+4 miimon=100 downdelay=200 updelay=200
mode=4 : signifie que nous utilisons le mode 802.3ad
xmit_hash_policy=layer3+4 : choix de l'interface en upload via les info niveau 3 (IP source et IP destination) et 4 (port source et port destination). Par défaut c'est le niveau 2 (adresse mac) => Dans la cas d'un serveur avec une passerelle par défaut, tout le trafic hors du réseau local part via la même interface. Cela ne concerne que l'upload. Pour le download, la configuration se fait sur le switch.
miimon=100 : une vérification de l'état des interfaces physiques est effectuée toutes les 100ms.
- Définition de l'interface réseau :
nano -w /etc/network/interfaces
# The primary network interface
#auto eth0
#iface eth0 inet dhcp
auto eth0
auto eth1
auto bond0
iface bond0 inet static
address 138.21.127.54
netmask 255.255.255.240
network 138.21.127.48
broadcast 138.21.127.63
gateway 138.21.127.62
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1
Certaines machines vont utiliser eth0 et d'autres eth1. A noter qu'un même PC, même protocole et même port peut utiliser eth0 en download et eth1 en upload.
En cas de panne d'une des deux liaisons, le trafic passe intégralement par l'autre.
En cas de ré-installation du serveur : l'accès internet est possible dès l'installation sans le bonding et sans reconfiguration du routeur.
-
Donc pour résumer dans le bonding utilisé habituellement une connexion TCP passe toujours par le même lien Ethernet.
Par contre quand on a plusieurs connexions TCP (venant d'une même machine ou de plusieurs) une partie sera toujours envoyée sur la première interface réseau et une partie toujours envoyée sur la seconde interface réseau.
Avec iperf je te conseille donc de faire varier les N° de ports et tu vas voir que tes deux interfaces devraient être utilisées en in et en out.
-
Si tu as deux interfaces agrégées, et qu'elles sont bien configurées en actif-actif, tu devrais pouvoir dépasser 200 Mio/s.
Ils fonctionnent sous Linux, les Thecus, il me semble ?
oui oui et c'est une dérivation de RedHat je suppose :
/raid/data/ # uname -a
Linux N5550 2.6.38 #1 SMP Wed Apr 18 17:58:27 CST 2012 x86_64 GNU/Linux
cat /proc/version
Linux version 2.6.38 (root@FC12-27) (gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC) ) #1 SMP Wed Apr 18 17:58:27 CST 2012
Si oui, peux-tu passer la commande suivante dessus :
cat /proc/net/bonding/bond0
bien sur :
root@N5550:/root # cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.0 (June 2, 2010)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 300
Down Delay (ms): 0
802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 2
Number of ports: 2
Actor Key: 17
Partner Key: 14
Partner Mac Address: 74:44:01:xx:xx:xx
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:14:fd:xx:xx:xx
Aggregator ID: 2
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: 00:14:fd:xx:xx:xx
Aggregator ID: 2
Slave queue ID: 0
mais j'ai de la lecture là !!!
merci je vais lire ça ce soir :D
-
D’après ton fichier de configuration, je lis "Bonding Mode: IEEE 802.3ad Dynamic link aggregation" => tu es bien en mode 4, le mode recommandé :
- Mode 4 : IEEE 802.3ad (https://fr.wikipedia.org/wiki/IEEE_802.3ad) : Groupement de ports pour load balancing et Failover : Fonctionne les switchs Ethernet qui supportent cette norme. Le mécanisme de load blancing est similaire à celui du mode Balance-XOR.Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. Cela implique que le switch gère le 802.ad et les interfaces soient compatibles mii-tool et/ou ethtool.
La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments sélectionnables suivants :
- les adresses MAC(source et ou destination)
- les adresses IP (source et ou destination)
- le port applicatif (destination)
Tous les ports d'un groupe doivent obligatoirement être paramétrés à la même vitesse, même duplex (full/half), même VLAN, même mode (access/trunk).
Par contre je lit Transmit Hash Policy: layer2 (0) ce qui signifie que la destination est choisie uniquement ne fonctionne des adresses niveau 2 (contre niveau 3 et 4 dans mon exemple, soit les adresses IP et les ports).
Un PC (adresse mac unique) utilisera donc toujours le même lien. Par exemple les adresses mac paires utiliseront le lien 1 en upload et les adresses mac impaires utiliseront le lien 2 en upload (c'est un exemple simplificateur mais on est assez proche de ce fonctionnement).
Pour le download, c'est le switch qui choisit qui va utiliser quel lien, il faudrait la configuration du switch pour comprendre.
-
Quelques explications (http://www.smallnetbuilder.com/lanwan/lanwan-basics/30853-smart-switch-how-to-part-3-bandwidth-control?start=1) sont données sur SmallNetBuilder.
Mais quitte à me répéter, il ne me semble pas rationnel de batailler à monter du LACP tant qu'on a pas vérifié les perfs sur un seul lien ...
-
Pour le plaisir!
-
Loin de moi l'idée de brider son plaisir, bien au contraire.
C'est juste que notre ami ne sait pas vraiment où sa configuration pose problème, et qu'il me semble utile d'être méthodique :
1. Je teste individuellement les 4 combinaisons possibles entre le PC et le NAS : je dois obtenir ~1 Gbps partout dans les deux sens
2. Je monte l'agrégat du PC , et je refais les tests à partir des 2 cartes du NAS : je dois obtenir ~1 Gbps sur les deux liens du NAS, dans les deux sens
3. Je casse l'agrégat du PC, monte celui du NAS , et je refais les tests à partir des 2 cartes du PC : je dois obtenir ~1 Gbps sur les deux liens du PC, dans les deux sens
4. Je remonte l'agrégat du PC, et teste à nouveau : je dois obtenir au moins 1 Gbps dans les deux sens
C'est l'affaire d'une toute petite heure de tests, et ça permettra de valider tous les éléments du circuit.
Si c'est non conforme quelque part, il saura où exactement, et pourra alors investiguer sur les causes du problème avec un maximum de billes en main.
-
merci pour ces précisions
je vais devoir tester chaque carte d'après ce que tu indiques...
ça va prendre bien plus qu'une heure !!! :P
à chaque modif de la config du NAS, je dois le rebooter et ça prend 100 secondes, sans compter que ça risque de le planter car une fois j'ai du faire un RAZ du réseau (et des /etc/passwd également)
Depuis, j'ai tout reconfiguré en team 802.3ad des deux côtés, avec pour le NAS l'interface fournie (pas le choix) et pour le PC un outil de HP (HP network configuration utility)
Je n'ai pas créé de VLAN car je n'en vois aucune utilité: le PC comme le NAS doivent tout 2 accéder au web donc, pas de VLAN. Est-ce nécessaire ?
Tout le monde est en 1000/full et 9000 jumbo frame
LACP est activé sur le switch
Le switch est dit de niveau 2 et accepte des frames de 9216 max partout :
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_1.png)
ci joint le dernier test iperf :
la config du PC :
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_2.png)
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_3.png)
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_4.png)
test1 : PC->NAS (65MB/s)
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_5.png)
les cartes du NAS :
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_6.png)
les cartes du PC :
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_7.png)
je suis pas expert mais ça montre clairement qu'à chaque fois une carte sert à l'envoi et l'autre à la réception.
et au retour c'est toujours la même carte qui est utilisée :
test2 : NAS->PC (85MB/s)
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_8.png)
les cartes du NAS :
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_9.png)
les cartes du PC :
(https://lafibre.info/images/iperf/201211_bonding_avec_un_nas_et_switch_hp_10.png)
Les envois de paquets sont clairement routés par la même carte, quelque soit le sens, et selon une règle qui m'échappe.
Si je débranche un câble ou l'autre du PC, je garde les mêmes débits.
Peut être que c'est le fonctionnement normal de l'aggrégation 802.3ad ?
Peut être que je n'ai pas compris quelque chose ?
Ma question de départ serait plutôt :
peut-on forcer 2 cartes en load balancing à répartir la charge aussi également que possible et donc à profiter de la bande passante de la somme des 2 ?
je veux juste pouvoir transférer à 100MB/s entre le PC et le NAS.
Si c'est impossible n'hésitez pas à me le dire comme ça je laisserai tomber, j'en ferai pas une maladie ;)
-
Il existe plusieurs types de 802.3ad. Si tu fais la répartition par Adresse mac ou par adresse IP il faut de nombreux PC connectés pour utiliser les deux ports simultanèment.
Si tu fais la répartition en ajoutant en plus les ports alors avec de multiples connexions en parallèle (-P 10 sous Iperf), tu pourras utiliser les deux ports simultanèment.
Pour rappel :
- Mode 4 : IEEE 802.3ad (https://fr.wikipedia.org/wiki/IEEE_802.3ad) : Groupement de ports pour load balancing et Failover : Fonctionne les switchs Ethernet qui supportent cette norme. Le mécanisme de load blancing est similaire à celui du mode Balance-XOR.Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. Cela implique que le switch gère le 802.ad et les interfaces soient compatibles mii-tool et/ou ethtool.
La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments sélectionnables suivants :
- les adresses MAC(source et ou destination)
- les adresses IP (source et ou destination)
- le port applicatif (destination)
Tous les ports d'un groupe doivent obligatoirement être paramétrés à la même vitesse, même duplex (full/half), même VLAN, même mode (access/trunk).
Concrètement, sous linux, c'est le fichier n/etc/modprobe.d/aliase-bond.conf à configurer.
alias bond0 bonding
options bonding mode=4 xmit_hash_policy=layer3+4 miimon=100 downdelay=200 updelay=200
mode=4 : signifie que nous utilisons le mode 802.3ad
xmit_hash_policy=layer3+4 : choix de l'interface en upload via les info niveau 3 (IP source et IP destination) et 4 (port source et port destination). Par défaut c'est le niveau 2 (adresse mac) => Dans la cas d'un serveur avec une passerelle par défaut, tout le trafic hors du réseau local part via la même interface. Cela ne concerne que l'upload. Pour le download, la configuration se fait sur le switch.
miimon=100 : une vérification de l'état des interfaces physiques est effectuée toutes les 100ms.
En 802.3ad, quel que soit la configuration utilisé, une connexion TCP ou UDP passera toujours par un seul port.
-
tu as tout à fait raison, je n'avais pas saisi cette subtilité. Le mode 802.3ad n'était pas ce que je voulais.
en modifiant des paramètres de la TEAM du PC, j'ai ainsi découvert que mes ports se mettaient en Tx/Rx ou Tx ou Rx seul, selon la configuration.
- j'ai ainsi sélectionné le mode SLB + round Robin => j'ai bien du Tx/Rx sur les 2 ports, et la charge est bien répartie
- sur le NAS j'ai sélectionné le mode correspondant : Balance-ALB
quand je transfert dans les 2 sens, j'ai bien une répartition sur les 2 ports :-) mission réussie !!
Sur le NAS par contre c'est toujours Tx ou Rx sur une seul des 2 cartes, mais ce n'est pas grave, j'ai la réponse à ma recherche :
mes taux de transferts sont toujours aussi dégueulasses voir pire. En effet dans le switch je remarque un tas de paquets en erreur.
Comme il est indiqué dans la config du PC, le mode Round Robin ne garanti pas l'ordre des paquets à l'arrivée. Ce qui provoque des rejets et donc des retransmissions, d'où la présence de paquets en erreur (le switch n'indique pas ce que veut dire "paquet en erreur" et ce n'est pas son rôle, c'est juste mon interprétation)
Le débit n'est donc pas meilleur, puisque ce que je gagne d'un côté je le perd de l'autre.
Ma conclusion de tout ce temps perdu c'est que aujourd'hui en 2012 avec les technologies actuelles à ma disposition, il m'est impossible de transférer plus d'information avec 2 cables qu'avec un seul.
Peut être existe-t-il des switchs qui réordonnent les paquets à transmettre, mais ce n'est que pure hypothèse, et si ça existe c'est sûrement très cher.
Je crois que je vais devoir me contenter d'un mode qui permet un seul sens de transmission sur chaque cable, et ce des 2 côtés, en sus d'un failover.
Je suis très déçu, j'avais un rêve et je constate que la technologie le permettant n'existe pas.
comment font les gens qui testent les NAS sur les site de tests pour avoir des débits de 90MB ??
-
Pour avoir de meilleurs débit ce n'est pas le réseau qui est important (avec un seul câble 1Gb/s tu peux avoir 110 Mo/s) mais les disques dur et/ou le processeur de ton NAS.
Je privilégie plus le disque sur. Pour faire du 90Mo/s il faut un disque dur qui ne soit pas bas de gamme et faire une lecture séquentielle d'un gros fichier (non fragmenté)
-
en local sur le NAS je copie un fichier à 120MB/s et quand je transfert, le CPU est pas franchement utilisé...
je transfert sur un RAM disk du PC bien entendu...
J'ai testé d'autres versions de Windows, notamment 7, mais pas mieux...
Les cables sont CAT5 donc c pas le souci.
Le sujet dérive donc je vais repasser sur les forums de Thecus.
merci vivien seb et tous les autres pour l'aide apportée !!! 8)
-
Avec l’arrivée des connexions FTTH à 1 Gb/s, Je cherche à faire la même chose pour un serveur.
Aujourd'hui je suis en Mode 4 : IEEE 802.3ad donc une connexion TCP est toujours sur la même interface limitée à 1 Gb/s.
=> Si il y a 100 Mb/s au moment ou le test 1 Gb/s est réalisé, le débit max sera de 900 Mb/s.
Vous avez compris si le Mode 0 : Round Robin (équilibrage de charge) permet d'envoyer 2 Gb/s et recevoir 2 Gb/s avec une même connexion TCP ?
Si oui, quel est la différence avec le Mode 6 : Adaptative load balancing (balance-alb) ?
-
seul le mode balance-rr permet de distribuer une même connexion TCP sur plusieurs liens physiques.
Ce mode génère souvent des 'out of order' qui entraînent des retransmissions.
Ce mode doit être supporté par le switch ce qui n'est pas souvent le cas.
Sinon ce que tu cherches à faire s’appelle du Multipath TCP (https://en.wikipedia.org/wiki/Multipath_TCP) , c'est en cours de normalisation et de mise au point donc expérimental et très peu supporté. En labo, le record est de 50Gbs pour un meme connexion TCP sur 6 liens 10Gbps. C'est plus haut niveau que LACP dont devrait marcher quelque soit l’équipement hardware.
Le port de Multipath pour Linux: http://www.multipath-tcp.org/ (http://www.multipath-tcp.org/)
un GoogleTechTalks d'1h30 d'explications de MultiPath: Multipath TCP (https://www.youtube.com/watch?v=02nBaaIoFWU#ws)
-
Multipath TCP qui est utilisé par Siri sous IOS7 : https://www.nextinpact.com/news/82634-ios-7-multipath-tcp-permet-a-siri-jongler-avec-connexions-3g-et-wi-fi.htm (https://www.nextinpact.com/news/82634-ios-7-multipath-tcp-permet-a-siri-jongler-avec-connexions-3g-et-wi-fi.htm)
-
en gros à part multipath TCP le meilleur mode à sélectionner serait le mode tcp connection (sur le screen de scavenger)
ça permettrait un équilibrage par session tcp, en gros une connection tcp est limité à 1gbps, mais 2 connections atteindront les 2 gbps (d''après ce que j'ai compris!)
-
seul le mode balance-rr permet de distribuer une même connexion TCP sur plusieurs liens physiques.
Ce mode génère souvent des 'out of order' qui entraînent des retransmissions.
Je n'avais pas pensé à des out of order pour un lien entre un serveur et un dswitch (le switch étant connecté en 10 Gb/s vers Internet)
Le meilleur mode n'est pas IEEE 802.3ad ?
Cela m'a souvent été conseillé en environnement pro (switch Cisco Catalyst 3750-E) et c'est ce qui est en place pour https://testdebit.info (https://testdebit.info)
- Mode 4 : IEEE 802.3ad (https://fr.wikipedia.org/wiki/IEEE_802.3ad) : Groupement de ports pour load balancing et Failover : Fonctionne les switchs Ethernet qui supportent cette norme. Le mécanisme de load blancing est similaire à celui du mode Balance-XOR.Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. Cela implique que le switch gère le 802.ad et les interfaces soient compatibles mii-tool et/ou ethtool.
La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments sélectionnables suivants :
- les adresses MAC(source et ou destination)
- les adresses IP (source et ou destination)
- le port applicatif (destination)
Tous les ports d'un groupe doivent obligatoirement être paramétrés à la même vitesse, même duplex (full/half), même VLAN, même mode (access/trunk).
-
Le meilleur mode n'est pas IEEE 802.3ad ?
si c'est le mieux et le plus ancien et le plus adopté.
mais la on parlais de pouvoir dépasser 1Gbps avec une seul connexion TCP, IEEE 802.3ad ne permet pas ca.
-
Mais quel que soit la méthode, envoyer une même connexion vers deux port risque de générer des out of order, donc je pense que je vais abandonner l'idée.
Il y aurais un moyen simple sous linux pour télécharger un fichier en http (ou ftp) avec deux connexions TCP en paralléle ?
Je voudrais un wget -O /dev/null http://1.testdebit.info/fichiers/100Mo.dat (http://1.testdebit.info/fichiers/100Mo.dat) qui utilise deux (ou plus) connexions TCP afin d'utiliser mon agrégation IEEE 802.3ad ! Le but est d'afficher le débit des deux connexions cumulés.
SpeedTest utilises plusieurs connexions en parallèle mais SpeedTest c'est en flash avec un navigateur, je préférerais avoir qq chose de fiable en ligne de commande.
Iperf a des nombreux bug entraînant une petite Rwin, une limitation a 5 connexions en // sous windows, une obligation d'ouvrir un port en NAT pour le sens descendant, pour moi ce n'est pas (plus) l'outil idéal.
-
regardes du coté des "download accelerators', notamment axel (http://manpages.ubuntu.com/manpages/precise/man1/axel.1.html) qui est installable sous ubuntu directement (sudo apt install axel).
par exemple:
axel -a -n 2 http://1.testdebit.info/fichiers/100Mo.dat
va lancer 2 connexions http pour télécharger ce fichier
edit: axel est assez ancien, il y a peut etre des choses plus recentes et plus completes mais axel est un bon début
-
Le problème d'Axel, c'est qu'il refuse de télécharger vers /dev/null c'est une autre de mes exigences, à 1 Gb/s il faut avoir un SSD pour pouvoir suivre sans perturber le téléchargement.
$ axel -o /dev/null -a -n 2 http://1.testdebit.info/fichiers/100Mo.dat
Initializing download: http://1.testdebit.info/fichiers/100Mo.dat
File size: 100000000 bytes
No state file, cannot resume!
En utilisant une autre destination que /dev/null cela fonctionne.
Si j'ai bien compris, c'est lié au fait que Axel télécharge dans deux fichiers différents avant des les concaténer en un seul.
-
oui c'est pas prevu pour ca mais tu dois contourner l’accès disque en utilisant un ramdisk (un tmpfs par exemple) si ta machine a assez de mémoire pour ca.
exemple pour avoir un ramdisk de 2Go :
sudo mkdir /mnt/ram2giga
sudo mount -o size=2G -t tmpfs none /mnt/ram2giga
ensuite y'a plus qu'a utiliser le ramdisk comme repertoire pour axel
axel -o /mnt/ram2giga -a -n 2 http://1.testdebit.info/fichiers/100Mo.dat
pour enlever le ramdisk (ou gardes le en permanence et supprimes les fichiers après chaque test)
sudo umount /mnt/ram2giga
de base beaucoup de systemes, on deja un ramdisk ou meme plusieurs, regardes (avec la commande df) si y'en a pas deja un avec l'espace libre suffisant.
Un tmpfs ne consomme la RAM qu'au besoin, il ne la reserve pas d'avance et peut aussi generer de la pagination.
Donc attention toutefois a ne pas déclencher de la pagination et donc des accès disques si la machine n'a pas assez de mémoire au moment du test, ca invaliderai le test de vitesse.
Pour etre sur d'etre toujours en RAM il faudra dans ce cas peut etre utiliser un ramdisk qui reserve la mémoire et ne pagine pas, donc avec ramfs par exemple mais c'est plus beaucoup plus contraignant pour le système, pas vraiment recommandé pour ce cas.
-
J'ai fait un test avec un système ubuntu serveur avec 16 Go de ram : La mémoire est utilisée a hauteur de 1 go par le système et 15 Go par le cache (je n'ai pas rebootée le serveur depuis longtemps)
Quand j'ai écrit les données sur le ram disque, il a été me mettre des données dans le swap (alors qu'il y avait la place en diminuant le cache)
-
ca devrait pas sauf si autre chose dans le système a besoin de la mémoire, surveilles avec htop eventuellement.
sinon faut monter un ramfs a la place d'un tmpfs , ca ne swap pas et on peut pas mettre de limite donc attention car ca peut bouffer toute la mémoire du système si on fait pas gaffe.
la 3eme alternative est un ramdisk a l'ancienne (un des /dev/ram*) , on peut mettre une limite mais ca se regle au boot uniquement, c'est plus compliquer à faire et ca consomme plus de mémoire.
tmpfs: quand on veut, avec une limite mais ca swap
ramfs: quand on veut, pas de limite et pas de swap
ramdisk: au boot uniquement, avec une limite et pas de swap
-
en plus d'Axel il y a aussi Aria2 qui fait la meme chose et meme plus (notamment téléchargements bittorrent en ligne de commande).
Il a le même défaut qu'axel quand le répertoire de sortie est /dev/null mais en revanche les développeurs d'aria2 ont l'air d'etre toujours actifs (la derniere maj date de septembre 2013) contrairement a axel qui n'a pas été mis a jour depuis 2009 malgres le bug signalé pour /dev/null (http://alioth.debian.org/tracker/index.php?func=detail&aid=312194&group_id=100070&atid=413085).
Il te serait peut etre donc possible de leur demander de rajouter une option 'speedtest' pour télécharger sans sauvegarder sur disque (style "an option to disable saving" par exemple).
Le site d'aria2: http://aria2.sourceforge.net/ (http://aria2.sourceforge.net/)
-
En quoi utiliser ramfs va moins déclencher la pagination que tmpfs?
-
Parce que ramfs utilise les mécanismes de gestion du cache disque.
https://fr.wikipedia.org/wiki/Ramfs (https://fr.wikipedia.org/wiki/Ramfs)