Settings

Sub-Account Management

A sub-account can be created by the admin or synced from an SSO authentication system and is managed by the admin. Resources created under a sub-account are managed by the sub-account. You can use a sub-account to create and manage resources under its management and implement fine-grained control over the permissions on resources.

Concepts

admin: The admin has super privileges over resources and shall be owned by the IT system administrator.
- The admin can share instance offerings, disk offerings, networks, images, and other cloud resources with sub-accounts or revoke the resources from sub-accounts. Sub-accounts can only manage resources to which they are granted access.
- The admin can modify resource quotas granted to a sub-account based on different business scenarios.
- After the admin created a VXLAN pool, sub-accounts can create VXLAN networks based on the VXLAN pool.
- Changing the owner of a VM instance will change the owner properties of the EIPs associated with the VM instance.
Sub-account:
- Sub-accounts can be categorized into local sub-accounts and SSO sub-accounts:
  - Local sub-account: A local sub-account is created by the admin. The account information is stored locally.
  - SSO sub-account:
    - The SSO sub-account information is stored in the SSO server and can be synchronized to the Cloud via the SSO server.
    - The admin can create a sub-account locally. The account information is synchronized to the SSO server for cross-platform SSO.
      Note: Currently, you can create an SSO account locally only after you add a ZStack IAM server.
  - A sub-account has management permissions on VM instances, images, volumes, and security groups created under the sub-account. A sub-account can perform read operations on resources shared by the admin, but cannot delete the resources.
  - Deleting a sub-account will delete all resources created by the sub-account, such as VM instances, volumes, and images.
  - The names of sub-accounts must be unique.
  - Resource quotas that the admin shares with a sub-account is displayed on the homepage of the sub-account.
  - Before a sub-account can create a VM instance, the admin must share an instance offering, disk offering, network, and other required resources with the sub-account. Otherwise, a VM instance cannot be created.
  - A sub-account can use an image that it adds to the Cloud or use an image shared by the admin.
Quota:
Resource quotas that the admin shares with a sub-account specify the maximum resources that the sub-account can manage, including computing resource quotas, storage resource quotas, network resource quotas, and other resource quotas.
The admin uses the preceding resource quota settings to manage the maximum resources granted to sub-accounts. If a resource is deleted but not expunged, the resource still occupies storage space of primary storage and volumes.

SSO Rename

Starting form ZStack Cloud 5.1.8, Third-party authentication is renamed to Single Sign-On (SSO). The following table describes some of the common term changes that have been updated throughout this guide as a result of the rename.

Legacy Term	Current Term
Third-Party Authentication	Single Sign On or SSO
Third-Party Authentication Server	SSO Server
Third-Party Authentication System	SSO System or SSO Authentication System
Third-Party User	SSO User
Third-Party Sub-Account	SSO Sub-Account
Third-Party Attribute	SSO Attribute

Email Server

If you select Email as the endpoint of an alarm, you need to set an email server. Then alarm messages are sent to the email server.

Log Server

A log server is used to collect management node logs or the platform operation logs. You can add a log server to the cloud and use the collected logs for operation trace or troubleshooting. This makes your O&M more efficient.

Log Server Type

Management Node Log Server: The server is used to receive management node logs of the Cloud. Only admin or platform managers can add management node log servers.
Cloud Operation Log Server: The server is used to receive cloud operation logs. Both the admin/platform managers and project members can add cloud operation log servers.
- If added by a project member, the log server receives the operation logs of users in this project. One project can have up to one log server.
- If added by the admin/platform manager, the log server receives operation logs of all users of the Cloud.
SNAT Log Server: The server is used to receive SNAT forwarding logs from the VPC router.

IP Allowlist/Blocklist

An IP allowlist or blocklist identifies and filters IP addresses that access the Cloud. You can create an IP allowlist or blocklist to improve access control of the Cloud.

Note: You can enable the IP allowlist and blocklist feature as needed. To configure it, follow these steps:

Go to Settings > Platform Setting > Global Setting > Basic > Platform Policy > Platform Login Policy. Set IP Allowlist/Blocklist to true. By default, this setting is set to false.

How IP Allowlist and Blocklist Work

No IP allowlist or blocklist added: By default, login requests from any IP address are allowed.
Only blocklist added: IPs in the blocklist are denied access to the platform, while all other IPs are allowed.
Both allowlist and blocklist added: The allowlist takes precedence over the blocklist.
- IPs in the allowlist are permitted to access to the platform.
- If the same IP is added to both the allowlist and blocklist, the allowlist takes precedence, allowing login requests from that IP.

Note:

If a login attempt is made from an IP address that is not allowed, the system will block the request during the login process.
If a load balancer forwards login requests to the platform, ensure that the X-Forwarded-For header is properly configured on the load balancer. If not configured, the platform cannot retrieve the actual client IP and will not be able to accurately allow or block access from that client.
The allowlist cannot be used independently. Before using it, ensure that at least one entry is added to the blocklist. Otherwise, the allowlist will not take effect.

Add IP Allowlist and Blocklist

On the IP allowlist and blocklist page, you can choose to add an IP allowlist or an IP allowlist. The process is the same for both. The following section introduces adding an IP blocklist.

On the main menu of ZStack Cloud, choose Operational Management > Access Control > IP Allowlist/Blocklist. On the IP Allowlist/Blocklist page, click Add IP Blocklist. Then, the Add IP Blocklist page is displayed.

On the displayed page, set the following parameters:

Name: Set a name for the IP blocklist.
Description: Optional. Enter a description for the blocklist.
IP Address: Enter the IP address to be added to the blocklist.
Note:
- You can enter fixed IP addresses, IP address ranges, and IP/mask formats. Separate multiple entries with English commas.
- Supports adding up to 100 entries.

