ZStack 3.10.0>Product Manuals>Maintenance Manual>System Architecture

System Architecture

ZStack 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 Functional Architecture

The functional architecture of ZStack is shown in Figure 1.

ZStack helps enterprises better manage infrastructure resources, such as the compute, storage, and network resources, in their data centers. The bottom layer of ZStack supports both KVM and VMware virtualization technologies. In addition, ZStack 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 also supports various network models, such as VLAN and VXLAN.

ZStack uses a message bus to communicate with the MariaDB database and different service modules, providing diversified features such as VM instance management, host management, storage management, network management, billing management, and real-time monitoring. That is the core Cloud engine of ZStack. In addition, ZStack provides Java SDKs and Python SDKs, and allows you to schedule and manage resources by using RESTful APIs. With ZStack, you can build a private Cloud that is Simple, Strong, Scalable, and Smart.

Highlights of ZStack functional architecture:

Asynchronous Architecture: asynchronous message, asynchronous method, and asynchronous HTTP call
- ZStack uses a message bus to connect various services. 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 communicate with each other through asynchronous messages. Inside services, the associated components and plugins are also called by using asynchronous methods. These methods are consistent with that of calling asynchronous messages.
- Every plugin in ZStack has a corresponding agent. ZStack 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 asynchronous message, asynchronous method, and asynchronous HTTP call, ZStack builds a layered architecture to ensure that asynchronous operations can be performed on all components.
- Based on the asynchronous architecture, a single ZStack 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, requests sent by compute node agents, storage agents, network services, console agent 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 and store any information.
- ZStack 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 and 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 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 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 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, every plugin provides services independently. Any newly added plugin has no impact on other existing plugins.
- ZStack 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 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 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.
- Every workflow can contain sub-flow to decouple the business logic further.
Tag System: extends the business logic and adds resource properties
- ZStack 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 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 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 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 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 supports millions of query conditions, comprehensive query APIs, and any way of condition combinations.

ZStack Resource Model

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

ZStack mainly has the following resources:

Zone: the largest resource scope defined in ZStack. 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 disk files, including root volumes, data volumes, root volume snapshots, data volume snapshots, and image caches, for VM instances. The types of primary storage include local storage, NFS, Shared Mount Point, SharedBlock, and Ceph.
Backup storage: a storage system that stores image templates. The types of backup storage 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. The types of VXLAN pool 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. The types of L2 network 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 of the VM instance CPU, memory, disk bandwidth, and network bandwidth.
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.
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 instance 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.
Virtual router offering: an instance offering that defines the CPU, memory, virtual router (vRouter) image, management network, and public network used by a vRouter (including ordinary vRouter, VPC vRouter, and ARM vRouter).
Virtual router (vRouter): a custom Linux VM instance that provides network services such as DHCP, DNS, SNAT, route table, EIP, port forwarding, load balancing, and IPsec tunnel.
VPC vRouter: a router created directly from vRouter offering. VPC vRouter, which has a public network and a management network, is the core of VPC. VPC vRouter provides 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 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 cluster, while a host is the parent resource of 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 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 VM instance, while a host is a descendant resource of 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 storage and backup storage are friends. Also, zone and backup storage are friends.
Note: Relationship between primary storage and backup storage:
- When you create a VM instance, primary storage needs to download images of the VM instance as caches from backup storage.
- When you create an image, primary storage needs to copy the root volume to backup storage and save it as a template.

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

UUID: the universally unique identifier. ZStack 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 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, if a parent resource is deleted, its associated child resources and descendant resources will also be deleted.

Next Chapter:Network Configuration

System Architecture

ZStack Functional Architecture

ZStack Resource Model

Products

Solutions

Help & Support

Contact Us