Rețea de stocare dedicată XCP-NG de 10 Gbit lentă (funcționează așa cum ar fi de 1 Gbit)

Am căutat o perioadă și nu găsesc răspuns sau chiar direcții pentru a aștepta înainte.

Asa de. Cluster XCP-NG de trei servere HP DL360p G8, NAS MSA 2060 iSCSI cu 12 unități SAS 10K, QNAP TS-1273U-RP, comutator Mikrotik CRS317. Rețeaua de stocare este în podul dedicat în mikrotik. Toate dispozitivele sunt conectate cu cabluri de cupru de 3 metri. Toate dispozitivele arată că legătura este 10G. Am configurat chiar și MTU la 9000 pentru toate dispozitivele. Fiecare server are card Ethernet cu două interfețe. Unul este folosit doar pentru rețeaua de stocare (eth1 pe toate cele trei servere). Subrețea diferită pentru rețeaua de stocare și rețea de management. Backend-ul rețelei Xen este openvswitch.

Cadrele Jumbo funcționează:

ping -M do -s 8972 -c 2 10.100.200.10 -- QNAP
PING 10.100.200.10 (10.100.200.10) 8972(9000) octeți de date.
8980 de octeți de la 10.100.200.10: icmp_seq=1 ttl=64 time=1.01 ms
8980 de octeți de la 10.100.200.10: icmp_seq=2 ttl=64 time=0,349 ms

--- 10.100.200.10 statistici ping ---
2 pachete transmise, 2 primite, 0% pierdere de pachete, timp 1001 ms
rtt min/avg/max/mdev = 0,349/0,682/1,015/0,333 ms

ping -M do -s 8972 -c 2 10.100.200.8 -- MSA 2060
PING 10.100.200.8 (10.100.200.8) 8972(9000) octeți de date.
8980 de octeți de la 10.100.200.8: icmp_seq=1 ttl=64 timp=9,83 ms
8980 de octeți de la 10.100.200.8: icmp_seq=2 ttl=64 time=0,215 ms

--- 10.100.200.8 statistici ping ---
2 pachete transmise, 2 primite, 0% pierdere de pachete, timp 1001 ms
rtt min/avg/max/mdev = 0,215/5,023/9,832/4,809 ms

Problemă: când copiez o mașină virtuală dintr-un spațiu de stocare (QNAP) în altul (MSA), viteza de scriere este de aproximativ 45 MB/s. Când copiez un fișier mare din QNAP (ex: instalare iso) pe servere de stocare locală, viteza este de aproximativ 100 MB/s și pe acel server htop arată un miez cu încărcare de 100%.

Este clar că rețeaua funcționează ca o rețea 1G.

Câteva informații despre hardware.

ethtool -i eth1
șofer: ixgbe
versiunea: 5.5.2
versiunea de firmware: 0x18b30001
expansion-rom-version:
info autobuz: 0000:07:00.1
suporturi-statistici: da
suporturi-test: da
suportă-eeprom-access: da
suportă-registru-dump: da
suportă-priv-flags: da

ethtool eth1
Setări pentru eth1:
        Porturi acceptate: [ FIBRE ]
        Moduri de legătură acceptate: 10000baseT/Full
        Utilizare acceptată a cadrului de pauză: simetric
        Suportă auto-negociere: Nu
        Moduri FEC acceptate: Nu sunt raportate
        Moduri de link anunțate: 10000baseT/Full
        Utilizarea cadrului de pauză anunțată: simetrică
        Auto-negociere anunțată: Nu
        Moduri FEC anunțate: Nu sunt raportate
        Viteza: 10000 Mb/s
        Duplex: complet
        Port: cupru cu atașare directă
        PHYAD: 0
        Transceiver: intern
        Auto-negociere: dezactivat
        Suporta Wake-on: d
        Trezire: d
        Nivelul curent al mesajului: 0x00000007 (7)
                               link sonda drv
        Link detectat: da

lspci | grep net
07:00.0 Controler Ethernet: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
07:00.1 Controler Ethernet: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Apoi am rulat serverul iper3 pe această gazdă: iperf3 -s -4 Rezultate pe server gazdă:

