Reference // Tra cứu kỹ thuậtcloudstack

CloudStack — Kiến trúc và vận hành hạ tầng

DOC PATH reference/cloudstack/theory

Doc Type: Reference
Technology: cloudstack
Status: Active
Version: 4.20.1.0
Tags: CloudStackIaaSArchitecture

Kiến trúc, account, compute, storage, network, HA và vận hành CloudStack. Đọc theo thứ tự các chương hoặc chọn mục cần tra cứu trong mục lục.

Kiến trúc và phân cấp hạ tầng

Apache CloudStack là nền tảng điều phối hạ tầng để cung cấp virtual machine (VM), network và storage theo mô hình Infrastructure as a Service (IaaS). CloudStack quản lý tài nguyên và vòng đời dịch vụ; hypervisor mới là thành phần trực tiếp chạy VM.

IaaS và ranh giới trách nhiệm

CloudStack tạo một lớp quản lý chung trên các host, mạng và storage pool. User chọn dịch vụ qua UI/API; nền tảng kiểm tra quyền, giới hạn và khả năng cấp phát trước khi thực hiện yêu cầu.

Khái niệm	Ý nghĩa
Resource pooling	Gom hạ tầng thành các nhóm tài nguyên để phân bổ theo chính sách.
Self-service	User tự yêu cầu dịch vụ trong phạm vi được cấp quyền; không đồng nghĩa toàn quyền hạ tầng.
Multi-tenancy	Nhiều account/project dùng chung nền tảng nhưng được phân tách về quyền, tài nguyên và mạng.
Elasticity	Khả năng tăng/giảm tài nguyên; không mặc nhiên có autoscaling cho ứng dụng.
Metering	Ghi nhận mức sử dụng; không tự tạo thành hệ thống tính tiền, hóa đơn và thanh toán.

Đội ngũ vận hành chịu trách nhiệm về nền tảng, kết nối và dịch vụ hạ tầng. Chủ VM vẫn phải quản lý hệ điều hành, dữ liệu và ứng dụng theo mô hình dịch vụ đã thỏa thuận. VM ở trạng thái Running chưa chứng minh ứng dụng bên trong hoạt động đúng.

Phân cấp hạ tầng

Region
└── Zone
    └── Pod
        └── Cluster
            └── Host

Cấp	Vai trò và ranh giới
Region	Nhóm một hoặc nhiều zone theo phạm vi địa lý/quản trị.
Zone	Đơn vị triển khai lớn, thường tương ứng một datacenter; chứa compute, mạng và storage phục vụ workload.
Pod	Nhóm hạ tầng trong zone, thường gắn với rack hoặc nhóm host dùng chung subnet quản lý.
Cluster	Nhóm host có hypervisor và cấu hình tương thích, chia sẻ các điều kiện cần cho placement/migration.
Host	Server vật lý chạy hypervisor và các VM được cấp phát lên đó.

Phân cấp logic không thay thế failure domain vật lý. Hai cluster có thể cùng phụ thuộc một storage array, switch hoặc nguồn điện. Hai zone cũng không tự động trở thành hai địa điểm DR độc lập. Cần đối chiếu sơ đồ CloudStack với network path, storage và nguồn điện thực tế. Xem định nghĩa thành phần trong CloudStack Concepts.

Control plane, data plane và System VM

Thành phần	Trách nhiệm chính	Không nên hiểu nhầm
Management Server	UI/API, điều phối tác vụ, chọn tài nguyên và quản lý trạng thái.	Không trực tiếp chạy guest VM hay lưu toàn bộ dữ liệu guest.
Database	Lưu cấu hình, quan hệ tài nguyên và trạng thái quản lý.	Backup database không phải backup disk của VM.
KVM host và `cloudstack-agent`	Nhận yêu cầu điều khiển; phối hợp với libvirt/QEMU-KVM để quản lý VM.	Agent trên host khác guest agent hoặc cloud-init trong VM.
Virtual Router (VR)	Cung cấp các dịch vụ mạng theo offering, provider và network mode.	Không phải mọi network đều có VR hoặc đủ mọi dịch vụ NAT/VPN/LB.
Secondary Storage VM (SSVM)	Hỗ trợ chuyển, xử lý template, ISO và snapshot trên secondary storage.	SSVM không phải storage backend và không thay thế primary storage.
Console Proxy VM (CPVM)	Trung gian cung cấp console VM qua giao diện web.	Lỗi console chưa chứng minh VM mất SSH hoặc ứng dụng dừng.

Với KVM, đường điều khiển điển hình là Management Server → cloudstack-agent → libvirt/QEMU-KVM → VM. I/O của VM đi tới primary storage; lưu lượng ứng dụng đi qua mạng guest. Không phải mọi gói tin và thao tác đọc/ghi đều đi qua Management Server.

Khi control plane mất kết nối, những VM đang chạy có thể tiếp tục phục vụ, trong khi các thao tác tạo, sửa, di chuyển hoặc quản lý tài nguyên bị gián đoạn. Ngược lại, UI hoạt động bình thường không chứng minh guest network và storage đều hoạt động bình thường.

Template và offering của System VM

System VM template là OS image dùng để tạo các VM hạ tầng, cần phù hợp phiên bản, hypervisor và kiến trúc CPU. System offering quy định tài nguyên của chúng; instance VR/SSVM/CPVM là VM cụ thể đang thực thi vai trò đó. Ba khái niệm này không thể thay thế nhau. Template của guest VM cũng không thay thế System VM template.

