Phương pháp kiểm tra hiệu năng một liên kết WAN

Chúng tôi có một cặp đa dạng-chuyển liên kết 1Gbps Ethernet mới giữa các địa điểm khoảng 200 dặm. 'Client' là một cỗ máy mới có sức mạnh hợp lý mới (HP DL380 G6, E56xx Xeons kép, 48GB DDR3, cặp đĩa đôi 300GB 10krpm SAS, W2K8R2-x64) và 'máy chủ' cũng là một máy đủ tốt (HP BL460c G6 , cặp E55xx Xeons kép, 72GB, cặp R1 của ổ đĩa 146 GB tốc độ 10 GB / phút, HBA Emulex 4Gbps FC cổng kép được liên kết với hai chiếc Cisco MDS9509 sau đó lên HP HP 8400 chuyên dụng với đĩa 128 x 450GB 15krpm FC, RHEL 5.3-x64).

Sử dụng SFTP từ máy khách, chúng tôi chỉ thấy khoảng 40Kbps thông lượng sử dụng các tệp lớn (> 2GB). Chúng tôi đã thực hiện kiểm tra máy chủ 'máy chủ cục bộ khác' và thấy khoảng 500Mb / giây thông qua các thiết bị chuyển mạch cục bộ (Cat 6509), chúng tôi sẽ làm tương tự ở phía máy khách nhưng cách đó một ngày.

Những phương pháp kiểm tra nào khác mà bạn sẽ sử dụng để chứng minh cho các nhà cung cấp liên kết rằng vấn đề là của họ?

Điều chỉnh một con voi:
Điều này có thể yêu cầu điều chỉnh, có lẽ không phải là vấn đề ở đây như pQd nói. Loại liên kết này được biết đến là "Đường ống dài, mập" hoặc con voi (xem RFC 1072 ). Vì đây là một ống gigabit béo đi qua một khoảng cách (khoảng cách thực sự là thời gian / độ trễ trong trường hợp này), cửa sổ nhận tcp cần phải lớn (Xem TCP / IP Illustrated Tập 1, Phần mở rộng TCP để xem hình ảnh).

Để tìm ra cửa sổ nhận cần là gì, bạn tính toán sản phẩm trễ băng thông:

Bandwidth * Delay = Product

Nếu có độ trễ 10MS, máy tính này ước tính bạn muốn có một cửa sổ nhận khoảng 1,2 MB. Chúng ta có thể tự làm phép tính với công thức trên:

echo $(( (1000000.00/.01)/8  )) 
12500000

Vì vậy, bạn có thể muốn chạy kết xuất gói để xem liệu mở rộng cửa sổ tcp (phần mở rộng TCP cho phép các cửa sổ lớn hơn) đang xảy ra đúng để điều chỉnh điều này một khi bạn tìm ra vấn đề lớn là gì.

Giới hạn cửa sổ:
Nếu đây là vấn đề, rằng bạn có kích thước cửa sổ bị ràng buộc không có tỷ lệ, tôi sẽ mong đợi các kết quả sau nếu không có tỷ lệ cửa sổ được đặt đúng chỗ và có độ trễ khoảng 200ms bất kể kích thước ống:

Throughput = Recieve Window/Round Trip Time

Vì thế:

echo $(( 65536/.2 ))
327680 #Bytes/second

Để có được kết quả mà bạn đang thấy, bạn chỉ cần giải quyết độ trễ, đó là:

RTT = RWIN/Throughput

Vì vậy (Đối với 40 kBytes / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Vui lòng kiểm tra Toán của tôi và tất nhiên những điều này không bao gồm tất cả các giao thức / chi phí tiêu đề)

40kbps là rất thấp [đến mức tôi có thể nghi ngờ bộ chuyển đổi phương tiện / lỗi song công bị lỗi [nhưng bạn có gigabit nên không có chỗ cho một nửa song công!] Vv]. phải có tổn thất gói hoặc jitter rất cao liên quan.

iperf là ​​công cụ đầu tiên xuất hiện trong đầu tôi để đo thông lượng có sẵn. chạy ở một bên

iperf -s 

và mặt khác:

iperf -t 60 -c 10.11.12.13

sau đó bạn có thể trao đổi vai trò máy khách / máy chủ, sử dụng -d cho song công, v.v. chạy mtr giữa cả hai máy trước khi bắt đầu thử nghiệm và xem độ trễ / mất gói nào bạn có trên liên kết không sử dụng và cách chúng thay đổi trong quá trình truyền dữ liệu.

bạn muốn thấy: jitter rất nhỏ và không mất gói cho đến khi liên kết được bão hòa ở mức 90 phần trăm dung lượng của nó.

iperf cho * nix và giành chiến thắng , đọc ở đây và ở đây về nó.

mtr cho * nix và giành chiến thắng .

tracepath có thể hiển thị cho bạn các vấn đề định tuyến giữa hai trang web.

iperf, ttcp và bwping có thể cung cấp cho bạn thông tin hữu ích.

Bạn có biết làm thế nào liên kết 1GB này được cung cấp? bạn đang bắc cầu hoặc định tuyến qua liên kết này? SLA của bạn cho liên kết là gì? bạn có thể được định hình bởi nhà cung cấp liên kết của bạn?

nếu bạn chỉ nhận được 40kbs, thì có một vấn đề nghiêm trọng, bạn có chắc chắn rằng đó không phải là liên kết 1MB thay vì liên kết 1GB / s. Bạn có thể thấy rằng tốc độ của liên kết không như bạn nghĩ :-)

RFC 2544 hoặc Y.156sam

Đây là các thử nghiệm mạng được thực hiện để chứng minh SLA bởi nhà mạng. IPERF và tương tự không phải là phương pháp kiểm tra mạng có thể kiểm chứng.