Action	Description
Add IP Allowlist/Blocklist	Add a new IP allowlist or blocklist. Note: Once added, the blocklist or allowlist takes effect immediately. IP addresses in the list will be denied or allowed access to the platform. Proceed with caution.
Edit Name and Description	Edit the name or description of an existing IP allowlist or blocklist.
Delete IP Allowlist/Blocklist	Delete the selected IP allowlist or blocklist. Note: Once deleted, the allowlist or blocklist will no longer be effective, and there will be no IP restrictions for logging into the platform. Proceed with caution.

HA Policy

HA Policy is a mechanism that ensures sustained and stable running of the business if VM instances are unexpectedly stopped or are errored because of errors occurring to compute, network, or storage resources associated with the VM instances. By enabling this feature, you can customize VM HA policies to ensure your business continuity and stability.

Concepts

The HA Policy feature involves the following key concepts:

HA mode: Specifies whether to enable auto restart if VM instances are unexpectedly stopped or are errored because of errors occurring to compute, network, or storage resources associated with the VM instances. None and NeverStop are supported:
- None: VM instances are not auto restarted no matter it is planned to be stopped or unexpectedly stopped.
- NeverStop:
  - Unexpectedly stopped VM instances are auto restarted on another host depending on the failover strategy you configure for them.
  - The VM instance does not reboot automatically if you stop it manually, including:
    - Manually perform the stopping VM instance, force stopping VM instance, and powering off VM instance actions on the UI.
    - Manually run the shutdown, poweroff, and halt commands in the VM OS.
    - Create a scheduled job to trigger the VM shutdown as planned.

VM Failover Strategy: Specifies whether to migrate a VM instance to another host if errors occur to the compute resource, storage resource, or network resource associated with the VM instance.

The VM failover mechanism inspects the following resource status:

Management Network Connectivity Status:
- Management network connectivity status indicates the status of the network that connects the management node and the host where VM instances reside.
- This status may turn Abnormal if errors occur to the management node or to the management network.

Storage Network Connectivity Status:
- Detects the connectivity status of the network that VM instances use to access the primary storage where the root volumes of these VM instances reside.
- This status may turn Abnormal if errors occur to the primary storage or to the storage network.
Business NIC Status:
- Business NIC status may turn Abnormal if errors occur to the host business NIC or the switch port directly connecting to the host business NIC that is associated with the L2 network of VM instances.
- Business network group: Supports adding redundant networks that carry the same service to a business network group and setting the minimum number of alive networks. A VM business NIC fault is detected only when the number of available networks in the group is less than this value.
  Note:
  - If a VM uses networks in a business network group, the number of attached networks from the same group should be no less than the minimum number of alive networks configured for that group, to avoid unexpected HA triggered by a misjudged business network exception.
  - Only public networks and flat networks can be added to a business network group.
  - Business network groups can be configured only when failover upon business NIC fault is enabled.

Based on the resource status inspection, the Cloud allows you to configure failover strategies for 4 fault scenarios:

Fault Scenario	Management Network Connectivity Status	Storage Network Connectivity Status	Business NIC Status	Fail Over
Scenario A: Business NIC Fault	Normal	Normal	Abnormal	Enable/Disable
Scenario B: Storage Network Fault	Normal	Abnormal	Normal	Enable/Disable
Scenarios C: Storage Network and Business NIC Fault	Normal	Abnormal	Abnormal	Set as false if both the scenario A and B have the failover policy set as false. Set as true if either of the scenario A or B has the failover policy set as true.
Scenario D: Management Network Fault	Abnormal	Normal	Normal	Disable. The failover cannot be enabled in this scenario.

Note: The failover policies take effect on VM instances whose HA modes are set as NeverStop only.

Fundamentals

ZStack Cloud HA Policy has the following mechanisms：

The Cloud polls the running status of VM instances. If a VM instance is unexpectedly stopped, its HA mode is checked. If the HA mode of the VM instance is NeverStop, then the VM instance is restarted on the current host or another host.

Figure 2. VM HA Started After Unexpectedly Stopped
The Cloud polls the status of the hosts where VM instances reside. Either of the management network connectivity status, storage network connectivity status, and business NIC status of the host turns abnormal, the corresponding VM failover strategy and VM HA mode are checked. If the corresponding failover strategy is Yes and VM HA mode is NeverStop, then related VM instances are migrated to another host.

Figure 3. VM HA Started After Host Business NIC Turns Down

Characteristics

HA Policy has the following characteristics:

Comprehensive & Powerful: Covers all mainstream HA scenarios, including various failures, and ensures the stability and continuity of your business.
Flexible & Visualized: Provides a simple table that allows you to configure VM failover strategies with one click. This table functions together with the HA Mode that can be configured on all and individual VM instances, thus greatly improving the flexibility of your business HA configuration.

Scenarios

The following describes the scenarios of the HA Policy feature.

Host Business NIC Turns Down:
If a host business NIC turns down, to ensure high availability of business, all VM instances associated with this NIC are expected to migrate to other hosts.
- For example, your business VM instances are running MySQL database service which is required to achieve high availability. In this case, you can set the HA mode of these VM instances to NeverStop and turn on the switch corresponding to Abnormal Business NIC Status. Then as long as host resources are sufficient, in case that a host business NIC associated with these VM instances turns down, these VM instances will be auto started on other hosts.
VM Unexpectedly Stops:
If a VM instance is unexpectedly stopped, it is expected to auto HA start.
- For example, your VM instances are running important business applications. To ensure business auto-recovery in case of VM stops due to reasons such as host powered-offs or business overloads, you can set the HA mode of these VM instances to NeverStop. Then if these VM instances are stopped, they are auto started.

PreviousOperational Management NextProduct Features