Kiểm thử chuyển đổi dự phòng: luồng TCP đã thiết lập có sống sót?

Hai kết quả ẩn trong câu nói rằng bản dự phòng hoạt động. Một yêu cầu mới thành công, đó là khôi phục. Một quá trình truyền đang chạy tiếp tục, đó là liên tục. Đây là hai lời hứa khác nhau, và hầu hết thiết kế chuyển đổi dự phòng trao lời hứa thứ nhất trong khi lời hứa thứ hai lặng lẽ hết thời gian. Hãy quyết định bạn cần cái nào trước khi chọn cơ chế, và viết bài kiểm thử để nó phân biệt được hai điều đó.

Hai kết quả trông như một thành công duy nhất

Hãy hình dung một máy khách ở 10.90.0.42 có kết nối tới 198.51.100.20:443. Cổng ra chính dịch nó thành một địa chỉ và cổng công cộng, còn cổng ra dự phòng dịch thành địa chỉ khác. Địa chỉ bên trong của máy khách không bao giờ đổi, vì thế người ta mong kết nối sẽ sống sót.

Máy chủ không thấy địa chỉ bên trong. Nó thấy điểm cuối đã dịch, và điểm cuối đó khác đi sau khi chuyển.

Vì vậy luồng cũ hết thời gian trong khi kết nối mới tới cùng dịch vụ hoạt động ngay lập tức. Cả hai quan sát đều đúng cùng lúc.

Máy chủ thấy gì khi cổng ra thay đổi

Kết nối TCP được nhận diện bằng bộ bốn của nó, và việc thay đổi địa chỉ hoặc cổng nguồn tạo ra một kết nối khác theo góc nhìn của máy chủ nhận. Các gói đến từ nguồn mới trên kết nối mà máy chủ không biết sẽ bị bỏ hoặc bị trả lời bằng cách đặt lại. Không có gì trong địa chỉ của máy khách VPN giữ được liên kết qua thay đổi đó.

Chuyển đổi dự phòng có trạng thái tồn tại chính là để tránh điều này, và nó hoạt động bằng cách trao đổi trạng thái dịch và trạng thái kết nối giữa các thiết bị chuyển tiếp. Đó là thuộc tính của cặp thiết bị, không phải của đường hầm, và phải được thiết kế, kiểm thử chứ không phải giả định.

Hãy kiểm tra xem cặp thiết bị có thực sự giữ trạng thái trước khi hứa liên tục với ai. Các lệnh dưới đây cho thấy trạng thái hiện tại ở cả hai phía.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Vì sao cùng một địa chỉ công cộng là không đủ

Giữ một địa chỉ công cộng trên cả hai đường là khởi đầu tốt, vì máy chủ sẽ thấy cùng một điểm cuối nguồn. Tuy nhiên chỉ riêng nó thì chưa đủ. Thiết bị chuyển tiếp vẫn cần trạng thái dịch, trạng thái tường lửa và đường quay về dùng được, và những thứ đó phải tồn tại trên thiết bị mang lưu lượng sau khi chuyển.

RFC 3022 mô tả việc dịch địa chỉ và coi việc trao đổi trạng thái giữa các thiết bị dịch là một phần của thiết kế dự phòng. Địa chỉ trôi nổi hay hồ sơ được sao chép chỉ di chuyển cấu hình mà không di chuyển trạng thái.

Vì thế một bài kiểm thử chỉ ping qua bản dự phòng chứng minh rất ít. Ping không có trạng thái kết nối để mất.

Hãy quyết định yêu cầu mạnh đến đâu

Nếu người dùng có thể kết nối lại sau sự cố, thiết kế là thiết kế khôi phục và bài kiểm thử chấp nhận là một yêu cầu mới. Nếu một quá trình truyền tệp phải sống sót, thiết kế cần đồng bộ trạng thái và một bài kiểm thử cẩn thận hơn nhiều. Nếu một phiên từ xa phải sống sót, yêu cầu còn mạnh hơn và có thể cần cơ chế ở tầng ứng dụng thay vì tầng mạng.

Viết yêu cầu thành một câu với kết quả đo được, chẳng hạn tải lên hoàn tất mà không khởi động lại hoặc người vận hành kết nối lại trong vòng một phút. Sau đó chọn cơ chế rẻ nhất đáp ứng được, và thường đó là thiết kế khôi phục.

Nói rõ điều gì xảy ra khi đường chính trở lại, vì việc quay lại tự động có thể cắt một kết nối vừa mới hồi phục trên bản dự phòng. Trường hợp đó thuộc kế hoạch kiểm thử, không phải chú thích cuối trang.

Kiểm tra luồng cũ và yêu cầu mới

Khởi động một quá trình truyền dài vô hại qua đường chính, sau đó một yêu cầu mới riêng tới cùng dịch vụ. Ghi lại ngữ cảnh ứng dụng, địa chỉ ra quan sát được và thời điểm. Cắt đường chính theo cách đã được phê duyệt và tiếp tục theo dõi quá trình truyền ban đầu trong khi gửi yêu cầu mới qua bản dự phòng.

Báo cáo ba giá trị: luồng cũ tiếp tục, bị đặt lại hay hết thời gian; lần đầu tiên thao tác mới hoạt động là khi nào; và việc quay lại có cắt đứt điều gì không. Ba dòng đó là biên bản chấp nhận.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Nếu khối lượng công việc ghi dữ liệu, đừng lặp lại một thao tác không chắc chắn một cách mù quáng sau khi hết thời gian. Việc ghi có thể đã tới nơi trước khi câu trả lời bị mất. Hãy hỏi ứng dụng kết quả, hoặc chỉ thử lại ở nơi thao tác là idempotent. Sau đó viết tuyên bố chấp nhận thành ba phần: các thao tác mới khôi phục theo chính sách cổng ra, các luồng hiện có có hành vi ngắt được ghi nhận, và ứng dụng tiếp tục an toàn. Tuyên bố đó có thể kiểm chứng và trung thực về điều thiết kế không hứa.