Bài 23: High Availability cơ bản
Bài này chi tiết hóa High Availability theo hướng dễ hiểu, có lệnh thực hành, tình huống production, checklist và bài tập.
- Hiểu High Availability dùng để giải quyết vấn đề gì trong production.
- Nắm các lệnh/cấu hình quan trọng.
- Biết quy trình thực hành từng bước trong lab.
- Có checklist kiểm tra trước khi áp dụng production.
Chốt ý nhanh
| Chủ đề | Điểm cần nhớ |
|---|---|
| High Availability | Không bảo đảm “không bao giờ down”, mà giảm điểm chết đơn lẻ và rút ngắn thời gian gián đoạn. |
| Tư duy nền | Muốn HA phải hiểu thành phần nào đang là single point of failure. |
| Trade-off | HA luôn đi kèm chi phí, độ phức tạp và yêu cầu vận hành cao hơn. |
1. Bối cảnh thực tế
High availability không phải kiến thức lý thuyết riêng lẻ. Trong vận hành production, nó giúp giảm downtime, giảm rủi ro bảo mật và giúp hệ thống dễ khôi phục hơn khi có sự cố.
2. Các khái niệm cần nắm
- Trạng thái hiện tại: trước khi sửa phải biết hệ thống đang chạy thế nào.
- Thay đổi nhỏ: thay đổi từng bước để dễ rollback.
- Log/metric: dùng để xác nhận thay đổi đúng hay sai.
- Rollback: luôn có đường quay lại khi cấu hình lỗi.
3. Lab thực hành
curl -I http://app1/health curl -I http://app2/health systemctl status nginx systemctl status haproxy || true systemctl status keepalived || true journalctl -u haproxy --since "1 hour ago" || true
Khi thực hành, anh nên ghi lại output trước và sau. Đây là thói quen rất quan trọng của SysAdmin/DevOps.
4. Tình huống thực tế
Một web server duy nhất là single point of failure. Anh cần hiểu load balancer, health check, nhiều app node, backup database và kế hoạch failover.
5. Quy trình triển khai an toàn
- Xác định mục tiêu thay đổi.
- Backup file cấu hình hoặc tạo snapshot nếu thay đổi rủi ro.
- Kiểm tra trạng thái hiện tại bằng lệnh phù hợp.
- Thay đổi trên lab/staging trước nếu có.
- Áp dụng production trong khung giờ phù hợp.
- Kiểm tra log, service, port, endpoint sau thay đổi.
- Ghi lại thay đổi và phương án rollback.
6. Lỗi thường gặp
- Làm trực tiếp production mà không backup.
- Sửa nhiều thứ cùng lúc nên không biết lỗi do đâu.
- Không đọc log sau khi reload/restart service.
- Không ghi lại command đã chạy.
7. Checklist
- Đã kiểm tra trạng thái hiện tại.
- Đã backup cấu hình/dữ liệu liên quan.
- Đã test syntax/config nếu có.
- Đã xác nhận service hoạt động sau thay đổi.
- Đã ghi lại thay đổi vào tài liệu vận hành.
8. Bài tập
- Dựng lab nhỏ cho chủ đề này.
- Chạy toàn bộ lệnh kiểm tra.
- Tạo một lỗi nhỏ có kiểm soát và sửa lại.
- Viết checklist 5 bước dùng cho production.
Phần thực hành mở rộng: nhìn hệ thống dưới góc single point of failure
Nhiều người nghe High Availability và nghĩ ngay đến cluster phức tạp. Nhưng bước đầu quan trọng hơn là học cách chỉ ra chỗ nào đang là điểm chết đơn lẻ trong một hệ thống nhỏ.
Lab 1: Vẽ sơ đồ thành phần tối thiểu của một web stack
- DNS
- load balancer hoặc reverse proxy
- web/app server
- database
- storage hoặc backup
Với từng thành phần, tự hỏi: nếu nó chết thì toàn hệ thống còn chạy được không?
Lab 2: Xác định single point of failure trên lab nhỏ
Ví dụ một web app 1 VM + 1 DB cùng máy:
- máy chủ là SPOF
- ổ đĩa local là SPOF
- IP public duy nhất cũng có thể là SPOF
Mục tiêu không phải sửa ngay tất cả, mà là nhìn ra rủi ro thật.
Lab 3: Mô phỏng health check đơn giản
curl -f http://127.0.0.1/health || echo 'backend unhealthy'
ss -tulpn | grep -E ':80|:443|:3306|:5432'
systemctl status nginxHA không thể tách rời monitoring và health check. Muốn failover, trước tiên phải biết lúc nào một node/service được coi là hỏng.
Lab 4: So sánh active-passive và active-active
Tự viết ngắn cho mỗi mô hình:
- chi phí
- độ phức tạp
- khả năng failover
- phù hợp với hệ thống nào
Đây là cách tốt để tránh học HA như tập hợp buzzword.
Lab 5: Viết checklist tối thiểu để nâng một service từ “1 máy” lên “ít rủi ro hơn”
- có backup và restore test
- có monitoring/alert
- có cấu hình lưu trong Git
- có cách dựng lại node mới
- có tách dữ liệu khỏi compute nếu phù hợp
Tình huống thực tế
Một hệ thống có hai web server nhưng chỉ một database local vẫn chưa thật sự HA ở lớp dữ liệu. Nhiều đội tưởng mình đã an toàn hơn chỉ vì có thêm node web, nhưng điểm chết thật lại nằm chỗ khác.
Lỗi phổ biến
- Đầu tư HA ở lớp không phải điểm nghẽn chính.
- Không test failover thật.
- Nhầm HA với backup/DR.
- Tăng độ phức tạp vượt khả năng vận hành của đội.
Kết bài
Sau bài này, anh sẽ có tư duy đúng hơn về High Availability: không màu mè, không thần thánh hóa, mà bắt đầu từ việc nhìn ra điểm chết đơn lẻ và giảm chúng có chọn lọc. Bài tiếp theo sẽ chuyển sang storage — nơi dữ liệu sống, và cũng là nơi rất nhiều quyết định kiến trúc production bắt đầu.
