Thông lượng tối đa tổng hợp liên kết (LACP / 802.3ad)


10

Tôi đang thấy một số hành vi khó hiểu liên quan đến các giao diện ngoại quan trong Linux và tôi muốn đưa tình huống ra ngoài với hy vọng ai đó có thể giải quyết nó cho tôi.

Tôi có hai máy chủ: Máy chủ 1 (S1) có kết nối ethernet 4x 1Gbit; Máy chủ 2 (S2) có các kết nối ethernet 2x 1Gbit. Cả hai máy chủ đều đang chạy Ubuntu 12.04, mặc dù với kernel 3.11.0-15 (từ gói chung chung lts-saucy).

Cả hai máy chủ đều có tất cả các giao diện mạng tương ứng được gói trong một giao diện bond0 duy nhất với cấu hình (in /etc/network/interfaces) sau:

bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate fast
bond-slaves eth0 eth1 [eth2 eth3]

Giữa các máy chủ là một vài bộ chuyển mạch HP (tôi nghĩ) được cấu hình chính xác cho LACP trên các cổng được đề cập.

Bây giờ, liên kết đang hoạt động - lưu lượng truy cập mạng vui vẻ đến và đi từ cả hai máy. Và tất cả các giao diện tương ứng đang được sử dụng, vì vậy nó không giống như sự kết hợp hoàn toàn thất bại. Tuy nhiên, tôi cần càng nhiều băng thông càng tốt giữa hai máy chủ này và tôi không nhận được ~ 2Gbit / s mà tôi mong đợi.

Trong thử nghiệm của mình, tôi có thể quan sát rằng mỗi máy chủ dường như phân bổ từng kết nối TCP (ví dụ: iperf, scp, nfs, bất cứ thứ gì) cho một giao diện nô lệ duy nhất. Về cơ bản, mọi thứ dường như giới hạn ở mức tối đa 1 gigabit.

Bằng cách cài đặt bond-xmit-hash-policy layer3+4, tôi có thể sử dụng iperf -c S1 -P2để gửi trên hai giao diện nô lệ, nhưng ở phía máy chủ, việc tiếp nhận vẫn chỉ xảy ra trên một giao diện nô lệ và do đó tổng thông lượng được giới hạn ở mức 1Gbit / s, tức là máy khách hiển thị ~ 40-50 MB / s trên hai giao diện nô lệ, máy chủ hiển thị ~ 100MB / s trên một giao diện nô lệ. Không thiết lập bond-xmit-hash-policyviệc gửi cũng bị giới hạn trong một giao diện nô lệ.

Tôi có ấn tượng rằng LACP nên cho phép loại kết nối này, ví dụ, cho phép một lần chuyển scp duy nhất để sử dụng tất cả các giao diện có sẵn giữa hai máy chủ.

Là sự hiểu biết của tôi về LACP sai? Hoặc tôi đã bỏ lỡ một số tùy chọn cấu hình ở đâu đó? Bất kỳ đề xuất hoặc manh mối để điều tra sẽ được nhiều đánh giá cao!

Câu trả lời:


18

Một lời giải thích nhanh chóng và bẩn thỉu là một dòng giao tiếp sử dụng LACP sẽ không phân chia các gói trên nhiều giao diện. Ví dụ: nếu bạn có một gói phát trực tuyến kết nối TCP từ HostA đến HostB, nó sẽ không mở rộng giao diện để gửi các gói đó. Gần đây tôi đã xem xét LACP rất nhiều về một giải pháp mà chúng tôi đang thực hiện và đây là một quan niệm sai lầm phổ biến rằng "liên kết" hoặc "kết nối" nhiều giao diện mạng với LACP cung cấp cho bạn "thông lượng" của các giao diện kết hợp. Một số nhà cung cấp đã tạo trình điều khiển độc quyền sẽ định tuyến qua nhiều giao diện nhưng tiêu chuẩn LACP không từ những gì tôi đã đọc. Đây là một liên kết đến một sơ đồ và giải thích hợp lý mà tôi tìm thấy từ HP trong khi tìm kiếm các vấn đề tương tự: http://www.hp.com/rnd/l Library / pdf / 59692372.pdf


