Doanh nghiệp có hai đường Internet nhưng failover không hoạt động: kiểm tra gì?
Failover cần health check đúng, route/NAT/policy tương thích và DNS/session được xử lý phù hợp. Chỉ cắm hai WAN không bảo đảm đường dự phòng tự chạy.
Failover cần health check đúng, route/NAT/policy tương thích và DNS/session được xử lý phù hợp. Chỉ cắm hai WAN không bảo đảm đường dự phòng tự chạy.
Với môi trường doanh nghiệp, một lỗi nhỏ có thể ảnh hưởng nhiều người nếu xử lý vội. Bài viết này đưa ra quy trình thực tế để khoanh vùng nguyên nhân, kiểm tra kết quả và biết khi nào nên chuyển cho kỹ thuật viên chuyên trách.
Cách xử lý nhanh
Failover cần health check đúng, route/NAT/policy tương thích và DNS/session được xử lý phù hợp. Chỉ cắm hai WAN không bảo đảm đường dự phòng tự chạy.
Dấu hiệu và nguyên nhân thường gặp
Trước khi thay đổi cấu hình, hãy xác nhận phạm vi ảnh hưởng: chỉ một người dùng, một thiết bị hay nhiều thiết bị cùng gặp lỗi. Phạm vi ảnh hưởng là dữ kiện quan trọng để biết nên bắt đầu ở endpoint hay hạ tầng dùng chung.
- health check chỉ ping gateway ISP nên không phát hiện mất Internet phía ngoài
- policy route/NAT chỉ áp dụng WAN chính
- session cũ hoặc DNS khiến người dùng tưởng failover thất bại
Quy trình kiểm tra từng bước
Bước 1: Xem trạng thái health check khi giả lập rút WAN chính
Trong thực tế hỗ trợ doanh nghiệp, xem trạng thái health check khi giả lập rút WAN chính. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.
Bước 2: Kiểm tra default route/SD-WAN/policy route và NAT cho WAN phụ
Ở bước này, kiểm tra default route/SD-WAN/policy route và NAT cho WAN phụ. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.
Bước 3: Test truy cập bằng phiên mới và nhiều loại dịch vụ
Về mặt kỹ thuật, test truy cập bằng phiên mới và nhiều loại dịch vụ. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.
Bước 4: Xác định yêu cầu failback và thời gian hội tụ chấp nhận được
Khi kiểm tra tại hiện trường, xác định yêu cầu failback và thời gian hội tụ chấp nhận được. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.
Cách xác nhận đã xử lý đúng
Không nên kết luận chỉ vì lỗi tạm thời biến mất. Với hệ thống doanh nghiệp, cần có tiêu chí xác nhận để tránh lỗi quay lại sau vài giờ hoặc sau khi người dùng đổi mạng/khởi động lại thiết bị.
- mất WAN chính thì phiên mới đi được WAN phụ
- WAN chính phục hồi không gây flap liên tục
Những việc không nên làm
- test failover giữa giờ làm việc mà không thông báo
- chỉ dùng một địa chỉ ping duy nhất làm health check
Khi nào nên chuyển cho IT chuyên trách?
Nếu lỗi ảnh hưởng nhiều người, liên quan quyền quản trị, dữ liệu, bảo mật, firewall, server hoặc cần thay đổi cấu hình production, nên dừng thử nghiệm ngẫu nhiên và chuyển cho người phụ trách IT. Với hạ tầng mạng LAN/WAN và Wi‑Fi doanh nghiệp, việc có log, ảnh chụp lỗi, thời điểm xảy ra và các bước đã thử sẽ rút ngắn đáng kể thời gian xử lý.
Gợi ý vận hành lâu dài
Sau khi xử lý xong, nên ghi lại nguyên nhân gốc, cấu hình đã thay đổi và biện pháp phòng ngừa. Những sự cố lặp lại nhiều lần thường là tín hiệu cần chuẩn hóa tài liệu, monitoring, patching hoặc thiết kế hệ thống thay vì tiếp tục xử lý từng lần riêng lẻ.
Xem thêm các bài trong Mạng & Wi‑Fi.
Bài viết liên quan
- Internet doanh nghiệp nên dùng IP tĩnh hay IP động?
- UniFi AP đang hoạt động nhưng quên Controller: có thể SSH để adopt sang Controller mới không?
Cần SMNET hỗ trợ?
Nếu doanh nghiệp cần kiểm tra thực tế, chuẩn hóa cấu hình hoặc vận hành lâu dài, tham khảo Hạ tầng mạng & Wi‑Fi doanh nghiệp.