Giải thích tải máy chủ VPN: người dùng, CPU hay đường lên?

Một cổng kết nối ở mức tải 0.4 vẫn có thể bò chậm với mọi người dùng phía sau nó. Tải trung bình đếm các tác vụ có thể chạy được hoặc bị kẹt trong trạng thái ngủ không thể ngắt, và trên máy chủ bốn lõi, một tiến trình bão hòa là đủ để đẩy nó về gần 1.0 trong khi ba lõi ngồi không. Đọc con số đó như phần dư thừa là sai lầm phổ biến nhất khi chọn điểm cuối. Thứ thực sự giới hạn một đường hầm thường là một trong bốn điều: một lõi bận, đường lên, hàng đợi trước nó hoặc một chính sách theo phiên mà không ai ghi lại.

Tải trung bình đếm tác vụ, không phải thông lượng

Nhân hệ điều hành lấy mẫu hàng đợi chạy và số tác vụ đang chờ vào ra, sau đó làm mượt cả hai trong một, năm và mười lăm phút. Không có gì trong định nghĩa đó nhắc đến byte, gói tin hay đường hầm. Một máy chủ có lưu trữ bị kẹt có thể báo tải cao gần như không có lưu lượng, và một máy chủ đẩy gigabit qua đường dữ liệu của nhân có thể báo mức tải thoải mái.

Vì vậy, tương quan tải với hiệu suất đường hầm đòi hỏi góc nhìn theo từng lõi. Nếu một lõi kín, phần trăm tổng trên bảng điều khiển vẫn trông ổn:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

Lệnh thứ ba là lệnh quan trọng nhất trên máy chủ VPN. Việc xử lý gói trong không gian người dùng ở OpenVPN 2.x phần lớn được tuần tự hóa theo từng tiến trình, nên một luồng bận có thể trở thành mức trần trong khi bảng điều khiển báo còn nhiều dung lượng rảnh. Nếu một luồng giữ phần lớn một lõi trong giai đoạn chậm của bạn, máy chủ không thiếu tài nguyên tổng thể; nó bị giới hạn ở chiều mà tình cờ lại quan trọng.

Cũng để ý thời điểm. Trung bình mười lăm phút che mất đợt bùng nổ đã phá hỏng một cuộc gọi, nên ảnh chụp màn hình lấy sau khi có khiếu nại là bằng chứng yếu. Hãy lấy mẫu trong lúc sự cố, và giữ dấu thời gian cùng với kết quả.

Đường lên và hàng đợi trước nó

Bộ đếm giao diện trả lời câu hỏi về băng thông mà các con số CPU không thể. Chúng cũng tách dung lượng khỏi mất mát, và đó là những hỏng hóc khác nhau với cách khắc phục khác nhau:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Một liên kết gần tốc độ được cấp trong lúc kiểm tra là lời giải thích, và không lượng CPU rảnh nào thay đổi được điều đó. Dòng qdisc bổ sung chi tiết quan trọng cho lưu lượng tương tác: tồn đọng và mất gói cho biết các gói có đang chờ trong hàng đợi trước khi rời đi hay không. Một hàng đợi đầy dưới một lần tải lên lớn tạo ra đúng triệu chứng mà người ta đổ lỗi cho máy chủ từ xa, tức là những cuộc gọi ì ạch trên một kết nối vẫn cho kết quả đo tốt.

Bộ đếm truyền lại bắt được trường hợp gói rời đi nhưng không bao giờ đến nguyên vẹn. Nếu truyền lại tăng trong khoảng thời gian chậm và giao diện còn xa dung lượng, vấn đề nằm ở đường đi chứ không ở máy chủ, và chuyển sang điểm cuối khác trong cùng thành phố sẽ không giúp gì.

Số phiên mô tả nhu cầu, không phải phần dư

Mọi danh bạ công khai đều hiển thị một số người dùng đang kết nối, và gần như không cái nào cho bạn biết những người dùng đó đang làm gì. Hai mươi phiên làm việc tương tác và bốn phiên tải tệp lớn tạo ra tải rất khác nhau trên cùng phần cứng. Mẫu thứ hai vô hình trong số người dùng, và chính nó phá hỏng một buổi tối. Vì vậy, số phiên nên được đọc như một gợi ý về nhu cầu, không bao giờ như một tuyên bố về dung lượng rảnh.

Trên máy chủ bạn kiểm soát, tệp trạng thái cho chiều còn thiếu. OpenVPN ghi ảnh chụp định kỳ bao gồm bộ đếm byte cho từng máy khách, và thế là đủ để xem một phiên có chịu trách nhiệm cho toàn bộ đường lên hay không:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Hai mẫu cách nhau mười giây biến những bộ đếm tích lũy đó thành tốc độ cho từng máy khách. Đó là phép đo mà số người dùng thay thế, và cũng nhờ đó bạn phát hiện rằng một máy khách cấu hình sai đang làm bão hòa liên kết mỗi đêm vào cùng một giờ.

Giới hạn theo phiên ẩn bên trong chính sách

Máy chủ có thể rảnh mà vẫn từ chối cấp băng thông cho bạn. Giới hạn tốc độ, mức trần băng thông theo máy khách và việc định hình lưu lượng thường được áp dụng theo tên chung hoặc theo nhóm, nên hai người dùng trên cùng một cổng có thể nhận kết quả rất khác nhau. Cơ chế không tinh tế, nhưng vô hình từ bên ngoài vì đường hầm vẫn lên bình thường trong cả hai trường hợp.

Tìm định hình trên giao diện đường hầm, không phải trên giao diện vật lý. Kiểm tra xem giới hạn đi theo người dùng, chứng chỉ hay nhóm địa chỉ. Nếu tài khoản thử nghiệm của bạn rơi vào nhóm không có mức trần, bạn sẽ kết luận rằng máy chủ ổn và người dùng phàn nàn mới là người sai. Kết luận đó tệ hơn không có kết luận, vì nó đóng phiếu hỗ trợ.

So sánh hai điểm cuối bằng một tác vụ cố định

Thí nghiệm phía máy khách vẫn đáng để chạy, nhưng chỉ khi các biến được cố định. Dùng cùng thiết bị, cùng mạng truy cập, cùng giao thức và cùng tệp đích, rồi lặp lại với một điểm cuối thứ hai ở khoảng cách tương tự. Bất cứ thứ gì thay đổi giữa các lần chạy, kể cả giờ trong ngày, đều làm nhiễm kết quả.

Ghi lại thất bại cẩn thận như thành công. Một chuỗi trong đó ba điểm cuối hoạt động và một điểm cuối hết thời gian có nhiều thông tin hơn bốn con số tốc độ, vì nó chỉ vào vấn đề đường đi hoặc chính sách chứ không phải dung lượng. Chạy mỗi trường hợp ít nhất hai lần; một mẫu chậm duy nhất không chứng minh được gì trên mạng chia sẻ.

Cuối cùng, hãy giữ những con số bạn thu thập được cùng với tuyên bố mà chúng hỗ trợ. "Điểm cuối này hoàn tất việc truyền trong đúng khoảng thời gian mà điểm kia bị kẹt" là có thể bảo vệ được, còn "điểm cuối này nhanh hơn" mời gọi một cuộc tranh luận mà bạn không thể thắng bằng điểm số trên trang chủ. Hướng dẫn OpenVPN 2.6 ghi lại tệp trạng thái và các tùy chọn định hình nếu bạn cần chỉ thị chính xác cho phía máy chủ.