Tập hợp liên kết FreeBSD không nhanh hơn liên kết đơn

Chúng tôi đặt một Intel I340-T4 4 cổng vào máy chủ FreeBSD 9.3 ¹ và định cấu hình nó để tổng hợp liên kết ở chế độ LACP nhằm giảm thời gian cần 8 đến 16 TiB dữ liệu từ máy chủ tệp chính xuống còn 2- 4 dòng vô tính song song. Chúng tôi đã mong đợi để có được băng thông tổng hợp lên tới 4 Gbit / giây, nhưng cho dù chúng tôi đã thử gì, nó không bao giờ xuất hiện nhanh hơn tổng hợp 1 Gbit / giây. ²

Chúng tôi đang sử dụng iperf3để kiểm tra điều này trên mạng LAN không hoạt động. ³ Trường hợp đầu tiên gần như đạt được một gigabit, như mong đợi, nhưng khi chúng tôi bắt đầu song song lần thứ hai, hai máy khách giảm tốc độ xuống còn khoảng ½ Gbit / giây. Thêm khách hàng thứ ba sẽ giảm cả tốc độ của ba khách hàng xuống ~ Gbit / giây, v.v.

Chúng tôi đã quan tâm trong việc thiết lập các iperf3thử nghiệm lưu lượng truy cập từ cả bốn khách hàng thử nghiệm đi vào công tắc trung tâm trên các cổng khác nhau:

Chúng tôi đã xác minh rằng mỗi máy kiểm tra có một đường dẫn độc lập trở lại công tắc giá và máy chủ tệp, NIC và công tắc đều có băng thông để loại bỏ điều này bằng cách chia lagg0nhóm và gán một địa chỉ IP riêng cho mỗi máy trong bốn giao diện trên card mạng Intel này. Trong cấu hình đó, chúng tôi đã đạt được băng thông tổng hợp ~ 4 Gbit / giây.

Khi chúng tôi bắt đầu con đường này, chúng tôi đã thực hiện điều này với một công tắc được quản lý cũ SMC8024L2 . (Bảng dữ liệu PDF, 1,3 MB.) Nó không phải là công tắc cao cấp nhất trong ngày, nhưng nó được cho là có thể làm điều này. Chúng tôi nghĩ rằng công tắc có thể bị lỗi, do tuổi của nó, nhưng việc nâng cấp lên HP 2530-24G có khả năng hơn nhiều đã không thay đổi triệu chứng.

Công tắc HP 2530-24G tuyên bố bốn cổng đang được đề cập thực sự được định cấu hình như một thân LACP động:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Chúng tôi đã thử cả LACP thụ động và chủ động.

Chúng tôi đã xác minh rằng tất cả bốn cổng NIC đang nhận được lưu lượng truy cập ở phía FreeBSD với:

$ sudo tshark -n -i igb$n

Điều kỳ lạ là, tsharktrong trường hợp chỉ có một máy khách, công tắc sẽ phân chia luồng 1 Gbit / giây qua hai cổng, rõ ràng là ping-ponging giữa chúng. (Cả hai bộ chuyển mạch SMC và HP đều thể hiện hành vi này.)

Vì băng thông tổng hợp của khách hàng chỉ kết hợp ở một nơi duy nhất - tại công tắc trên giá của máy chủ - chỉ có công tắc đó được định cấu hình cho LACP.

Không quan trọng chúng tôi bắt đầu khách hàng nào trước, hoặc chúng tôi bắt đầu họ theo thứ tự nào.

ifconfig lagg0 về phía FreeBSD nói:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Chúng tôi đã áp dụng rất nhiều lời khuyên trong hướng dẫn điều chỉnh mạng FreeBSD có ý nghĩa với tình huống của chúng tôi. (Phần lớn không liên quan, chẳng hạn như nội dung về tăng FD tối đa.)

Chúng tôi đã thử tắt giảm tải phân đoạn TCP , không có thay đổi trong kết quả.

Chúng tôi không có máy chủ 4 cổng thứ hai để thiết lập thử nghiệm thứ hai. Do thử nghiệm thành công với 4 giao diện riêng biệt, chúng tôi sẽ giả định rằng không có phần cứng nào bị hỏng. ³

