Kiến trúc microservice của OpenStack

Phần 1 trả lời câu hỏi OpenStack là gì và vì sao doanh nghiệp chọn nó. Phần này đi vào bên trong: OpenStack được ghép từ nhiều dịch vụ độc lập, mỗi dịch vụ làm một việc và có API riêng. Bài viết đi qua chín dịch vụ hay gặp nhất và kết thúc bằng những điểm cần quyết định khi chọn thành phần cho cụm đầu tiên.

Một tập dịch vụ, không phải một khối

Theo tài liệu OpenStack, nền tảng này cung cấp IaaS qua một tập dịch vụ liên quan với nhau. Mỗi dịch vụ có API riêng, và bạn cài một phần hay toàn bộ tùy nhu cầu. Cách ghép khá nhất quán:

• Dịch vụ này gọi dịch vụ kia qua public API (REST).
• Bên trong một dịch vụ, các tiến trình nói chuyện với nhau qua message broker AMQP (thường là RabbitMQ).
• Trạng thái của mỗi dịch vụ nằm trong database riêng (thường là MySQL hoặc MariaDB).
• Mọi dịch vụ xác thực qua một dịch vụ định danh chung là Keystone.

Hệ quả thực tế: bạn mở rộng từng dịch vụ riêng (thêm node compute không cần đụng tới controller), thay backend bên dưới mà API không đổi, và chỉ cài những gì cần.

Dịch vụ	Dự án	Việc đảm nhận	Ghi chú
Nova	Compute	Tạo, lập lịch, di chuyển, xóa VM	KVM qua libvirt là lựa chọn phổ biến nhất
Neutron	Networking	Network, subnet, port, router, floating IP, security group	ML2 với Open vSwitch hoặc OVN
Cinder	Block Storage	Volume gắn vào VM	Ceph RBD hay dùng; hàng chục driver khác
Glance	Image	Kho image hệ điều hành	Backend: file, Swift, Ceph RBD, Cinder, S3
Swift	Object Storage	Lưu object, truy cập qua HTTP	Hoặc dùng Ceph RGW với S3 API
Keystone	Identity	Xác thực, ủy quyền, catalog dịch vụ	Dịch vụ nào cũng cần
Horizon	Dashboard	Giao diện web	Viết trên Django
Barbican	Key Manager	Lưu khóa, chứng chỉ, mật khẩu	Tùy chọn
Heat	Orchestration	Hạ tầng dưới dạng template	HOT và template tương thích CloudFormation

Nova: compute

Nova là dịch vụ compute, chịu trách nhiệm cấp phát và quản lý VM: tạo, lập lịch lên node nào, di chuyển (live migration) và xóa. Người dùng khởi chạy, đổi kích thước và tắt VM qua API hoặc giao diện; quản trị viên kiểm soát tài nguyên compute và chính sách lập lịch.

Nova không tự ảo hóa mà điều khiển hypervisor bên dưới qua driver. Theo tài liệu Nova hiện tại, danh sách hỗ trợ gồm KVM, QEMU, LXC (qua libvirt), VMware vSphere, Virtuozzo, zVM và Ironic cho bare metal. Hầu hết cụm chỉ dùng một hypervisor, và KVM là lựa chọn phổ biến nhất.

Lưu ý Danh sách hypervisor thay đổi theo release. Xen và Hyper-V từng có driver trong Nova nhưng không còn trong danh sách hỗ trợ hiện nay. Khi thiết kế, kiểm tra tài liệu Nova đúng release bạn định dùng.

Neutron: mạng định nghĩa bằng phần mềm

Neutron là dịch vụ mạng, điều khiển hoàn toàn qua API. Các đối tượng cơ bản gồm network, subnet (một khối địa chỉ IP), port (điểm nối một thiết bị, như NIC của VM, vào mạng ảo), router (định tuyến và NAT giữa mạng tenant và mạng provider), floating IP (truy cập VM từ ngoài qua destination NAT trên router ảo) và security group (tập quy tắc firewall áp lên port).

Mỗi project có network và router riêng, nên hai tenant có thể dùng trùng dải IP mà không ảnh hưởng nhau. Neutron cũng hỗ trợ định tuyến phân tán, để lưu lượng không dồn về một node mạng.

Phần hiện thực nằm ở plug-in ML2 với mechanism driver. Hai driver phổ biến là Open vSwitch và OVN; neutron-server nói chuyện với agent trên từng node compute qua message queue. Chọn OVS hay OVN là quyết định lớn nhất về mạng khi thiết kế cụm.

Lưu trữ: Cinder, Glance và Swift

Cinder: block storage

Cinder cung cấp volume cho VM. Volume gắn và gỡ theo cơ chế hot-plug, không cần dừng VM đang chạy, kể cả khi snapshot. Người dùng tạo, gắn, gỡ, snapshot và backup volume độc lập với compute, nên vòng đời dữ liệu không gắn với vòng đời VM.

Cinder tách API khỏi backend. Bảng driver của Cinder liệt kê hàng chục backend: Ceph RBD, LVM, NFS, NetApp ONTAP, Pure Storage, Dell PowerMax và PowerFlex, HPE 3PAR và Alletra, IBM, Huawei, và nhiều hãng khác. Nghĩa là có thể đưa SAN đang dùng vào cụm OpenStack mà không phải mua lưu trữ mới. Trong cụm mã nguồn mở hoàn toàn, Ceph RBD là lựa chọn thường gặp.

