FreeBSD và bhyve sắp có live migration

Một bản WIP RFC (đề xuất đang trong quá trình phát triển, mời góp ý) vừa được công bố, trình bày trạng thái hoạt động đầu tiên của tính năng live migration (di chuyển máy ảo đang chạy) cho các máy khách bhyve trên FreeBSD 15.1. Máy khách amd64 đang chạy có thể được chuyển từ máy chủ này sang máy chủ khác qua TCP mà vẫn tiếp tục hoạt động, chỉ bị tạm dừng ở pha stop-and-copy cuối cùng.

Đây là bước tiến đáng chú ý với cộng đồng FreeBSD: live migration từ lâu được xem là điều kiện gần như bắt buộc để một nền tảng ảo hóa được dùng trong môi trường doanh nghiệp, nơi việc bảo trì máy chủ hay thay thế phần cứng không thể kéo theo gián đoạn dịch vụ.

Cách triển khai hiện tại vận hành

Quá trình migration bắt đầu bằng pha pre-copy. Hệ thống gửi toàn bộ vùng nhớ của máy khách đã được cấp phát, sau đó liên tục lấy bitmap các trang nhớ bị thay đổi kể từ lần quét trước và chỉ gửi những trang đó.

Khi tập trang bẩn còn lại đã nằm trong mức downtime mục tiêu, không giảm thêm hoặc đạt giới hạn số vòng cấu hình, bhyve sẽ tạm dừng máy khách cùng các thiết bị của nó, gửi các trang bẩn cuối cùng và trạng thái snapshot hiện có cho vCPU, kernel và thiết bị mô phỏng.

Máy đích kiểm tra hình học cơ bản của máy ảo, nhận bộ nhớ và trạng thái, khôi phục rồi báo sẵn sàng. Chỉ khi đó máy nguồn mới gửi GO — điểm commit. Trước GO, nếu migration thất bại, máy nguồn có thể tiếp tục chạy máy khách. Máy đích sẽ không khởi động máy khách nếu không nhận được thông điệp commit. Ngoài ra còn có chế độ warm stop-and-copy, hữu ích như phương án dự phòng và làm mốc so sánh.

Minh họa live migration máy ảo bhyve

Những gì đã có trong bản thử nghiệm

• Pre-copy trực tiếp và warm migration: pre-copy có thể cấu hình downtime và số vòng tối đa; migration stop-and-copy tường minh cũng được hỗ trợ.
• Giao thức hỗ trợ nhiều vCPU: bắt tay migration mang theo số vCPU của máy khách, máy đích từ chối nếu số lượng không khớp, toàn bộ vCPU được tạm dừng và phục hồi trong quá trình migration. Tuy nhiên môi trường thử nghiệm công bố chủ yếu mới chạy máy khách một vCPU, nên vẫn cần kiểm thử stress và race với nhiều vCPU trước khi đưa ra tuyên bố rộng hơn.
• Kiểm tra tính nhất quán bộ nhớ: theo dõi trang bẩn bao phủ cả ghi của máy khách lẫn ghi mô phỏng có ánh xạ thông qua trạng thái bẩn của trang, còn các write hold của vmm được ghi nhận riêng. Khối lượng công việc kiểm thử ghi lại và xác minh bộ nhớ máy khách, báo lỗi nếu có trang bị thiếu hoặc cũ.
• Kiểm tra ghi đĩa: một workload phía máy khách liên tục ghi và fsync tệp, kiểm tra checksum, rồi kiểm tra lại sau khi khởi động nguội.
• Xử lý lỗi: đã thử với trường hợp máy đích từ chối, đích không thể kết nối, và đích biến mất trong cả hai pha pre-copy lẫn stop-and-copy.
• Phạm vi hỗ trợ: chỉ áp dụng cho amd64, phụ thuộc vào tính năng thử nghiệm BHYVE_SNAPSHOT, và cần các thiết bị mô phỏng có khả năng snapshot. Hiện PCI passthrough chưa thể migrate.

Kết quả quan sát được

Trong môi trường thử nghiệm hai máy chủ hiện tại, các đợt live migration lặp lại, workload ghi lại bộ nhớ và workload đĩa nhiều fsync đều hoàn tất thành công. Với máy khách 512 MiB ghi chậm, downtime quan sát được khoảng 138–171 ms. Máy khách ghi nhanh có thể không hội tụ trong pha pre-copy, nhưng vẫn rơi về stop-and-copy đúng đắn với thời gian tạm dừng lâu hơn.

