스마트 스위치에서 링크 집계 그룹(LAG)을 설정할 때 대역폭의 링크 집계(본딩)가 작동하지 않습니다.

내 질문은: 스마트 스위치에 링크 집계 그룹을 설정하면 두 시스템 간의 대역폭이 감소하는 이유는 무엇입니까?

마침내 2개의 본딩된 10G CAT7 케이블을 통해 연결된 TP-LINK T1700X-16TS 스마트 스위치를 통해 두 시스템(ubuntu 18.04 서버를 실행하는 서버) 간에 더 높은 처리량(대역폭)을 달성했습니다. 이 케이블은 PCI-E x8에 연결되는 각 시스템의 단일 Intel X550-T2 NIC(각 카드에 2개의 RJ45 포트)에 연결됩니다.

제가 가장 먼저 한 일은 각 컴퓨터가 연결된 두 개의 포트가 포함된 스위치 구성에 정적 LAG 그룹을 만드는 것이었습니다. 이것은 결국 나의 첫 번째 실수였습니다.

각 상자에서 인텔 X550-T2 카드의 두 포트를 포함하는 본드를 만듭니다. 저는 netplan과 네트워킹을 사용하고 있습니다. 예를 들어:

network:
 ethernets:
     ens11f0:
         dhcp4: no
         optional: true
     ens11f1:
         dhcp4: no
         optional: true
 bonds:
         bond0:
             mtu: 9000 #1500
             dhcp4: no
             interfaces: [ens11f0,ens11f1]
             addresses: [192.168.0.10/24]
             parameters:
                 mode: balance-rr
                 transmit-hash-policy: layer3+4 #REV: only good for xor ?
                 mii-monitor-interval: 1
                 packets-per-slave: 1

9000바이트 MTU(점보 패킷용) 및 Balance-rr에 유의하세요.

이러한 설정을 사용하면 이제 iperf(iperf3)를 사용하여 컴퓨터 간의 대역폭을 테스트할 수 있습니다.

iperf3 -s (on machine1)

iperf3 -c machine1 (on machine2)

초당 약 9.9Gbit의 속도를 얻고 있습니다(단일 10G 연결의 이론상 최대값에 매우 가깝습니다).

하지만 뭔가 잘못됐어요. 나는 라운드 로빈을 사용하고 있으며 (이론적으로) 컴퓨터 사이에 두 개의 10G 케이블이 있습니다. 20G 대역폭을 얻을 수 있어야겠죠?

잘못된.

이상하게도 다음으로 스마트 스위치에서 LAG 그룹을 삭제했습니다. 이제 Linux 측에는 본딩된 인터페이스가 있지만 스위치의 경우 본딩이 없습니다(LAG 없음).

이제 iperf3을 다시 실행합니다.

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  1.77 GBytes  15.2 Gbits/sec  540    952 KBytes       
[  4]   1.00-2.00   sec  1.79 GBytes  15.4 Gbits/sec  758    865 KBytes       
[  4]   2.00-3.00   sec  1.84 GBytes  15.8 Gbits/sec  736    454 KBytes       
[  4]   3.00-4.00   sec  1.82 GBytes  15.7 Gbits/sec  782    507 KBytes       
[  4]   4.00-5.00   sec  1.82 GBytes  15.6 Gbits/sec  582   1.19 MBytes       
[  4]   5.00-6.00   sec  1.79 GBytes  15.4 Gbits/sec  773    708 KBytes       
[  4]   6.00-7.00   sec  1.84 GBytes  15.8 Gbits/sec  667   1.23 MBytes       
[  4]   7.00-8.00   sec  1.77 GBytes  15.2 Gbits/sec  563    585 KBytes       
[  4]   8.00-9.00   sec  1.75 GBytes  15.0 Gbits/sec  407    839 KBytes       
[  4]   9.00-10.00  sec  1.75 GBytes  15.0 Gbits/sec  438    786 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  17.9 GBytes  15.4 Gbits/sec  6246             sender
[  4]   0.00-10.00  sec  17.9 GBytes  15.4 Gbits/sec                  receiver

하하, 이제 15.4Gbits/sec(때때로 16.0까지 높음)을 얻습니다.