Account, offering và cấp phát tài nguyên

Offering: danh mục dịch vụ được phép cấp phát

Loại offering	Quy định chính
Compute offering	CPU, RAM và chính sách compute/placement; cấu hình cố định hoặc cho phép tùy chọn trong giới hạn.
Disk offering	Đặc tính data volume: dung lượng, storage tags, local/shared và giới hạn I/O nếu backend hỗ trợ.
Network offering	Bộ dịch vụ mạng cùng provider thực hiện chúng.
VPC offering	Khả năng dịch vụ và provider áp dụng cho VPC.
System offering	Tài nguyên compute dành cho các VM hạ tầng.

Offering là chính sách yêu cầu, không phải tài nguyên vật lý đã được giữ chỗ. Một offering hiển thị trong UI vẫn có thể không cấp phát được vì thiếu host phù hợp, storage pool, IP hoặc giới hạn còn lại. Phạm vi public/domain và phạm vi zone cần được xét riêng. Các lựa chọn chi tiết được mô tả trong Service Offerings.

User, account, domain và project

Khái niệm	Cách hiểu
User	Danh tính đăng nhập, thuộc một account.
Account	Ranh giới sở hữu tài nguyên và quyền trong ngữ cảnh thông thường; không đồng nhất với một user.
Domain	Cấu trúc phân cấp để tổ chức account/subdomain và phạm vi quản trị.
Role	Tập quyền API gắn với account; quyết định được thực hiện thao tác nào.
Project	Không gian tài nguyên dùng chung cho các thành viên, có quyền và giới hạn riêng.

VM tạo ngoài project thường thuộc account, không thuộc riêng user đã bấm tạo. Trong project, quyền truy cập phụ thuộc tư cách thành viên và chính sách project; loại một thành viên không có nghĩa xóa các VM của project. Project role có thể hạn chế thêm, không dùng để nâng quyền vượt role của account.

Root administrator quản trị toàn hệ thống; domain administrator chỉ quản trị trong phạm vi được giao. Xác thực trả lời “ai đang gọi”, còn phân quyền trả lời “được làm gì, trên tài nguyên nào”. Tham khảo Accounts, Users and Domains.

Resource limits, quota và capacity

Lớp kiểm soát	Phạm vi kiểm soát
Role và phạm vi sở hữu	Quyền thực hiện thao tác trên tài nguyên cụ thể.
Offering visibility	Dịch vụ được phép chọn trong domain/zone hiện tại.
Resource limits	Hạn mức VM, vCPU, RAM, volume, IP và dung lượng storage.
Quota	Mức sử dụng quy đổi theo biểu giá, credit, balance và chính sách thực thi quota.
Capacity	Khả năng thực tế của hạ tầng để cấp phát tài nguyên phù hợp.

Giới hạn account, project và domain phải được xét trong đúng ngữ cảnh; tổng mức dùng của các account có thể chạm giới hạn domain dù từng account chưa hết hạn mức. Giảm limit không tự thu hồi hoặc xóa tài nguyên đã tồn tại.

Quota là cơ chế riêng dựa trên Usage Server và quota plugin, có thể gắn với chính sách khóa account khi thiếu balance. Nó không thay thế resource limits, không tạo thêm capacity và không mặc nhiên đã được bật trên mọi hệ thống.

Luồng cấp phát VM

Xác định account/project, quyền, offering và hạn mức.
Chọn zone, template/ISO, compute offering, volume và network.
Tìm host, storage và mạng thỏa mãn đồng thời các điều kiện cấp phát.
Chuẩn bị disk/NIC và dịch vụ mạng, rồi yêu cầu hypervisor khởi động VM.
Guest OS khởi động, nhận cấu hình và chạy bootstrap nếu có; ứng dụng được kiểm tra ở lớp riêng.

Lỗi ở một bước không nhất thiết nằm ở compute: deploy có thể thất bại vì template chưa sẵn sàng, hết IP, không có pool khớp storage tag hoặc VR không khởi tạo được. Khi đọc trạng thái, cần phân biệt tác vụ điều phối, trạng thái VM và khả năng phục vụ của ứng dụng bên trong.

Compute, storage và vòng đời VM

Compute quyết định VM chạy ở đâu và được cấp bao nhiêu tài nguyên. Storage quyết định dữ liệu nằm ở đâu, host nào truy cập được và khả năng phục hồi khi có sự cố. Hai lớp này phải được xét cùng nhau khi deploy, resize, migrate hoặc thiết kế HA.

Placement: điều kiện để một host được chọn

Một host còn RAM chưa chắc là đích hợp lệ. Việc cấp phát phải đồng thời thỏa mãn:

Zone/cluster/host ở trạng thái cho phép cấp phát; hypervisor, kiến trúc CPU và template tương thích.
CPU/RAM khả dụng theo chính sách cấp phát và phần tài nguyên dành cho hệ thống.
Host tags, dedicated resources và affinity/anti-affinity phù hợp.
Có storage pool đáp ứng disk offering, dung lượng và khả năng truy cập.
Có đường mạng, VLAN và dịch vụ mạng cần thiết cho NIC của VM.

Capacity tổng của cluster không đồng nghĩa capacity cho một VM. Nếu các host chỉ còn lần lượt 2 GiB và 6 GiB RAM khả dụng, không thể ghép hai phần trống đó để chạy một VM cần 8 GiB trên một host.

Tags, affinity và dedication

