HA thật trên OpenStack: Masakari, live migration và storage chung

Kỹ sư đi từ vSphere hỏi: “OpenStack có HA không, bật ở đâu?” Trưởng hạ tầng đang chạy máy lẻ hỏi: “Server hỏng lúc 2 giờ sáng thì VM có tự chạy lại không, cần gì?” Câu trả lời trung thực cho cả hai: có, ở ba lớp, mỗi lớp có điều kiện riêng, và điều kiện lớn nhất là storage chung. Bài này đi qua ba lớp, giải thích vì sao trang thoát VMware xếp vSphere HA sang Masakari là “cần thiết kế lại”, rồi đưa một kịch bản tắt host trên staging để bạn tự đo.

Ba lớp HA, không lớp nào là một ô tick

Trên vSphere, HA và DRS là hai ô tick ở cấp cluster. Trên OpenStack, HA là ba cơ chế cho ba loại lỗi:

Lớp	Lỗi gì	Cơ chế	Điều kiện	Gần nhất bên vSphere
Control plane	Một controller hỏng	keepalived, HAProxy, Galera, RabbitMQ cluster	Nhiều controller, đủ giữ quorum	vCenter HA
Host compute	Host chết, VM trên đó mất	Masakari gọi Nova evacuate dựng lại VM trên host khác	Storage chung, dư tài nguyên, cluster pacemaker trên compute	vSphere HA
Tiến trình VM	VM dừng hoặc treo, host vẫn sống	instancemonitor (event libvirt), introspectiveinstancemonitor (QEMU guest agent)	Metadata HA_Enabled	VM Monitoring

Live migration không phải HA mà là công cụ bảo trì có kế hoạch, nhưng cần cùng điều kiện storage chung.

Lớp control plane là bài toán HA cổ điển: dịch vụ stateless (các API) chạy nhiều bản sau load balancer; dịch vụ stateful (database, message queue) cần cluster thật: Galera là “cluster multi-master đồng bộ”, RabbitMQ cần ít nhất ba server cho production. Kolla Ansible làm sẵn với keepalived, HAProxy, Galera và quorum queue của RabbitMQ 4.0 trở lên.

Vì sao storage chung là điều kiện

Host chết thì RAM của VM mất, không cứu được. Cái cứu được là đĩa, nếu đĩa không nằm trên host vừa chết.

Nếu đĩa là Cinder volume trên Ceph RBD, hoặc đĩa ephemeral do Nova đặt thẳng trên Ceph, Ceph ghi nó thành nhiều bản sao, mặc định osd_pool_default_size = 3, và với failure domain host thì CRUSH bảo đảm mỗi bản sao nằm trên một host khác nhau. Host compute chết, đĩa vẫn nguyên. Nếu đĩa nằm trên ổ cục bộ, đĩa chết cùng host. Tài liệu Nova nói rõ hậu quả:

• Evacuate dựng lại instance “từ image hoặc volume gốc” và chỉ chạy khi host nguồn đã được xác nhận không hoạt động. Muốn giữ dữ liệu trên đĩa của VM thì host đích phải thấy được cùng storage chung; nếu không, VM lên lại từ image sạch và những gì đã ghi vào đĩa cục bộ không đi theo.
• Live migration với storage chung hoặc volume-backed không chép đĩa, chỉ chuyển RAM. Đĩa cục bộ phải dùng block migration: chép cả đĩa qua mạng, thêm tải lên mạng và storage.

Bài gom máy chủ lẻ thành một cụm đặt Ceph trước Masakari vì lý do này: không có storage chung, cái lên lại sau evacuate là một VM mới với đĩa trống.

Lưu ý Kiểm tra VM còn đĩa ephemeral cục bộ trước khi bật HA. openstack server show cho biết VM boot từ volume hay từ image; với VM boot từ image, backend ephemeral của Nova trên host phải trỏ vào Ceph ([libvirt] images_type = rbd).

Masakari: thành phần và luồng xử lý

Masakari là dự án OpenStack cho HA của instance và tiến trình compute. Trên controller có masakari-api (nhận notification, chuyển cho engine qua RPC) và masakari-engine (chạy recovery workflow, gọi Nova). Trên mỗi compute có masakari-monitors: hostmonitor theo dõi host, processmonitor theo dõi tiến trình như nova-compute, instancemonitor bắt domain event từ libvirt, introspectiveinstancemonitor ping vào guest qua QEMU guest agent.