재전송으로 인해 걱정이 되었지만(LAG를 설정할 때 전송 결과가 전혀 나오지 않았습니다) 이제는 최소한 어느 정도 이점이 있습니다.

점보 패킷을 비활성화하거나 MTU를 1500으로 설정하면 약 4Gbps~5Gbps만 얻을 수 있습니다.

성능을 제한하는 대신 링크 집계 그룹이 스마트 스위치에 설정되는 이유(이것이 도움이 될 것이라고 생각합니다)를 아는 사람이 있습니까? 반면에 설정하지 않으면(돈을 절약하고 관리되지 않는 스위치를 구입할 수도 있었을 텐데!) 더 정확하게 라우팅된 패킷을 보낼 수 있습니까?

스위치의 LAG 그룹의 의미는 무엇입니까? 내가 어딘가에서 뭔가 잘못하고 있는 걸까? 가능하다면 대역폭을 16Gbps 이상으로 늘리고 싶습니다.

편집하다

아래 내 의견 복사(업데이트됨):

한 시스템의 램디스크에서 다른 시스템으로 60GB 파일을 복사하기 위해 nc(netcat)를 사용하여 본드 연결을 통해 실제 애플리케이션 속도가 11Gbps(1.25GiB/초)인지 확인했습니다. 해시를 사용하여 파일 무결성을 확인했는데 양쪽에 동일한 파일이 있습니다.

한 번에 10G 포트 중 하나만 사용하거나 균형 잡힌 XOR과 같은 본딩을 사용하면 1.15GiB/초(~9.9Gbps)를 얻습니다. iperf와 nc는 모두 기본적으로 TCP 연결을 사용합니다. 루프백을 통해 로컬 시스템에 복사하는 데는 1.5GiB/초가 소요됩니다. 스위치의 포트 사용량을 보면 발신자 Tx 측의 사용량은 거의 동일하고(iperf의 경우 70%, nc 파일 복사의 경우 약 55%) 본딩된 2개의 포트 간의 사용량을 알 수 있습니다. 수신 측에서도 동일합니다.

따라서 현재 설정(balance-rr, MTU 9000, 스위치에 정의된 LAG 그룹 없음)에서는 10Gbps 이상을 달성할 수 있지만 간신히 달성할 수 있습니다.

이상하게도 스위치에서 LAG 그룹을 정의하면 이제 모든 것이 중단됩니다(iperf 및 파일 전송은 이제 0바이트를 보냅니다). 새로운 스위치 상황을 파악하는 데 시간이 걸릴 수도 있지만 여러 번 다시 실행하고 스위치를 몇 번 재부팅/재설정했습니다. 그래서 왜 그런지 잘 모르겠습니다.

편집 2

실제로 kernel.org 문서에서 단일 포트 대역폭보다 더 높은 대역폭을 허용하는 스트라이핑 및 Balance-rr에 대한 언급을 발견했습니다.

https://www.kernel.org/doc/Documentation/networking/bonding.txt

구체적으로

12.1.1 단일 스위치 토폴로지를 위한 MT 본딩 모드 선택

이 구성은 필요에 가장 적합한 바인딩 모드를 결정해야 하지만 설정하고 이해하기 가장 쉽습니다. 각 모드의 장단점은 다음과 같습니다.

Balance-rr: 이 모드는 단일 TCP/IP 연결을 통해 여러 인터페이스에 트래픽을 스트라이프할 수 있는 유일한 모드입니다. 따라서 단일 TCP/IP 흐름이 여러 인터페이스의 처리량을 활용할 수 있도록 하는 유일한 모드입니다. 그러나 이는 비용이 듭니다. 스트라이핑으로 인해 피어 시스템이 순서에 맞지 않는 패킷을 수신하게 되어 TCP/IP의 혼잡 제어 시스템이 작동하게 됩니다(보통 세그먼트 재전송을 통해).

TCP/IP의 정체 제한은 net.ipv4.tcp_reordering sysctl 매개변수를 변경하여 조정할 수 있습니다. 일반적인 기본값은 3입니다. 하지만 TCP 스택은 재정렬을 감지하면 자동으로 이 값을 늘릴 수 있다는 점을 명심하세요.

