• For LocalStorage primary storage, the volume is created on the primary storage with the largest available space by default.
• For NFS primary storage, the volume is created on a random primary storage by default.
• For the combination of LocalStorage and NFS primary storage or the combination of LocalStorage and SharedMountPoint (SMP) primary storage, by default, the volume is created on a primary storage that does not store the root volume of the VM instance.

• Four types of VM scheduling policies: VM Exclusive from Each Other, VM Affinitive to Each Other, VMs Exclusive from Hosts, and VMs Affinitive to Hosts.
  • VM Exclusive from Each Other: VM instances in the same VM scheduling group should not/must not run on the same host.
  • VM Affinitive to Each Other: VM instances in the same VM scheduling group should/must run on the same host.
  • VMs Exclusive from Hosts: Given any one of the VM instances in a VM scheduling group and any one of the hosts in a host scheduling group, the VM instance should not/must not run the host.
  • VMs Affinitive to Hosts: Given any one of the VM instances in a VM scheduling group and any one of the hosts in a host scheduling group, the VM instance should/must run the host.
• A VM scheduling policy can be executed based on either of the two execution mechanisms: Hard and Soft. Hard execution mechanism requires VM instances to strictly comply with their associated scheduling policies, while Soft execution mechanisms allows for some flexibility in policy execution when the hosts do not have sufficient resources.
  • Hard: VM instances are forcibly assigned to hosts based on the associated VM scheduling policies. For example, if you associate the VM Exclusive from Each Other policy with a VM scheduling group and select the Hard mechanism for the policy, any two of the VM instances in the scheduling group are not allowed to run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will end up failure upon startup.
  • Soft: VM instances are primarily assigned to hosts based on the associated VM scheduling policies. For example, if you associate the VM Exclusive from Each Other policy with a VM scheduling group and select the Soft mechanism for the policy, any two of the VM instances in the scheduling group will primarily not run on the same host. If no host is available to be scheduled based on the policy for a VM instance, the VM instance will attempt to run on a host that does not satisfy the policy.

• A VM instance can only be added to one VM scheduling group. After the addition, the VM instance will be scheduled based on the associated scheduling policies.
• A VM scheduling group can associate with one or more scheduling policies.
• A scheduling policy can associate with one VM scheduling group.
• Deleting a VM scheduling group also deletes its associated VM scheduling policies.

• A host can only be added to one host scheduling group. After the addition, the host will be scheduled based on the associated scheduling policies.
• A host scheduling group can associate with one or more scheduling policies.
• A scheduling policy can associate with one VM scheduling group.
• Deleting a host scheduling group also deletes its associated VM scheduling policies.

• If Host3 has sufficient resources, VM3 can start and run normally on Host3.
• If Host3 does not have sufficient resources, then VM3 cannot start.

• If Host3 has sufficient resources, VM3 can start and run normally on Host3.
• If Host3 does not have sufficient resources, VM3 tries to start on other host that has available resources. In this scenario, VM3 starts and runs on Host2.

• If Host1 has sufficient resources, VM3 can start and run normally on Host1.
• If Host1 does not have sufficient resources, VM3 cannot start.

• If Host1 has sufficient resources, VM3 can start and run normally on Host1.
• If Host3 does not have sufficient resources, VM3 tries to start on other host that has available resources. In this scenario, VM3 starts and runs on Host2.

• If Host1 has sufficient resources, VM3 can start and run normally on Host1.
• If Host1 does not have sufficient resources, VM3 cannot start.

• If Host1 has sufficient resources, VM3 can start and run normally on Host1.
• If Host1 does not have sufficient resources, VM3 tries to start on other host that has available resources. In this scenario, VM3 starts and runs on Host2.

• If Host2 or Host3 have sufficient resources, VM6 can start and run normally on Host2 or Host3.
• If Host2 and Host3 do not have sufficient resources, VM6 cannot start.

