OpenStack Nova Cells: mở rộng compute trên nhiều datacenter

Khi một cloud OpenStack lớn lên tới hàng trăm hypervisor hoặc trải ra nhiều datacenter, control plane của Nova trở thành điểm nghẽn trước khi phần cứng hết. Nova Cells là cách Nova chia compute thành các vùng độc lập mà vẫn giữ một API cho người dùng. Bài này đi qua cell là gì, khi nào cần thêm cell, cách bố trí hai datacenter thành hai cell, và những giới hạn phải tính trước.

Nova Cells là gì

Nova Cells là kiến trúc để mở rộng compute theo chiều ngang trong khi vẫn giữ một control plane thống nhất. Mỗi cell là một vùng compute được cô lập về logic, có database, message queue, nova-conductor và các compute node riêng. Một dịch vụ thuộc cell nào được xác định bằng cặp transport_url và database.connection mà nó dùng.

Phía trên các cell là lớp API dùng chung cho toàn cloud: nova-api, nova-scheduler, placement, super conductor và API database. API database giữ danh sách cell và ánh xạ từ mỗi instance tới cell chứa nó. Nhờ đó người dùng và các dịch vụ OpenStack khác chỉ thấy một Nova API, không cần biết VM của mình nằm ở cell nào.

Ngoài ra luôn có một cell đặc biệt tên là cell0. Cell0 không có compute node, chỉ lưu bản ghi của những instance bị lỗi ngay ở bước lập lịch. Cell0 là bắt buộc, và mỗi cloud chỉ có một cell0.

Lưu ý Từ các phiên bản OpenStack hiện đại, mọi triển khai Nova đều là Cells v2, kể cả cloud một rack. Một cloud tối thiểu gồm cell0 và một cell thường. Vì vậy câu hỏi thực tế không phải “có dùng cell hay không”, mà là “khi nào thêm cell thứ hai”.

Vì sao cần nhiều cell

Với một cell, mọi compute node dùng chung một database và một message queue. Cách này ổn với môi trường nhỏ và vừa. Lên hàng trăm node hoặc nhiều datacenter, nó dẫn tới tranh chấp database, lập lịch chậm và các kịch bản lỗi khó lường. Nhiều cell giải quyết bốn việc:

1. Mở rộng. Mỗi cell có database và message queue riêng, nên không có một MariaDB hay một cụm RabbitMQ nào phải gánh toàn bộ cloud.
2. Cô lập lỗi. Database hoặc message queue của một cell hỏng thì chỉ cell đó ngừng. Các cell khác vẫn tạo, xóa và vận hành VM bình thường.
3. Phân tán địa lý. Mỗi cell có thể đặt ở một datacenter hoặc một availability zone riêng, với nguồn điện, làm mát và nhà cung cấp mạng riêng.
4. API tập trung, hạ tầng phân tán. Người dùng và các công cụ tự động hóa vẫn gọi một endpoint Nova duy nhất, triển khai workload lên bất kỳ cell nào mà không cần quan tâm phía sau.

Ví dụ: hai datacenter, hai cell

Giả sử bạn có hai datacenter đặt gần nhau. Mỗi nơi có đường mạng, hạ tầng vật lý và năng lực compute riêng. Mục tiêu là không có điểm lỗi duy nhất mà người dùng vẫn thấy một cloud.

Bố trí mỗi datacenter thành một cell:

Thành phần	Datacenter 1	Datacenter 2
Compute node	Cell 1	Cell 2
Cell database và message queue	Của cell 1, đặt tại chỗ	Của cell 2, đặt tại chỗ
nova-conductor của cell	Cell 1	Cell 2
Nova API, scheduler, super conductor, API database	Chạy ở cả hai site	Chạy ở cả hai site

Với bố trí này:

• Mỗi site là một đơn vị lỗi độc lập. Nếu một cell không truy cập được, cell còn lại vẫn hoạt động.
• Người dùng chọn availability zone tương ứng với từng site và tự phân tán workload để chịu lỗi tốt hơn.
• Vẫn chỉ có một API và một control plane. Để control plane đó không thành điểm lỗi duy nhất, API database, RabbitMQ của lớp API và nova-api phải chạy phân tán trên cả hai site.

Điểm cuối hay bị bỏ qua. Chia cell chỉ cô lập lỗi ở tầng cell. Nếu cả lớp API nằm ở datacenter 1 và nơi đó mất điện, người dùng không tạo được VM ở datacenter 2, dù VM đang chạy ở đó vẫn chạy.

Khi nào nên thêm cell

Cân nhắc thêm cell ngoài cell mặc định khi gặp một trong các điều kiện sau:

• Triển khai có từ khoảng 100 compute node trở lên.
• Bạn quản lý nhiều datacenter hoặc nhiều availability zone.
• Bạn cần chịu lỗi giữa các vùng hạ tầng, không chỉ giữa các host.
• Database chính và message bus của Nova đã là điểm nghẽn hiệu năng.

Với triển khai nhỏ, dưới 50 đến 100 node tại một địa điểm, một cell thường cộng cell0 là đủ. Thêm cell ở quy mô này chỉ thêm việc vận hành.