순서 없이 전달되는 패킷의 비율은 매우 다양하며 0이 될 가능성이 없습니다. 재정렬 수준은 네트워크 인터페이스, 스위치, 구성된 토폴로지를 비롯한 다양한 요소에 따라 달라집니다. 일반적으로 고속 네트워크 카드는 패킷 병합과 같은 요인으로 인해 재정렬이 더 많이 발생하며 "다대다" 토폴로지는 "다대느림에서 1빠름"보다 더 높은 속도로 재정렬됩니다. " 구성.

많은 스위치는 스트라이프 트래픽 모드를 지원하지 않습니다(대신 IP 또는 MAC 수준 주소를 기반으로 포트를 선택함). 이러한 장치의 경우 스위치를 통해 Balance-rr에 의해 바인딩된 특정 연결로 흐르는 트래픽은 둘 이상의 인터페이스 대역폭을 사용하지 않습니다.

TCP/IP, UDP와 같은 프로토콜을 사용하고 애플리케이션이 잘못된 전달을 허용할 수 있는 경우 이 모드를 사용하면 인터페이스가 바인딩에 추가됨에 따라 단일 스트림 데이터그램 성능이 거의 선형적으로 확장될 수 있습니다.

이 모드에서는 스위치가 적절한 포트를 "etherchannel" 또는 "trunking"으로 구성해야 합니다.

따라서 이론적으로는 Balance-rr~ 할 것이다단일 TCP 연결에 대해 패킷을 스트라이프할 수 있습니다. 그러나 순서대로 도착하지 않을 수도 있습니다.

그러나 대부분의 스위치는 스트라이핑을 지원하지 않는다고 언급되어 있습니다. 제 스위치도 그런 것 같습니다. 실제 파일 전송 중 트래픽을 관찰하면 Rx 패킷(예: 송신 시스템 -> 스위치)이 본딩된 두 포트에 고르게 분산됩니다. 그러나 Tx 패킷(스위치 -> 수신 시스템)은 포트 중 하나를 통해서만 전송됩니다(포화도가 90% 이상에 도달).

스위치에서 링크 집계 그룹을 명시적으로 설정하지 않음으로써 더 높은 처리량을 달성할 수 있었지만 수신 컴퓨터가 스위치에 하나를 한 포트로 보낸 다음 다른 포트로 보내도록 지시하는 방법을 잘 모르겠습니다.

결론적으로:

스위치 링크 집계 그룹은 패킷 전송 라운드 로빈(즉, 포트 스트라이핑)을 지원하지 않습니다. 따라서 이를 무시하면 높은 처리량을 얻을 수 있지만 실제 메모리(램디스크)에 쓰는 작업은 메모리, CPU 처리 또는 패킷 재정렬 포화 지점에 도달하는 것 같습니다.

sysctl 증가/감소 재정렬과 TCP 메모리 버퍼 읽기 및 쓰기를 사용해 보았지만 성능에는 변화가 없었습니다. 예를 들어

sudo sysctl -w net.ipv4.tcp_reordering=50
sudo sysctl -w net.ipv4.tcp_max_reordering=1000

sudo sysctl -w net.core.rmem_default=800000000
sudo sysctl -w net.core.wmem_default=800000000
sudo sysctl -w net.core.rmem_max=800000000
sudo sysctl -w net.core.wmem_max=800000000

sudo sysctl -w net.ipv4.tcp_rmem=800000000
sudo sysctl -w net.ipv4.tcp_wmem=800000000

내가 알아차린 유일한 성능 변화는
1) 더 강력한 프로세서(약간 더 높은 단일 코어 클럭, L3 캐시는 신경 쓰지 않음)
2) 더 빠른 메모리를 갖춘 시스템 사이에서였습니다. (또는 더 적은 수의 DIMM을 사용하여 동일한 양의 메모리)

