ZStack Cloud provides high availability (HA) for double management
nodes (MNs, also known as hosts) by using separate HA suites. When any one of the MNs is
disconnected, the HA will be triggered in seconds to ensure the business continuity.
HA Mechanism
In a dual-MN model, each MN runs a zsha2 HA process. This process monitors the
critical services, including the MN service, UI service, and database service, on
each MN in real time. When any critical service is down, the Cloud immediately
triggers virtual IP (VIP) migration through Keepalived, and then attempts to restore
the downtime service.
Figure 1. Dual-MN HA
Installation and Deployment
Prepare Software Tools
The administrator needs to prepare the following necessary software packages to
facilitate the installation and deployment process.
Note: After you download the required software, confirm the
integrity of the file by using the MD5 checksum tool.
Check Hardware Devices
This topic provides a scenario where two x86 servers are used to deploy a dual-MN HA
environment. The configuration information is listed in Table 1. The
administrator can adjust the capacity ratio of the CPU, memory, and hardware according
to actual business requirements.
Server
Accessory
Model
Quantity
Total
CPU
Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
2
2
Memory
DDR4 16GB
8
Motherboard
Two-way server standard motherboard
1
RAID controller
Supports SAS/SATA RAID 0/1/10
Supports the passthrough mode
1
SSD
Intel SSD DC S3610 480GB
2
HDD1
SAS HDD 300GB 3.5", 15K RPM
2
HDD2
NL SAS HDD 2TB 3.5", 7.2K RPM
6
1-Gigabit Ethernet port
1GbE, RJ45
2
10-Gigabit Ethernet port
10GbE, SFP+
2
Optical module
-
HBA card
-
Remote management
DELL iDRAC Enterprise
1
Power supply
1100W standard power supply
2
In addition, this scenario involves one 10 Gigabit switch, one 1-Gigabit switch, and
several cat5 jumpers.
Check Network Connections
The administrator puts the servers and network devices mentioned
before in place, and connects them to check the network connections according to the
network topology.
Figure 2. Network Topology
Install the Operating System
Procedure
Preparations
The administrator powers on the network devices and servers, manually starts
the server to enter the BIOS mode, and makes the following preparations:
Activate all CPU cores, enable the hyper-threading function, and set
the system performance to the highest performance state.
Turn on hardware virtualization to accelerate the optimization of
hardware virtualization.
Go to the RAID controller settings, configure RAID1 (Mirror) for the
two system hard drives, and set the passthrough mode for the
remaining hard drives.
Use Rufus to open the ISO image file.
Open Rufus, select Disk or ISO image (Please select)
from the Boot selection drop-down list, and click the
Select button to open the downloaded ISO image
file.
Figure 3. Open DVD Image in Rufus
Write the Image.
Use the default setting and click In Rufus, choose
Start.Figure 4. Write Disk Image on Rufus
After you click Start, you will be reminded of the risk
that the disk data will be formatted. Click OK to burn
the image file.
Note: Before you burn the image file, make sure that you
backup the data on the U disk.
Figure 5. Confirm to Write ISO Image on Rufus
Enter the installation guide page.
The ISO image is burned to the USB drive. Then, this USB drive can be used as
a boot disk, which supports the Legacy and UEFI boot modes. Then, the
administrator boots the node through the installation media and enters the
installation guide page.
Figure 6. USB Drive Guide Page
Install the operating system.
By default, the operating system installation begins.
On the installation summary page, some options are preconfigured as below.
You can modify the configurations as needed.
DATE & TIME: UTC/GMT+8
LANGUAGE SUPPORT: English (United
States)
KEYBOARD: English (United States)
Generally, the administrator does not need to modify the configurations.
However, the administrator needs to partition the hard disks. The
recommended partitioning method is as follows (UEFI mode):
/boot/efi: create a 500 MB partition
/boot: create a 1 GB partition
swap (exchange partition): create a 32 GB partition
/ (root partition): configure the remaining capacity
After the partitions are configured, click SOFTWARE
SELECTION. On the software selection page, select the
management node installation, and go back to the installation summary
page.
After the software selection, click Root Password and
set a password for the root user. Then, go back to the installation summart
page.
Click Begin Installation. Then, the installation
process proceeds automatically.
After the installation is completed, reboot the server and unplug the USB
drive. If the installation is successful, the server restarts and enters the
operating system login prompt. You can use your root account and password to
log in to the operating system.
Note: The administrator can change the
password as needed.
Configure Networks
The administrator can configure networks after installing the operating system on both
servers. ZStack Cloud provides a convenient network configuration
script in the /usr/local/bin/ directory. The administrator can use
this script to quickly configure the interface and bridge information.
The following table lists the network information of the two MNs and the VIP settings
used for Keepalived communication in this scenario.
Server
NIC1
NIC2
Bond
Bridge
IP Address
Netmask
Gateway
MN1
eth0
eth1
bond0
br_bond0
192.168.195.200
255.255.0.0
192.168.0.1
MN2
eth0
eth1
bond0
br_bond0
192.168.196.125
255.255.0.0
192.168.0.1
Node
NIC1
NIC2
Bond
Bridge
IP Address
Netmask
Gateway
MN1
em1
em2
bond1
-
-
-
-
MN2
em1
em2
bond1
-
-
-
-
-
IP Address
Netmask
VIP
192.168.199.151
255.255.0.0
Note: The virtual IP address (VIP) is used to log in to the UI. Do not use the
VIP to log in to a MN through SSH.
The data provided above is sample data. The administrator can change the data in
the actual deployment environment.
The gateway must be provided by a physical network device. Meanwhile, the
gateway is used to detect the network status.
In the following sections, we will describe how to configure the management network and
the VM data network, respectively.
Configure the Management Network
Assume that the settings of the management network is as follows.
Server
NIC1
NIC2
Bond
Bridge
IP Address
Netmask
Gateway
MN1
eth0
eth1
bond0
br_bond0
192.168.195.200
255.255.0.0
192.168.0.1
MN2
eth0
eth1
bond0
br_bond0
192.168.196.125
255.255.0.0
192.168.0.1
On MN1, run the following
commands:
# Create bond0.
[root@localhost ~]# zs-bond-lacp -c bond0
# Attach eth0 and eth1 to bond0.
[root@localhost ~]# zs-nic-to-bond -a bond0 eth0
[root@localhost ~]# zs-nic-to-bond -a bond0 eth1
# After the preceding bonds are configured, configure LACP aggregation on the corresponding switch port.
# Create br_bond0, and configure the IP address, netmask, and gateway.
[root@localhost ~]# zs-network-setting -b bond0 192.168.195.200 255.255.0.0 192.168.0.1
# Check whether bond0 is successfully created.
[root@localhost ~]# zs-show-network
...
--------------------------------------------------------------------
| Bond Name | SLAVE(s)| BONDING_OPTS |
--------------------------------------------------------------------
| bond0 | eth0 | miimon=100 mode=4 xmit_hash_policy=layer2+3 |
| | eth1 | |
--------------------------------------------------------------------
On MN2, run the similar commands.
Note:
After you attach eth0 and eth1 to bond0, you must configure LACP aggregation for
the port of the corresponding switch. Otherwise, the network communication might
be abnormal. If the switch does not support LACP aggregation, contact the
network device manufacturer to replace the device.
After you create a bridge named br_bond0 via bond0, the bridge will provide
management network services.
For the IP address, netmask, and gateway of the bridge, you can enter a value
according to your actual needs.
After the management network is configured, you can check the configuration by
using the ping command. If the configuration is correct, the
management IP addresses of these two MNs can ping each other.
We recommend that you use a 10-Gigabit or above bandwidth for the management
network. If the management network is deployed independently, a 1-Gigabit
bandwidth is allowed.
After the management network is configured, you can configure the VM
data network accordingly.
Configure the VM Data Network
Assume that the settings of the VM data network is as follows.
Node
NIC1
NIC2
Bond
Bridge
IP Address
Netmask
Gateway
MN1
em1
em2
bond1
-
-
-
-
MN2
em1
em2
bond1
-
-
-
-
On MN1, run the following
commands:
# Create bond1.
[root@localhost ~]# zs-bond-lacp -c bond1
# Attach em1 and em2 to bond1.
[root@localhost ~]# zs-nic-to-bond -a bond1 em1
[root@localhost ~]# zs-nic-to-bond -a bond1 em2
# After the preceding bonds are configured, configure LACP aggregation on the corresponding switch port.
# You do not need to create a bridge for the VM data network.
# Check whether bond1 is successfully created.
[root@localhost ~]# zs-show-network
...
--------------------------------------------------------------------
| Bond Name | SLAVE(s)| BONDING_OPTS |
--------------------------------------------------------------------
| bond1 | em1 | miimon=100 mode=4 xmit_hash_policy=layer2+3 |
| | em2 | |
--------------------------------------------------------------------
On MN2, run the similar commands.
Note:
After you attach em1 and em2 to bond1, you must configure LACP aggregation for the
port of the corresponding switch. Otherwise, the network communication might be
abnormal. If the switch does not support LACP aggregation, contact the network
device manufacturer to replace the device.
Install the HA Suite
This section introduces two methods to install the HA suite.
Install the HA suite directly by using the command line.
Install the HA suite by writing configuration files.
Note: With the same configurations, the command line method has higher priority
than the configuration file method.
Use the Command Line
About this task
The administrator installed two ZStack Cloud MNs with the
latest version, and installed licenses for these two MNs. Now, the administrator
wants to install a dual-MN HA suite on one of the MNs to achieve HA.
MN1 (192.168.195.200)
MN2 (192.168.196.125)
Assume that the administrator wants to install the HA suite on MN1. In this case, MN1
is the active MN, and MN2 is the standby MN.
Procedure
Import the HA suite.
Run the following commands to import the HA suite to MN1 and decompress the
suite:
# Copy the HA suite to MN1 by using the scp tool.
[root@localhost ~]# ls
ZStack-Multinode-HA-Suite-5.5.38.tar.gz
# Decompress the suite. Then, two executable files are generated: zsha2 and zstack-hamon.
[root@localhost ~]# tar zxvf ZStack-Multinode-HA-Suite-5.5.38.tar.gz
zsha2 //A program for installing and managing multi-node HA.
zstack-hamon //A program for monitoring multi-node HA.
Initialize the HA suite.
On MN1, run the following commands to install the HA suite:
After the installation commands are executed, the database of
the active and backup MNs will be automatically backed up, and
then the suite will be installed.
To install the HA suite, you need to put zsha2 and
zstack-hamon in the same directory. During the
installation process, zsha2 will automatically deploy
zstack-hamon and related configuration files.
Description of parameters in the installation commands:
-nic: The name of the physical device.
This parameter is used to configure a VIP. In production
environments, this parameter is generally a management
network bridge, such as -nic
br_bond0.
-gateway: The arbitration gateway of
the active and backup MNs, for example, -gateway
192.168.0.1.
-slave: Specifies the standby MN, for
example, -slave
"root:password@192.168.196.125".
Note:
During the installation process, the database
of the standby MN will be overwritten by that of
the active MN. Please exercise caution.
When you install an HA suite, we recommend
that you set the root password to a regularly used
password for easy and quick deployment. You can
change the root password later as needed. The HA
suite will no longer depend on the system root
password.
If the root password contains special shell
characters, for example, ' " * ? \ ~ ` ! #
$ & |, enter \ to
escape these characters.
For example, if the
system password is ' " * ? \ ~ ` ! # $
& |, you can escape the password as
follows:
-vip: Specifies the VIP for Keepalived
communication, for example, -vip
192.168.199.151.
-myip: Optional. Specifies the local IP
address, for example, -myip
192.168.195.200.
-db-root-pw: The database root password
of the active and standby MNs, for example,
-db-root-pw zstack.mysql.password.
Make sure that both MNs share the same root
password.
-time-server: Specifies a time
synchronization server for unified time synchronization,
for example, ./zsha2 install-ha -time-server
192.168.196.125.
Note: You can specify
multiple time servers at a time, for example,
./zsha2 install-ha -time-server
192.168.196.125,192.168.196.126.
-cidr: Optional. Specifies the network
range, which must cover the IP address, VIP, and gateway
of the active and standby MNs. For example,
./zsha2 install-ha -cidr
192.168.0.0/16.
Note: If not specified, the
system will automatically calculate a minimum
network range, which might fail to meet the
requirements. We recommend that you specify a
network range.
-force: Optional. Force runs the
zsha2 installation command in the
active MN when the database of the active and standby
MNs cannot be automatically synchronized for a long
time. For example, ./zsha2 install-ha
-force.
Note: We recommend that you back up
both databases before performing a force
installation.
-repo: Optional. Specifies the YUM
repository, which defaults to the local repository, for
example, ./zsha2 install-ha -repo
zstack-local.
-timeout: Optional. The timeout for
copying the databases of the active and backup MNs.
Default value: 600. Unit: second. For example,
./zsha2 install-ha -timeout
600.
-yes: Optional. Indicates that all
settings are allowed.
After the HA suite is initialized, you can run the following commands to view
the status of the
MNs:
# View the status of MN1.
[root@localhost ~]# zsha2 status
Status report from 192.168.195.200
=================================
Owns virtual address: yes //MN1 has obtained a VIP. Only one MN can obtain VIP at the same time.
Self 192.168.195.200 reachable: yes //MN1 is reachable.
Gateway 192.168.0.1 reachable: yes //The current gateway is reachable.
VIP 192.168.199.151 reachable: yes //The VIP is reachable.
Peer 192.168.196.125 reachable: yes //MN2 is reachable.
Keepalived status: active //The Keepalived service is in the running state.
ZStack HA Monitor: active //The HA monitoring service isin the running state.
MySQL status: mysqld is alive //The database is running properly.
MN status: Running [PID:6500] //The MN is running properly.
UI status: Running [PID:9785] http://192.168.195.200:5000 //The UI is running properly.
Slave Status:
-------------
Slave_IO_Running: Yes //Slave I/O is running properly.
Slave_SQL_Running: Yes //Slave SQL is running properly.
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Warning: Permanently added '192.168.196.125' (ECDSA) to the list of known hosts.
Status report from 192.168.196.125 //View the status of MN2.
================================
Owns virtual address: no
Self 192.168.196.125 reachable: yes
Gateway 192.168.0.1 reachable: yes
VIP 192.168.199.151 reachable: yes
Peer 192.168.195.200 reachable: yes
Keepalived status: active
ZStack HA Monitor: active
MySQL status: mysqld is alive
Slave Status:
-------------
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Note: visit ZStack UI with http://192.168.199.151:5000
Note: During
the installation of the HA suite, SSH password-free login was
automatically configured for these two MNs.
Initialize the Cloud.
The administrator can access the UI of MN1 through the VIP
(192.168.199.151), and then complete the Cloud
initialization.
Figure 7. Login Page
Run the following command on MN1. Then, MN1 switches to the backup MN online,
and MN2 obtains the VIP (192.168.199.151) and becomes the active
MN.
[root@localhost ~]# zsha2 demote
The administrator can refresh the UI (http://192.168.199.151:5000) of
MN2 by using the VIP and complete the Cloud initialization.
Configuration Files
About this task
The administrator installed two ZStack Cloud MNs with the
latest version, and installed licenses for these two MNs. Now, the administrator
wants to install a dual-MN HA suite in one of the MNs to achieve HA.
MN1 (192.168.195.200)
MN2 (192.168.196.125)
Assume that the administrator wants to install the HA suite on MN1. In this case, MN1
is the active MN, and MN2 is the standby MN.
Procedure
Import the HA suite.
Run the following commands to import the HA suite to MN1 and decompress the
suite:
# Copy the HA suite to MN1 by using the scp tool.
[root@localhost ~]# ls
ZStack-Multinode-HA-Suite-5.5.38.tar.gz
# Decompress the suite. Then, two executable files are generated: zsha2 and zstack-hamon.
[root@localhost ~]# tar zxvf ZStack-Multinode-HA-Suite-5.5.38.tar.gz
zsha2 //A program for installing and managing multi-node HA.
zstack-hamon //A program for monitoring multi-node HA.
Write the configurations.
Run the following commands to write the initialization configuration file for
the HA
suite:
[root@localhost ~]# chmod +x zsha2 zstack-hamon
[root@localhost ~]# ./zsha2 sample-config > zs-install.config
[root@localhost ~]# cat zs-install.config
{
"gateway": "192.168.0.1", //The arbitration gateway of the active and standby MNs.
"virtualIp": "192.168.199.151", //Specifies the VIP for Keepalived communications.
"myIp": "192.168.195.200", //Specifies the local IP address.
"peerIp": "192.168.196.125", //Specifies the IP address of the peer MN.
"peerSshUser": "root", //Specifies the SSH username of the peer MN.
"peerSshPass": "password", //Specifies the SSH password of the peer MN.
"peerSshPort": 22, //Specifies the SSH port of the peer MN.
"dbRootPass": "zstack.mysql.password", //Specifies the root password of the active and backup MNs. Make sure that both MNs share the same root password.
"interface": "br_bond0", //The name of the physical device. This parameter is used to configure a VIP. In production environments, this parameter is generally a management network bridge.
"timeServer": "192.168.196.125" //Specifies a time synchronization server for unified time synchronization.
}
The administrator needs to modify the parameters above
according to specific deployment scenarios.
Initialize the HA suite.
Run the following command to initialize and install the HA suite:
After the installation command is executed, the database of the
active and backup MNs will be automatically backed up, and then
the suite will be installed.
To install the HA suite, you need to put zsha2 and
zstack-hamon in the same directory. During the
installation process, zsha2 will automatically deploy
zstack-hamon and related configuration files.
Description of parameters in the installation commands:
-config: Optional. Installs the HA
suite by initializing the configuration files.
After the HA suite is initialized, you can run the following commands to view
the status of the
MNs:
# View the status of MN1.
[root@localhost ~]# zsha2 status
Status report from 192.168.195.200
=================================
Owns virtual address: yes //MN1 has obtained a VIP. Only one management node can obtain VIP at the same time.
Self 192.168.195.200 reachable: yes //MN1 is reachable.
Gateway 192.168.0.1 reachable: yes //The current gateway is reachable.
VIP 192.168.199.151 reachable: yes //The VIP is reachable.
Peer 192.168.196.125 reachable: yes //MN2 is reachable.
Keepalived status: active //The Keepalived service is in the running state.
ZStack HA Monitor: active //The HA monitoring service is in the running state.
MySQL status: mysqld is alive //The database is running properly.
MN status: Running [PID:6500] //The MN is running properly.
UI status: Running [PID:9785] http://192.168.195.200:5000 //The UI is running properly.
Slave Status:
-------------
Slave_IO_Running: Yes //Slave I/O is running properly.
Slave_SQL_Running: Yes //Slave SQL is running properly.
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Warning: Permanently added '192.168.196.125' (ECDSA) to the list of known hosts.
Status report from 192.168.196.125 //View the status of MN2.
================================
Owns virtual address: no
Self 192.168.196.125 reachable: yes
Gateway 192.168.0.1 reachable: yes
VIP 192.168.199.151 reachable: yes
Peer 192.168.195.200 reachable: yes
Keepalived status: active
ZStack HA Monitor: active
MySQL status: mysqld is alive
Slave Status:
-------------
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Note: visit ZStack UI with http://192.168.199.151:5000
Note: During
the installation of the HA suite, SSH password-free login was
automatically configured for these two MNs.
Initialize the Cloud.
The administrator can access the UI (http://192.168.199.151:5000) of
MN1 through the VIP (192.168.199.151), and then complete the Cloud
initialization.
Figure 8. Login Page
Run the following command on MN1. Then, MN1 switches to the backup MN online,
and MN2 obtains the VIP (192.168.199.151) and becomes the active
MN.
[root@localhost ~]# zsha2 demote
The administrator can refresh the UI (http://192.168.199.151:5000) of
MN2 by using the VIP and complete the Cloud initialization.
Install the License
In this scenario, the license type of two ZStack Cloud MNs must be
the same.
The administrator can install licenses either via the UI or by using CLI.
UI Method
Access the UI (http://VIP:5000) by using a VIP and log in to the Cloud as
an admin.
Go to the License Management page and click
Upload license in the upper right corner. On the
displayed Upload License page, upload or drag-and-drop the
dual-MN license you obtained before.
CLI Method
The administrator can import licenses to these two MNs by using CLI.
Upgrade the Cluster
This topic provides an example of how to upgrade a dual-MN HA environment in ZStack Cloud.
The upgrade involves the following three steps:
Complete the preparations before the upgrade.
Upgrade the HA suite.
Upgrade the MNs.
Before you perform any upgrades, complete the following
preparations:
Disable the VM HA functionality globally to avoid accidentally triggering VM HA
and affecting the upgrade. Method: On the main menu of the MN UI, choose Settings > Global Setting. On the Global Setting page, disable the
VM HA option. You can manually enable this functionality after the
upgrade is completed.
Run the following command on each MN to back up your
database:
Make sure that the zstack-upgrade script, the
corresponding ISO, the installation and upgrade package, and the HA suite are
downloaded for these two MNs.
Run the following command on each MN to update the local repo by using the
latest ISO you downloaded
before:
After you obtain the new HA suite, you can use the suite to upgrade the existing
zsha2 service. The steps are as follows:
Run the following command on any MN to check on which node
the HA VIP is located. After you execute zsha2, the node whose "Owns virtual
address" is yes in the returned result is the MN where the VIP is
located.
[root@localhost ~]#zsha2 status
Log in to the MN where the VIP is located through IPMI, and run the following
command to decompress the dual-MN HA
suite:
Run the following command to grant executable permissions to the decompressed
zsha2 and
zstack-hamon:
[root@localhost ~]#chmod +x zsha2 zstack-hamon
Run the following command in the MN where the VIP is located to complete the
upgrade of the HA
suite:
[root@localhost ~]# ./zsha2 upgrade-ha
After you upgrade the HA suite, you can upgrade the MNs by following these steps:
Make sure that:
The VIP is reachable.
The current gateway is reachable.
The standby MN is reachable.
The database is synchronized.
You can view the MN status by running zsha2
status.
[root@localhost ~]# zsha2 status
Status report from 192.168.195.200
=================================
Owns virtual address: yes //MN1 has obtained a VIP. Only one MN can obtain VIP at the same time.
Self 192.168.195.200 reachable: yes //MN1 is reachable.
Gateway 192.168.0.1 reachable: yes //The current gateway is reachable.
VIP 192.168.199.151 reachable: yes //The VIP is reachable.
Peer 192.168.196.125 reachable: yes //MN2 is reachable.
Keepalived status: active //The Keepalived service is in the running state.
ZStack HA Monitor: active //The HA monitoring service is in the running state.
MySQL status: mysqld is alive //The database is running properly.
MN status: Running [PID:6500] //The MN is running properly.
UI status: Running [PID:9785] http://192.168.195.200:5000 //The UI is running properly.
Slave Status:
-------------
Slave_IO_Running: Yes //Slave I/O is running properly.
Slave_SQL_Running: Yes //Slave SQL is running properly.
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Warning: Permanently added '192.168.196.125' (ECDSA) to the list of known hosts.
Status report from 192.168.196.125 //View the status of MN2.
================================
Owns virtual address: no
Self 192.168.196.125 reachable: yes
Gateway 192.168.0.1 reachable: yes
VIP 192.168.199.151 reachable: yes
Peer 192.168.195.200 reachable: yes
Keepalived status: active
ZStack HA Monitor: active
MySQL status: mysqld is alive
Slave Status:
-------------
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Note: visit ZStack UI with http://192.168.199.151:5000
Note: In the preceding command, the
-peerpass parameter is optional. You can
use this parameter to set the SSH login password for the peer
MN.
Other Operations
Monitoring Alarm
In a dual-MN HA scenario, if the active MN is disconnected, the administrator can create
an event alarm in Monitoring Alarm, add the corresponding alarm metric, and specify an
endpoint. Then, the system will send alarm messages via email, DingTalk, HTTP
application, short message service, or Microsoft Teams.Figure 9. Active MN Is Disconnected
If the backup MN is disconnected, the administrator can receive relevant notifications in
Message Center.
Figure 10. Backup MN Is Disconnected
Log Output
In a dual-MN HA scenario, the administrator can collect logs related to the
zsha2 service by running the following
commands:
In a dual-MN HA scenario, assume that MN1 is the active MN and MN2 is the standby
MN.
If the administrator needs to temporarily shut down MN1 for maintenance, follow these
steps:
Switch MN1 to the standby MN.
On MN1, run the zsha2 demote
command. Then, MN1 is switched to the standby MN online, and MN2 becomes the
active MN after obtaining a VIP.
Stop MN1.
If MN1 is not added to ZStack Cloud as a compute
node, follow these steps:
Run the zsha2 stop-node command on MN1 to stop
the zsha2 service.
Shut down MN1.
Maintain MN1 after shutdown.
If MN1 is reused as a compute node and added to ZStack Cloud, follow these steps:
Run the zsha2 stop-node command on MN1 to stop
the zsha2 service.
Put MN1 into maintenance mode.
Shut down MN1.
Maintain MN1 after shutdown.
Start MN1.
After powering on MN1, start the server manually or through IPMI.
Wait for MN1 to start and successfully boot the operating system.
On MN1, run the zsha2 start-node command to start the
zsha2 service.
On MN1, run the zsha2 status command to check whether
the zsha2 service is running properly.
On MN1, run the zstack-ctl status command to check
whether the MN service and the UI are running properly.
Standby MN Maintenance
In a dual-MN HA scenario, assume that MN1 is the active MN and MN2 is the standby
MN.
If the administrator needs to temporarily shut down MN2 for maintenance, follow these steps:
Stop MN2.
If MN2 is not added to ZStack Cloud as a
compute node, follow these steps:
On MN2, run the zsha2 stop-node command to
stop the zsha2 service.
Shut down MN2.
Maintain MN2 after shutdown.
If MN2 is reused as a compute node and added to ZStack Cloud, follow these steps:
On MN2, run the zsha2 stop-node command to
stop the zsha2 service.
Put MN2 into the maintenance mode.
Shut down MN2.
Maintain MN2 after shutdown.
Start MN2.
After powering on MN2, start the server manually or through
IPMI.
Wait for MN2 to start and successfully boot the operating
system.
On MN2, run the zsha2 start-node command to start
services related to zsha2.
On MN2, run the zsha2 status command to check
whether the zsha2 service is running
properly.
On MN2, run the zstack-ctl status command to check
whether the MN service and the UI are running properly.
Dual-MN Maintenance
In a dual-MN HA scenario, assume that MN1 is the active MN and MN2 is the standby MN.
If the administrator needs to temporarily shut down these two MNs for maintenance, follow
these steps:
On each MN, run the zsha2 stop-node command to stop the
zsha2 service.
Shut down each MN.
Maintain each MN after shutdown.
After powering on each MN, start the server manually or through IPMI.
Wait for each MN to start and successfully boot the operating system.
On each MN, run the zsha2 start-node command to start the
zsha2 service.
On each MN, run the zsha2 status command to check whether the
zsha2 service is running properly.
On each MN, run the zstack-ctl status command to check whether
the MN services and the UI are running properly.
MN Troubleshooting
Single-MN Troubleshooting
In a dual-MN HA scenario, if one MN fails, repair and recover the node by following these
steps:
On the failed MN, run the zsha2 stop-node command to stop the
zsha2 service.
Try to recover the failed node. If the recovery fails, use ZStack Cloud installation package of the same version to repair the node
or install a new node.
If you need to install a new node, follow these steps:
Provision a backup server to make the hardware specifications more similar to those
of the failed node.
Install the basic operating system. After the installation is completed, configure
the root password and network information, which must be consistent with that of the
failed node. For more information, see Installation and Deployment.
On the new node, run the zsha2 status command
to check whether the zsha2 service is running properly.
In the new node, run the zstack-ctl status
command to check whether the MN service and the UI are running properly.
Dual-MN Troubleshooting
In a dual-MN HA scenario, if both MNs fail, repair and recover the nodes by following
these steps:
Try to recover the failed nodes. If the recovery fails, use ZStack Cloud of the same version to repair the nodes or
install two new nodes.
If you need to install two new nodes, follow these steps:
Provision two backup servers to make the hardware specifications more
similar to those of the failed nodes.
Install the basic operating system on each backup server. After the
installation is completed, configure the root password and network
information, which must be consistent with that of the failed nodes. For
more information, see Installation and Deployment.
Select a MN that is running
properly, SSH to the MN via its IP address, and run
the following command to recover the database on
this
MN:
In the preceding command,
/var/lib/zstack/mysql-backup/xxx.gz
is the file path and name of the backup
database.
MYSQL_PASSWORD is the password of the
database. Default password:
zstack.mysql.password.
On this node, run the
install_ha command to reinstall
an HA suite. For more information, see Use the Command Line.
On the new node, run the zsha2 status command
to check whether the zsha2 service is running properly.
In the new node, run the zstack-ctl status
command to check whether the MN service and the UI are running properly.
MN Database Backup and Recovery
Database Backup
In a dual-MN HA scenario, you can back up a database by using the
following method:
Select a MN that is running properly, SSH to the MN via
its IP address, and run the zstack-ctl
dump_mysql command to manually back up
the database.
Note:
VIPs are used to log in to the UI. Do not use
VIPs to log in to a MN through SSH.
After the database is backed up, the database
is saved to the
/var/lib/zstack/mysql-backup/
directory as a .gz file. Example name:
zstack-backup-db-2019-06-18_00-30-04.gz.
Database Recovery
In a dual-MN HA scenario, you can recover a database by following these
steps:
Select a MN that is running
properly, SSH to the MN via its IP address, and run
the following command to recover the database on
this
MN:
In the preceding command,
/var/lib/zstack/mysql-backup/xxx.gz
is the file path and name of the backup
database.
MYSQL_PASSWORD is the password of the
database. Default password:
zstack.mysql.password.
On this node, run the
install_ha command to reinstall
an HA suite. For more information, see Use the Command Line.
CLI Guidance
zsha2 has many sub-commands. This section will elaborate on what each
sub-command is and how to use them.
-h
Description
Displays the help information, which allows you to view all sub-commands of
zsha2.
Usage
[root@localhost ~]# zsha2 -h
usage:
zsha2 [ global options ] command [ command options ]
Global options:
-h,--help Display this message
Commands:
install-ha install two-node HA environment
stop-node stop zstack service in HA environment
start-node start zstack service in HA environment
upgrade-mn upgrade the MN in HA environment
upgrade-ha upgrade the HA suites
demote demote current node as backup
status show HA status
show-config show HA configuration
sample-config generate sample configuration to setup HA environment
collect-log collect HA related log files
help show this help message
version
Description
Displays the version information, including the version No. and commit ID.
Usage
[root@localhost ~]# zsha2 version
version 3.1.0.0, commit 2b1b06788e4e1d4b514342db1f381b460f7242e6
install-ha
Description
An installation command. If you installed two MNs, you could run the
zsha2 installation command in a MN to switch to the dual-MN
HA mode.
Usage
Parameter
Description
Example
-nic
The physical device name, which is used to
configure a VIP. In production environments, this parameter is
usually a network management bridge.
./zsha2 install-ha -nic
br_bond0
-gateway
The arbitration gateway of the active and standby
MNs.
./zsha2 install-ha -gateway
192.168.0.1
-slave
Specifies the standby MN.
Note:
During the installation, the database of the standby MN
will be overwritten by that of the active MN. Please
exercise caution.
If the root password contains special shell characters,
escape these characters.
Optional. Specifies an network range, which must
cover the IP address, VIP, and gateway of the active and standby
MNs.
Note: If not specified, the system will calculate a minimum
network range, which might fail to meet the requirements. We
recommend that you specify a network range.
./zsha2 install-ha -cidr
192.168.0.0/16
-force
Optional. Force runs the zsha2
installation command in the active MN if the database of the active
and standby MNs cannot automatically synchronized for a long
time.
Note: We recommend that you back up these two databases
before you perform the force installation.
./zsha2 install-ha
-force
-repo
Optional. Specifies the YUM repository, which
defaults to the local repository.
./zsha2 install-ha -repo
zstack-local
-timeout
Optional. The timeout for copying the databases
of the active and standby MNs. Default: 600. Unit: second.
./zsha2 install-ha -timeout
600
-yes
Optional. Indicates that all settings are
allowed.
./zsha2 install-ha -yes
-config
Optional. Initializes and installs an HA suite by
using a configuration file.
./zsha2 install-ha -config
zs-install.config
The following is an example of how to install an HA suite by specifying the command
line:
[root@localhost ~]# ./zsha2 install-ha -nic br_bond0 -gateway 192.168.0.1 -slave "root:password@192.168.196.125" \
-vip 192.168.199.151 -myip 192.168.195.200 -db-root-pw zstack.mysql.password -time-server 192.168.196.125 -cidr 192.168.0.0/16 -yes
Master IPv4 address: 192.168.195.200
ZStack version @ 192.168.195.200: 2.6.0
ZStack version @ 192.168.196.125: 2.6.0
Calculated CIDR: 192.168.0.0/16
Backuping databases on 192.168.196.125 (/var/lib/zstack/mysql-backup/zstack-backup-db-2018-10-09T164934-0800.gz) ...
Start installation ...
x checking network interface and gateway ...
✓ Task 1: checking network interface and gateway ... completed.
x prepare HA-services ...
✓ Task 2: prepare HA-services ... completed.
+ setting up DB config before replication ...
✓ Task 3: setting up DB config before replication ... completed.
x creating DB user for replication ...
✓ Task 4: creating DB user for replication ... completed.
+ update iptables rules ...
✓ Task 5: update iptables rules ... completed.
+ starting the initial replication ...
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 1844
Binlog_Do_DB:
Binlog_Ignore_DB:
+ starting the initial replication ...
Local database backuped to /var/lib/zstack/mysql-backup/zstack-backup-db-2018-10-09T164934-0800.gz
✓ Task 6: starting the initial replication ... completed.
x wait peer slave sync status ...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:
Last_SQL_Error:
Last_Error:
Last_Errno: 0
✓ Task 7: wait peer slave sync status ... completed.
+ wait local DB sync status ...
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 245
Binlog_Do_DB:
Binlog_Ignore_DB:
x wait local DB sync status ...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:
Last_SQL_Error:
Last_Error:
Last_Errno: 0
✓ Task 8: wait local DB sync status ... completed.
+ setting up keepalived ...
✓ Task 9: setting up keepalived ... completed.
x check slave virtual IP settings ...
✓ Task 10: check slave virtual IP settings ... completed.
x configuring ZStack servers ...
✓ Task 11: configuring ZStack servers ... completed.
x installing HA scripts ...
✓ Task 12: installing HA scripts ... completed.
x starting ZStack HA service ...
✓ Task 13: starting ZStack HA service ... completed.
x waiting management node up and running ...
✓ Task 14: waiting management node up and running ... completed.
OK, installation completed.
Hints:
- Stop server with: zsha2 stop-node,
- Start server with: zsha2 start-node,
- Get HA status with: zsha2 status -peer 192.168.196.125
Please also setup SSH pubkey-login between 192.168.195.200 and 192.168.196.125
The following is an example of how to install an HA suite by writing a configuration
file:
[root@localhost ~]# ./zsha2 install-ha -config zs-install.config
Master IPv4 address: 192.168.195.200
ZStack version @ 192.168.195.200: 2.6.0
ZStack version @ 192.168.196.125: 2.6.0
Calculated CIDR: 192.168.0.0/16
Backuping databases on 192.168.196.125 (/var/lib/zstack/mysql-backup/zstack-backup-db-2018-10-09T164934-0800.gz) ...
Start installation ...
x checking network interface and gateway ...
✓ Task 1: checking network interface and gateway ... completed.
x prepare HA-services ...
✓ Task 2: prepare HA-services ... completed.
+ setting up DB config before replication ...
✓ Task 3: setting up DB config before replication ... completed.
x creating DB user for replication ...
✓ Task 4: creating DB user for replication ... completed.
+ update iptables rules ...
✓ Task 5: update iptables rules ... completed.
+ starting the initial replication ...
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 1844
Binlog_Do_DB:
Binlog_Ignore_DB:
+ starting the initial replication ...
Local database backuped to /var/lib/zstack/mysql-backup/zstack-backup-db-2018-10-09T164934-0800.gz
✓ Task 6: starting the initial replication ... completed.
x wait peer slave sync status ...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:
Last_SQL_Error:
Last_Error:
Last_Errno: 0
✓ Task 7: wait peer slave sync status ... completed.
+ wait local DB sync status ...
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 245
Binlog_Do_DB:
Binlog_Ignore_DB:
x wait local DB sync status ...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:
Last_SQL_Error:
Last_Error:
Last_Errno: 0
✓ Task 8: wait local DB sync status ... completed.
+ setting up keepalived ...
✓ Task 9: setting up keepalived ... completed.
x check slave virtual IP settings ...
✓ Task 10: check slave virtual IP settings ... completed.
x configuring ZStack servers ...
✓ Task 11: configuring ZStack servers ... completed.
x installing HA scripts ...
✓ Task 12: installing HA scripts ... completed.
x starting ZStack HA service ...
✓ Task 13: starting ZStack HA service ... completed.
x waiting management node up and running ...
✓ Task 14: waiting management node up and running ... completed.
OK, installation completed.
Hints:
- Stop server with: zsha2 stop-node,
- Start server with: zsha2 start-node,
- Get HA status with: zsha2 status -peer 192.168.196.125
Please also setup SSH pubkey-login between 192.168.195.200 and 192.168.196.125
stop-node
Description
Stops a MN and its zsha2 service in a dual-MN HA scenario.
Note: In the preceding command, the
-peerpass parameter is optional. You can
use this parameter to set the SSH login password for the peer
MN.
Note: In the preceding command, the
-peerpass parameter is optional. You can
use this parameter to set the SSH login password for the peer
MN.
upgrade-ha
Description
Upgrades the zsha2 service on the current node in a dual-MN
scenario.
Usage
[root@localhost ~]# ./zsha2 upgrade-ha
Start upgrading ...
+ Stopping HA-services ...
✓ Task 1: Stopping HA-services ... completed.
+ Upgrading HA suites ...
✓ Task 2: Upgrading HA suites ... completed.
x starting ZStack HA service ...
✓ Task 3: starting ZStack HA service ... completed.
OK, upgrade HA completed.
Hints:
- Stop server with: zsha2 stop-node,
- Start server with: zsha2 start-node,
- Get HA status with: zsha2 status -peer 192.168.196.125
demote
Description
Switches the active MN to the standby MN online in a dual-MN HA scenario.
Usage
[root@localhost ~]# zsha2 demote
status
Description
In a dual-MN HA scenario, displays the status of the current MN, including whether a
VIP is obtained, whether the MN is reachable, whether the gateway is reachable,
whether the VIP is reachable, whether the peer MN is reachable, the status of the
Keepalived service, the status of the HA monitoring service, the database status,
the MN status, the UI status, the Slave status, and the status of the peer MN.
Usage
[root@localhost ~]# zsha2 status
Status report from 192.168.195.200
=================================
Owns virtual address: yes
Self 192.168.195.200 reachable: yes
Gateway 192.168.0.1 reachable: yes
VIP 192.168.199.151 reachable: yes
Peer 192.168.196.125 reachable: yes
Keepalived status: active
ZStack HA Monitor: active
MySQL status: mysqld is alive
MN status: Running [PID:6500]
UI status: Running [PID:9785] http://192.168.195.200:5000
Slave Status:
-------------
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Warning: Permanently added '192.168.196.125' (ECDSA) to the list of known hosts.
Status report from 192.168.196.125
================================
Owns virtual address: no
Self 192.168.196.125 reachable: yes
Gateway 192.168.0.1 reachable: yes
VIP 192.168.199.151 reachable: yes
Peer 192.168.195.200 reachable: yes
Keepalived status: active
ZStack HA Monitor: active
MySQL status: mysqld is alive
Slave Status:
-------------
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Error:
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:
Note: visit ZStack UI with http://192.168.199.151:5000
show-config
Description
In a dual-MN HA scenario, displays the configuration information about the current
MN.
An instance is a virtual machine or server that runs the images of operating
systems in Cloud, such as VM instance and elastic baremetal
instance.
VM Instance
A VM instance is a virtual
machine instance running on a host. A VM instance has its own IP address and can
access public networks and run application services.
Volume
A volume provides storage space for a VM instance. Volumes
are categorized into root volumes and data volumes.
Root Volume
A root volume provides support for the system operations
of a VM instance.
Data Volume
A data volume provides extended storage space for a VM
instance.
Image
An image is a template file used to create a VM instance
or volume. Images are categorized into system images and volume
images.
Instance Offering
An instance offering defines the number of vCPU cores,
memory size, network bandwidth, and other configuration settings of VM
instances.
Disk Offering
A disk offering defines the capacity and other
configuration settings of volumes.
GPU Specification
A GPU specification defines the frame per second (FPS),
video memory, resolution, and other configuration settings of a physical or virtual
GPU. GPU specifications are categorized into physical GPU specifications and virtual
GPU specifications.
vNUMA Configuration
vNUMA uses CPU pinning to passthrough the topology of
associated host physical NUMA (pNUMA) nodes to a VM instance, generating a topology
of virtual NUMA (vNUMA) nodes for the VM instance. This topology enables a vCPU on a
vNUMA node to primarily access the local memory and thus improves VM
performance.
NUMA (Non-Uniform Memory Access)
Non-uniform memory access (NUMA) is a computer memory
design where the memory access time depends on the memory location relative to the
CPU. Under NUMA, a processor can access its own local memory faster than non-local
memory and thus improves VM performance.
pNUMA Node (physical NUMA Node)
A pNUMA node (physical NUMA node) is a host NUMA node
predefined based on the host NUMA architecture. It is used to manage the CPUs and
memory of the host.
pNUMA Topology (physical NUMA Topology)
A pNUMA topology (physical NUMA topology) is the topology
of the host NUMA nodes predefined by the CPU vendor based on the host NUMA
architecture.
vNUMA Node (virtual NUMA Node)
A vNUMA node (virtual NUMA node) is generated by
passing-through associated pNUMA nodes via CPU pinning. It is used to manage the
CPUs and memory of a VM instance.
vNUMA Topology (virtual NUMA Topology)
A vNUMA topology (virtual NUMA topology) is the topology
of VM NUMA nodes generated by passing-through associated pNUMA nodes via CPU
pinning.
Local Memory
Local memory is the memory that a CPU (pCPU or vCPU)
accesses through the Uncore iMC (Integrated Memory Controller) of the same NUMA
(pNUMA or vNUMA) node. Compared with accessing non-local memory, accessing local
memory has lower latencies.
CPU Pinning
CPU pinning assigns the virtual CPUs (vCPUs) of a VM
instance to specific physical CPUs (pCPUs) of the host, which improves VM
performance.
EmulatorPin Configuration
EmulatorPin assigns all other threads than virtual CPU
(vCPU) threads and IO threads of a VM instance to physical CPUs (pCPUs) of the host
so that these threads run on assigned pCPUs.
Auto-Scaling Group
An auto-scaling group is a group of VM instances that are
used for the same scenarios. An auto-scaling group can automatically scale out or in
based on application workloads or health status of VM instances in the
group.
Snapshot
A snapshot is a point-in-time capture of data status in a
volume.
Affinity Group
A VM scheduling policy is a resource orchestration policy
based on which VM instances are assigned hosts to achieve the high performance and
high availability of businesses.
Zone
A zone is a logical group of resources such as clusters,
L2 networks, and primary storage. Zone is the largest resource scope defined in the
Cloud.
Cluster
A cluster is a logical group of hosts (compute
nodes).
Host
A host provides compute, network, and storage resources
for VM instances.
Primary Storage
A primary storage is 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
An image storage is a storage server that stores VM image
templates, including ISO image files.
iSCSI Storage
iSCSI storage is an SAN storage that uses the iSCSI
protocol for data transmission. You can add an iSCSI SAN block as a Shared Block
primary storage or pass through the block to a VM instance.
FC Storage
FC storage is an SAN storage that uses the FC technology
for data transmission. You can add an FC SAN block as a Shared Block primary storage
or pass through the block to a VM instance.
NVMe Storage
A type of storage implemented via the NVMe-oF (NVMe over
fabrics) protocol. You can add a block device configured from an NVMe storage as
SharedBlock primary storage.
L2 Network
An L2 network is a layer 2 broadcast domain used for layer
2 isolation. Generally, L2 networks are identified by names of devices on the
physical network.
VXLAN Pool
A VXLAN pool is 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.
L3 Network
An L3 network includes IP ranges, gateway, DNS, and other
network configurations that are used by VM instances.
Public Network
Generally, a public network is a logical network that is
connected to the Internet. However, in an environment that has no access to the
Internet, you can also create a public network.
Flat Network
A flat network is connected to the network where the host
is located and has direct access to the Internet. VM instances in a flat network can
access public networks by using elastic IP addresses.
VPC Network
A VPC network is a private network where VM instances can
be created. A VM instance in a VPC network can access the Internet through a VPC
vRouter.
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 storage, image storage, and VPC vRouters.
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.
VPC vRouter
A VPC vRouter is a dedicated VM instance that provides
multiple network services.
VPC vRouter HA Group
A VPC vRouter HA group consists of two VPC vRouters.
Either VPC vRouter can be a primary or secondary VPC vRouter for the group. If the
primary VPC vRouter does not work as expected, the VPC vRouter becomes the secondary
VPC vRouter in the group to ensure high availability of business.
vRouter Image
A vRouter image encapsulates network services and can be
used to create VPC vRouters.
Dedicated-Performance LB Image
A dedicated-performance load balancer (LB) image
encapsulates dedicated-performance load-balancing services and can be used to create
load balancer instances. However, a dedicated-performance load balancer image cannot
be used to create VM instances.
vRouter Offering
A vRouter offering defines 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.
LB Instance Offering
A load balancer (LB) instance offering defines the CPU,
memory, image, and management network configuration settings used to create LB
instances. LB instances provide load balancing services for the public network, flat
network, and VPC network.
SDN Controller
The SDN controller is the core of the SDN architecture,
responsible for centralized management and control of network
devices.
SDN Cluster
A cluster of dedicated VM instances designed to provide highly available SDN capabilities.
SDN Instance
A dedicated VM instance designed to provide SDN network
capabilities.
SDN Image
An SDN image encapsulates an SDN software and can be used
to create SDN instances.
SDN Instance Offering
An SDN instance offering defines the CPU, memory, SDN
image, and management network configuration used for creating SDN
instances.
Security Group
A 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.
VIP
In bridged network environments, a virtual IP address
(VIP) provides network services such as serving as an elastic IP address (EIP), port
forwarding, load balancing, IPsec tunneling. When a VIP provides the preceding
network services, packets are sent to the VIP and then routed to the destination
network where VM instances are located.
EIP
An elastic IP address (EIP) functions based on the NAT
technology. IP addresses in a private network are translated into an EIP that is in
another network. This way, private networks can be accessed from other networks by
using EIPs.
Port Forwarding
Port forwarding functions based on the layer-3 forwarding
service of VPC vRouters. This service forwards traffic flows of the specified IP
addresses and ports in a public network to specified ports of VM instances by using
the specified protocol. If your public IP addresses are insufficient, you can
configure port forwarding for multiple VM instances by using one public IP address
and port.
Load Balancer
A load balancer distributes traffic flows of a virtual IP
address to backend servers. It automatically inspects the availability of backend
servers and isolates unavailable servers during traffic distribution. This way, the
load balancer improves the availability and service capability of your
business.
Listener
A listener monitors the frontend requests of a load
balancer and distributes the requests to a backend server based on the specified
policy. In addition, the listener performs health checks on backend
servers.
Forwarding Rule
A forwarding rule forwards the requests from different
domain names or URLs to different backend server groups.
Backend Server Group
A backend server group is a group of backend servers that
handles requests distributed by load balancers. It is the basic unit for traffic
distribution by load balancer instances.
Backend Server
A backend server handles requests distributed by a load
balancer. You can add a VM instance on the Cloud or a server on a third-party cloud
as a backend server.
Frontend Network
A frontend network is a type of network that is associated
with a load balancer. Requests from the network are distributed by the load balancer
to backend servers based on a specified policy.
Backend Network
A backend network is a type of network that is associated
with a load balancer. Requests from frontend networks are distributed by the load
balancer to servers in the backend network.
Load Balancer Instance
A load balancer instance is a custom VM instance used to
provide load balancing services.
Certificate
If you select HTTPS for a listener, associate it with a
certificate to make the listener take effect. You can upload either a certificate or
certificate chain.
Firewall
A firewall is 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.
Firewall Rule Set
A firewall rule set is a set of rules that a firewall uses
to defend against network attacks. You need to associate a rule set with the egress
or ingress flow direction of VPC vRouter NICs to make the rule set take
effect.
Firewall Rule
A firewall rule is an access control entry associated with
the egress or ingress flow direction of VPC vRouter NICs to defend against network
attacks. A firewall rule includes rule priority, match condition, and
behavior.
Rule Template
A rule template is a template that you can select when you
add rules to a rule set or a firewall.
IP/Port Set
An IP or port set is a set of IP addresses or ports that
you can select when you add rules to a rule set or a firewall.
IPsec Tunnel
An IPSec tunnel encrypts and verifies IP packets that
transmit over a virtual private network (VPN) from one site to
another.
OSPF Area
An Open Shortest Path First (OSPF) area is divided from an
autonomous system based on the OSPF protocol. This simplifies the hierarchical
management of vRouters.
NetFlow
A NetFlow monitors the ingress and egress traffic of the
NICs of VPC vRouters. The supported versions of data flows are V5 and
V9.
Port Mirroring
Port mirroring mirrors the traffic data of VM NICs and
sends the traffic data to the target ports. This allows for the analysis of data
packets of ports and simplifies the monitoring and management of data traffic and
makes it easier to locate network errors and exceptions.
Route Table
A route table contains information about various routes
that you configure. Route entries in a route table must include the destination
network, next hop, and route priority.
CloudFormation
CloudFormation is a service that simplifies the management
of cloud resources and automates deployment and O&S. You can create a stack
template to configure cloud resources and their dependencies. This way, resources
can be automatically configured and deployed in batches. CloudFormation provides
easy management of the lifecycle of cloud resources and integrates automatic O&S
into API and SDK.
Resource Stack
A resource stack is a stack of resources that are
configured by using a stack template. The resources in the stack have dependencies
with each other. You can manage resources in the stack by managing the resource
stack.
Stack Template
A stack template is a UTF8-encoded file based on which you
can create resource stacks. The stack template defines the resources that you want,
the dependencies between the resources, and the configuration settings of the
resources. When you use a stack template to create a resource stack, CloudFormation
parses the template and the resources are automatically created and
configured.
Sample Template
A sample template is a commonly used resource stack. You
can use a sample template provide by the Cloud to create resource
stacks.
Designer
A designer is a CloudFormation tool that allows you to
orchestrate cloud resources. You can drag and drop resources on a canvas and use
lines to establish dependencies between the resources.
Baremetal Cluster
A baremetal cluster consists of baremetal chassis. You can
manage baremetal chassis by managing a baremetal cluster where the chassis
reside.
Deployment Server
A deployment server is a server that provides PXE service
and console proxy service for baremetal chassis.
Baremetal Chassis
A baremetal chassis is used to create a baremetal instance
and is identified based on the BMC interface and IPMI configuration
setting.
Preconfigured Template
A preconfigured template is used to create a preconfigured
file that allows for unattended batch installation of an operating system for
baremetal instances.
Baremetal Instance
A baremetal instance is an instantiated baremetal chassis.
Elastic Baremetal Management
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.
Provision Network
A provision network is a dedicated network for PXE boot
and image downloads while creating elastic baremetal instances in a gateway proxy
cluster.
Elastic Baremetal Cluster
Provides a separated cluster to manage baremetal
nodes.
Gateway Node
A gateway node is a node where the ingress and egress
traffic of the Cloud and elastic baremetal instances in gateway proxy clusters is
forwarded.
Baremetal Node
A baremetal node is used to create a baremetal instance
and is identified based on the BMC interface and IPMI configuration
setting.
Elastic Baremetal Instance
An elastic baremetal instance has the same performance as
physical servers and allows elastic scaling. You can apply for and scale resources
based on your needs.
Elastic Baremetal Offering
An elastic baremetal offering defines the number of vCPU
cores, memory size, CPU architecture, CPU model, and other configuration settings of
elastic baremetal instances.
vCenter
The Cloud allows you to take over vCenter and manage
resources on the vCenter.
VM Instance
A VM instance is an ESXi virtual machine instance running
on a host. A VM instance has its own IP address to access public networks and can
run application services.
Network
A vCenter network defines the network settings of VM
instances on vCenter, such as IP range, gateway, DNS, and network
services.
Volume
A volume provides storage space for a VM instance on
vCenter. A volume attached to a VM instance can be used as a root volume or data
volume. A root volume provides support for the system operations of a VM instance. A
data volume provides extended storage space for a VM instance.
Image
An image is a template file used to create a VM instance
or volume on vCenter. Images are categorized into system images and volume
images.
Event Message
Event Message displays event alarm messages of vCenter
that is took over by the Cloud. This feature allows you to locate errors and
exceptions efficiently.
Network Topology
A network topology visualizes the network architecture of
the Cloud. It allows for efficient planning, management, and improvement of network
architecture. Network topologies can be categorized into global topologies and
custom topologies.
Performance Analysis
Performance Analysis displays the performance metrics of
key resources monitored externally or internally in the Cloud. You can view the
performance analysis or export the analysis report as needed to improve the O&M
efficiency.
Capacity Management
Capacity Management visualizes the capacities and usages
of key resources in the Cloud. You can use this feature to improve O&S
efficiency.
MN Monitoring
Management Node (MN) monitoring allows you to view the
health status of each management node when you use multiple management nodes to
achieve high availability.
Alarm
An alarm is used to monitor the status of time-series data
and events and respond to the status change. Alarms can be categorized into resource
alarm, event alarm, and extended alarm.
One-Click Alarm
A one-click alarm integrates multiple metrics of a
resource. You can create one-click alarms for multiple resources to monitor these
resources.
Alarm Template
An alarm template is a template of alarm rules. If you
associate an alarm template with a resource group, an alarm is created to monitor
the resources in the group.
Resource Group
A resource group consists of resources grouped based on
your business needs. If you associate an alarm template with a resource group, the
alarm rules specified by the template take effect on all the resources in the
group.
Message Template
A message template specifies the text template of a
resource alarm message or event alarm message sent to an SNS system.
Message Source
A message source is used to take over extended alarm
messages. If you configure alarms for message sources, extended alarm messages can
be sent to various endpoints.
Endpoint
An endpoint is a method that users obtain subscribed
messages. Endpoints are categorized into system endpoints, email, DingTalk, HTTP
application, short message service, and Microsoft Teams.
Alarm Message
An alarm message is a message sent the time when an alarm
is triggered.
Current Task
A current task is an ongoing operation performed in the
Cloud. You can perform centralized management over ongoing
operations.
Operation Log
An operation log is a chronological record of operations
on the specified objects and their operation results.
Audit
Audit monitors and records all activities on the Cloud.
You can use this feature to implement operation tracking, cybersecurity classified
protection compliance, security analysis, troubleshooting, and automatic
O&M.
Log Collection
Allows you to collect with one click the log data from the
Cloud and various nodes on the Cloud generated in the specified time period and
download the log data.
One-Click Inspection
Comprehensively inspects the health status of key
resources and services of the Cloud and scores their healthiness based on the
inspection results. In addition, the one-click inspection service provides O&M
suggestions and inspection reports.
Backup Management
Backup management integrates multiple disaster recovery
technologies such as incremental backup and full backup that are suitable for
multiple business scenarios. You can implement local backup and remote backup based
on your business needs.
Backup Job
You can create a backup job to back up local VM instances,
volumes, or databases to a specified storage server on a regular
basis.
Local Backup Data
Local backup data of VM instances, volumes, and databases
is stored in the local backup server.
Local Backup Server
A local backup server is located at the local data center
and is used to store local backup data.
Remote Backup Server
A remote backup server is located at a remote data center
or a public cloud and is used to store remote backup
data.
Continuous Data Protection (CDP)
Continuous Data Protection (CDP) provides second-level and
fine-grained continuous backups for important business systems in VM instances,
allowing users to restore VM data to a specific time state, and retrieve files
without restoring the system.
CDP Task
You can create a CDP task to continuously back up your VM
data to a specified backup server to achieve continuous data protection and
recovery.
CDP Data
The backup data generated from continuous data protection
on VM instances is stored in local backup servers.
Recovery Point
A recovery point is a data point generated during
continuous data protection. A recovery point corresponds to a data record within the
recovery point interval specified by the user.
Locked Recovery Point
You can lock or unlock a recovery point as needed. After a
recovery point is locked, data of the recovery point will not be automatically
cleared or deleted.
Recovery Task
A recovery task helps you quickly restore data by
specifying a CDP task and recovery point, and allows you to view the recovery
progress and logs in a more friendly way.
Cryptography Security Compliance
The Cryptography Security Compliance service provides
applications with cloud security capabilities based on commercial cryptography,
meeting the requirements of commercial cryptography application security
assessments.
HSM Pool
An HSM pool is a logical group of hardware security
modules (HSMs) and is used to provide unified cryptography services such as
signature validation and encryption.
HSM
A hardware security module (HSM) is a dedicated device
that encrypts, decrypts, and authenticates information by using the cryptographic
technology.
Platform Cryptography Security Compliance
Enables the Cloud to meet the requirements of Cryptography
Security Compliance through the cryptography capabilities provided by HSM
pools.
Certificate Login
Authenticates the identity of a user by using a UKey
device.
Data Protection
Protects important data on the Cloud to ensure the data
confidentiality and integrity.
Scheduled Job
A scheduled job defines that a specific action be
implemented at a specified time based on a scheduler.
Scheduler
A scheduler is used to schedule jobs. It is suitable for
business scenarios that last for a long time.
Tag
A tag is used to mark resources. You can use a tag to
search for and aggregate resources.
Migration Service
The Cloud provides V2V migration service that allows you
to migrate VM instances and data from other virtualized platform to the current
cloud platform.
ZMigrate Migration Service
A migration service installed from
Application Market that migrates VM instances and their data from VMware environments
to the current cloud platform.
V2V Migration
V2V Migration allows you to migrate VM instances from the
VMware or KVM platform to the current cloud platform.
V2V Conversion Host
A V2V conversion host is a host in the destination cluster
that you need to specify during V2V migration to cache VM instances and data when
you implement V2V migration. After the VM instances and data are cached in the
V2Vconversion host, they are migrated to the destination primary
storage.
User
A user is a natural person that constructs the most basic
unit in Tenant Management.
User Group
A user group is a collection of natural persons or a
collection of project members. You can use a user group to grant
permissions.
Role
A role is a collection of permissions that can be granted
to users. A user that assumes a role can call API operations based on the
permissions specified by the role. Roles are categorized into platform roles and
project roles.
Single Sign-On
The Single Sign-On service provided by the Cloud. It supports seamless access to SSO systems. Through the service, related users can directly log in to the Cloud and manage cloud resources.
Project
A project is a task that needs to be accomplished by
specific personnel at a specified time. In Tenant Management, you can plan resources
at the project granularity and allocate an independent resource pool to a project.
The word Tenant in Tenant Management mainly refers to projects. A project is
a tenant.
Project Member
A project member is a member in a project who is granted permissions on
specific project resources and can use the resources to accomplish tasks. Project
members include the project admin, project managers, and normal project
members.
Process Management
Process management is part of ticket management that
manages the processes related to the resources of projects. Processes can be
categorized into default processes and custom processes.
My Approvals
In the Cloud, only the administrator and project
administrators are granted approval permissions. the administrator and project
administrators can approve or reject a ticket. If a ticket is approved, resources
are automatically deployed and allocated to the specified project.
Bills
A bill is the expense of resources totaled at a specified
time period. Billing is accurate to the second. Bills can be categorized into project bills, department bills, and account
bills.
Pricing List
A pricing list is a list of unit prices of different
resources. The unit price of a resource is set based on the specification and usage
time of the resource.
Console Proxy
Console proxy allows you to log in to a VM instance by
using the IP address of a proxy.
AccessKey Management
An AccessKey pair is a security credential that one party
authorizes another party to call API operations and access its resources in the
Cloud. AccessKey pairs shall be kept confidential.
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.
Application Center
Application Market allows you to add applications to the
Cloud and then access the applications with one click. It extends the functionality
of the Cloud. You can add default applications through the built-in installation
package or add more applications through URLs.
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.
Theme and Appearance
You can customize the theme and appearance of the
Cloud.
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.
Global Setting
Global Setting allows you to configure settings that take
effect on the whole platform.
Scenario Template
Scenario Template provides multiple templates that
encapsulate scenario-based global settings. You can apply a template globally with
one click based on your business needs. This improves your O&M
efficiency.
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.
Time Management
Manages the Cloud system time and allows you to configure
time servers for the Cloud. After you configure NTP time servers for the Cloud, the
clock of the time servers is synced with all nodes of the Cloud.
GPU Device
A GPU device is a powerful microprocessor with high
computational capabilities. You can use a GPU device to handle intricate graphics
rendering and parallel computing jobs, thus improving the efficiency of businesses
such as graphic production, video processing, and machine learning.
Script Library
The script library stores and manages script files
centrally. By executing scripts on VM instances, you can complete complex O&M
operations and automated jobs.
XML Hook
An XML Hook is a script that can flexibly insert or modify
parameters in XML files of VM instances. By attaching an XML Hook to a VM instance,
you can customize VM configurations and enable specialized
functionalities.
Container Service
A simple and user-friendly container management service,
providing features like GPU management & scheduling, multi-tenancy,
multi-cluster, quota configuration, CI/CD. and microservice. The service reduces the
container using complexity and aligns well with traditional user's habits, helping
you easily manage and deploy your container cluster, and enjoy the benefits of
cloud-native technologies in a quick and convenient way.
Advanced Monitoring Server
An advanced monitoring server is a dedicated VM instance
used to receive advanced monitoring data of load balancers and other
resources.
Advanced Monitoring Server Image
An advanced monitoring server image encapsulates the
advanced monitoring service and can be used to create advanced monitoring
server.
Advanced Monitoring Server Offering
An advanced monitoring server offering defines the CPU
cores, memory size, image, management network, and public network configurations of
advanced monitoring server. You can use an advanced monitoring server offering to
create advanced monitoring servers.
Plugin Management
You can package extended resources or tools into
standardized plugins for quick installation and integration, expanding the Cloud
capabilities.
Region Management
A region is a self-contained cloud environment with
independent management node(s), networks, hardware, and cloud resources. ZStack IAM
enabled user synchronization and SSO across multiple regions.
Note: After you download the required software, confirm the
integrity of the file by using the MD5 checksum tool.