[ ID] Lățimea de bandă de transfer pe interval
[ 5] 0,00-10,04 sec 0,00 octeți 0,00 biți/sec expeditor
[ 5] 0,00-10,04 sec 5,48 GBytes 4,69 Gbits/sec receptor
[ 7] 0,00-10,04 sec 0,00 octeți 0,00 biți/sec expeditor
[ 7] 0,00-10,04 sec 5,44 GBytes 4,66 Gbits/sec receptor
[SUM] 0,00-10,04 sec 0,00 octeți 0,00 biți/sec expeditor
[SUM] 0,00-10,04 sec 10,9 GBytes 9,35 Gbits/sec receptor

Și client pe o altă gazdă: iperf3 -c 10.100.200.20 -P 2 -t 10 -4 Rezultate pe gazda client:

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0,00-10,00 sec 5,49 GBytes 4,72 Gbits/sec 112 expeditor
[ 4] 0,00-10,00 sec 5,48 GBytes 4,71 Gbits/sec receptor
[ 6] 0,00-10,00 sec 5,45 GBytes 4,68 Gbits/sec 178 expeditor
[ 6] 0,00-10,00 sec 5,44 GBytes 4,67 Gbits/sec receptor
[SUM] 0,00-10,00 sec 10,9 GBytes 9,40 Gbits/sec 290 expeditor
[SUM] 0,00-10,00 sec 10,9 GBytes 9,38 Gbits/sec receptor

Ce să testați în continuare sau cum să găsiți blocajele?

iperf3 arată că legătura funcționează cu o viteză de 10 Gbit sau interpretez incorect rezultatele?

Versiuni de software:

xe host-list params=versiunea-software
versiunea software (MRO): product_version: 8.2.0; text_versiunea_produs: 8.2; product_version_text_short: 8.2; platform_name: XCP; platform_version: 3.2.0; produs_brand: XCP-ng; build_number: release/stockholm/master/7; nume gazdă: localhost; data: 20-05-2021; dbv: 0,0,1; xapi: 1,20; xen: 4,13,1-9,11,1; Linux: 4.19.0+1; xencenter_min: 2,16; xencenter_max: 2,16; network_backend: openvswitch; db_schema: 5.602


versiunea software (MRO): product_version: 8.2.0; text_versiunea_produs: 8.2; product_version_text_short: 8.2; platform_name: XCP; platform_version: 3.2.0; produs_brand: XCP-ng; build_number: release/stockholm/master/7; nume gazdă: localhost; data: 20-05-2021; dbv: 0,0,1; xapi: 1,20; xen: 4,13,1-9,11,1; Linux: 4.19.0+1; xencenter_min: 2,16; xencenter_max: 2,16; network_backend: openvswitch; db_schema: 5.602


versiunea software (MRO): product_version: 8.2.0; text_versiunea_produs: 8.2; product_version_text_short: 8.2; platform_name: XCP; platform_version: 3.2.0; produs_brand: XCP-ng; build_number: release/stockholm/master/7; nume gazdă: localhost; data: 20-05-2021; dbv: 0,0,1; xapi: 1,20; xen: 4,13,1-9,11,1; Linux: 4.19.0+1; xencenter_min: 2,16; xencenter_max: 2,16; network_backend: openvswitch; db_schema: 5.602

Alte două servere au carduri HP 530FLR-SFP+:

    lspci | grep net
    03:00.0 Controler Ethernet: Broadcom Inc. și filiale NetXtreme II BCM57810 10 Gigabit Ethernet (rev. 10)
    03:00.1 Controler Ethernet: Broadcom Inc. și filiale NetXtreme II BCM57810 10 Gigabit Ethernet (rev. 10)

ethtool -i eth1
driver: bnx2x
versiunea: 1.714.24 storm 7.13.11.0
versiunea de firmware: bc 7.10.10
expansion-rom-version:
info autobuz: 0000:03:00.1
suporturi-statistici: da
suporturi-test: da
suportă-eeprom-access: da
suportă-registru-dump: da
suportă-priv-flags: da

ethtool eth1
Setări pentru eth1:
        Porturi acceptate: [ FIBRE ]
        Moduri de legătură acceptate: 1000baseT/Full
                                10000baseT/Full
        Utilizare acceptată a cadrului de pauză: Simetric Receive-only
        Suportă auto-negociere: Nu
        Moduri FEC acceptate: Nu sunt raportate
        Moduri de link anunțate: 10000baseT/Full
        Utilizarea cadrului de pauză anunțată: Nu
        Auto-negociere anunțată: Nu
        Moduri FEC anunțate: Nu sunt raportate
        Viteza: 10000 Mb/s
        Duplex: complet
        Port: cupru cu atașare directă
        PHYAD: 1
        Transceiver: intern
        Auto-negociere: dezactivat
        Suporta Wake-on: g
        Trezire: g
        Nivelul curent al mesajului: 0x00000000 (0)

        Link detectat: da