Cơ chế	Mục đích	Giới hạn
Host tags	Ràng buộc compute offering với nhóm host thích hợp.	Khác metadata tag tùy ý gắn lên tài nguyên.
Storage tags	Chọn pool khớp yêu cầu disk/compute offering; nếu yêu cầu nhiều tag thì pool phải đáp ứng tất cả.	Nhãn `ssd` không tự kiểm chứng phần cứng hoặc hiệu năng.
Affinity	Ưu tiên/ràng buộc các VM cùng host theo loại nhóm được hỗ trợ.	Tăng mức phụ thuộc vào cùng một failure domain.
Anti-affinity	Tách các VM ra các host khác nhau theo chính sách nhóm.	Khác host vẫn có thể chung rack, switch hoặc storage.
Dedicated resources	Giới hạn tài nguyên cho domain/account được chỉ định.	Làm giảm tập ứng viên có thể dùng cho placement và phục hồi.

Phân biệt ràng buộc bắt buộc và ưu tiên không bắt buộc: chính sách non-strict có thể cho phép placement khác mong muốn khi thiếu capacity. Anti-affinity giúp giảm rủi ro chung host, nhưng không thay thế replication hoặc failover ở lớp ứng dụng.

Allocation và overprovisioning

Allocated capacity là phần tài nguyên CloudStack đã tính cho VM; utilization là mức dùng thực tế. Hai số đo phục vụ hai mục đích khác nhau và không nên thay thế nhau.

CPU/memory overprovisioning tăng khả năng cấp phát theo tỷ lệ cấu hình, không sinh thêm CPU hay RAM vật lý. Cần đánh giá tranh chấp CPU, memory pressure, hỗ trợ ballooning và tải đồng thời. Host còn “capacity” theo scheduler vẫn có thể không đáp ứng độ trễ hoặc throughput của ứng dụng.

Template, ISO và volume

Đối tượng	Vai trò
Template	OS image đã chuẩn bị, dùng làm nguồn tạo root volume cho VM.
ISO	Bộ cài hoặc phương tiện boot; không đồng nghĩa hệ điều hành đã được cài lên disk.
Root volume	Disk hệ điều hành riêng của instance, thay đổi khi guest ghi dữ liệu.
Data volume	Disk dữ liệu có vòng đời và thao tác attach/detach riêng.

Attach volume chỉ gắn thiết bị vào VM; partition, filesystem và mount thuộc guest OS. Detach không đồng nghĩa xóa disk. Với một số luồng tạo volume trống, đối tượng ban đầu mới là metadata và dung lượng vật lý chỉ được cấp khi attach lần đầu.

Template chuẩn cần đúng hypervisor/format, kiến trúc CPU và driver phù hợp. Golden image không nên chứa private key, thông tin đăng nhập hoặc định danh host cần tạo riêng cho từng instance.

User data, metadata và guest integration

User data chứa cấu hình hoặc chỉ dẫn bootstrap; metadata mô tả instance. VR hoặc ConfigDrive có thể cung cấp dữ liệu đó, còn cloud-init hay công cụ tương đương trong guest mới là thành phần đọc và áp dụng. Cấp user data thành công không chứng minh bootstrap đã chạy xong.

Virtio driver hỗ trợ thiết bị ảo; guest agent hỗ trợ tích hợp với guest OS. Chúng khác cloudstack-agent chạy trên KVM host. Không dùng template hoặc user data để lưu lâu dài các secret.

Vòng đời VM và dữ liệu

Thao tác/trạng thái	Tác động cần hiểu
Stop / Start	Trong vòng đời thông thường, disk được giữ lại; lần start cần cấp phát lại compute và có thể chọn host khác.
Reboot	Khởi động lại guest; không đồng nhất với toàn bộ quá trình stop/start và placement.
Destroy	Đánh dấu xóa VM; khả năng recover còn phụ thuộc thời điểm expunge, quyền và chính sách.
Expunge	Xóa cuối cùng; không còn recover bằng cơ chế phục hồi VM đã destroy của CloudStack.
Delete attached volumes	Là lựa chọn có tác động riêng tới data volume, không nên suy từ trạng thái VM.

Root volume gắn với vòng đời VM. Data volume thường được giữ lại nếu thao tác và chính sách hiện tại không yêu cầu xóa kèm, nhưng phải kiểm tra yêu cầu xóa cụ thể. VM stop hoặc volume persistent không có nghĩa dữ liệu đã được backup hay có HA.

Primary và secondary storage

Đặc điểm	Primary storage	Secondary storage
Dữ liệu chính	Root/data volume phục vụ I/O của VM.	Template, ISO và volume snapshot theo backend/workflow.
Thời điểm sử dụng	Liên tục khi guest đọc/ghi disk.	Provisioning, truyền image, tạo snapshot và restore.
Phạm vi	Local hoặc shared; cluster/zone tùy backend và hỗ trợ.	Phục vụ kho image/backup trong thiết kế zone; có thể dùng object storage và staging.
Ảnh hưởng sự cố	Có thể trực tiếp làm VM mất I/O hoặc ngừng dịch vụ.	Thường ảnh hưởng tác vụ dùng image/snapshot; không mặc nhiên làm mọi VM đang chạy dừng lại.

Luồng thông thường là template trên secondary → root volume trên primary → VM đọc/ghi root volume. Secondary không phải bản mirror liên tục của primary. SSVM hỗ trợ luồng chuyển dữ liệu, còn độ bền dữ liệu (durability) do backend và chính sách bảo vệ dữ liệu quyết định.