1
Đó là tất cả có ý nghĩa. Tôi không biết tại sao tôi không phát hiện ra quan niệm sai lầm của mình sớm hơn; Tôi chắc chắn đã đi qua các trang tài liệu và thuật ngữ tìm kiếm phù hợp. Có vẻ như tùy thuộc vào phần cứng mạng, chúng tôi có thể thay đổi chế độ băm src-Dest và may mắn với thông lượng đa giao diện, nhưng tôi nghĩ ở giai đoạn này tôi sẽ hài lòng với những gì chúng tôi có. Cảm ơn bạn đã làm rõ và các liên kết rất hữu ích.
Zetten

Vui mừng được giúp đỡ. Gần đây tôi đã đọc rất nhiều về điều này khi cố gắng làm rõ về thuật ngữ xử lý trung kế và liên kết được sử dụng khác nhau bởi các nhà cung cấp khác nhau. Tôi đã thấy rằng bên ngoài các tiêu chuẩn cụ thể như các tiêu chuẩn được xác định bởi các nhà cung cấp của IEEE có xu hướng sử dụng một số thuật ngữ thay thế cho nhau ...
Mike Naylor

6
Tài liệu này không còn có sẵn trên URL ban đầu, nhưng nó vẫn còn truy cập thông qua Internet Archive: web.archive.org/web/20030324105208/http://www.hp.com/rnd/...
smbear

3

bond-xmit-hash-policy layer3+4đặt cân bằng tải từ máy chủ nguồn của bạn sang công tắc. Nó không đặt thuật toán cân bằng tải từ chuyển sang máy chủ thứ hai. Điều đó gần như chắc chắn vẫn là lớp 2 hoặc lớp 3 cân bằng, tức là hoàn toàn không.


2

Chà, trước tiên, khi bạn đang sử dụng trình điều khiển hợp tác, điều đó sẽ tạo ra một số chi phí và giảm thông lượng tối đa dự kiến, là ~ 940 MB / s trên bộ điều hợp 1GB, ~ 10%.

Tôi không chắc bạn có loại bộ điều hợp nào, nhưng nếu bạn đang sử dụng trình điều khiển trong hộp, cài đặt có thể không lý tưởng cho thông lượng tối đa. bạn có thể xem xét thêm hàng đợi, tối đa 4, vì một hàng đợi trên bộ điều hợp có thể không đạt được tốc độ dây.

Một cân nhắc khác, đó là một chủ đề của iperf có thể sẽ không đạt được tốc độ tối đa. Đối với 1GB, 2-6 luồng có lẽ lý tưởng hơn, bạn có thể sử dụng tập lệnh bash đơn giản để khởi chạy nhiều luồng cùng lúc.

Đối với một Intel NIC, nhưng RSC RSS và Phần cứng có thể ảnh hưởng đến thông lượng, trên Broadcom đảm bảo rằng TOE đang hoạt động.

Tuy nhiên, bước một sẽ là loại bỏ các LAG và chỉ cần thử kiểm tra 1 cổng lưu lượng trên mỗi hệ thống để xem nó có bao nhiêu thông lượng, thực hiện điều này với tất cả các cổng, sau đó thử 2. LACP là một con thú hay thay đổi đúng, và tôi chưa bao giờ thử thiết lập nó trên một công tắc HP, chỉ Force10 (tiền Dell).

Ngoài ra, tại sao có một vài công tắc?


Như câu trả lời khác được mô tả, vấn đề tiềm ẩn là sự hiểu biết của tôi về LACP, nhưng chỉ để điền vào hình ảnh: các hộp linux đang sử dụng trình điều khiển liên kết của kernel. Mỗi giao diện riêng lẻ có thể đẩy thông lượng gần max-gigabit (rõ ràng khoảng 110-117 MB / giây tùy thuộc vào lưu lượng khác), vì vậy tôi thực sự chỉ tìm cách tăng băng thông đó thay vì điều chỉnh các NIC riêng lẻ. Đối với các thiết bị chuyển mạch, chúng tôi có một trang web đa văn phòng và có các thiết bị chuyển mạch trung kế với mux / demux sợi và nhiều bit và bobs khác trên đường đi. Tôi đã có cả hai máy chủ trên một công tắc HP 2920-48G để thử nghiệm.
Zetten

iperf có --paralleltham số kiểm soát số lượng luồng máy khách song song sẽ chạy
8.8.8.8
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.