Editare 1: Test de stocare locală:

dmesg | grep sda
[ 13.093002] sd 0:1:0:0: [sda] 860051248 Blocuri logice de 512 octeți: (440 GB/410 GiB)
[ 13.093077] sd 0:1:0:0: [sda] Protecția la scriere este dezactivată
[ 13.093080] sd 0:1:0:0: [sda] Mode Sense: 73 00 00 08
[ 13.093232] sd 0:1:0:0: [sda] Cache de scriere: dezactivat, cache de citire: activat, nu acceptă DPO sau FUA
[ 13.112781] sda: sda1 sda2 sda3 sda4 sda5 sda6
[ 13.114348] sd 0:1:0:0: [sda] Disc SCSI atașat
[ 15.267456] EXT4-fs (sda1): montarea sistemului de fișiere ext3 folosind subsistemul ext4
[ 15.268750] EXT4-fs (sda1): sistem de fișiere montat cu modul de date ordonat. Opțiuni: (null)
[ 17.597243] EXT4-fs (sda1): remontat. Opțiuni: (null)
[ 18.991998] Adăugarea a 1048572k swap pe /dev/sda6. Prioritate:-2 extinderi:1 peste:1048572k
[ 19.279706] EXT4-fs (sda5): montarea sistemului de fișiere ext3 folosind subsistemul ext4
[ 19.281346] EXT4-fs (sda5): sistem de fișiere montat cu modul de date ordonat. Opțiuni: (null)

dd if=/dev/sda of=/dev/null bs=1024 count=1000000
1000000+0 înregistrări în
1000000+0 înregistrări scoase
1024000000 de octeți (1,0 GB) copiați, 11,1072 s, 92,2 MB/s

Acest lucru este ciudat, deoarece serverul are controler Smart Array P420i cu 2 GB cache, raid hardware10 de 6 unități SAS de 146 GB 15k. iLo arată că cu stocarea totul este ok. Pe un alt server rezultatele sunt similare 1024000000 de octeți (1,0 GB) copiați, 11,8031 s, 86,8 MB/s

Editare 2 (test de stocare partajată):
Qnap (SSD Raid10):

dd if=/run/sr-mount/23d45731-c005-8ad6-a596-bab2d12ec6b5/01ce9f2e-c5b1-4ba8-b783-d3a5c1ac54f0.vhd of=/dev/null bs=102000000
1000000+0 înregistrări în
1000000+0 înregistrări scoase
1024000000 de octeți (1,0 GB) copiați, 11,2902 s, 90,7 MB/s

MSA (raid HP MSA-DP+):

dd if=/dev/mapper/3600c0ff000647bc2259a2f6101000000 of=/dev/null bs=1024 count=1000000
1000000+0 înregistrări în
1000000+0 înregistrări scoase
1024000000 de octeți (1,0 GB) copiați, 11,3974 s, 89,8 MB/s

Nu mai mult de 1 rețea Gigabit... Deci, dacă transfer imagini VM între stocarea partajată, atunci stocarea locală nu este implicată. Openvswitch poate fi blocat?

Editare 3 (Mai multe teste de disc):
sda = Raid10 de 6 x 146GB 15k sas, sdb = un 146GB 15k SAS în raid0

dd if=/dev/sdb of=/dev/null bs=1024 count=1000000
1000000+0 înregistrări în
1000000+0 înregistrări scoase
1024000000 de octeți (1,0 GB) copiați, 16,5326 s, 61,9 MB/s
[14:35 xcp-ng-em ssh]# dd if=/dev/sdb of=/dev/null bs=512k count=1000
1000+0 înregistrări în
1000+0 înregistrări scoase
524288000 octeți (524 MB) copiați, 8,48061 s, 61,8 MB/s
[14:36 ​​xcp-ng-em ssh]# dd if=/dev/sdb of=/dev/null bs=512k count=10000
10000+0 înregistrări în
10000+0 înregistrări scoase
5242880000 de octeți (5,2 GB) copiați, 84,9631 s, 61,7 MB/s
[14:37 xcp-ng-em ssh]# dd if=/dev/sda of=/dev/null bs=512k count=10000
10000+0 înregistrări în
10000+0 înregistrări scoase
5242880000 octeți (5,2 GB) copiați, 7,03023 s, 746 MB/s