• If Host2 or Host3 have sufficient resources, VM6 can start and run normally on Host2 or Host3.
• If both Host2 and Host3 do not have sufficient resources, VM6 tries to start on other host that has available resources. In this scenario, VM6 starts and runs on Host1.

• ZStack Cloud provides four types of scheduling policies matched with two execution mechanisms to define mutual exclusion/affinity relationships between VM instances and between VM instances and hosts. Various scheduling policies can be flexibly combined to meet the needs of all mainstream business scenarios.
• ZStack Cloud supports the association of one or more scheduling policies with multiple VM instances in the VM scheduling group, as well as the removal of these policies from the VM instances in the VM scheduling group, which is simple and efficient.
• ZStack Cloud intuitively displays the VM scheduling status and provides quick conflict resolution operations to facilitate users to grasp business scheduling dynamics in real time and make timely adjustments.

• ZStack Cloud supports exclusion/affinity between the same/different businesses, achieving business isolation/efficient communication and ensuring high business performance and reliability.
• You can flexibly configure the failure domains in VM businesses through host scheduling groups. ZStack Cloud supports single host deployment, batch hosts deployment within a single cluster, and cross-cluster hosts deployment to avoid single point of failure. This ensures business stability and improves physical resource utilization.

• The management networks you add in Resource Pool > Network Resource > Dedicated Network comply with the management network definition here.
• The host IP addresses displayed on ZStack Cloud belong to the management network.
• The host callback IP addresses belong to the management network.

• If you add a management network in Resource Pool > Network Resource > Dedicated Network, the NIC port of the L2 network it belongs to is attached with a management network tag.
• The NIC port of the network to which a host IP address belongs is attached with a management network tag.
• The NIC port of the network to which a host callback IP address belongs is attached with a management network tag.

• Software SDN:
  • The VNI range of a software-SDN VXLAN pool can be 1-16777214.
  • Hosts in the cluster to which the software-SDN VXLAN pool is attached must have an IP address as a VXLAN tunnel endpoint (VTEP) in the specified CIDR.
    • Generally, a VTEP corresponds to a NIC IP of a compute node within a cluster. On the Cloud, you can configure a VTEP according to its CIDR. For example,
      • Assume that the NIC IP of a compute node is 10.12.0.8, the netmask is 255.0.0.0, and the gateway is 10.0.0.1. Then, the CIDR of the VTEP is 10.0.0.1/8.
      • Assume that the NIC IP of the compute node is 172.20.12.13, the netmask is 255.255.0.0, and the gateway is 172.20.0.1. Then, the CIDR of the VTEP is 172.20.0.1/16.
    • When a VXLAN pool is attached to a cluster, the IP address that is associated to the VTEP will be checked without checking physical L2 devices.
• Hardware SDN:
  • Before you can create a hardware-SDN VXLAN pool, add an SDN controller to the Cloud in advance.
  • The VNI range of a hardware-SDN VXLAN pool depends on the distributed vSwitch to which an SDN controller corresponds.
  • The host NIC in the cluster to which the hardware-SDN VXLAN pool is attached must connect to a switch managed by the SDN controller.
  • If you use VCFC to configure hardware SDN, configure the mapping between VLAN and VXLAN on VCFC in advance.

• A public network can be used in the flat network environment to create VM instances.
• A public network can be used in the VPC network environment to create VM instances that work with public networks.

• A flat network supports multiple network services, including DHCP, User Data, EIP, security group, and port mirroring.
• The network services provided by a flat network use the distributed DHCP and the distributed EIP structure.
• The DHCP service provided by a flat network also includes the DNS feature.
• The network model used in the wizard is a flat network.
• The flat network architecture based on VxlanNetwork or HardwareVxlanNetwork is supported.

• A VPC network provides the following network services: DHCP, User Data, DNS, SNAT, route table, EIP, port forwarding, load balancing, IPsec tunnel, security group, dynamic routing, multicast routing, VPC firewall, port mirroring, and netflow.
• The DHCP service of the VPC network uses DHCP by default.
• VPC networks mainly use custom Linux VM instances as VPC vRouters to provide network services.
• Network services can act on multiple subnets of a VPC at the same time, further improving network efficiencies.
• Supports VxlanNetwork-based VPC network architecture.
• Supports distributed routing, optimizing east-west network traffic and effectively reducing network latency.

