Proxmox 7. High Availability (HA) và HA Manager trong Proxmox VE

1. Tổng quan​

High Availability (HA) là khả năng để một VM/CT tự động khởi động lại trên node khỏe mạnh khi node đang chạy nó gặp sự cố. Trong Proxmox VE, tính năng này do HA Manager đảm nhiệm - một hệ thống phân tán gồm hai nhóm dịch vụ (CRM và LRM) phối hợp với Corosync và cơ chế watchdog/fencing.
HA của Proxmox có cơ chế restart-on-failure chứ không phải fault tolerance. VM không chạy song song trên hai node. Khi node lỗi, VM bị mất dữ liệu trong khoảng thời gian khởi động lại ở node khác (thường tính bằng phút). Đây là điểm khác biệt so với vSphere FT (chạy bản sao đồng bộ) nhưng tương đương với vSphere HA.
Tài liệu này giải thích kiến trúc HA Manager (CRM/LRM), vòng đời trạng thái của một HA resource, vai trò sống còn của quorum và fencing, khái niệm HA group/priority, cùng các điều kiện tiên quyết để HA hoạt động ổn định.

Mục tiêu của bài này:​

· Hiểu HA Proxmox là restart-on-failure, phân biệt với FT.
· Nắm kiến trúc CRM/LRM và cách chúng phối hợp qua pmxcfs/Corosync.
· Hiểu vòng đời trạng thái HA resource và ý nghĩa từng trạng thái.
· Hiểu vì sao quorum + fencing là điều kiện bắt buộc của HA.
· Biết HA group/priority và các điều kiện tiên quyết để HA tin cậy.

2. Nội dung chính​

2.1 HA giải quyết điều gì ?​

HA tồn tại để giảm thời gian gián đoạn khi phần cứng/node lỗi. Nhưng nó có một vài giới hạn sau đây:
Ba yếu tốt bắt buộc của HA
HA chỉ hoạt động ổn định khi có đủ:

1. Cluster có QUORUM ổn định.
2. FENCING/watchdog để cô lập node lỗi, tránh split-brain
3. STORAGE mà node đích truy cập được (shared như Ceph/NFS hoặc replication ZFS).

Nếu thiếu một trong ba, HA có thể gây ra lỗi hoặc gây hỏng dữ liệu.

2.2 Kiến trúc HA Manager: CRM và LRM​

HA Manager gồm hai loại dịch vụ chạy trên các node của cụm, giao tiếp gián tiếp qua pmxcfs (cluster filesystem) được Corosync đồng bộ:

· CRM master được bầu ra và giữ một "manager lock" trong pmxcfs. Nếu master lỗi, một node khác giành lock và trở thành master mới.
· LRM chỉ hành động khi node có quorum và giành được "agent lock" của mình. Nếu mất quorum thì LRM sẽ không thực hiện thao tác gì (để đảm bảo an toàn).
· Cơ chế lock này chính là nền tảng chống split-brain: chỉ node nào có quorum mới được điều khiển HA resource.

2.3 Vòng đời trạng thái của một HA resource​

Khi đưa một VM/CT vào HA, nó trở thành một "HA resource" với các trạng thái do CRM quản lý. Các trạng thái thường gặp:

Cách thoát trạng thái error​

Khi một HA resource ở trạng thái error, HA sẽ không tự động thao tác tiếp để tránh làm tình hình tệ hơn. Quản trị viên cần xử lý nguyên nhân gây lỗi rồi xóa cờ lỗi (disable rồi enable lại resource hoặc dùng ha-manager để đặt lại trạng thái).

2.4 HA Node Affinity Rules và Priority​

HA Node Affinity Rules xác định nhóm node mà một resource được phép chạy, kèm mức ưu tiên (priority) cho từng node. Đây là cách để xây dựng workload theo yêu cầu của người quản trị:
· priority cao hơn = ưu tiên chạy trên node đó, khi node ưu tiên khỏe trở lại, resource có thể được đưa về (tùy nofailback).
· restricted: nếu bật, resource chỉ được chạy trên các node trong group, không còn node nào trong group thì resource dừng thay vì chạy ở nơi khác.

2.5 Quan hệ với quorum, fencing và storage​

HA không phải một tính năng độc lập, nó hoạt động dựa trên các lớp bên dưới:
1. Quorum (Corosync): CRM/LRM chỉ hành động khi cụm có quorum. Nếu mất quorum, HA sẽ đóng băng để tránh đưa ra quyết định sai. Vì vậy thiết kế quorum (số node lẻ/QDevice) là bước chuẩn bị bắt buộc của HA.
2. Fencing/watchdog: trước khi khởi động lại resource ở node khác, HA phải chắc chắn node cũ đã "chết" (bị reset). Proxmox dùng watchdog: node mất quorum sẽ tự reset sau timeout (self-fencing). Không có fencing sẽ có nguy cơ hai node cùng chạy một VM gây hỏng dữ liệu.
3. Storage: node đích phải truy cập được đĩa của VM. HA hoạt động với shared storage (Ceph/NFS) hoặc với đĩa cục bộ nhưng cần ZFS replication để node đích có bản sao.

Cần lưu ý​

Khi node lỗi, HA chờ một khoảng thời gian để xác nhận (thông qua Corosync), node lỗi tự reset bằng watchdog (thường trong khoảng 60 giây nếu chỉ lỗi reset), rồi CRM mới cho phép khởi động resource ở node khác. Vì vậy thời gian gián đoạn của HA thường trong khoảng vài phút, không phải tức thì.

2.6 Điều kiện tiên quyết và tối ưu nhất cho HA​

· Cụm ổn định, số Quorum lẻ (3 node, hoặc 2 node + QDevice).
· Mạng Corosync độ trễ thấp, tách khỏi backup/migration/storage.
· Storage phù hợp: shared (Ceph/NFS/iSCSI) hoặc ZFS + replication cho đĩa cục bộ.
· Watchdog hoạt động (softdog mặc định hoặc watchdog phần cứng nếu có).
· Chỉ đưa vào HA những workload thực sự cần, đặt HA group/priority theo thiết kế.
· Dùng maintenance mode khi bảo trì để migrate VM đi mà không kích hoạt fencing.
· Luôn có backup độc lập vì HA không thể thay thế backup.

3. Kết luận​

HA Manager giúp dịch vụ tự trở lại sau sự cố node mà không cần người thường trực. Nó hoạt động thông qua bộ đôi CRM (quyết định toàn cục) cùng với LRM (thực thi cục bộ) dựa trên quorum và fencing. Hiểu được cơ chế hoạt động của HA và các yêu cầu cốt lõi sẽ giúp việc vận hành HA trở nên dễ dàng hơn cho người quản trị.