OpenStack Gazpacho: live migration song song, Watcher và nâng cấp SLURP

Người vận hành vSphere khi xem OpenStack thường hỏi ba câu: có vMotion không, có DRS không, và nâng cấp có làm chết cụm không. OpenStack 2026.1 Gazpacho, phát hành ngày 1/4/2026, trả lời được một phần của cả ba, nhưng mỗi phần kèm điều kiện. Bài này đọc release note của Nova, Watcher, Neutron và Ironic dưới góc nhìn đó: cái gì mới, cái gì vẫn “khác cách làm” so với vSphere, và vì sao SLURP làm nâng cấp bớt đáng sợ mà không miễn việc đọc deprecation note.

Gazpacho ở đâu trong lịch phát hành

Theo trang phát hành chính thức, 2026.1 Gazpacho ra ngày 1/4/2026. Thông cáo trên openstack.org gọi đây là bản thứ 33, với khoảng 500 người đóng góp từ 100 tổ chức và gần 9.000 thay đổi. Phiên bản từng dịch vụ: Nova 33.0.0, Neutron 28.0.0, Watcher 16.0.0, Masakari 21.0.0, Ironic 35.0.0. Thông cáo cũng nói thẳng ai đứng sau yêu cầu cho một tính năng: live migration song song trong Nova là thứ “được các nhà vận hành đang tìm lựa chọn thay thế VMware yêu cầu nhiều”.

SLURP: nâng cấp mỗi năm một lần, với điều kiện

OpenStack phát hành hai bản mỗi năm. Từ 2023.1 Antelope, cứ cách một bản lại có một bản được đánh dấu SLURP (Skip Level Upgrade Release Process). Theo Project Team Guide: nâng cấp được hỗ trợ giữa hai bản kề nhau và giữa hai bản SLURP liên tiếp; nâng từ bản không SLURP sang bản không SLURP, hoặc nhảy quá một chu kỳ SLURP, thì không được kiểm thử. Việc đánh dấu deprecated và gỡ bỏ chỉ diễn ra ở bản SLURP, để ai bỏ qua bản không SLURP cũng không bỏ sót thay đổi bắt buộc nào. Cơ chế này cũng “không nhất thiết yêu cầu live hay rolling upgrade”.

Bản	Ngày phát hành	SLURP	Nâng thẳng từ bản SLURP trước
2023.1 Antelope	22/3/2023	Có, bản đầu tiên
2023.2 Bobcat	4/10/2023	Không
2024.1 Caracal	3/4/2024	Có	Antelope
2024.2 Dalmatian	2/10/2024	Không
2025.1 Epoxy	2/4/2025	Có	Caracal
2025.2 Flamingo	1/10/2025	Không
2026.1 Gazpacho	1/4/2026	Có	Epoxy
2026.2 Hibiscus	dự kiến 30/9/2026	Không, theo quy tắc xen kẽ

Nghĩa thực tế: cụm ở Epoxy nâng thẳng lên Gazpacho, bỏ qua Flamingo. Cụm ở Caracal phải qua Epoxy trước, vì từ Caracal lên Gazpacho là hai chu kỳ SLURP, vượt mức được kiểm thử. Bản kế tiếp, 2026.2 Hibiscus, theo lịch dự kiến trên trang lịch phát hành là ngày 30/9/2026; ai theo nhịp một năm thì bỏ qua bản này.

Lưu ý SLURP đảm bảo đường nâng cấp được kiểm thử, không đảm bảo không có thay đổi. Mọi thay đổi bắt buộc đều dồn vào bản SLURP, nên release note của bản SLURP là bản phải đọc kỹ nhất.

Nova: “song song” là nhiều kết nối cho một VM, không phải nhiều VM

Theo release note Nova 33.0.0, parallel live migration nghĩa là driver libvirt mở nhiều kết nối để truyền bộ nhớ của một VM. Bật bằng [libvirt] live_migration_parallel_connections lớn hơn 1; mặc định tắt. Giới hạn ghi rõ: QEMU trước 10.1.0 không hỗ trợ multifd cùng với post-copy, nên Nova không cho bật đồng thời hai thứ này trên QEMU cũ.

Số VM rời một host cùng lúc là chuyện khác, và Gazpacho không nới. [DEFAULT] max_concurrent_live_migrations vẫn mặc định 1, để tránh các migration đi ra làm quá tải host hoặc mạng. Release note đánh dấu deprecated giá trị 0 (không giới hạn), nói rằng đổi mặc định 1 “gần như luôn là ý tồi”, và “nếu cần live migration nhanh hơn, dùng live_migration_parallel_connections”. Vậy khi đưa một host có 40 VM vào bảo trì, điều thay đổi là mỗi VM có thể truyền RAM nhanh hơn, còn 40 VM vẫn đi lần lượt.

