Một cổng trên X520-DA2 chỉ đạt 1 Gbit/s trong iperf3 sau khi chuyển từ TrueNAS Core sang SCALE 24.10
Cái máy lưu trữ đã đi từ Core 13.0-U6.7 lên SCALE 24.04 rồi tiếp tục lên 24.10, và từ đó tới giờ một cổng ì ạch trong khi cổng song sinh trên cùng card lại chạy ngon lành. Card 25G cũng hành xử y hệt vậy, đó là điều khiến tôi nghi ngờ chính mắt mình.
- Intel X520-DA2 với quang multimode SFP+ hãng Intel, 10G tới switch
- Intel XXV710-DA2 với quang SFP28 hãng Intel, 25G tới cùng switch đó
- TrueNAS SCALE 24.10 trên NAS (trước là Core 13.0-U6.7, rồi 24.04)
- iperf3 giữa NAS và một client làm thước đo
Trạng thái link trên cổng chậm trông đúng như nó phải vậy:
$ ethtool enp1s0f0 | grep -E 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes
$ iperf3 -c 192.168.3.2
# parks itself around 1 Gbit/s for the whole run
# the second port of the same card does line rate against its own client
Đã làm:
- đổi chỗ quang giữa hai cổng trên card; cổng chậm vẫn chậm, cổng nhanh vẫn nhanh
- so sánh sysctl net.ipv4.tcp_congestion_control ở cả hai đầu, cùng giá trị
- tháo lắp lại cả hai đầu và lau sạch đầu ferrule
Mọi thứ đo được ở tầng link đều nói là 10G và 25G full duplex, mà payload thì vẫn kẹt ở khoảng một gigabit. Module đang xuống cấp, NIC sắp hỏng, hay tôi đang nhìn sai tầng?
Comments 3
Bạn đã tự loại quang ra khỏi danh sách nghi vấn rồi: bạn đã đổi chỗ chúng giữa các cổng và sự chậm chạp vẫn ở lại với cổng đó. Vậy cứ để yên các module, và tách riêng các sự kiện ở tầng link khỏi con số throughput, vì chúng đang trả lời hai câu hỏi khác nhau.
Thường có hai thứ khác nhau giữa một cổng nhanh và một cổng chậm trên cùng một card. Xem chúng cùng nhau:
Nếu một bên ở MTU 1500 còn bên kia ở 9014, và chúng nằm ở VLAN khác nhau, thì bài test chậm của bạn không đi ra khỏi NIC rồi quay lại, mà nó đang đi qua đường routing của host. Đặt một client cùng VLAN và cùng subnet với cổng chậm, rồi chạy iperf3 -c nhắm vào đó. Không router nào trên đường đi, không lệch MTU, chẳng có gì để tranh cãi nữa.
Nếu bài test cùng VLAN cho bạn full line rate, thì cổng và transceiver đều ổn, và thứ bạn thực sự đo được là hiệu năng routing liên VLAN trên host, đây chính là nơi khá nhiều ca chuyển từ Core sang SCALE kết thúc: forward giữa các VLAN kém hẳn so với thời còn Core.
Đó là một chẩn đoán chứ chưa hẳn là cách chữa. Bạn lấy lại được phần lớn hiệu năng bằng cách giữ các luồng nặng trong cùng một VLAN, hoặc giao việc routing cho switch thay vì NAS. Ít nhất nó cũng giúp bạn khỏi phải trả lại hai module SFP+ hoàn toàn tốt.
Trước khi ai đó bắt đầu rút quang ra: switch nói gì về hai cổng đó? Tốc độ đã thương lượng, duplex và các bộ đếm lỗi ở cả hai. Và đầu nào đang chạy iperf3 server trong bài test chậm, cái trần đó có đứng yên không khi bạn đảo chiều test và đẩy từ phía bên kia?
Rồi đăng MTU và VLAN của cổng chậm và cổng nhanh, đặt cạnh nhau. Một cổng thương lượng 10G mà chỉ chuyển được một gigabit payload gần như luôn luôn là vấn đề forwarding hoặc đường đi, không phải vấn đề quang. Nếu hai cổng không nằm cùng VLAN, iperf3 đang chấm điểm router của bạn, không phải link của bạn.
Phần cứng khác nhưng hình dạng vấn đề giống hệt. Hai máy đấu lưng nhau qua card X520-DA bằng một DAC SFP+, một bên Hyper-V Server Core 2012 R2, bên kia là một máy lưu trữ NAS4Free 9.1. Đấu thẳng, cặp đó đạt 8-9 Gbit/s cả đọc lẫn ghi. Ngay khi cổng được gán vào một Hyper-V virtual switch, tốc độ rơi xuống cỡ 500 Mbit/s, và test lại card dưới Windows Server 2012 R2 và Windows 8.1 cũng chẳng thay đổi gì cả.
Chuyện này chưa bao giờ được chứng minh rõ ràng. Câu trả lời duy nhất tôi nhận được là hỏi phía sau mỗi đầu có ổ đĩa gì và RAID level nào, một câu hỏi hợp lý, vì storage có thể chính là cái trần giới hạn từ rất lâu trước khi đường 10G kịp là giới hạn. Thói quen tôi rút ra từ đó: đo cùng một link cả khi có lớp phụ đó gắn vào lẫn khi tháo ra, và đo với một RAM disk nếu sắp xếp được. Cáp và card ở đó cũng không phải là vấn đề.