• Management network: A management network is used to manage physical resources in the Cloud. For example, you can create a management network to manage access to hosts, primary storages, backup storages, and VPC vRouters.
  Note: When you create a VPC vRouter, you need an IP address that can be interconnected between the management nodes of the VPC vRouter. With this IP address, you can deploy an agent and obtain messages returned by the agent.
• Flow network: A flow network is a dedicated network for port mirror transmission. You can use a flow network to transmit the mirrors of data packets of NIC ports to the target ports. A flow network cannot be used for other purposes, such as creating VM instances.

• Storage network: A storage network is the network specified by the shared storage. You can use a storage network to check the health state of a VM instance. We recommend that you plan for an independent storage network in advance to avoid potential risks.
• VDI network: When you create a cluster, you can specify CIDR for the VDI network in the cluster. In the VDI scenario, the network traffics generated by the protocol communication between the server side and client side use the VDI network. If you do not make any configuration to the VDI network, notice that the management network will be used by default.
• Migration network: When you create a cluster, you can specify CIDR for the migration network in the cluster. The migration network is used to migrate VM instances in the Cloud. If you do not make any configuration to the migration network, notice that the management network will be used for VM migrations.
• Image synchronization network: An image synchronization network is used to synchronize images among ImageStore backup storages in the same management node.
  • If you deployed an independent network for synchronizing images, you can specify CIDR for the image synchronization network when you add an ImageStore backup storage.
  • If you do not make any configuration to the image synchronization network, notice that the management network will be used by default.
  • If you set an image synchronization network for both the source ImageStore backup storage and target one, only the image synchronization network in the target ImageStore backup storage takes effect.
• Data network: A data network is the network where data can transfer between a compute node and a backup storage.
  • Using an independent data network can avoid network congestion and improve the data transfer rate.
  • If you do not make any configuration to the data network, notice that the management network will be used by default.
• Backup network: If you are using the Backup Service or the Continuous Data Protection (CDP) service, in the local backup scenario,both the data backup and recovery are implemented by using the backup network.
  • If you deploy an independent network for local backups, you can specify CIDR for the backup network when you add a local backup server.
  • Using an independent backup network can avoid network congestion and improve the data transfer rate.
  • If you do not make any configuration to the backup network, notice that the management network will be used for local backup by default.
  Note:

  The Backup Service and the CDP Service are separately provided in a separate module. To use this feature, purchase both the Base License and the Plus License. Note that a Base License is required before you can install a Plus License.

• User Data: Customizes some parameters, such as ssh-key injection. By running cloud-init, these parameters will be loaded and injected into your VM instance when the VM instance is started.
• EIP: Allows you to access private networks through public networks.
• DHCP: Dynamically obtains an IP address.
  Note: The DHCP service includes the DNS feature.

• Security group: Manipulates securities of VM instance firewalls by using iptables.

• User Data: Customizes some parameters, such as ssh-key injection. By running cloud-init, these parameters will be loaded and injected into your VM instance when the VM instance is started.
• DHCP: Dynamically obtains an IP address.

• DNS: Uses vRouters to provide the DNS service.
• SNAT: Allows VM instances to access directly the Internet.
• vRouter route table: Manages custom routes.
• EIP: Uses vRouters to access private networks of VM instances through public networks.
• Port forwarding: Forwards port traffics of specified public IP addresses to the ports of corresponding VM instances according to specified protocols.
• Load balancing: Distributes inbound traffics from a VIP to a set of backend VM instances. Then, unavailable VM instances will be detected and isolated automatically.
• IPsec: Achieves VPN connections.

• Security group: Manipulates securities of VM instance firewalls by using iptables.