Local, shared và zone-wide

Local storage phụ thuộc host chứa dữ liệu, nên giới hạn khả năng migration và khởi động VM trên host khác. Shared storage cho nhiều host truy cập, nhưng một backend dùng chung vẫn có thể là single point of failure nếu thiếu dự phòng.

Zone-wide primary storage chỉ mở rộng phạm vi trong zone theo hỗ trợ của backend. Nó không phải storage xuyên zone, không tự cho phép mọi kiểu live migration giữa cluster và không tự tạo DR. Object secondary storage như S3/Swift có thể cần NFS staging/cache theo thiết kế plugin; cần phân biệt luồng truyền dữ liệu này với I/O primary của VM.

Capacity và hiệu năng storage

Chọn pool phụ thuộc scope, trạng thái, local/shared, tags và ngưỡng capacity. Ngưỡng cảnh báo không nhất thiết trùng ngưỡng ngừng cấp phát. Thin provisioning cho phép dung lượng logic vượt phần đang dùng vật lý nhưng không tạo thêm chỗ trống khi dữ liệu tăng.

Đánh giá storage cần cả dung lượng thực, dung lượng đã cấp, IOPS, latency, throughput, băng thông mạng và khoảng trống cho snapshot/rebuild. Backend còn nhiều TB trống vẫn có thể quá tải I/O.

Snapshot và tính nhất quán

Cơ chế	Phạm vi bảo vệ	Điểm cần lưu ý
Volume snapshot	Trạng thái một volume tại một thời điểm.	Không lưu CPU/RAM; không tự bảo đảm nhất quán giao dịch của ứng dụng.
VM snapshot	Trạng thái VM theo khả năng hypervisor, có thể bao gồm memory nếu được hỗ trợ và lựa chọn.	Khác volume snapshot; điều kiện disk/memory và phục hồi phụ thuộc nền tảng.
Backup	Bản phục hồi theo chính sách/provider, retention và nơi lưu riêng.	Không suy ra tính độc lập hoặc khả năng restore chỉ từ nhãn “backup”.

Crash-consistent gần với trạng thái sau mất điện; application-consistent cần ứng dụng/database phối hợp flush, quiesce hoặc quy trình backup chuyên biệt. Snapshot nhiều volume không mặc nhiên tạo một thời điểm nhất quán chung cho cả ứng dụng.

Snapshot thành công chỉ chứng minh tác vụ tạo snapshot hoàn tất. Khả năng phục hồi cần được xác nhận ở mức volume, filesystem, database và ứng dụng; mục tiêu backup/DR được trình bày ở trang HA, bảo mật và vận hành.

Resize và migration

Thao tác	Ý nghĩa	Điều kiện chính
Change compute offering	Đổi cấu hình CPU/RAM của VM.	Capacity, offering, hypervisor, guest OS và hỗ trợ dynamic scaling.
Cold migration	Di chuyển khi VM đã dừng.	Đích tương thích, truy cập disk và mạng; có thời gian gián đoạn.
Live migration	Chuyển VM đang chạy sang host khác.	Tương thích CPU/hypervisor, storage, mạng và đủ tài nguyên đích.
Storage migration	Di chuyển volume hoặc VM cùng volume theo workflow được hỗ trợ.	Khác migration compute thuần; phụ thuộc backend, scope và trạng thái VM.

Không suy ra hot-add CPU/RAM chỉ vì UI có Change Offering. Tài liệu 4.20.1.0 mô tả dynamic scaling cho các hypervisor hỗ trợ như VMware/XenServer cùng điều kiện guest tools; với KVM phải xác minh hỗ trợ cụ thể, không mặc định resize khi đang chạy.

Luồng live migration KVM thủ công thông thường trong tài liệu 4.20.1.0 yêu cầu VM đang chạy, host đích cùng cluster và không dùng local disk trong luồng đó. Các workflow chuyển cả VM lẫn volume có điều kiện riêng. Live migration cũng không phải cam kết không gián đoạn ứng dụng trong mọi hoàn cảnh. Tham khảo Virtual Machines — Scaling and Migration.

Network và đường đi traffic

Mạng CloudStack gồm hạ tầng vật lý, mạng logic của guest và các dịch vụ do provider cung cấp. Cần phân biệt ba lớp này: tạo được network trong UI chưa chứng minh VLAN đã thông, và VM nhận được IP chưa chứng minh có đường tới Internet hoặc ứng dụng.

Traffic type và physical network

Traffic type	Mục đích
Management	Liên lạc điều khiển giữa các thành phần quản lý, host và VM hạ tầng theo thiết kế.
Guest	Lưu lượng của VM của user trong mạng tenant.
Public	Kết nối tới mạng bên ngoài và dải IP public trong những mô hình cần public traffic.
Storage	Traffic phục vụ secondary storage khi sử dụng storage network; không mặc nhiên bao gồm mọi I/O tới storage.

Physical network là mô hình CloudStack dùng để ánh xạ các loại traffic vào hạ tầng của zone. Guest network là mạng logic nơi các NIC của VM được kết nối. Tách traffic bằng VLAN trên cùng NIC không đồng nghĩa có các đường vật lý độc lập.

Đường I/O tới primary storage cần thiết kế riêng theo backend, routing và NIC/bond thực tế. Không kết luận rằng cấu hình traffic type Storage đã tự tách toàn bộ NFS/iSCSI/RBD hay lưu lượng replication của backend.