Tác giả nhấn mạnh đây là kết quả kỹ thuật đáng khích lệ, chứ không phải cam kết hỗ trợ production hay bằng chứng đầy đủ về tính đúng đắn.

Những rào cản trước khi có thể đưa vào upstream

Trước khi việc đưa code vào FreeBSD chính thức được xem xét một cách có trách nhiệm, một loạt yêu cầu kỹ thuật cần được giải quyết:

• Chứng minh và gia cố tính đúng của dirty log: thuật toán theo dõi trang bẩn phía kernel phải chứng minh không làm mất một lệnh ghi nào trong lúc kiểm tra và xóa bit bẩn, kèm lập luận về locking và memory ordering có thể review được.
• Định nghĩa hợp đồng tương thích đầy đủ: không chỉ khớp dung lượng bộ nhớ và số vCPU, mà còn phải xác minh danh tính máy khách, khả năng CPU, tương thích bhyve/vmm và định dạng snapshot, cấu trúc thiết bị, và danh tính lưu trữ chia sẻ.
• Gia cố transport và giao thức: TCP hiện tại không có xác thực hay mã hóa và dùng giao thức phiên bản đầu tiên. Một giao thức ổn định cần định dạng wire tường minh, xử lý thông điệp có giới hạn, timeout, thương lượng phiên bản, xác thực hoặc mô hình transport bảo mật bên ngoài được hỗ trợ.
• Làm rõ ranh giới commit và hiệu ứng phía thiết bị: việc bàn giao nguồn/đích phải được review để khôi phục thiết bị không gây ra công việc nhìn thấy từ bên ngoài trước khi nguồn commit, và để tình huống không chắc chắn sau khi mất ack post-commit có thể phục hồi được về mặt vận hành.
• Quy định bàn giao lưu trữ và mạng: lưu trữ chia sẻ cần định nghĩa rõ tính nhất quán, độ bền và giả định fencing. Migration mạng cần câu trả lời rõ cho xử lý tap/bridge, di chuyển MAC/IP và hội tụ lưu lượng.
• Xây dựng chiến lược kiểm thử trong cây nguồn: các script hiện tại hữu ích, nhưng review upstream cần độ phủ hồi quy tự động và ma trận hỗ trợ được ghi tài liệu.
• Tách công việc thành các bản vá có thể review độc lập: theo dõi trang bẩn, tái cấu trúc API snapshot, giao thức/bộ nhận, thay đổi CLI và kiểm thử nên được xem xét riêng.

Bước tiếp theo

Trọng tâm trước mắt là tính đúng đắn, xác thực tương thích, an toàn transport và kiểm thử lặp lại được — chưa phải tối ưu hiệu năng. Các tính năng như nén, bỏ qua trang rỗng (zero-page elision), mở rộng độ phủ thiết bị, điều phối phong phú hơn và tinh chỉnh hiệu năng sẽ đến sau khi nền tảng đã vững.

Code và công cụ kiểm thử dự kiến được công bố trên git.gyptazy.com/gyptazy/freebsd-bhyve-live-migration và github.com/gyptazy/freebsd-bhyve-live-migration. Hiện một số người đã có quyền truy cập, và dự án dự kiến công bố ít nhất dưới dạng đề xuất. Tác giả cũng cho biết live migration là mảnh ghép trung tâm của dự án Sylve — hướng tới một giải pháp ảo hóa giống Proxmox cho FreeBSD — và của BoxyBSD, nơi cung cấp VPS miễn phí dựa trên BSD.

Góc nhìn

Với các kỹ sư vận hành FreeBSD, đây là tín hiệu đáng theo dõi nhưng chưa phải lúc thay đổi quy trình. Bản RFC vẫn thiếu xác thực, mã hóa, cơ chế fencing cho lưu trữ chia sẻ và chưa hỗ trợ PCI passthrough — nghĩa là chưa thể dùng cho các workload doanh nghiệp đòi hỏi tính sẵn sàng cao. Tuy nhiên, việc có một triển khai thực tế để thử và mổ xẻ giúp cộng đồng đánh giá đúng khoảng cách còn lại thay vì tranh luận trừu tượng.

Với các đội đang cân nhắc FreeBSD làm nền tảng ảo hóa, đây là thời điểm hợp lý để đọc RFC, chạy thử trên môi trường lab và gửi phản hồi thiết kế. Những vấn đề như hợp đồng tương thích giữa hai máy chủ hay ranh giới commit ảnh hưởng trực tiếp đến cách bạn thiết kế cụm máy chủ và lưu trữ sau này — góp ý sớm sẽ có giá trị hơn nhiều so với việc sửa một giao thức đã ổn định.