• Ingress Rule: Ingress rules take effect on flows accessing VM NICs. They are responsible for filtering ingress flow sources.
• Egress Rule: Egress rules take effect on flows out of VM NICs. They are responsible for filtering egress flow destinations.

• IP address as source: A source IP is filtered by ingress rules. The rules may allow or reject the flows from this IP address to access VM NICs.
• Security group as source: A source security group is filtered by ingress rules. The rules may allow or reject the flows from this security group to access VM NICs.
• IP address as destination: A destination IP is filtered by egress rules. The rules may allow or reject VM NICs to access this IP address.
• Security group as destination：A destination security group is filtered by egress rules. The rules may allow or reject VM NICs to access this security group.

• A public VIP can provide network services, such as EIP and load balancing, for flat networks. A public VIP can also provide network services, such as EIP, port forwarding, load balancing, and IPsec tunnel, for VPC networks.
• You can use a public VIP to simultaneously provide port forwarding, load balancing, and IPsec tunnel services. You can also use a public VIP to provide one service for multiple VM instances. However, you cannot specify the same port number for different services.
• A public VIP supports QoS, monitoring data, performance TOP 5, performance analysis, alarm, and other features.

• A VPC VIP can provide load balancing services for VPC networks.
• VPC VIPs do not support QoS, monitoring data, performance TOP 5, performance analysis, and alarm features.

• A flat network VIP provides network services, such as EIP and load balancing, for flat networks.
• A flat network VIP supports QoS, monitoring data, performance TOP 5, performance analysis, alarm, and other features.

• One custom public VIP can only be applied to one EIP instance.
• Custom VIPs cannot be used across VPC vRouters.
• When you use the EIP, port forwarding, load balancing, or IPsec tunnel services, you can select Create VIP to create a new VIP, or you can select Use Existing VIP to provide the services.

• A system VIP belongs to only one VPC vRouter. When you attach a public network to a VPC vRouter, the Cloud will automatically create a system VIP. This VIP is the default IP address of the vRouter in the network.
• By default, the system VIPs created from public networks are used to provide the source network address translation (SNAT) service.
• When you use the EIP, port forwarding, load balancing, or IPsec tunnel service, you can select Use Existing VIP to provide the services.

• The private network is an isolated network that cannot be directly accessed from other networks or the Internet. A public EIP can directly associate the access to a public network with the VM IP of the private network.
• A public EIP can be associated with or disassociated from a VM instance dynamically.
• A public EIP can be associated with VM instances created from private networks, such as flat networks and VPC networks.
  • The public EIP realized by a distributed EIP can access flat networks through public networks.
  • A VPC vRouter can be used to access VPC networks through public networks.

• L3 isolations exist between flat networks of different network ranges. Therefore, these flat networks cannot be accessed directly. A flat EIP can be used to associate the access to one flat network with the VM IP created from another flat network.
• A flat EIP can be associated with or disassociated from a VM instance dynamically.
• A flat EIP can be associated with VM instances created from other flat networks.

The following diagram shows how an EIP is used in a flat network scenario.

• Public networks can connect to the Internet through firewalls.
• Flat networks provide IP addresses for VM instances in each compute node. Notice that these IP addresses cannot connect to the Internet by default.
• A distributed EIP is deployed on each compute node, and can be associated with public networks or private networks separately.

The following diagram shows how an EIP is used in a VPC network scenario.

Financial industry, security industry, and others have rigorous standards for the business compliance and business data security. With the Baremetal Management service, they can ensure their exclusive use of resources, data isolation, strict supervision and control, and effective tracking.

In high-performance computing scenarios, supercomputing centers, gene sequencing companies, and other entities require high computing performance, high stability, and accurate real-time update for servers. Sometime later, business performances will be affected by the performance loss and hyper-threading brought by visualization. In this regard, to deploy BM cluster to a certain scale, meet the strict requirements for the high performance computing.