Bridge, VLAN, bond và MTU trên KVM

Đường đi L2 điển hình: NIC ảo của VM → bridge trên host → NIC/bond và VLAN → switch. Traffic label phải khớp bridge thực tế trên các host. Tên cloudbr0 hoặc cloudbr1 là quy ước triển khai, không có ý nghĩa management/guest cố định trong mọi hệ thống.

Khái niệm	Điều cần phân biệt
VLAN	Phân tách broadcast domain ở lớp 2; trunk/allowed VLAN phải nhất quán xuyên đường truyền.
Subnet/CIDR	Không gian địa chỉ L3 và ranh giới định tuyến; khác VLAN dù thường được ánh xạ cùng nhau.
IP range	Tập địa chỉ cho phép cấp trong một subnet; hết range không đồng nghĩa hết toàn bộ subnet.
Bond	Dự phòng hoặc phân tải nhiều link tùy mode và switch; một flow không mặc nhiên đạt tổng tốc độ các link.
MTU	Kích thước gói tin phải tương thích đầu cuối, kể cả overhead encapsulation.

MTU không đồng nhất có thể khiến ping nhỏ thành công nhưng truyền file hoặc gói lớn thất bại. Management vẫn kết nối được cũng không chứng minh VLAN guest, trunk public hoặc storage path hoạt động đúng.

Basic và Advanced zone

Mô hình	Đặc điểm
Basic networking	Một guest network trong zone, mô hình đơn giản; thường dùng Security Group để phân tách truy cập giữa VM.
Advanced networking	Hỗ trợ nhiều guest network, phân tách tenant và các mô hình mạng/dịch vụ phong phú hơn, bao gồm VPC khi cấu hình phù hợp.

Network type là lựa chọn kiến trúc của zone, không phải nút chuyển tùy ý cho từng VM. Việc đổi mô hình cần thiết kế lại và kế hoạch di chuyển phù hợp, không nên coi là thao tác bật/tắt tại chỗ. Phạm vi hỗ trợ còn phụ thuộc hypervisor và network provider. Xem Networking Overview.

Isolated, Shared và L2 network

Loại mạng	Cách sử dụng	Dịch vụ đi kèm
Isolated	Mạng tenant được cô lập, thường thuộc account hoặc project.	Có thể dùng VR/provider cho routing và dịch vụ theo offering; không mặc định mọi dịch vụ đều bật.
Shared	Mạng cho nhiều account dùng theo phạm vi và quyền được cấp.	Dịch vụ, IP allocation và Security Group phụ thuộc mô hình đã cấu hình.
L2	Cung cấp kết nối lớp 2.	Không có VR và cơ chế cấp IP của CloudStack như mạng có dịch vụ; IP do guest/hệ thống ngoài quản lý.

Shared không đồng nghĩa “không có kiểm soát truy cập”. Isolated cũng không đồng nghĩa chỉ một account luôn có thể sử dụng: quyền chia sẻ network có thể cho phép account/project khác tạo VM trên mạng mà không trao quyền sửa cấu hình/rule của mạng đó.

ConfigDrive có thể cung cấp metadata/user data cho guest trong các mô hình phù hợp, nhưng không biến L2 network thành mạng có DHCP, NAT hay VR.

Network offering, service và provider

Network offering mô tả dịch vụ được yêu cầu; service là chức năng như DHCP hoặc Source NAT; provider là thành phần thực thi như Virtual Router hoặc thiết bị/plugin mạng bên ngoài. Network cụ thể là instance được tạo theo offering đó.

Dịch vụ	Chức năng	Không thay thế
DHCP	Cấp địa chỉ và thông tin mạng như gateway/DNS.	Đường truyền vật lý, routing hoặc DNS server hoạt động tốt.
DNS	Phân giải tên theo cấu hình.	Khả năng kết nối tới IP đích.
Source NAT	Đổi địa chỉ nguồn, thường cho nhiều guest ra ngoài qua IP public.	Rule cho phép kết nối từ ngoài vào dịch vụ guest.
Static NAT	Ánh xạ một-một giữa IP public và IP guest.	Firewall và dịch vụ thực sự lắng nghe trong VM.
Port Forwarding	Chuyển một cổng/giao thức trên IP public tới cổng của guest.	Quyền truy cập ở mọi lớp hoặc route trả về đúng.
Firewall	Cho phép/chặn traffic theo rule.	NAT hoặc việc mở cổng ứng dụng trong guest.
Load Balancer	Phân phối kết nối đến các backend.	Trạng thái hoạt động, tính nhất quán dữ liệu và HA của chính ứng dụng.
VPN	Kết nối từ xa hoặc kết nối giữa các mạng tùy loại VPN được hỗ trợ.	Chính sách truy cập, routing và kiểm soát hai đầu tunnel.

Remote-access VPN phục vụ client truy cập từ xa; site-to-site VPN kết nối các mạng. Tên dịch vụ có trong danh mục không bảo đảm mọi offering, mode hoặc provider đều hỗ trợ nó.

NATTED và ROUTED

Mode và loại network là hai khái niệm khác nhau. Với isolated network/VPC, mode quyết định cách lưu lượng guest đi ra mạng bên ngoài.

Mode	Cơ chế	Yêu cầu
NATTED	VR có thể cung cấp Source NAT cùng Static NAT, Port Forwarding, LB hoặc VPN theo offering.	Dải public IP, chính sách NAT/firewall và kết nối upstream phù hợp.
ROUTED	Định tuyến tới prefix guest, không dựa trên Source NAT của VR.	Upstream biết đường tới subnet guest và có đường trả về đúng.