Chúng tôi thấy những con đường phía trước, không ai trong số chúng hấp dẫn:

1. Mua một công tắc lớn hơn, tệ hơn, hy vọng rằng việc triển khai LACP của SMC chỉ là tệ và công tắc mới sẽ tốt hơn. (Nâng cấp lên HP 2530-24G không giúp được.)

2. Nhìn chằm chằm vào laggcấu hình FreeBSD một số nữa, hy vọng rằng chúng tôi đã bỏ lỡ một cái gì đó. ⁴

3. Quên tập hợp liên kết và sử dụng DNS vòng tròn để thực hiện cân bằng tải thay thế.

4. Thay thế máy chủ NIC và chuyển đổi lại, lần này bằng 10 công cụ GigE , với chi phí khoảng 4 × chi phí phần cứng của thí nghiệm LACP này.

Chú thích

1. Tại sao không chuyển sang FreeBSD 10, bạn hỏi? Bởi vì FreeBSD 10.0-RELEASE vẫn sử dụng ZFS pool phiên bản 28 và máy chủ này đã được nâng cấp lên ZFS pool 5000, một tính năng mới trong FreeBSD 9.3. Dòng 10. x sẽ không có được điều đó cho đến khi FreeBSD 10.1 xuất xưởng khoảng một tháng . Và không, xây dựng lại từ nguồn để có được cạnh chảy máu 10.0-STABLE không phải là một lựa chọn, vì đây là một máy chủ sản xuất.

2. Xin đừng đi đến kết luận. Kết quả kiểm tra của chúng tôi sau này trong câu hỏi cho bạn biết lý do tại sao đây không phải là bản sao của câu hỏi này .

3. iperf3là một thử nghiệm mạng thuần túy. Mặc dù mục tiêu cuối cùng là thử và lấp đầy ống tổng hợp 4 Gbit / giây đó từ đĩa, chúng tôi vẫn chưa liên quan đến hệ thống con đĩa.

4. Buggy hoặc thiết kế kém, có thể, nhưng không bị hỏng hơn khi nó rời khỏi nhà máy.

5. Tôi đã bị lác mắt khi làm điều đó.

Thuật toán cân bằng tải được sử dụng trên cả hệ thống và công tắc là gì?

Tất cả kinh nghiệm của tôi với điều này là trên Linux và Cisco, không phải FreeBSD và SMC, nhưng lý thuyết tương tự vẫn được áp dụng.

Chế độ cân bằng tải mặc định trên chế độ LACP của trình điều khiển liên kết Linux và trên các thiết bị chuyển mạch cũ của Cisco như 2950, ​​chỉ để cân bằng dựa trên địa chỉ MAC.

Điều này có nghĩa là nếu tất cả lưu lượng truy cập của bạn đi từ một hệ thống (máy chủ tệp) sang một MAC khác (có thể là cổng mặc định hoặc Giao diện ảo được chuyển đổi trên công tắc) thì MAC nguồn và đích sẽ giống nhau, do đó chỉ có một nô lệ được dùng.

Từ sơ đồ của bạn, có vẻ như bạn đang gửi lưu lượng truy cập đến một cổng mặc định, nhưng tôi không chắc liệu các máy chủ thử nghiệm có ở 10.0.0.0/24 hay không, nếu các hệ thống kiểm tra nằm trong các mạng con khác và được định tuyến qua giao diện lớp 3 trên công tắc.

Nếu bạn đang định tuyến trên công tắc, có câu trả lời của bạn.

Giải pháp cho vấn đề này là sử dụng thuật toán cân bằng tải khác nhau.

Một lần nữa tôi không có kinh nghiệm với BSD hoặc SMC, nhưng Linux và Cisco có thể cân bằng dựa trên thông tin L3 (địa chỉ IP) hoặc thông tin L4 (số cổng).

Vì mỗi hệ thống kiểm tra của bạn phải có một IP khác nhau, hãy thử cân bằng dựa trên thông tin L3. Nếu vẫn không được, hãy thay đổi một vài IP xung quanh và xem bạn có thay đổi mẫu cân bằng tải không.