ZStack Cloud 4.4.0>Product Manuals>zstack-cli Command Manual>System Architecture

System Architecture

ZStack Cloud is a next-generation product-level Private Cloud management platform that aims to manage various resources, such as compute, storage, and network resources in data centers by providing flexible and comprehensive APIs.

ZStack Cloud Functional Architecture

The functional architecture of ZStack Cloud is shown in Figure 1.

ZStack Cloud helps enterprises better manage their infrastructure resources, such as the compute, storage, and network resources, in their data centers. The bottom layer of ZStack Cloud supports both KVM and VMware virtualization technologies. In addition, ZStack Cloud supports various storage types, such as DAS, NAS, SAN, and DFS. To be more specific, local storage, NFS storage, SAN storage, and distributed block storage are supported. ZStack Cloud also supports various network models, such as VLAN and VXLAN.

ZStack Cloud communicates with the MariaDB database and other service modules by using a message bus, providing diversified features such as VM instance management, host management, storage management, network management, billing management, and real-time monitoring. In addition, ZStack Cloud provides Java SDKs and Python SDKs, and allows you to schedule and manage resources by using RESTful APIs. With ZStack Cloud, you can build a private cloud that is simple, strong, scalable, and smart.

Highlights of ZStack Cloud functional architecture:

Asynchronous Architecture: asynchronous message, asynchronous method, and asynchronous HTTP call
- ZStack Cloud connects various services by using a message bus. When a service calls another service, the source service sends a message to the destination service, registers a callback function, and then returns back immediately. Once the destination service finishes the task, it gives a feedback on the task result by triggering the callback function that was registered by the source service. Asynchronous messages can be processed in parallel.
- Services in ZStack Cloud communicate with each other through asynchronous messages. The components and plugins inside each service are also called by using the asynchronous method, which is the same as calling asynchronous messages.
- Every plugin in ZStack Cloud has a corresponding agent. ZStack Cloud puts a callback URL in the HTTP header of every request. Therefore, agents can send responses to the URL of the caller when tasks are finished.
- Based on the asynchronous message, asynchronous method, and asynchronous HTTP call, ZStack Cloud builds a layered architecture to ensure that asynchronous operations can be performed on all components.
- Based on the asynchronous architecture, ZStack Cloud with a single management node can process tens of thousands of concurrent API requests per second, and simultaneously manage tens of thousands of servers and hundreds of thousands of VM instances.
Stateless Service: A single request does not rely on other requests.
- In ZStack Cloud, requests sent by compute node agents, storage agents, network services, console proxy services, and configuration services can be processed without relying on other requests. The sent requests contain all the required information, and related nodes do not need to maintain or store any information.
- ZStack Cloud authenticates resources such as management nodes and compute nodes through consistent hashing ring by using their UUIDs as the unique ID. Because of the consistent hashing ring, a message sender does not need to know which service instance is about to handle the message. Services do not need to maintain or exchange information about what resources they are managing. All the services need to do is to handle the incoming messages.
- Little information is shared among ZStack Cloud management nodes. Therefore, a minimum of two management nodes can meet the requirements of high availability and scalability.
- The stateless service mechanism makes the system more robust. Restarting the server will not lose any state information. This also simplifies the scaling out and scaling in of a data center.
Lock-free Architecture: consistent hashing algorithm
- The consistent hashing algorithm guarantees all messages of the same resource are always handled by the same service instance. In this way, messages are congregated to a specified node, reducing the complexity of synchronization and concurrency.
- ZStack Cloud uses work queue to avoid lock contention. Serial tasks are stored in memory as work queues. Work queues can process any operation of any resource in parallel to improve system concurrency.
- The queue-based lock-free architecture enables tasks to run in parallel, thereby improving the system performance.
In-Process Microservices Architecture: microservices decoupling
- ZStack Cloud uses a message bus to isolate and control various services, such as VM instance services, identity authentication services, snapshot services, volume services, network services, and storage services. All microservices are enclosed in the same process of a management node. These services communicate with each other through the message bus. After all messages are sent to the message bus, the destination service is selected by the consistent hashing ring for message forwarding.
- In-process microservices provide a star-like architecture, ensuring every service in microservices to run independently. This architecture also decouples the highly centralized control business, and achieves a high degree of autonomy and isolation of the system. Failure of any service does not affect other components. This effectively guarantees the system reliability and stability.
Versatile Plugin System: supports horizontal expansion of plugins
- In ZStack Cloud, every plugin provides services independently. Any newly added plugin has no impact on other existing plugins.
- ZStack Cloud concludes plugins into two patterns: strategy pattern and observer pattern. Strategy pattern plugins will inherit parent-class interfaces and then perform specific implementations. Observer pattern plugins will register a listener to monitor event changes of the internal business logic in an application. Once an event is detected inside the application, the observer pattern plugins will respond to this event automatically and execute a piece of code to affect the corresponding business flow.
- ZStack Cloud supports horizontal expansion of plugins. The Cloud can be quickly upgraded, and the overall system architecture still remains robust.
Workflow Engine: sequence-based management, rollback on errors
- ZStack Cloud clearly defines every workflow by using XML files. Every flow can be rolled back on errors. A workflow can roll back all prior executed steps and clean up the garbage resources during the execution when an error happens in a step.
- Each workflow can contain a sub-flow to decouple the business logic further.
Tag System: extends the business logic and adds resource properties
- ZStack Cloud uses system tags and plugins to extend the original business logic.
- You can use tags to group your resources and search for resources with specific tags.
Cascade Framework: supports cascading operations on resources
- ZStack Cloud uses a cascade framework to perform cascading operations on resources. The cascade framework allows an operation to be cascaded from one resource to other resources. For example, the operation of uninstalling or deleting a resource can be cascaded to the descendant resources.
- Resources can join in a cascade framework through a plugin. Joining or quitting the cascade framework will not affect other resources.
- The cascading mechanism makes the configuration of ZStack Cloud more flexible and simple, meeting the requirements of resource configuration changes.
Full Automation By Ansible: automated deployment by agentless Ansible
- Being seamlessly integrated with Ansible (which is agentless), ZStack Cloud can automatically install dependencies, configure physical resources, and deploy agents. This whole process is transparent to users and requires no additional intervention. You can upgrade your agents simply by reconnecting the agents.
Comprehensive Query API: Every property of every resource can be queried.
- ZStack Cloud supports millions of query conditions, comprehensive query APIs, and any way of condition combinations.