Static routing cần cấu hình route upstream; dynamic routing dùng BGP với AS number và peer được chuẩn bị cho zone. Bật ROUTED không tự làm subnet guest có thể truy cập từ mọi nơi: prefix, peer/route, rule và đường trả về đều phải phù hợp.

VPC, tier và Network ACL

VPC gom nhiều tier vào một không gian mạng có định tuyến và chính sách chung. Mỗi tier là một mạng con; CIDR các tier phải phù hợp dải của VPC và không chồng lấn nhau.

Một ứng dụng có thể tách tier web, ứng dụng và database để kiểm soát đường truy cập giữa các lớp. Việc tạo các tier không tự sinh ra chính sách bảo mật đúng: phải xác định nguồn, đích, giao thức, cổng và chiều traffic được phép.

Cơ chế	Phạm vi điển hình
Network ACL	Kiểm soát traffic vào/ra tier tại ranh giới định tuyến của VPC.
Security Group	Áp dụng chính sách theo VM/nhóm trong các mô hình mạng và hypervisor có hỗ trợ.
Isolated network firewall	Kiểm soát traffic qua ranh giới mạng isolated theo provider/mode.
Guest OS firewall	Lớp kiểm soát bên trong hệ điều hành VM.

Một tier gắn một ACL list; một list có thể dùng cho nhiều tier trong cùng VPC. Rule được xét theo thứ tự số ưu tiên tăng dần, nên thứ tự allow/deny ảnh hưởng kết quả. Cần kiểm tra cả chiều traffic, rule mặc định và đường trả về, không chỉ kiểm tra xem đã có rule cho phép hay chưa.

Không coi Security Group là tên khác của VPC ACL, hoặc cho rằng ACL giữa tier kiểm soát mọi giao tiếp L2 giữa VM trong cùng tier. Phạm vi enforcement phụ thuộc nơi traffic thực sự đi qua.

Đọc đường đi gói tin

Ví dụ kết nối ra ngoài từ mạng isolated NATTED:

Ứng dụng / firewall trong guest
→ NIC ảo → bridge / VLAN trên KVM host
→ NIC guest của VR → routing / firewall / Source NAT
→ NIC public của VR → switch / upstream → máy đích

Chiều trả về phải đi tới đúng IP/NAT state và quay lại guest. Với Port Forwarding hoặc Static NAT, hướng từ ngoài vào cũng cần ứng dụng lắng nghe, rule phù hợp và guest có route trả về đúng.

Triệu chứng	Lớp cần phân biệt
VM không nhận IP	NIC/link, VLAN, DHCP/provider và dải địa chỉ còn lại.
Có IP nhưng không tới gateway	Subnet/mask, bridge/VLAN, ARP và trạng thái VR.
Tới gateway nhưng không tới đích ngoài	Route, NAT theo mode, firewall, public/uplink và đường trả về.
Tới IP nhưng không phân giải tên	DNS được cấp, DNS server và đường tới resolver.
Ping nhỏ được, truyền dữ liệu lớn lỗi	MTU, encapsulation, loss và các thiết bị trung gian.
Console web lỗi nhưng SSH vẫn được	CPVM/đường console, không kết luận guest network đã hỏng.

Đây là cách chia lớp để suy luận, không phải kết luận nguyên nhân chỉ từ một triệu chứng. Đối chiếu thêm trạng thái NIC, VR, host và tác vụ mạng trước khi thay đổi cấu hình.

HA, backup và disaster recovery

Độ sẵn sàng phải được đánh giá trên toàn bộ các thành phần tham gia phục vụ ứng dụng: control plane, compute, mạng, storage và dữ liệu. Nhiều Management Server hoặc nhiều host chỉ giải quyết một phần của chuỗi phụ thuộc đó.

HA theo từng lớp

Lớp	Mục tiêu	Phụ thuộc còn phải bảo vệ
Management Server HA	Duy trì khả năng tiếp nhận UI/API và điều phối.	Database, load balancer, DNS, kết nối quản lý và cấu hình nhất quán.
Host/VM HA	Phát hiện sự cố và khởi động lại VM trên tài nguyên phù hợp.	Fencing, host dự phòng, disk truy cập được và network tương thích.
Network HA	Duy trì đường truyền và dịch vụ mạng.	NIC/bond, switch, uplink, provider và khả năng redundant VR của offering.
Storage HA	Duy trì khả năng đọc/ghi khi thành phần storage lỗi.	Backend, controller, replica, quorum, multipath và capacity phục hồi tùy công nghệ.
Application HA	Giữ dịch vụ ứng dụng hoạt động hoặc failover đúng.	Replica ứng dụng/database, dữ liệu nhất quán, health check và cơ chế chuyển vai trò.

Nhiều Management Server dùng chung database không loại bỏ database khỏi danh sách single point of failure. Tương tự, hai VM trên hai host nhưng cùng phụ thuộc một storage array hoặc switch vẫn có failure domain chung.

VM HA, host HA và fencing

VM HA thường khôi phục bằng cách restart, không phải tiếp tục nguyên trạng RAM của VM trên host đã hỏng. Host đích phải có capacity, khả năng truy cập disk, mạng và điều kiện placement tương thích.

