MCX516A-CCAT 100G DAC 메시: lshw는 40Gbit/s라고 하고 iperf3 단일 스트림은 21Gbit/s에서 한계
노드 세 대를 스위치 없이 100G DAC로 서로 직결한 클러스터를 운영하고 있고, replication 트래픽이 자기만의 fabric을 쓰게 인터페이스는 broadcast bond로 묶어뒀어요. 실제 부하를 걸기 전에 기준값을 잡아두려고 했는데, 수치들이 서로 안 맞아요.
- Mellanox ConnectX-5 EN 3장, MCX516A-CCAT, 듀얼 포트 QSFP28
- 노드 쌍마다 100G DAC 하나씩
- AMD EPYC 호스트, 셋 다 Proxmox
ethtool은 완전히 만족스러워요:
# ethtool ens1
Settings for ens1:
Supported link modes: 100000baseCR4/Full
Advertised link modes: 100000baseCR4/Full
Speed: 100000Mb/s
Duplex: Full
Link detected: yeslshw는 아니에요:
# lshw -class network
*-network
description: Ethernet interface
vendor: Mellanox Technologies
capacity: 40Gbit/s그리고 노드 두 개 사이의 iperf3는 대략 21 Gbit/s에 머물러 있는데, 이건 둘 중 어느 수치랑도 안 맞아요.
이미 해본 것:
- 케이블을 양쪽 카드의 두 번째 포트로 옮겨봤는데 변화 없음
- 같은 타입의 다른 DAC로 바꿔봤는데 변화 없음
- 링크는 내내 Up이고 카운터에 쌓이는 에러도 없음
그러면 두 도구 중 어느 쪽이 거짓말을 하고 있는 걸까요, 그리고 케이블, 카드, 드라이버 중 뭘 파야 할까요?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
올리신 내용 중에는 DAC를 가리키는 게 하나도 없어요. 여기서는 서로 무관한 일이 두 가지 벌어지고 있어요.
첫째, 수치 불일치요.
lshw -class network는 자기 나름대로 계산한 capability 수치를 찍는 건데, 이 카드들에서는 100G로 올라온 링크에 대해서도 태연하게capacity: 40Gbit/s라고 해요. 실제로 협상된 속도는ethtool이 보고하는 값이고, 거기엔Speed: 100000Mb/s에100000baseCR4/Full이 advertise됐다고 나와요. 이 부분은 멀쩡하고 고칠 게 없어요.둘째, 처리량이요. 다른 걸 건드리기 전에 먼저 슬롯부터 확인하세요:
LnkCap이 8GT/s라고 하는데LnkSta가 2.5GT/s로 트레이닝됐다면, 실제 배선 속도보다 훨씬 낮게 캡이 걸린 거라서 케이블을 아무리 바꿔도 소용없어요. 카드를 다시 꽂고 실제로 풀 width로 배선된 슬롯에 있는지 확인하세요.그다음엔 단일 스트림으로 측정하는 걸 그만두세요:
이 등급의 호스트에서 코어 하나가 내줄 수 있는 게 대략 21 Gbit/s 정도라서, 그 수치 하나만으로는 알 수 있는 게 별로 없어요. 돌리는 동안 CPU도 지켜보시고 idle state가 뭘 하고 있는지도 보세요. 버스트 사이에 코어가 깊은 C-state로 떨어지는 게 이 속도대에서는 실제 대역폭을 갉아먹어요.
뭐든 교체 주문하기 전에 그 카드의
lspci -vv에서LnkSta줄이랑 실제로 쓴 iperf3 명령줄을 그대로 올려주세요. 100G에서 스트림 하나는 링크가 아니라 CPU 코어 하나를 측정하는 거라서, 여기서 며칠씩 날리는 사람들이 있어요. 그리고 테스트하는 동안 두 번째 포트가 놀고 있는 게 아니라 실제로 메시의 다른 구간을 나르고 있는지도 확인하세요. 슬롯 하나가 살아있는 100G 포트 두 개를 먹이는 건 하나만 먹이는 것과 예산이 달라요. 저라면 지금은lshw는 일단 접어둘 것 같아요, 이 질문에는 맞는 도구가 아니에요.C-state 부분에 정정 하나요: 호스트가 EPYC면 이런 스레드마다 붙여넣는
intel_idle옵션들은 아무 효과가 없어요, 그 드라이버는 AMD에서는 아예 경로에 없거든요. 저한테 먹힌 방법은 커널 명령줄의processor.max_cstate=2였어요. 아이디어는 같은데 플랫폼이 다른 거예요. 그 글의 나머지 내용, 특히 협상된 속도를lshw에서 읽으면 안 된다는 건 그대로 맞아요.조금 다른 종류의 장애인데 같은 계열 하드웨어니까 슬롯 문제를 해결하고 나면 배제해볼 만해요. ConnectX-5 QSFP28 포트로 직결 메시를 짜면 레이어3에서 꼬이기가 아주 쉬워요. 저는 노드 세 개를 MCX516A-CCA_Ax로, 펌웨어 16.35.4030에 DOCA 2.8.0 드라이버로, MCP1600-C003E30L 3m 구리 DAC로 배선했었어요. 모든 링크가 100Gbps로 active라고 나왔는데 핑이 하나도 안 건너갔어요. 메시 인터페이스 여섯 개 전부 경로 어디에도 스위치 없이 10.5.5.x라는 서브넷 하나에서 주소를 받고 있어서, 커널이 특정 목적지가 어느 물리 포트에 속하는지 판단할 방법이 없었던 거예요. 노드 쌍마다 서브넷을 하나씩, 10.5.5.x, 10.5.6.x, 10.5.7.x로 나눴더니 그때부터 동작하기 시작했어요. 누가 구리 케이블 탓하기 전에 세 장비 전부에서
ip a랑ip route부터 돌려볼 만해요.둘 다 맞았어요.
lspci -vv를 보니LnkCap은 8GT/s인데 카드는 2.5GT/s로 트레이닝돼 있었고, 그게 첫 번째 용의자였어요. 세 장비 전부 카드를 다른 슬롯으로 옮겼더니LnkSta가 이제 8GT/s로 뜨고,iperf3 -P 8로 같은 노드 쌍을 테스트하니 바로 단일 스트림 수치를 넘어섰어요.broadcast bond도 포기하고 메시를 Open vSwitch에 RSTP로 다시 짰어요. CPU 스레드 세 개랑 포트 두 개에 iperf를 분산시키니까 지금은 대략 95 Gbit/s가 나오는데, 이 클러스터가 하는 일 치고는 line rate에 충분히 가까워요.
lshw는 여전히 40Gbit/s라고 우기고 있고 저는 이제 그건 그냥 안 봐요.