ZStack Cloud Resource Model

ZStack Cloud is essentially a configuration management system for resources in the Cloud. The following figure describes the resource model managed by ZStack Cloud, as shown in Figure 1.

ZStack Cloud mainly has the following resources:

Zone: the largest resource scope defined in ZStack Cloud. A zone is a logical group of resources, such as clusters, L2 networks, and primary storages.
Cluster: a logical group of analogy hosts (compute nodes).
Host: also known as a compute node, is a physical server that provides VM instances with compute, network, and storage resources.
Primary storage: a storage system that stores VM disk files, including root volumes, data volumes, root volume snapshots, data volume snapshots, and image caches. Supported primary storage types include local storage, NFS, SharedMountPoint, SharedBlock, and Ceph.
Backup storage: a storage system that stores image templates. Supported backup storage types include ImageStore, SFTP, and Ceph.
VXLAN pool: an underlay network in VXLAN. You can create multiple VXLAN overlay networks (VXLAN) in a VXLAN pool. The overlay networks can operate on the same underlay network device. Supported VXLAN pool types include software SDN and hardware SDN.
L2 network: a layer 2 broadcast domain used for layer 2 isolation. Generally, L2 networks are identified by names of devices on the physical network. Supported L2 network types include L2NoVlanNetwork, L2VlanNetwork, VxlanNetwork, and HardwareVxlanNetwork.
L3 network: a collection of network configurations for VM instances, including the IP range, gateway, DNS, and network services.
Instance offering: a specification that defines the number or size of CPU, memory, disk bandwidth, and network bandwidth for a VM instance.
Disk offering: a specification of a volume, which defines the size of a volume and how the volume will be created.
VM instance: a virtual machine instance running on a host. A VM instance has its own IP address to access public network and run application services. VM instances are core components of ZStack Cloud.
Image: an image template used by a VM instance or volume. Image template includes root volume images and data volume images. The types of root volume image include ISO and Image, while the type of data volume image is Image.
Root volume: the system disk where the VM operating system is installed.
Data volume: the data disk that provides additional storage for a VM instance.
Snapshot: a point-in-time capture of data in a disk. Snapshots are captured incrementally.
Network service module: a module for providing network services. This resource is hidden in the UI.
Network service: provides various network services for VM instances, including VPC firewall, security group, virtual IP (VIP), elastic IP (EIP), port forwarding, load balancing, IPsec tunnel, and flow monitoring.
VPC firewall: manages north-south traffic of the VPC network. You can manage the network access policy by configuring rule sets and rules.
Security group: provides L3 network firewall control over the VM instances, and controls TCP, UDP, and ICMP data packets for effective filtering. You can use a security group to effectively control specified VM instances on specified networks according to specified security rules.
vRouter offering: an instance offering that defines the number of vCPU cores, memory size, image, management network, and public network configuration settings of VPC vRouters.
VPC vRouter: a router created directly from a vRouter offering. VPC vRouter, which has a public network and a management network, is the core of VPC. VPC vRouters provide various network services, including DHCP, DNS, SNAT, route table, EIP, port forwarding, load balancing, IPsec tunnel, dynamic routing, multicast routing, VPC firewall, and Netflow.

The resource relationships in ZStack Cloud are as follows:

Parent-child: A resource can be the parent or child of another resource. For example, a host is the child resource of a cluster and the parent resource of a VM instance.
Sibling: Resources sharing the same parent resource are siblings. For example, clusters and L2 networks are sibling resources because all of them are child resources of a zone.
Ancestor-descendant: A resource can be the lineal ancestor or lineal descendant of another resource. For example, a cluster is the ancestor resource of a VM instance, while a host is a descendant resource of a zone.
Friend: Resources that do not have the above three relationships but still need to cooperate with each other in some scenarios are friends. For example, primary storages and backup storages are friends. Also, zones and backup storages are friends.
Note: Relationship between primary storages and backup storages:
- When you create a VM instance, the primary storage needs to download images of the VM instance as caches from the backup storage.
- When you create an image, the primary storage needs to copy the root volume to the backup storage and save it as a template.

The following properties are common to almost all resources in ZStack Cloud:

UUID: the universally unique identifier. ZStack Cloud uses version 4 UUIDs to uniquely identify a resource.
Name: a human readable string that is used to identify resources. Names can be duplicated and are usually required.
Description: also known as a brief introduction that is used to briefly describe a resource. Description is usually optional.
Creation date: the date and time when a resource was created.
Last operation date: the date and time when a resource was updated last time.

Resources in ZStack Cloud support full or partial Create, Read, Update, Delete (CRUD) operations.

Create: create or add a new resource.
Read: read or query information about a resource.
Update: update information about a resource.
Delete: delete a resource. Due to the cascade framework provided by ZStack Cloud, if a parent resource is deleted, its associated child resources and descendant resources will also be deleted.

Next Chapter:Command Line Tool