Mất kết nối agent không chứng minh host đã tắt: guest có thể vẫn chạy trong khi mạng management bị chia cắt. Nếu vội khởi động bản VM thứ hai trên cùng disk, hai bên có thể ghi đồng thời và làm hỏng dữ liệu.

Fencing là cơ chế cô lập hoặc bảo đảm host cũ không còn tiếp tục truy cập tài nguyên trước khi phục hồi nơi khác. Host HA kết hợp health check, kiểm tra hoạt động và out-of-band management theo cấu hình. Không nên coi việc có IP out-of-band management là bằng chứng fencing đã được tích hợp và kiểm chứng.

Redundant VR chỉ bảo vệ những vai trò được provider/offering hỗ trợ. Nó không sửa lỗi trunk VLAN, storage, switch upstream hoặc ứng dụng bên trong VM.

Snapshot, backup và disaster recovery

Khái niệm	Mục đích	Điều không được mặc định
Snapshot	Trạng thái dữ liệu/VM tại một thời điểm, dùng để khôi phục trong phạm vi hỗ trợ.	Không mặc nhiên độc lập với backend gốc hoặc nhất quán ứng dụng.
Backup	Bản sao phục hồi có chính sách lưu giữ, vị trí lưu và quyền truy cập.	Job thành công không chứng minh mọi dữ liệu và dịch vụ đều restore được.
Replication	Duy trì bản dữ liệu ở vị trí/thiết bị khác.	Có thể nhân bản cả thao tác xóa, dữ liệu lỗi hoặc mã hóa do tấn công.
Disaster recovery (DR)	Khôi phục dịch vụ khi mất một failure domain lớn.	Không tự xuất hiện chỉ vì có hai zone hoặc snapshot định kỳ.

Thiết kế bảo vệ dữ liệu cần xét cả VM disk, database của CloudStack, cấu hình/provider, network mapping và thông tin cần để dựng lại dịch vụ. Backup database quản lý không chứa toàn bộ guest data; backup guest disk cũng không thay thế cấu hình nền tảng.

Bản backup nên được bảo vệ khỏi cùng sự cố và cùng quyền xóa với dữ liệu gốc; xem xét retention, offsite backup, immutable backup và account truy cập riêng theo khả năng hệ thống. Mức độc lập phải được đánh giá theo backend và quyền thực tế, không chỉ tên storage pool.

RPO và RTO

Chỉ số	Ý nghĩa	Yếu tố chi phối
Recovery Point Objective (RPO)	Mức mất dữ liệu tối đa chấp nhận được, tính theo thời gian.	Chu kỳ bản sao, replication lag, lần backup thành công và tính nhất quán.
Recovery Time Objective (RTO)	Thời gian tối đa chấp nhận để phục hồi dịch vụ.	Phát hiện, quyết định, fencing, cấp phát, restore, khởi động và kiểm tra ứng dụng.

Lịch backup mỗi 15 phút không bảo đảm RPO 15 phút nếu job thất bại hoặc bản sao không sử dụng được. RTO không chỉ là thời gian boot VM: còn truyền dữ liệu, database recovery, đổi route/DNS và xác nhận user truy cập được.

Restore, failover và failback

Restore phải được xác nhận theo các lớp: dữ liệu đọc được, filesystem hợp lệ, database nhất quán, ứng dụng vận hành và kết nối phụ thuộc đúng. Việc chỉ thấy VM Running là chưa đủ.

Failover đưa dịch vụ sang nơi dự phòng; failback đưa dịch vụ trở lại nơi chính. Sau failover có thể đã phát sinh dữ liệu mới, nên không thể đơn giản quay về bản cũ ở nơi chính. Phải xác định authoritative copy (bản dữ liệu được chọn làm nguồn chuẩn), đồng bộ phần thay đổi và tránh hai nơi cùng nhận ghi ngoài thiết kế.

Capacity dự phòng và hiệu năng khi lỗi

Capacity cần đáp ứng cả hoạt động bình thường, bảo trì và tình huống lỗi đã chọn làm mục tiêu thiết kế. Với mục tiêu chịu lỗi một host, phần tài nguyên còn lại sau khi mất host phải chứa được workload cần phục hồi, các System VM và phần dự phòng vận hành.

Tính theo từng host và nhóm ứng viên hợp lệ, không chỉ tổng CPU/RAM của zone.
Xét host/storage tags, anti-affinity, dedication, kiến trúc CPU và các giới hạn placement khác.
Dành capacity cho snapshot, rebuild, migration, tăng trưởng dữ liệu và tác vụ bảo trì.
Đánh giá latency/IOPS và network throughput trong trạng thái suy giảm, không chỉ khi mọi thành phần đều hoạt động.

Bond mất một link có thể vẫn giữ kết nối nhưng không còn đủ băng thông. Storage mất một phần replica có thể vẫn phục vụ song chậm hơn vì phục hồi. “Còn hoạt động” và “đáp ứng mức dịch vụ” là hai tiêu chí khác nhau.

Giám sát, bảo mật và bảo trì

Quan sát và suy luận sự cố

Kết hợp trạng thái CloudStack, số đo hạ tầng và kiểm tra chức năng ứng dụng. Các lớp này bổ sung cho nhau; không lớp nào đủ để chứng minh toàn bộ dịch vụ hoạt động bình thường.