In some entities, some key database businesses cannot be deployed on normal VM instances, and must be loaded on the physical servers that can protect their exclusive resources, network isolation, and performances. To meet this requirements, use the Baremetal Management service that provides exclusive, high-performance physical servers for one or more appliances.

• Before you can use Elastic Baremetal Management, you need to deploy an IPv4 provision network.
• Provision networks require high network performance. We recommend that you use at least 10 Gigabit NICs for your provision network.
• You can configure a gateway for your provision network. This way, the provision network can be connected to other networks. If you do not need to connect your provision network to other networks, you do not need to configure a gateway for your provision network.

• You must attach a provision network to an elastic baremetal cluster to provide PXE services for baremetal nodes in the cluster.
• You can attach only one provision network to an elastic baremetal cluster. However, you can attach a provision network to multiple elastic baremetal clusters.
• You can attach an L2 network to an elastic baremetal cluster to provide an extended L2 business network for elastic baremetal instances in the cluster. Elastic baremetal instances and VM instances that share the same L2 network can access each other without using the gateway. The L2 network that you can attach to an elastic baremetal cluster can be of the VLAN or NoVLAN type.

• You can attach multiple gateway nodes to an elastic baremetal cluster. However, you can attach only one gateway node to an elastic baremetal cluster.
• A gateway node is used to take over primary storages and assign storage space for elastic baremetal instances.
• A gateway node provides iPXE, DHCP, and other services. It is used to deliver configuration settings to elastic baremetal instances.

• You can set the startup methods for the baremetal nodes. The following two startup methods are supported:
  • Startup from a volume: Uses a volume as the system volume of the baremetal node to install and deploy the operating system.
  • Startup form a local disk: Uses a local disk as the system volume of the baremetal node to install and deploy the operating system.
  • If you select to startup the baremetal node from a local disk, you can choose whether to take over the original operating system.
    • If you choose not to take over the original operating system, the Local Disk (Non Take-Over) is used. When you use the baremetal node to create an elastic baremetal instance, this method helps download an operating system from the Cloud and install it on the instance. Meanwhile, the local system volume is formatted.
    • If you choose to take over the original operating system, the Local Disk (Take-Over) method is used. The elastic baremetal instance created from the baremetal node used the original system operating system stored on the local disk directly.
• The management node must be connected to the IPMI network to remotely manage baremetal nodes.
• Baremetal nodes must be configured with the BMC interfaces, IPMI addresses, ports, usernames, and passwords, and be connected to the IPMI network.
• A baremetal node can be distributed to only one elastic baremetal instance and an elastic baremetal instance can only be assigned one baremetal node.
• You can provide compute resources for elastic baremetal instances by using a baremetal node or elastic baremetal offering.

• You can get elastic baremetal offerings of baremetal nodes by obtaining their hardware information. Baremetal nodes with the same offering can be managed in a unified way.
• The baremetal offerings obtained from the node hardware information can be classified into 3 types according to their startup methods: startup from a volume, startup from a local disk (take-over), and startup from a local disk (non take-over).
• You can use an elastic baremetal offering to create an elastic baremetal instance. You can also release the advanced settings of baremetal nodes to avoid resource idling.
• You can create a pricing list for elastic baremetal instances based on elastic baremetal offerings. Then bills are generated for the elastic baremetal instances based on their usage.

• The following two startup methods are supported for elastic baremetal instances:
  • Volume: Uses a volume as the system volume of the elastic baremetal instance to install and deploy the operating system.
  • Local Disk: Uses a local disk as the system disk of the elastic baremetal instance to install and deploy the operating system.
  • The Local Disk (Non Take-Over) and Local Disk (Take-Over) methods are supported:
    • Local Disk (Non Take-Over): When you use a baremetal node to create the elastic baremetal instance, the operating system is downloaded from the Cloud and installed on the elastic baremetal instance. This method will format the local system disk.
    • Local Disk (Take-Over): When you use a baremetal node to create the elastic baremetal instance, the original operating system on the local system disk is used as the operating system of the elastic baremetal instance.