Glance: kho image

Glance quản lý image hệ điều hành: đăng ký, tìm và lấy image để Nova khởi tạo VM. Danh mục image chuẩn hóa giúp triển khai nhất quán.

Glance cũng tách API khỏi nơi lưu. Store hỗ trợ gồm file, HTTP, Ceph RBD, Swift, Cinder, VMware và S3. Định dạng image mặc định gồm raw, qcow2, vmdk, vhd, vhdx, vdi, iso, ploop và ami, nên image từ VMware (vmdk) hay Hyper-V (vhd, vhdx) đều nhập được.

Swift: object storage

Swift là object storage gốc của OpenStack: lưu dữ liệu dưới dạng object trong container, truy cập qua HTTP API, mở rộng theo chiều ngang, nhân bản dữ liệu giữa các node. Swift là một trong những thành phần đầu tiên của OpenStack và đã chạy production ở quy mô petabyte.

Swift có API riêng, không phải S3. Muốn dùng S3 API thì bật middleware s3api, nhưng bảng tương thích của Swift ghi rõ một số tính năng S3 không được hỗ trợ, như bucket policy, bucket lifecycle và bucket notification.

Lưu ý Nhiều cụm OpenStack không dùng Swift mà dùng Ceph RGW cho object storage. Lý do: nếu đã chạy Ceph cho Cinder và Glance, RGW cho S3 API trên cùng cụm Ceph đó, không phải vận hành thêm một hệ lưu trữ phân tán thứ hai. Swift vẫn hợp lý khi bạn không muốn phụ thuộc Ceph hoặc cần object storage tách biệt hẳn.

Keystone và Barbican: định danh và bí mật

Keystone là dịch vụ định danh. Mọi dịch vụ khác đều xác thực người dùng và xác thực lẫn nhau qua Keystone, nên nó được cài đầu tiên. Keystone hỗ trợ LDAP (dùng Active Directory có sẵn), federated identity (đăng nhập qua identity provider bên ngoài như Keycloak), xác thực đa yếu tố với TOTP, và token Fernet hoặc JWS.

Phân quyền theo vai trò (RBAC) không nằm hết trong Keystone. Keystone cấp token mang vai trò của người dùng trên project; mỗi dịch vụ có tệp policy riêng quyết định vai trò nào được gọi API nào. Muốn phân quyền theo cấu trúc tổ chức hoặc yêu cầu kiểm toán, bạn sửa policy từng dịch vụ.

Barbican là dịch vụ quản lý khóa và bí mật: khóa mã hóa, chứng chỉ, mật khẩu. Thay vì mỗi dịch vụ tự giữ bí mật trong tệp cấu hình, Barbican cho một kho tập trung có kiểm soát truy cập. Barbican là tùy chọn.

Horizon và Heat: giao diện và điều phối

Horizon là giao diện web, nơi người dùng và quản trị viên tạo và theo dõi VM, volume, network. Horizon viết trên Django, đổi được theme, màu và logo theo tổ chức. Mọi việc Horizon làm được đều làm được qua API và CLI, nên Horizon không bắt buộc nhưng gần như cụm nào cũng cài.

Heat là dịch vụ điều phối: mô tả cả nhóm tài nguyên (VM, network, volume, security group) trong một template rồi để Heat tạo, cập nhật và xóa theo template đó. Heat có định dạng template riêng là HOT, đồng thời hỗ trợ resource type và function tương thích CloudFormation, nên đội đã quen AWS chuyển template sang dễ hơn. Hạ tầng viết thành mã giúp triển khai lặp lại được và giảm lỗi thao tác tay.

Chọn thành phần cho cụm đầu tiên

Không cần cài hết chín dịch vụ ngay. Tài liệu cài đặt OpenStack ghi bộ tối thiểu, theo thứ tự cài: Keystone, Glance, Placement, Nova, Neutron. Sau đó nên thêm Horizon và Cinder; phần còn lại thêm khi có nhu cầu. Trước khi thiết kế, trả lời sáu câu hỏi sau:

1. Lưu trữ: dùng Ceph cho cả ba lớp (RBD cho Cinder và Glance, RGW cho S3), hay tận dụng SAN có sẵn qua driver Cinder?
2. Object storage: cần S3 API đầy đủ đến mức nào? Điều này quyết định Swift hay Ceph RGW.
3. Mạng: Open vSwitch hay OVN? Có cần định tuyến phân tán và cách ly tenant ở mức nào?
4. Định danh: đăng nhập bằng LDAP hoặc Active Directory có sẵn, hay qua identity provider bên ngoài?
5. Tự động hóa: đội sẽ dùng Heat, hay đã có Terraform/OpenTofu và Ansible và chỉ cần API?
6. Cách triển khai: cài các dịch vụ lên node controller bằng Kolla-Ansible hoặc OpenStack-Ansible, hay chạy control plane như một ứng dụng trên Kubernetes bằng OpenStack-Helm? Cách thứ hai hợp với đội đã quen vận hành Kubernetes.

Mỗi câu trả lời kéo theo một bộ thành phần và một mô hình vận hành khác nhau. Nếu muốn một góc nhìn từ bên ngoài, kỹ sư CloudMaster có thể rà soát thiết kế cùng bạn trước khi đặt phần cứng.