So sánh một cell và nhiều cell

Tiêu chí	Một cell	Nhiều cell
Quy mô compute	Phù hợp môi trường nhỏ và vừa, dưới 100 node	Dành cho quy mô lớn, từ 100 node
Cô lập lỗi	Hạn chế, sự cố database hoặc MQ ảnh hưởng toàn bộ	Lỗi một cell không ảnh hưởng cell khác
Tải database	Chung một database và một message queue	Mỗi cell có database và MQ riêng, giảm tranh chấp
Phân tán địa lý	Thường một địa điểm hoặc một rack	Hỗ trợ nhiều datacenter và AZ
Độ phức tạp vận hành	Đơn giản để thiết lập và quản lý	Phải đăng ký cell, ánh xạ host, theo dõi từng cell

Giới hạn phải biết trước

Nhiều cell không phải không có giá. Tài liệu Nova liệt kê các giới hạn sau, và chúng ảnh hưởng trực tiếp tới cách bạn thiết kế:

• Chuyển VM giữa các cell. Cold migrate và resize qua ranh giới cell chỉ có từ bản Ussuri. Live migration, evacuate và unshelve vẫn không đi qua được cell. Một VM sinh ra ở cell nào gần như ở lại cell đó.
• Không có up-call. Compute node và conductor của cell không nối vào message queue của lớp API, nên không gọi ngược lên scheduler hay API database được. Hệ quả: khi boot hoặc resize thất bại trên một host, Nova không tự lập lịch lại sang host khác trong bố trí nhiều cell. Tài liệu khuyên đặt scheduler.max_attempts = 1 để không chờ vô ích.
• Server group affinity và anti-affinity. Bước kiểm tra anti-affinity muộn khi tạo VM và khi evacuate không hoạt động với nhiều cell. Tài liệu đề cập cấu hình workarounds.disable_group_policy_check_upcall cho trường hợp này.
• Quota. Quota được tính tại thời điểm hỏi, nên một cell mất kết nối làm số liệu sử dụng sai. Từ bản Train có thể đếm từ placement và API database thay vì hỏi từng cell.
• Cell mất kết nối. nova-api chờ 60 giây rồi mới trả kết quả thiếu. Cấu hình api.list_records_by_skipping_down_cells quyết định bỏ qua bản ghi của cell đó hay trả lỗi.

Giới hạn Chuyển compute node kèm VM đang chạy từ cell này sang cell khác là việc rất khó và không có công cụ chính thức. Vì vậy phải quyết định bố trí cell trước khi cloud lớn lên, không phải sau. Ghép cell với ranh giới vật lý rõ ràng, như một datacenter hoặc một AZ, là lựa chọn an toàn nhất.

Lưu ý khi triển khai

1. Cell0 là bắt buộc. Tạo và ánh xạ cell0 bằng nova-manage cell_v2 map_cell0 ngay khi dựng API database. Nó theo dõi các instance không lập lịch được.
2. Đăng ký cell bằng nova-manage. Cell thêm vào phải được tạo và ánh xạ host tường minh. Nova không tự nhận ra một cụm compute mới.
3. Mở rộng và phục hồi độc lập theo cell. Giám sát database, message queue và conductor của từng cell riêng. Kế hoạch backup và khôi phục cũng làm theo từng cell.
4. Phân tán lớp API. Chạy nova-api và các thành phần đi kèm trên nhiều AZ để lớp API không thành điểm lỗi duy nhất.

Các lệnh chính để thêm một cell cho datacenter thứ hai:

# Đăng ký cell mới với database và message queue riêng của nó
nova-manage cell_v2 create_cell --name dc2 \
  --database_connection "mysql+pymysql://nova:PASS@db-dc2/nova_dc2" \
  --transport-url "rabbit://nova:PASS@mq-dc2:5672/" \
  --verbose

# Ánh xạ các compute host đã đăng ký vào cell đó
nova-manage cell_v2 discover_hosts --cell_uuid UUID_CELL_DC2

# Kiểm tra lại danh sách cell và host
nova-manage cell_v2 list_cells
nova-manage cell_v2 list_hosts

Nếu không muốn chạy discover_hosts thủ công mỗi khi thêm node, đặt scheduler.discover_hosts_in_cells_interval để scheduler tự quét định kỳ.

Việc cần làm tiếp

Nova Cells là quyết định thiết kế nền tảng cho cloud cần lớn hoặc trải nhiều địa điểm. Nếu bạn đang hoặc sắp vận hành một môi trường như vậy, hãy làm ba việc trước khi mua thêm phần cứng:

1. Xác định ranh giới cell theo ranh giới vật lý: datacenter, AZ hoặc nhóm rack có nguồn điện và mạng riêng.
2. Rà lại các workload cần live migration, evacuate hoặc server group anti-affinity. Chúng phải nằm trọn trong một cell.
3. Quyết định lớp API đặt ở đâu và chạy phân tán ra sao, vì chia cell không bảo vệ được lớp này.

Với cloud lớn hoặc phân tán, cell không phải tính năng “nên có”. Nó là yêu cầu bắt buộc, và phải được lên kế hoạch từ ngày đầu.