이는 버스, CPU 또는 메모리 읽기/쓰기 작업을 수행하고 있음을 의미하는 것 같습니다. 램디스크에서 로컬로 간단한 "복사"(예: dd if=file1 of=file2 bs=1M)는 2.6Ghz에서 약 2.3GiB/초, 2.4Ghz에서 2.2GiB/초, 2.0GiB/초 속도의 최고 속도를 달성합니다. 2.2GHz. 두 번째 것 역시 메모리가 더 느리지만 그것은 중요하지 않은 것 같습니다.

모든 TCP 복사본은 느린 머신에서 2.6Ghz 램디스크까지 1.15GiB/s, 2.4Ghz에서 1.30GiB/s, 가장 빠른 머신에서 중간 머신, 더 느린 머신(더 빠른 메모리 포함)까지 1.02GiB/s였습니다. 1.03 GiB/초 등

가장 큰 영향은 수신 측의 단일 코어 CPU와 메모리 클럭에 있는 것 같습니다. BIOS 설정을 비교하지는 않았지만 둘 다 동일한 BIOS 버전을 실행하고 동일한 마더보드, eth 카드 등을 사용합니다. CAT7 케이블이나 스위치 포트를 재배치해도 별 효과가 없는 것 같습니다.

내가 찾았어

http://louwrentius.com/achieving-340-mbs-network-file-transfers-using-linux-bonding.html

4개의 1GbE 연결로 이를 수행하는 사람은 누구입니까? 별도의 VLAN 설정을 시도했지만 작동하지 않았습니다(속도 증가 없음).

마지막으로 동일한 방법을 사용하여 자체적으로 전송하면 0.3GiB - 0.45GiB/초의 페널티가 발생하는 것으로 보입니다. 그래서 제가 관찰한 값은저것이 방법의 "이론적" 최대값보다 훨씬 낮습니다.

편집 3 (후손을 위해 더 많은 정보를 추가합니다)

스위치에 Balance-rr 및 LAG가 설정된 경우에도 9.9Gbps가 표시됨에도 불구하고 Balance-rr의 재시도 횟수가 LAG가 없을 때보다 실제로 더 높다는 것을 깨달았습니다! 그룹이 있을 때 평균 횟수는 초당 2500회, 그룹이 없을 때 평균 횟수는 초당 1000회입니다!

하지만 그룹 설정 후 실제 메모리 간 평균 파일 전송 속도는 1.15GiB/s(9.9Gbps)로 나타났다. 머신당 하나의 포트만 연결하면 속도는 동일하고(1.15GiB/s) 재시도 횟수는 거의 없습니다. 모드를 균형 XOR로 전환하면 1.15GiB/s(9.9Gbps)를 얻을 수 있고 재전송이 없습니다. 따라서 Balance-rr 모드는 출력의 한 쪽을 전환하기 위해 스트라이프를 시도하는데, 이로 인해 순서가 잘못된 패킷이 많이 발생하는 것 같습니다.

스위치 LAG와 균형 XOR을 사용하기 때문에 메모리 간 전송의 최대(실제) 성능은 비슷하거나 높으며 재전송(혼잡)이 적으므로 이를 사용하고 있습니다. 그러나 최종 목표는 NFS 및 MPI 전송이므로 이러한 경우 네트워크 속도를 포화시키고 측정하는 방법을 찾아야 하며 이는 MPI 연결이 구현되는 방식에 따라 달라질 수 있습니다.

최종 편집

XOR은 항상 동일한 두 피어에 대해 동일한 포트로 해시하기 때문에 (스위치 측에 LAG를 설정하지 않고) Balance-rr을 재사용했습니다. 따라서 포트 중 하나만 사용하게 됩니다. Balance-rr을 사용하여 2개 이상의(RAM에서 RAM으로) 파일 전송을 동시에 실행하면 이론적 최대치인 20Gbps에 매우 가까운 18-19Gbps의 순 속도를 얻을 수 있습니다.

최종 최종 편집(몇 달 사용 후)

오류가 발생하여 더 이상 시스템에 SSH를 연결할 수 없기 때문에 스위치에 LAG 그룹을 설정해야 했습니다. 패킷이 일부 주소 지정 콘텐츠와 함께 가야 할 곳에서 왜곡되었기 때문인 것 같습니다. 지금은 연결당 최대 10GBPS만 얻을 수 있지만 안정적입니다.