• The following describes the resources supplied to elastic baremetal instances of different startup methods:
  • To elastic baremetal instances of both the volume startup method and local disk startup method, the compute resources are provided by corresponding baremetal nodes, and L3 networks on the Cloud are used as their business networks.
  • To elastic baremetal instances of the volume startup method, the storage resources are provided by SharedBlock or Ceph primary storage on the Cloud, and the PXE boots are supported by the provision network.
  • To elastic baremetal instances of local disk startup method, the storage resources are provides by their local disks. If you attach data volumes to the instances, they can use the storage resources provided by SharedBlock or Ceph primary storage on the Cloud.
• We recommend that you create an elastic baremetal instance by using an image that has installed the agent. Otherwise, you cannot perform the following actions on the instance: open the instance console, modify the instance password, attach a volume to or detach a volume from the instance, and attach a network to or detach a network from the instance.
• By default, you can you an image whose BIOS mode is UEFI to create an elastic baremetal instance. If you need to use an image with a Legacy BIOS mode, contact the official technical support.
• You can configure business networks for elastic baremetal instances. If you attach an L2 network to the cluster where your baremetal nodes reside, elastic baremetal instances and VM instances that share the same L2 network can access each other without using the gateway.
• You can enable the elastic baremetal instances of the volume startup method to automatically release the associated baremetal node when it is powered-off. The baremetal node released can be used by other elastic baremetal instances, thus avoiding the resource idling.

The financial and insurance industries have high requirements over business deployment compliance and data security. In these scenarios, you can use Baremetal Management to secure dedicated resources, data isolation, easy management, and operation-tracking. This way, you can ensure the reliability and security compliance of your key business system and data.

Supercomputing, genome sequencing, and other high-performance computing scenarios have high requirements over the computing performance, stability, and timeliness. However, the virtualization may cause performance losses and hyperthreading may negatively influence the business. Deploying a reasonable number of baremetal clusters can solve these problems, meeting the high-performance computing requirements.

To meet business requirements, you may not want to deploy some key databases on VM instances while want to deploy the databases on physical servers that feature dedicated resources, network isolation, and guaranteed performance. In these scenarios, you can use Baremetal Management to provide dedicated high-performance physical servers for your applications.

Elastic Baremetal Management provides dedicated physical servers for your applications to ensure high performance and stability. In addition, this feature allows elastic scaling. You can apply for and scale resources based on your needs.

A single management node allows you to manage 10,000 baremetal nodes and scale-out according to your needs.

An elastic baremetal instance no longer depends on IPMI/BMC network (optional), and the NIC can be used as a baremetal node as long as it supports PXE boot. The realization of the elastic baremetal instance does not associate any CPU or virtualization technology. As long as there is a system image that can be started, and no matter if it is an ISO, qcow2, or raw image, it can be used as a virtual hard disk by an elastic baremetal instance. That is, the elastic baremetal can be directly used on domestic servers.

In addition, the elastic baremetal management feature can be achieved by software only, without purchasing any proprietary hardware. It is compatible with all x86 and most of domestic ARM CPU architectures and supports mainstream x86 operating systems and some ARM operating systems.

In addition to turn on/off baremetal servers and deploy system, elastic baremetal management also supports the use of virtual resources on the Cloud, including VPC/flat/public networks, volumes, primary storage and other resources, which seamlessly connects physical resources and cloud resources, and greatly improves the availability of cloud resources.

All features of a VM instance can be directly operated on an elastic baremetal instance. And an elastic baremetal instance can use any advanced network services without purchasing additional network hardware.

An elastic baremetal instance supports both volume deployment method and local disk deployment method, respectively using the primary storage resource and the local disk on the Cloud, which combines the scalability of resources on the Cloud with the stable I/O and high throughput of local disks.

The primary storage resources used by an elastic baremetal instance can be shared by the KVM clusters of the Cloud, which relieves you from deploying additional storage resources. In addition, local disk deployment method supports take over the original system, which effectively ensures the business continuity.

