Thông báo AWS Health nói rằng một đường hầm đang down thường đến khi không có gì trông như hỏng. Chính vì thế nó bị bỏ qua. Thông báo không mô tả sự cố; nó mô tả một trạng thái dự phòng đã kéo dài quá cửa sổ quan sát của AWS. Việc bạn có hành động hay không phụ thuộc vào điều thiết kế của bạn chịu được, không phụ thuộc vào cảm giác của bảng điều khiển.

Thông báo thực sự đo cái gì

Mỗi kết nối Site-to-Site có hai đường hầm, kết thúc tại các điểm cuối AWS khác nhau. Tài liệu giám sát của AWS khuyến nghị cấu hình cả hai để dự phòng và nâng thông báo khi một đường hầm nằm down trong khoảng thời gian đã ghi nhận. Khoảng thời gian đó quan trọng, vì một dao động ngắn và một mất mát vĩnh viễn trông giống hệt nhau trên một biểu đồ.

Đọc dữ liệu đo từ xa theo từng đường hầm thay vì trạng thái tổng thể của kết nối. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' trả về trạng thái và thông điệp cho từng đường hầm, và đó là bằng chứng mà thông báo dựa vào.

Ba điều kiện quyết định phản ứng của bạn

Xem xét cả ba trước khi quyết định đây là một phiếu hay một cái nhún vai.

Thứ nhất, đường hầm còn lại có gánh được tải không, kể cả mọi giới hạn băng thông và các tiền tố mà nó quảng bá? Thứ hai, chuyển đổi có thực sự xảy ra không, khi đường hầm thứ hai down từ lúc tạo chưa từng được chứng minh là lên lại? Thứ ba, thay đổi theo kế hoạch tiếp theo của bạn có làm cả hai đường hầm down cùng lúc không, điều đó biến một cảnh báo hình thức thành vấn đề cửa sổ bảo trì. Nếu bất kỳ câu trả lời nào là không hoặc không rõ, thông báo là một phát hiện thực sự.

Nếu cả ba đều được chứng minh là ổn, hãy ghi lại vì sao có thể chấp nhận và tiếp tục. Ghi chú đó đáng giá hơn cuộc tranh luận quý sau.

Điều mà peer dự phòng không chứng minh

Một cổng khách hàng có peer dự phòng đã cấu hình không phải bằng chứng rằng AWS thấy hai đường hầm khỏe mạnh. Phía khách hàng có thể giữ một peer nguội cần đàm phán mới, và đó có thể là thiết kế hợp lệ. Tuy vậy đó vẫn không phải quan sát giống hai đường hầm đang sống.

Hai router vật lý cũng không sửa được trường hợp ngược lại. Khi cả hai đường hầm kết thúc trên một thiết bị hoặc đi ra qua một đường lên duy nhất, dự phòng chỉ tồn tại trên giấy.

Gắn thay đổi với bán kính ảnh hưởng của nó

Tài liệu tài liệu thay thế điểm cuối của AWS tách các trường hợp, và sự khác biệt rất dễ bị bỏ qua. Các bản cập nhật do AWS quản lý được áp dụng cho từng đường hầm một. Các thay đổi do khách hàng khởi tạo trên cổng đích, cổng khách hàng hoặc các tùy chọn kết nối làm cả hai đường hầm không khả dụng trong khi các điểm cuối thay thế được chuẩn bị.

Thay đổi tùy chọn trên một đường hầm là trường hợp thứ ba với tác động riêng đã nêu: đường hầm đó không khả dụng trong lần cập nhật của chính nó và đường còn lại vẫn chạy.

Chứng minh phương án thay thế trước khi cần đến nó

Lên lịch kiểm thử thay vì chờ sự kiện. Hạ đường hầm khỏe mạnh xuống trong một cửa sổ bảo trì, xác nhận phương án thay thế đàm phán, rồi xác nhận lưu lượng thật đi qua nó theo cả hai chiều. Kiểm tra định tuyến quay về cùng với trạng thái đường hầm, vì sự không khớp ở giai đoạn hai để đường hầm ở trạng thái lên và khối lượng công việc chết. Đo thời gian chuyển đổi khi bạn ở đó.

Giữ thông báo, đầu ra dữ liệu đo từ xa và kế hoạch thay đổi trong một bản ghi. Bản ghi đó biến thông báo quý sau thành một buổi xem xét hai phút thay vì một cuộc tranh luận về việc liệu có ai từng kiểm thử bản dự phòng hay chưa.

Bài viết liên quan