Điều kiện để chỉ truyền RAM: theo tài liệu Nova, live migration trên storage chung và live migration của VM boot từ volume “không sao chép đĩa”, còn block migration thì có. Với đĩa VM trên Ceph RBD, mỗi lần di chuyển chỉ là RAM và trạng thái thiết bị, giống vMotion trên storage chung. Với cụm nhiều cell, VM chỉ live migrate trong cùng cell; nếu bạn tách datacenter theo cell như bài Nova Cells, cửa sổ bảo trì tính theo từng cell.

vTPM: VM Windows đi theo được, nhưng phải đổi flavor

Nova 33.0.0 hỗ trợ live migration cho VM có vTPM khi dùng chế độ secret host: khóa TPM lưu trong libvirt và chuyển qua RPC sang host đích. Chọn qua extra spec hw:tpm_secret_security=host; compute host khai báo chế độ cho phép bằng [libvirt]supported_tpm_secret_security. Hai giới hạn: chế độ cũ user chưa hỗ trợ live migration; VM có vTPM từ trước phải resize sang flavor mới, và thao tác này do chủ VM làm vì secret trong Barbican thuộc về họ, trừ khi admin được cấp ACL. VM Windows có vTPM mang từ vSphere sang cần được lập danh sách trước.

Watcher: cân bằng tải theo chiến lược, và cần người duyệt

Trang thoát VMware của CloudMaster xếp cặp “DRS” và “Watcher + lập lịch Nova” vào nhóm “khác cách làm”, và Gazpacho không thay đổi cách xếp đó. Theo tài liệu Watcher, một audit là một yêu cầu tối ưu cụm (“request for optimizing a Cluster”), gắn với một goal như workload_balancing và một strategy, tức “thuật toán tìm lời giải cho goal đó”. Decision engine chạy strategy và xếp các action thành action plan ở trạng thái RECOMMENDED; applier thực thi bằng cách gọi API các dịch vụ khác, như Nova. Audit có kiểu ONESHOT chạy một lần, hoặc CONTINUOUS tạo action plan theo chu kỳ tính bằng giây hoặc theo cron, khuyến nghị tối thiểu 60 giây. Action plan không tự chạy: phải bật auto-trigger “nếu muốn tự động áp dụng”, mặc định trong ví dụ của tài liệu là False.

Chiến lược gần DRS nhất là Workload Balance Migration: tạo action di chuyển “mỗi khi CPU hoặc RAM của một server vượt ngưỡng chỉ định”, mặc định 25,0%, “chỉ lập kế hoạch cho một VM mỗi lần”, cần ceilometer-agent-compute trên mỗi compute node, và “giả định live migration là khả thi”.

Tình huống	DRS trên vSphere	Watcher và nova-scheduler
Đặt VM mới	Initial placement tự động ở mức Partially và Fully Automated	nova-scheduler chọn host lúc tạo VM; Watcher không tham gia
Host quá tải	Đánh giá mỗi 5 phút theo mặc định; mức Fully Automated tự vMotion	Continuous audit theo chu kỳ bạn đặt, mỗi lần một VM, action plan chờ duyệt trừ khi bật auto-trigger
Đưa host vào bảo trì	Fully Automated: VM tự rời host khi vào maintenance mode; Manual hoặc Partially: phải Apply Recommendations	Chiến lược Host Maintenance (goal cluster_maintaining), audit ONESHOT với maintenance_node; hoặc openstack server migrate --live-migration theo runbook
Độ “hăng” của cân bằng	Thanh trượt từ Most Conservative tới Most Aggressive	threshold, metrics của strategy và chu kỳ audit

Điểm mới của Watcher 16.0.0, theo release note: bầu leader để chạy được nhiều decision engine; datasource Prometheus bị đánh dấu deprecated và thay bằng aetos; Monasca bị gỡ. Về “cross-zone migration” trong thông cáo: “zone” của chiến lược Zone Migration (goal hardware_maintenance) là “một tập compute node và storage pool do người dùng định nghĩa”, không phải availability zone; cùng trang ghi “di chuyển qua availability zone thật chưa được kiểm thử đầy đủ”. Nếu bạn chờ một nút “chuyển cả AZ” thì chưa có.

Giới hạn Watcher chỉ tốt bằng số liệu nó nhận: Workload Balance cần Ceilometer trên từng compute node. Cụm chưa có pipeline telemetry thì việc đầu tiên không phải cài Watcher.

Tóm lại, Watcher ít tự động hơn DRS: dịch vụ riêng, chạy theo chiến lược bạn chọn, mặc định dừng ở bước đề xuất. Với nhiều đội vận hành, đó lại là điều họ muốn: đọc được action plan trước khi cho chạy.

Neutron và Ironic: hai đoạn ngắn