• dvSwitch scenario:

  Only resources of the hosts that are added to a dvSwitch can be imported to ZStack Cloud. If you do not add a host to a dvSwitch, the associated resources cannot be imported to ZStack Cloud.

• vSwitch scenario:
  The resources imported to ZStack Cloud must be the resources of the hosts in the same cluster and must be added with at least one same vSwitch name. In addition, they must have at least one same port group attribute (including the same network labels and the same VLAN ID) at the same time.

  Note: ZStack Cloud can only manage VM networks rather than VMkernels or management networks.

• ECS Instance: An elastic compute service (ECS) instance is a VM instance created on Alibaba Cloud.
• Disk: A disk provides storage space for an ECS instance created on Alibaba Cloud.
• Image: An image is a template file that is used to create ECS instances. Images are categorized into custom images and Alibaba Cloud images.
• Security Group: A security group provides security control services for ECS instances on the L3 network. It filters the inbound or outbound packets of ECS instances based on security rules.
• VPC: A virtual private cloud (VPC) is a private network dedicated for ECS instances created on Alibaba Cloud.
• EIP: An elastic IP address (EIP) is an IP address in Alibaba Cloud public networks. You can attach EIPs to ECS instances so that the ECS instances can access public networks by using the EIPs.

• VPN Gateway: A virtual private network (VPN) gateway establishes a secure connection between a local data center and Alibaba Cloud VPC by using an encrypted channel.
• VPN Customer Gateway: A VPN customer gateway provides services for a local data center.
• VPN Connection: A VPN connection is an encrypted communication channel established between a VPN gateway and VPN customer gateway.

• Router Interface: A router interface is a virtual device that is used to establish communication channels and control their status.
• Virtual Border Router: A virtual border router (VBR) is virtualized from a physical switch port on the access point of Alibaba Cloud. It forwards the data on the physical circuit to Alibaba Cloud VPC.

• File System: A file system is a backend storage system used for Alibaba Cloud NAS primary storage. Before you add an AliyunNAS primary storage, you need to add an NAS file system.
• Permission Group: A permission group is an allowlist of IP addresses or IP ranges which can access file systems according to specified permission rules.

• Region: A region is a physical data center. A region in ZStack Cloud Hybrid Cloud corresponds to a region in Alibaba Cloud.
• Zone: A zone is a physical area in a region that is independent from other zones in the region in terms of electricity and network supplies.

• AccessKey Management: An AccessKey pair is an identity credential that has access to APIs of Alibaba Cloud or Private Alibaba Cloud. It has full access to the Cloud. An AccessKey pair consists of AccessKey ID and AccessKey secret.
• Hybrid Cloud Settings: Hybrid cloud settings allow you to configure settings that take effect on the whole platform.

ZStack Cloud Hybrid Cloud seamlessly integrates Alibaba Cloud Public Cloud. Combined with the benefits of ZStack Cloud Private Cloud, it provides users a platform to manage both public clouds and private clouds in a unified way.

ZStack Cloud Hybrid Cloud allows seamless upgrading without affecting business continuity.

ZStack Cloud Hybrid Cloud seamlessly integrates cloud services and terminals in a unified cloud platform. You can easily manage local private clouds and access resources on the public cloud as needed.

Financial, medical and some other industries have a high requirement for the compliance of long-term data storage. However, backing up data in local data centers is relatively risky, cost-consuming, and hard for O&M. To deal with these problems, ZStack Cloud Hybrid Cloud helps you back up the data to the Cloud, providing you with a stable data storage service at a lower cost.

Enterprises and institutions need to store large amounts of data. In these scenarios, you can use ZStack Cloud Hybrid Cloud to store data on Cloud. This solution lowers your investment and management costs and allows data access from multiple regions and zones.

High data negotiability is important to some enterprises and institutions whose works are finished based on multi-regional cooperation. In these scenarios, you can use ZStack Cloud Hybrid Cloud to migrate data to Cloud, thus ensuring a stable data transmission and data integrity.