Luồng cho lỗi host: hostmonitor trên các host còn sống thấy một host mất heartbeat, gửi notification COMPUTE_HOST tới masakari-api; engine chạy workflow mặc định ba bước: disable_compute_service_task (vô hiệu nova-compute của host lỗi), prepare_HA_enabled_instances_task (lập danh sách VM cần cứu), evacuate_instances_task. Với notification PROCESS, engine disable compute node; với VM, engine stop rồi start lại instance và xác nhận trạng thái ACTIVE.

Hostmonitor không tự biết host chết. Theo tài liệu masakari-monitors, hostmonitor dựa vào pacemaker hoặc pacemaker-remote trên các compute node, và lấy trạng thái host từ heartbeat của cluster đó. Mặc định hostmonitor còn kiểm tra IPMI để chắc host đã tắt hẳn (disable_ipmi_check = False) và chờ 30 giây trước khi kích hoạt STONITH (stonith_wait). Bật Masakari nghĩa là vận hành thêm một cluster pacemaker, IPMI và fencing trên compute.

Thời gian cũng không tức thì. Mặc định hostmonitor kiểm tra node mỗi 60 giây (monitoring_interval); engine chờ 180 giây sau khi disable service (wait_period_after_service_update) và 90 giây sau mỗi evacuate (wait_period_after_evacuation). Cộng thêm thời gian dựng lại VM và boot guest, hãy hình dung đơn vị là phút, và đo trên cụm của mình.

Failover segment, recovery_method và VM nào được cứu

Bạn tạo failover segment, nhóm host mà tài liệu API gợi ý “định nghĩa theo ranh giới storage chung”, rồi thêm host bằng openstack segment host create. Mỗi segment có một recovery_method:

recovery_method	Hành vi theo tài liệu	Chọn khi
auto	Evacuate toàn bộ VM, Nova scheduler chọn host đích	Dư tài nguyên rải đều
reserved_host	Evacuate sang host đã đánh dấu reserved trong segment	Cần chắc chỗ: host dự phòng để trống chờ lỗi
auto_priority	Thử auto, thất bại mới dùng reserved_host	Dư thường đủ, host dự phòng là lưới an toàn
rh_priority	Thử reserved_host, thất bại mới dùng auto	Muốn VM lên host dự phòng trước

Với cụm nhỏ, reserved_host dễ giải thích nhất: một host để trống, ai cũng biết VM sẽ lên đó, cái giá là một host không chạy tải. auto tiết kiệm hơn nhưng phải giữ dư N+1 trên toàn segment và kiểm tra định kỳ.

VM nào được cứu do cấu hình và metadata quyết định. Mặc định [host_failure] evacuate_all_instances = True: host lỗi thì mọi VM đều được evacuate; đặt False thì chỉ VM có HA_Enabled=True. Với lỗi tiến trình VM thì ngược lại: mặc định process_all_instances = False, chỉ VM có HA_Enabled=True mới được restart.

Live migration cho bảo trì có kế hoạch

Khi cần vá kernel hay thay RAM, live migration chuyển VM đi trong lúc nó vẫn chạy: chép RAM sang host đích theo từng trang, trang bị ghi sau khi chép phải chép lại; VM ghi RAM nhanh hơn tốc độ chép thì migration không hội tụ. Nova có ba cách xử lý, và cả ba đều phải tự cấu hình: live_migration_completion_timeout, mặc định 800 giây cho mỗi GiB cần chuyển; auto-converge, tắt mặc định, bóp CPU của VM và tài liệu nói rõ “không bảo đảm thành công”; post-copy, tắt mặc định, bật VM ở đích trước khi chép hết RAM, nhưng mạng đứt giữa chừng thì VM bị reboot.

Điều kiện thứ hai sau storage chung là CPU tương thích: host-passthrough chỉ migrate được sang host có CPU giống nguồn gần như tuyệt đối; host-model migrate được nhưng không chắc hai chiều; cụm nhiều đời CPU, như cụm gom từ máy lẻ, nên chọn custom với model của CPU cũ nhất.

Nova mặc định max_concurrent_live_migrations = 1 trên mỗi host, “để migration đi ra không làm quá tải host và mạng”. Từ 2026.1 Gazpacho có thêm [libvirt] live_migration_parallel_connections cho một migration dùng nhiều kết nối song song, mặc định tắt, không bật được cùng post-copy trên QEMU cũ hơn 10.1.0; xem bài Gazpacho có gì mới.

So với vSphere HA và DRS

Trang thoát VMware xếp vSphere HA sang Masakari là “cần thiết kế lại”, vMotion sang live migration là “tương đương”, DRS sang Watcher cộng lập lịch Nova là “khác cách làm”:

