ZStack Cloud Platform
Single Server, Free Trial for One Year
-
Documentation&Tools
Comprehensive product documentation and tools
-
Support & Services
Upholding the value of Customer First and the mission of Serving Customer, ZStack is dedicated to providing secure and stable services for customers.
-
Training & Certification
To educate ZStack partners and interested individuals about cloud computing and to cultivate cloud computing talent.
-
Content
ZStack provides innovative cloud infrastructure for ten major industries
VMware-to-ZStack Case Collection
The report provides three major
solutions and customer case studies for transitioning from VMware to ZStack.
ZStack Cloud 5.4.0>ZStack Cloud Product Manuals>ZStack Cloud Technical Whitepaper>Product Architecture
Product Architecture
Software Architecture
ZStack Cloud software architecture highlights:
- Fully Asynchronous Architecture: Asynchronous messaging, methods, and HTTP calls.
- Asynchronous messaging: Services communicate via a message bus. When calling a service, the source service sends a message to the destination service, registers a callback function, and returns immediately. Upon task completion, the destination service triggers the callback with results. Asynchronous messages can be processed in parallel.
- Asynchronous methods: Services communicate through asynchronous messages. Components or plugins inside each service use asynchronous method calls, following the same pattern as asynchronous messaging.
- Asynchronous HTTP calls: Each plugin has an agent that puts a callback URL in the HTTP header of every request. After task completion, the agent sends the response to the caller's URL.
- Based on these three asynchronous approaches, ZStack Cloud builds a layered architecture to ensure all components operate asynchronously.
- With this fully asynchronous architecture, a single management node can process tens of thousands of concurrent API requests per second, while managing tens of thousands of hosts and hundreds of thousands of VM instances.
- Stateless Service: Each request is independent.
- Compute node agents, storage agents, network services, console proxy services, and configuration services require no inter-request dependencies. Every request carries complete context and no node needs to maintain or store any information.
- Resources such as management nodes and compute nodes are authenticated via UUID-based consistent hashing ring. Message senders do not need to know specific service instances, and services simply process messages without maintaining or exchanging resource information.
- Little information is shared among 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 servers 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 ensures all messages of the same resource are always processed by the same service instance. This message aggregation to specific nodes reduces synchronization and parallel processing complexity.
- Work queues replace lock contention. Serial tasks are stored in memory as work queues, which can process any operation on any resource in parallel to improve system parallelism.
- The queue-based lock-free architecture enables tasks to run in parallel, thereby improving the system performance.
- In-Process Microservices: Decoupled microservices.
- A message bus isolates and controls services, such as VM instance services, identity authentication services, snapshot services, volume services, network services, and storage services. All microservices are enclosed in the management node process. These services communicate with each other through the message bus. All messages are first sent to the message bus, then forwarded to the destination service using consistent hashing ring.
- In-process microservices adopt a star-like architecture where each service runs independently. This architecture decouples the highly centralized control business, achieving high autonomy and isolation. Service failures will not affect other components, ensuring system reliability and stability.
- Versatile Plugin System: Horizontally scalable plugins.
- Every plugin provides services independently. Any newly added plugin has no impact on other existing plugins.
- Plugins support both Strategy Pattern and Observer Pattern designs. Strategy plugins inherit parent-class interfaces to implement specific functions. Observer plugins register Listeners to monitor event changes of the internal business logic in an application. When events occur, the observer plugins will automatically respond and trigger corresponding business flow.
- This horizontal plugin scalability enables ZStack Cloud to rapidly upgrade while maintaining robust system architecture.
- Workflow Engine: Sequence-based management and error rollback.
- Every workflow is clearly defined in XML. If error occur at any step, the workflow rolls back along the original executed path and cleans up the garbage resources.
- Each workflow can contain sub-workflows for extended business logic implementation.
- Tag System: Enables business logic change and resource attributes.
- Extend or modify business logic dynamically using system tags and plugin mechanisms.
- Group and categorize resources with tags, enabling resource searches by specific tags.
- Cascade Framework: Supports chained resource operations.
- The Cascade framework manages resources through waterfall-like chained operations. For example, uninstalling or deleting a resource triggers corresponding cascading operations on related resources.
- Resources can be added to the Cascade framework as plugins. Their addition or removal does not affect other resources.
- The cascading mechanism enables flexible and lightweight resource configuration, allowing rapid adaptation to customer configuration changes.
- Automated Deployment: Agentless auto-deployment with Ansible.
- Leverages agentless Ansible to automate dependency installation, physical resource configuration, and agent deployment. The whole process is transparent to users and requires no additional intervention. You can upgrade your agents simply by reconnecting the agents.
- Comprehensive Query APIs: Access any attribute of any resource.
- Supports resource queries with millions of conditions, comprehensive query APIs, and any way of condition combinations.
Functional Architecture
ZStack Cloud functional architecture highlights:
- ZStack Cloud provides enterprise-grade data center infrastructure services for compute, storage, and network resource management. ZStack Cloud supports both KVM and VMware virtualization technologies at its foundation. ZStack Cloud supports DAS, NAS, SAN, and DSS storage types, including local storage, NFS storage, SAN storage, and distributed storage. ZStack Cloud supports network models like NoVLAN, VLAN, VXLAN, and SDN.
- With ZStack Cloud as its core engine, the platform uses a message bus to communicate with MariaDB database and service modules. Key functionalities include VM instance management, host management, storage scheduling, network services, account billing, monitoring and auditing, and more.
- ZStack Cloud provides Java and Python SDKs and RESTful APIs for resource scheduling and management.
Resource Structure
ZStack Cloud resource structure highlights:
- ZStack Cloud is essentially a resource configuration management system.
- ZStack Cloud mainly has the following resources:
- Zone: The largest resource scope defined in ZStack Cloud, including clusters, L2 networks, primary storages, and other resources.
- Cluster: A logical group of hosts (compute nodes).
- Host: A physical server that provides compute, network, and storage resources for VM instances.
- Primary Storage: One or more servers that store volume files of VM instances. These files include root volume snapshots, data volume snapshots, image caches, root volumes, and data volumes.
- Image Storage: A storage server that stores VM image templates, including ISO image files.
- VXLAN Pool: A collection of VXLAN networks established based on VXLAN Tunnel Endpoints (VTEPs). The VNI of each VXLAN network in a VXLAN pool must be unique.
- 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.
- L3 Network: A collection of network configurations for VM instances, including the IP address ranges, gateway, DNS, and more.
- Instance Offering: Defines the number of vCPU cores, memory size, network bandwidth, and other configuration settings of VM instances.
- Disk Offering: Defines the capacity and other configuration settings of volumes.
- VM Instance: A virtual machine instance running on a host. A VM instance has its own IP address to access public networks and can run application services.
- Image: A template file used to create a VM instance or volume. Images are categorized into system images and volume images.
- Root Volume: Provides support for the system operations of a VM instance.
- Data Volume: Provides extended storage space for a VM instance.
- Snapshot: A point-in-time capture of data status in a volume.
- Network Service Module: A module to provide network services. This module 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, flow monitoring, and shared bandwidth.
- Firewall: An access control policy that monitors ingress and egress traffic of VPC vRouters and decides whether to allow or block specific traffic based on the associated rule sets and rules.
- Security Group: Provides security control services for VM NICs. It filters the ingress or egress TCP, UDP, and ICMP packets of VM NICs based on the specified security rules.
- vRouter Offering:Ddefines the number of vCPU cores, memory size, image, management network, and public network configuration settings of VPC vRouters. You can use a vRouter offering to create VPC vRouters that can provide network services for public networks and VPC networks.
- VPC vRouter: A dedicated VM instance that provides multiple network services.
- Relationships between resources:
- Parent-Child: A resource can be the parent or child of another resource. For example, a cluster and its hosts, or a host and its VM instances.
- Sibling: Resources sharing the same parent are siblings. For example, clusters and L2 networks, or clusters and primary storage.
- Ancestor-Descendant: A resource can be a direct ancestor or descendant of another resource. For example, a cluster and its VM instances, or a zone and its hosts.
- Friend: Some resources, while not directly related in the above ways, collaborate in certain scenarios. For example, primary storage and image storage, or zones and image storage.
Note: Relationships between primary storage and image storage: - When you create a VM instance, the primary storage downloads VM instance images as caches from the image storage.
- When you create an image, the primary storage copies the root volume to the image storage and save it as a template.
- Resources contain the following basic attributes:
- UUID: Universally Unique Identifier (UUIDv4) that uniquely identifies a resource.
- Name: a human-readable string for resource identification. Names can be duplicated and are usually required.
- Description: Optional. A brief introduction to a resource.
- Creation Time: The date and time when a resource was created.
- Last Operation Time: The date and time when a resource was updated last time.
- Resources typically support 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 a cascade framework, deleting a parent resource also deletes associated child resources and descendant resources.
Next Chapter: Resource Virtualization