Neutron 28.0.0. Thông cáo liệt kê “hỗ trợ BGP” trong nhóm cải tiến của driver OVN. Release note Neutron 28.0.0 mà chúng tôi đọc không có mục tính năng nào về BGP; các mục OVN trong đó là [ovn]ha_failover_strategy chỉnh BFD, định tuyến North/South cho external port, allowed address pair với MAC ảo (cần OVN v26.03), và gỡ hỗ trợ OVN dưới 20.03.0. Đường BGP kiểm chứng được trong Gazpacho vẫn là hai dự án đi kèm: ovn-bgp-agent 6.0.0, “cho phép công bố VM/container qua BGP trên OVN” với VM có floating IP hoặc trên provider network, và neutron-dynamic-routing 28.0.0. Ai cần: datacenter nhiều rack muốn mỗi rack là một miền L3, công bố địa chỉ VM bằng BGP thay vì kéo VLAN qua các rack. Cụm một hai rack đã có VLAN thì chưa cần. Phần nền có trong bài OVN và Neutron.

Ironic 35.0.0. Deploy interface autodetect chọn deploy interface cụ thể theo metadata của image và cấu hình node; bật mặc định, thứ tự ưu tiên lấy từ autodetect_deploy_interfaces, mặc định ['ramdisk', 'bootc', 'direct']. Virtual media qua Redfish có thêm NFS và CIFS/SMB, driver tự dò giao thức BMC hỗ trợ; cấu hình trong nhóm [nfs] hoặc [cifs], ghi đè theo node bằng driver_info[vmedia_transport_protocol]. Ironic không chạy hay quản lý dịch vụ NFS/CIFS: bạn tự dựng share và bảo đảm BMC với tới được. Ai cần: đội đưa node bare metal cho GPU hoặc database vào cùng cụm. Chỉ chạy VM thì không ảnh hưởng.

Nâng cấp lên Gazpacho trong thực tế

SLURP cho bạn đường nâng cấp được kiểm thử từ Epoxy; phần còn lại vẫn là quy trình: control plane trước, compute node theo lô sau, API cũ và mới chạy song song đủ lâu để kiểm tra, và cửa sổ quay lui. Các upgrade note sau hay bị bỏ sót khi chỉ tin vào chữ SLURP:

• Nova: [DEFAULT]/graceful_shutdown_timeout mặc định đổi từ 60 lên 180 giây; TimeoutStopSec của systemd phải đặt ít nhất 180 giây. Hai script nova-api-wsgi và nova-metadata-wsgi bị gỡ.
• Neutron: script WSGI neutron-api bị gỡ, cấu hình phải trỏ sang neutron.wsgi.api.
• Ironic: 35.0.0 bắt buộc database dùng bộ mã ký tự UTF8MB4, cần MySQL 8.0 hoặc MariaDB 10.3 trở lên. Migration khóa từng bảng trong lúc ALTER TABLE; release note yêu cầu lên kế hoạch downtime và chạy thử trên bản sao dữ liệu production.
• Watcher: mặc định watcher_datasources đổi sang aetos; Monasca bị gỡ.

Giới hạn của bài Mọi nhận định trên lấy từ release note và tài liệu chính thức của từng dự án, không từ một đợt nâng cấp hay đo đạc trên cụm cụ thể. Tốc độ live migration với nhiều kết nối, thời gian khóa bảng của Ironic và hành vi của Watcher ở chế độ continuous là ba thứ bạn phải đo trên staging của mình.

Việc cần làm nếu bạn đang ở Epoxy hoặc Caracal

1. Ghi lại phiên bản từng dịch vụ và QEMU, libvirt trên compute node. Nếu đang ở Caracal, lên kế hoạch hai lần nâng cấp qua Epoxy.
2. Đọc Upgrade Notes và Deprecation Notes của Nova 33.0.0, Neutron 28.0.0, Ironic 35.0.0, Watcher 16.0.0; đối chiếu với unit systemd và cấu hình WSGI đang dùng.
3. Dựng staging với bản sao database production, nâng cấp thật, đo thời gian migration của Ironic và kiểm tra API từng dịch vụ.
4. Liệt kê VM có vTPM, tạo flavor với hw:tpm_secret_security=host, lên lịch để chủ VM resize.
5. Trên hai compute node staging, bật live_migration_parallel_connections lớn hơn 1, giữ max_concurrent_live_migrations ở 1, đo thời gian di chuyển một VM có tốc độ ghi bộ nhớ cao.
6. Nếu định dùng Watcher, tạo continuous audit với goal workload_balancing, không bật auto-trigger, đọc các action plan nó đề xuất trước khi cho chạy thật.

Bảng tương đương đầy đủ giữa vSphere và OpenStack, gồm cả cặp vSphere HA và Masakari ở nhóm “cần thiết kế lại”, nằm ở trang giải pháp thoát VMware; ai làm việc nâng cấp này trong từng mô hình vận hành thì xem ba mô hình vận hành.