vSphere	OpenStack	Nhãn trên site	Vì sao
vSphere HA	Masakari + pacemaker + Nova evacuate	Cần thiết kế lại	Segment, recovery_method, host dự phòng, HA_Enabled, IPMI và fencing đều là quyết định của bạn
vMotion	Live migration	Tương đương	Cùng cơ chế chép RAM, cùng cần shared storage
DRS	Watcher + Nova scheduler	Khác cách làm	Watcher sinh action plan ở trạng thái RECOMMENDED chờ admin duyệt, không tự cân bằng

vSphere HA tiện hơn thật. Theo tài liệu vSphere 8.0, các host tự bầu primary host; primary nhận heartbeat mỗi giây, mất heartbeat thì kiểm tra thêm qua datastore heartbeat và ping để phân biệt host chết với host bị cô lập mạng, rồi mới restart VM trên host khác. Nhưng điều kiện khi tạo cluster vẫn là “mọi VM và file cấu hình nằm trên shared storage”, đúng như OpenStack. DRS mặc định kiểm tra cân bằng mỗi 5 phút với ba mức tự động; Watcher có strategy Workload Balance và audit liên tục, nhưng không phải là một vòng lặp tự cân bằng bật sẵn.

Ba lớp này chỉ cứu được trong phạm vi một cụm. Funtap có DC2 dự phòng nóng nhận bản sao Ceph từ DC1, RPO dưới 5 phút, RTO dưới 15 phút, nhưng việc chuyển sang DC2 là một runbook được diễn tập, không phải việc của Masakari.

Kịch bản tự kiểm chứng: tắt một compute host trên staging

Đừng tin bài này, kể cả phần thời gian. Hãy chạy kịch bản sau trên staging:

1. Segment đã có, host nằm trong đó (openstack segment host list); nếu dùng reserved_host, host dự phòng có reserved = True và đang trống. Phần trống còn lại trong segment đủ chứa VM của host sắp tắt.
2. VM thử có HA_Enabled=True (openstack server set --property HA_Enabled=True), boot từ volume trên Ceph, chạy một vòng lặp ghi date vào file mỗi giây.
3. Bảng mốc để điền: T0 tắt nguồn; T1 notification xuất hiện (openstack notification list); T2 notification sang running; T3 VM thử ACTIVE trên host khác; T4 ứng dụng trong VM trả lời.

Tắt nguồn host bằng IPMI, không shutdown, vì tắt sạch không giống host chết. Quan sát: notification COMPUTE_HOST xuất hiện sau bao lâu; VM thử lên host nào; file ghi thời gian trong VM còn dòng cuối trước T0 không; openstack notification show có lỗi không.

Lặp lại bằng cách rút cáp mạng thay vì tắt nguồn để thử fencing: lúc này host vẫn sống và VM vẫn chạy, nên pacemaker phải STONITH host đó trước khi Masakari evacuate; nếu không, hai bản của cùng một VM có thể cùng ghi vào một volume.

Giới hạn của bài Bài không nêu số đo thời gian phát hiện hay khôi phục, vì chúng phụ thuộc monitoring_interval, cấu hình IPMI và STONITH, các khoảng chờ của engine, số VM trên host lỗi và tốc độ guest boot; giá trị mặc định trong bài lấy từ tài liệu, không từ một lần đo. Driver hostmonitor theo consul và kubernetes, và introspectiveinstancemonitor, bài chỉ dẫn lại tài liệu, chưa chạy.

Việc cần làm trong tuần này

1. Kiểm kê VM theo ba nhóm: cần HA, chỉ cần lên lại trong giờ hành chính, không cần. Chỉ nhóm đầu gắn HA_Enabled.
2. Liệt kê VM còn đĩa cục bộ (boot từ image với images_type khác rbd, hoặc flavor có ephemeral disk) và chuyển sang volume trước khi bật HA.
3. Kiểm tra dư N+1 trên từng nhóm host sẽ thành segment, rồi quyết định auto hay reserved_host.
4. Chốt cpu_mode; nhiều đời CPU thì chọn custom với model cũ nhất và thử live migration hai chiều.
5. Dựng Masakari và pacemaker trên staging, chạy kịch bản trên hai lần, điền bảng mốc, đưa vào runbook kèm người trực.

Bảng tương đương đầy đủ giữa vSphere và OpenStack nằm ở trang thoát VMware, còn câu hỏi “host lỗi lúc 2 giờ sáng thì ai trực” trong từng mô hình vận hành được trả lời ở trang vận hành.