J'ai directement connecté deux crossover PowerEdge 6950 (en utilisant des lignes droites) sur deux adaptateurs PCIe différents.
J'obtiens un lien gigabit sur chacune de ces lignes (1000 MBit, full duplex, flux contol dans les deux sens).
Maintenant, j'essaie de lier ces interfaces dans bond0 en utilisant l'algorithme rr des deux côtés (je veux obtenir 2000 MBit pour une seule session IP).
Lorsque j'ai testé le débit en transférant / dev / zero vers / dev / null en utilisant dd bs = 1M et netcat en mode tcp, j'obtiens un débit de 70 Mo / s - pas - comme prévu plus de 150 Mo / s.
Lorsque j'utilise les lignes simples, j'obtiens environ 98 Mo / s sur chaque ligne, si j'utilise une direction différente pour chaque ligne. Lorsque j'utilise les lignes simples, j'obtiens 70 Mo / s et 90 Mo / s sur la ligne, si le trafic va dans la "même" direction.
Après avoir lu le fichier readme de liaison (/usr/src/linux/Documentation/networking/bonding.txt), j'ai trouvé la section suivante utile: (13.1.1 Sélection du mode de liaison MT pour la topologie à commutateur unique)
balance-rr: Ce mode est le seul mode qui permettra à une seule connexion TCP / IP de répartir le trafic sur plusieurs interfaces. C'est donc le seul mode qui permettra à un même flux TCP / IP d'utiliser plus d'une interface de débit. Cependant, cela a un coût: la répartition a souvent pour résultat que les systèmes homologues reçoivent des paquets dans le désordre, ce qui provoque le démarrage du système de contrôle de congestion de TCP / IP, souvent en retransmettant des segments.
It is possible to adjust TCP/IP's congestion limits by altering the net.ipv4.tcp_reordering sysctl parameter. The usual default value is 3, and the maximum useful value is 127. For a four interface balance-rr bond, expect that a single TCP/IP stream will utilize no more than approximately 2.3 interface's worth of throughput, even after adjusting tcp_reordering. Note that this out of order delivery occurs when both the sending and receiving systems are utilizing a multiple interface bond. Consider a configuration in which a balance-rr bond feeds into a single higher capacity network channel (e.g., multiple 100Mb/sec ethernets feeding a single gigabit ethernet via an etherchannel capable switch). In this configuration, traffic sent from the multiple 100Mb devices to a destination connected to the gigabit device will not see packets out of order. However, traffic sent from the gigabit device to the multiple 100Mb devices may or may not see traffic out of order, depending upon the balance policy of the switch. Many switches do not support any modes that stripe traffic (instead choosing a port based upon IP or MAC level addresses); for those devices, traffic flowing from the gigabit device to the many 100Mb devices will only utilize one interface.
Maintenant, j'ai changé ce paramètre sur les deux serveurs connectés sur toutes les lignes (4) de 3 à 127.
Après le collage à nouveau, j'obtiens environ 100 Mo / s mais toujours pas plus que cela.
Des idées pourquoi?
Mise à jour: détails du matériel de lspci -v:
24:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at dfe80000 (32-bit, non-prefetchable) [size=128K]
Memory at dfea0000 (32-bit, non-prefetchable) [size=128K]
I/O ports at dcc0 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
Capabilities: [e0] Express Endpoint, MSI 00
Kernel driver in use: e1000
Kernel modules: e1000
Mettre à jour les résultats finaux:
8589934592 octets (8,6 Go) copiés, 35,8489 secondes, 240 Mo / s
J'ai changé beaucoup d'options TCP / IP et de pilote de bas niveau. Cela comprend l'élargissement des tampons réseau. C'est pourquoi ddaffiche maintenant des nombres supérieurs à 200 Mo / s: dd se termine alors qu'il y a encore une sortie en attente de transfert (dans les tampons d'envoi).
Mise à jour 2011-08-05: paramètres qui ont été modifiés pour atteindre l'objectif ( /etc/sysctl.conf ):
# See http://www-didc.lbl.gov/TCP-tuning/linux.html
# raise TCP max buffer size to 16 MB. default: 131071
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# raise autotuninmg TCP buffer limits
# min, default and max number of bytes to use
# Defaults:
#net.ipv4.tcp_rmem = 4096 87380 174760
#net.ipv4.tcp_wmem = 4096 16384 131072
# Tuning:
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Default: Backlog 300
net.core.netdev_max_backlog = 2500
#
# Oracle-DB settings:
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
kernel.shmmax = 2147659776
kernel.sem = 1250 256000 100 1024
net.core.rmem_default = 262144
net.core.wmem_default = 262144
#
# Tuning for network-bonding according to bonding.txt:
net.ipv4.tcp_reordering=127
Paramètres spéciaux pour le périphérique de liaison (SLES: / etc / sysconfig / network / ifcfg-bond0 ):
MTU='9216'
LINK_OPTIONS='txqueuelen 10000'
Notez que la définition du plus grand MTU possible était la clé de la solution.
Réglage des tampons rx / tx des cartes réseau impliquées:
/usr/sbin/ethtool -G eth2 rx 2048 tx 2048
/usr/sbin/ethtool -G eth4 rx 2048 tx 2048
nuttcp. Testez facilement des connexions uniques ou multiples.
/proc/net/bonding/bond0pour vous assurer que vous vous mettez bien en équilibre-rr ? Avez-vous vu la note n que la documentation que vous avez collée sur une liaison à 4 interfaces ne vous donne que 2,3 interfaces de débit? Compte tenu de cette note, il semble hautement improbable que vous vous rapprochiez des 2000 Mo / s que vous souhaitez.