Thành phần	Tín hiệu cần quan sát	Tác động điển hình khi lỗi
Management Server / database	API latency, kết nối DB, hàng đợi/tác vụ, lỗi điều phối.	Tạo/sửa tài nguyên bị lỗi hoặc chậm.
KVM host	Agent, libvirt, CPU pressure, RAM, NIC và I/O.	Placement, thao tác VM hoặc chính workload bị ảnh hưởng.
Primary storage	Space, latency, IOPS, đường truy cập và trạng thái backend.	VM chậm, lỗi I/O hoặc dừng dịch vụ.
Secondary storage / SSVM	Dung lượng, kết nối, trạng thái transfer và job xử lý image/snapshot.	Deploy từ template, sao chép hoặc restore thất bại.
VR / network provider	Dịch vụ, interface, route, IP pool và rule.	Một hoặc nhiều chức năng mạng tenant bị gián đoạn.
CPVM	Kết nối proxy/console và trạng thái VM hạ tầng.	Không mở được console, dù guest có thể vẫn phục vụ.
Ứng dụng	Endpoint thực, truy vấn dữ liệu và giao dịch mẫu.	Phát hiện lỗi mà trạng thái hạ tầng không thể hiện.

Event mô tả hành động hoặc thay đổi trạng thái; alert chỉ ra điều kiện cần chú ý. Nhiều alert có thể là hệ quả của cùng một lỗi nền. Trạng thái trên UI cũng có thể chậm hơn tình trạng thực khi mất liên lạc.

Liên kết bằng chứng giữa các lớp

Async job ID, resource ID/UUID, host và thời điểm là các thông tin để đối chiếu sự kiện điều phối với log host. Đồng bộ thời gian giúp dựng đúng chuỗi sự kiện; cần phân biệt thời điểm bắt đầu lỗi với thời điểm hệ thống phát hiện.

Log Management Server thường ở /var/log/cloudstack/management/management-server.log; log KVM agent nằm trong /var/log/cloudstack/agent/. Log libvirt/QEMU và guest thuộc các lớp khác, cần khớp VM/host tương ứng. Một thông báo “deploy failed” chỉ là kết quả tổng hợp, không thay thế nguyên nhân ở bước con.

Trước khi restart hàng loạt, cần giữ lại trạng thái và bằng chứng đủ để phân biệt lỗi quyền, limit, placement, template, storage và network. Restart có thể làm mất dấu hoặc tạo thêm sự kiện, dù không xử lý nguyên nhân.

Bảo mật theo lớp

Quyền, danh tính và API

Áp dụng quyền tối thiểu theo account/domain/project và role. Các user khác nhau trong cùng account không tự tạo ranh giới sở hữu tài nguyên độc lập. Quyền sử dụng network không nhất thiết bao gồm quyền sửa rule hoặc restart network.

API key và secret key là thông tin xác thực nhạy cảm; chữ ký yêu cầu không thay thế HTTPS hoặc phân quyền. Tách danh tính tự động hóa theo nhiệm vụ, giới hạn quyền, quản lý vòng đời, thực hiện key rotation và thu hồi key khi không còn dùng. Không nhúng secret vào golden image, tài liệu công khai hoặc user data dùng lâu dài.

Mạng quản trị và chuỗi tin cậy

Management Server, database, agent/libvirt và giao diện storage cần được giới hạn vào các mạng, nguồn truy cập và người quản trị phù hợp. Public access cho dịch vụ guest không phải lý do mở toàn bộ management plane ra ngoài. Bastion/VPN và TLS phải được thiết kế cùng quy trình quản lý certificate.

Không suy ra mọi kênh đều đã được mã hóa chỉ vì UI dùng HTTPS. Kiểm tra cơ chế CA/certificate, kết nối agent, cấu hình cũ sau nâng cấp và giao thức của backend theo triển khai thực tế.

System image, dữ liệu và audit log

Dùng System VM template đúng nguồn, phiên bản và hypervisor; cập nhật host, guest image và VM hạ tầng theo chính sách hỗ trợ. Tách quyền quản lý backup khỏi quyền vận hành workload khi phù hợp; bảo vệ cả dữ liệu, khóa mã hóa và khả năng restore.

Log tập trung giúp truy vết nhưng cũng có thể chứa thông tin nhạy cảm. Cần giới hạn người đọc, thời gian lưu, tránh ghi secret và theo dõi thao tác API/quản trị có tác động lớn.

Bảo trì và nâng cấp

Host maintenance cần có đích phù hợp cho VM, disk và network trước khi rút host khỏi phục vụ. Không phải VM nào cũng live migrate được. Restart agent, reboot hypervisor và reboot guest là các thao tác khác nhau với phạm vi tác động khác nhau.

Nâng cấp CloudStack liên quan nhiều lớp: package Management Server, schema database, agent, System VM template, hypervisor và plugin. Đường nâng cấp được hỗ trợ cùng thứ tự thực hiện phải được xác nhận cho đúng phiên bản; có nhiều Management Server không mặc nhiên cho phép rolling upgrade không gián đoạn.

Ví dụ, hướng dẫn nâng cấp từ 4.20.x lên 4.20.1.0 yêu cầu dừng các Management Server và backup database trước các bước nâng cấp tương ứng. Đây là lý do cần theo hướng dẫn nâng cấp chính thức cho đúng release, thay vì chỉ cập nhật package đang chạy.

Rollback package không đủ nếu database schema hoặc dữ liệu đã thay đổi. Phương án rollback phải phù hợp cả trạng thái nền tảng lẫn dữ liệu phát sinh sau thay đổi; backup và khả năng restore là điều kiện thiết kế, không chỉ một mục đánh dấu trước nâng cấp.