Khởi động lại OpenVPN hằng ngày? Chọn lỗi hỏng, đừng chọn đồng hồ

Bạn thừa hưởng một cron job khởi động lại OpenVPN lúc 04:10 mỗi ngày, và nó đã giữ mọi thứ ổn định suốt một năm. Nhưng nó cũng ngắt một đường hầm khỏe mạnh vào giờ cố định và không làm gì với sự cố thực sự xảy ra vào bữa trưa. Khởi động lại theo lịch là một quyết định bảo trì. Khôi phục là một thiết kế khác với cơ chế kích hoạt cụ thể.

Ba dạng hỏng hóc cần ba người chủ khác nhau. Chọn lỗi hỏng trước, cơ chế sẽ theo sau.

Ba lỗi hỏng, ba người chủ

Đường hầm có thể vẫn hoạt động trong khi peer của nó đã biến mất: tiến trình chạy, giao diện tồn tại, và không có gì hữu ích đi qua. Tiến trình có thể đã chết trong khi peer vẫn ổn, và khi đó chỉ thứ đã khởi chạy nó mới đưa nó trở lại. Ứng dụng phía sau đường hầm có thể hỏng trong khi cả đường hầm lẫn peer đều khỏe, và khởi động lại client khi đó sẽ mở rộng sự cố mà không chạm tới nguyên nhân. Tách ba trường hợp đó chính là toàn bộ quyết định.

Mỗi thứ có tín hiệu riêng và người chủ riêng. Khả năng sống thuộc về giao thức VPN, vòng đời tiến trình thuộc về trình quản lý dịch vụ, và sức khỏe ứng dụng thuộc về giám sát với thẩm quyền hẹp.

Một tùy chọn khả năng sống làm được gì và không làm được gì

keepalive là một trợ giúp mở rộng thành cặp ping và ping-restart, như tài liệu tham chiếu tùy chọn liên kết mô tả, và các thời gian chờ nó tạo ra không giống nhau trên máy chủ và máy khách. Giá trị do máy chủ đẩy xuống cũng có thể ghi đè thứ máy khách đã cấu hình cục bộ, vì vậy một thời gian chờ trông đúng trong tệp cục bộ có thể không phải là cái đang có hiệu lực.

Điều đó khiến nó là công cụ đúng cho một peer bị mất và công cụ sai cho một tiến trình đã chết, vì tiến trình đã thoát không thể chạy bộ hẹn giờ của chính nó. Nó cũng không nói gì về việc ứng dụng phía sau đường hầm có trả lời hay không, bởi trao đổi diễn ra giữa hai điểm cuối VPN. Sao chép một cặp thời gian chờ từ một triển khai khác mà không kiểm tra vai trò, các gián đoạn dự kiến và hành vi xác thực lại chính là cách một đường hầm ổn định bắt đầu rung.

Trình quản lý dịch vụ sở hữu gì

Nếu daemon thoát, trình quản lý đã khởi chạy nó quyết định điều gì xảy ra tiếp theo. Một chính sách khởi động lại dựa trên lỗi hỏng, với độ trễ và giới hạn tốc độ khởi động, xử lý vòng lặp sụp đổ mà không biến nó thành bom fork. Những cài đặt đó phản ứng với kết quả tiến trình và thời gian chờ, và chúng không phát hiện một tiến trình còn sống nhưng vô dụng. Đó không phải là lỗ hổng để vá bằng chính sách rộng hơn; đó là ranh giới giữa vòng đời và khả năng sống.

Quyền sở hữu quan trọng ngang với cài đặt. Một kết nối do trình quản lý mạng trên máy tính khởi chạy nên giữ cách khôi phục của trình quản lý đó, và thêm một service unit cạnh tranh cho cùng giao diện sẽ cho một đường hầm hai người chủ. Chọn một và ghi lại là cái nào.

Khi nào khởi động lại theo lịch là chính đáng

Khởi động lại theo giờ có thể là một hành động bảo trì hợp lý: nó có người chủ, khung giờ, phiên bản có tên và đường vào độc lập. Điều nó không thể là một chính sách độ tin cậy chung đồng thời ngắt kết nối mọi người vào giờ cố định.

Nếu việc khởi động lại tồn tại để lách một rò rỉ đã biết hoặc một trạng thái bị kẹt, hãy nói điều đó trong mô tả của unit, nếu không người tiếp theo sẽ giữ nó mãi mãi.

Hãy thử các trường hợp quan trọng: peer biến mất trong khi tiến trình vẫn chạy, tiến trình thoát, lần thử lại cần thông tin đăng nhập mới, và đường hầm trở lại trong khi ứng dụng vẫn hỏng. Quan sát thành phần nào phản ứng và để lại trạng thái gì.

Câu hỏi đúng không phải là khởi động lại bao lâu một lần, mà là thứ gì nên nhận ra lỗi hỏng trước tiên.