Installation and Deployment

Overview

ZStack Cloud provides high availability (HA) for multiple 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.

This Tutorial provides an example of a dual-MN HA scenario.

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

This section mainly describes how to install and deploy a dual-MN HA environment.

Prepare Software Tools

The administrator needs to prepare the following necessary software packages to facilitate the installation and deployment process.
  • ZStack Cloud ISO.
    • ZStack Cloud ISO:
      • h84r: ZStack-Cloud-x86_64-DVD-4.8.38-h84r.iso
      • Download address: Click here
    • ZStack Cloud installation package:
      • Software: ZStack-Cloud-installer-4.8.38.bin
      • Download address: Click here
  • Multi-MN HA suite
    • Software: ZStack-Multinode-HA-Suite-4.8.38.tar.gz
    • Download address: Click here
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

  1. 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.
  2. 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


  3. Write the Image.
    Use the default setting and click In Rufus, choose Start.
    Figure 4. Write Disk Image on Rufus


  4. 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


  5. 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


  6. 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.

    Click Begin Installation. Then, the installation process proceeds automatically. The administrator needs to set the root account and password.

    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 multi-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

  1. 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-4.8.38.tar.gz
    
    # Decompress the suite. Then, two executable files are generated: zsha2 and zstack-hamon.
    [root@localhost ~]# tar zxvf ZStack-Multinode-HA-Suite-4.8.38.tar.gz
    zsha2 //A program for installing and managing multi-node HA.
    zstack-hamon //A program for monitoring multi-node HA.
  2. Initialize the HA suite.
    On MN1, run the following commands to install the HA suite:
    [root@localhost ~]# chmod +x zsha2 zstack-hamon
    [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
    Note:
    • 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:
          -slave "root:\' \" \* \? \\ \~ \` \! \# \$ \& \|@192.168.196.125"
      • -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.
  3. 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 multi-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

  1. 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-4.8.38.tar.gz
    
    # Decompress the suite. Then, two executable files are generated: zsha2 and zstack-hamon.
    [root@localhost ~]# tar zxvf ZStack-Multinode-HA-Suite-4.8.38.tar.gz
    zsha2 //A program for installing and managing multi-node HA.
    zstack-hamon //A program for monitoring multi-node HA.
  2. 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.

  3. Initialize the HA suite.
    Run the following command to initialize and install the HA suite:
    [root@localhost ~]# ./zsha2 install-ha -config zs-install.config
    Note:
    • 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.
  4. 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

  1. Access the UI (http://VIP:5000) by using a VIP and log in to the Cloud as an admin.
  2. 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:
  1. Complete the preparations before the upgrade.
  2. Upgrade the HA suite.
  3. Upgrade the MNs.
Before you perform any upgrades, complete the following preparations:
  1. 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.
  2. Run the following command on each MN to back up your database:
    [root@localhost ~]#zstack-ctl dump_mysql --file-name zstack-db-backup
  3. 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.
  4. Run the following command on each MN to update the local repo by using the latest ISO you downloaded before:
    [root@localhost ~]#cd /root/
    #bash /root/zstack-upgrade -r ZStack-Cloud-x86_64-DVD-4.8.38-h84r.iso
After you obtain the new HA suite, you can use the suite to upgrade the existing zsha2 service. The steps are as follows:
  1. 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
  2. Log in to the MN where the VIP is located through IPMI, and run the following command to decompress the dual-MN HA suite:
    [root@localhost ~]#tar zxvf ZStack-Multinode-HA-Suite-4.8.38.tar.gz
  3. Run the following command to grant executable permissions to the decompressed zsha2 and zstack-hamon:
    [root@localhost ~]#chmod +x zsha2 zstack-hamon
  4. 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:
  1. 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
  2. Prepare the following necessary packages:
    • ZStack Cloud ISO:
      • h84r: ZStack-Cloud-x86_64-DVD-4.8.38-h84r.iso
      • Download address: Click here
    • ZStack Cloud installation package:
      • Software: ZStack-Cloud-installer-4.8.38.bin
      • Download address: Click here
    • Upgrade script
      • Software: zstack-upgrade
      • Download address: Click here
      Note: The version of the upgrade script must be consistent with the version of the custom ISO and the bin package.
    Note: After you download the software, check the authentication code by using MD5 and verify that the code conforms with the release information.
  3. Select a proper upgrade method. You can upgrade from the bin package or from ISO.
    If you upgrade the MN from the bin package, follow these steps:
    1. Import the new version of ZStack Cloud custom ISO to each MN and run the following command on each MN to upgrade the local repo to the latest version:
      [root@localhost ~]# bash zstack-upgrade -r ZStack-Cloud-installer-4.8.38.bin
    2. Run the following command on either MN. Then, both MNs will be upgraded.
      [root@localhost ~]# zsha2 upgrade-mn -peerpass password ZStack-Cloud-installer-4.8.38.bin
    If you choose to upgrade the MN from ISO, follow this step:
    1. Run the following command on either MN. Then, both MNs will be upgraded.
      [root@localhost ~]# zsha2 upgrade-mn -peerpass password ZStack-Cloud-x86_64-DVD-4.8.38-h84r.iso
      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:
[root@localhost ~]# zsha2 collect-log
Collecting logs ...
Collected log: zsha2-log-2018-09-17T154358+0800.tgz

# Decompress the log package.
[root@localhost ~]# tar zxvf zsha2-log-2021-01-17T154358+0800.tgz
tmp/zsha2-log588815976/
tmp/zsha2-log588815976/zsha2-status.log
tmp/zsha2-log588815976/zstack-ha.log
tmp/zsha2-log588815976/keepalived.data
tmp/zsha2-log588815976/zs-vip-192.168.199.151.log
tmp/zsha2-log588815976/keepalived_status.log

HA Test and Recovery

Planned O&M

Single-MN Maintenance

Active 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 MN1 for maintenance, follow these steps:

  1. 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.

  2. Stop MN1.
    • If MN1 is not added to ZStack Cloud as a compute node, follow these steps:
      1. Run the zsha2 stop-node command on MN1 to stop the zsha2 service.
      2. Shut down MN1.
      3. Maintain MN1 after shutdown.
    • If MN1 is reused as a compute node and added to ZStack Cloud, follow these steps:
      1. Run the zsha2 stop-node command on MN1 to stop the zsha2 service.
      2. Put MN1 into maintenance mode.
      3. Shut down MN1.
      4. Maintain MN1 after shutdown.
  3. Start MN1.
    1. After powering on MN1, start the server manually or through IPMI.
    2. Wait for MN1 to start and successfully boot the operating system.
    3. On MN1, run the zsha2 start-node command to start the zsha2 service.
    4. On MN1, run the zsha2 status command to check whether the zsha2 service is running properly.
    5. 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:
  1. Stop MN2.
    • If MN2 is not added to ZStack Cloud as a compute node, follow these steps:
      1. On MN2, run the zsha2 stop-node command to stop the zsha2 service.
      2. Shut down MN2.
      3. Maintain MN2 after shutdown.
    • If MN2 is reused as a compute node and added to ZStack Cloud, follow these steps:
      1. On MN2, run the zsha2 stop-node command to stop the zsha2 service.
      2. Put MN2 into the maintenance mode.
      3. Shut down MN2.
      4. Maintain MN2 after shutdown.
  2. Start MN2.
    1. After powering on MN2, start the server manually or through IPMI.
    2. Wait for MN2 to start and successfully boot the operating system.
    3. On MN2, run the zsha2 start-node command to start services related to zsha2.
    4. On MN2, run the zsha2 status command to check whether the zsha2 service is running properly.
    5. 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:
  1. On each MN, run the zsha2 stop-node command to stop the zsha2 service.
  2. Shut down each MN.
  3. Maintain each MN after shutdown.
  4. After powering on each MN, start the server manually or through IPMI.
  5. Wait for each MN to start and successfully boot the operating system.
  6. On each MN, run the zsha2 start-node command to start the zsha2 service.
  7. On each MN, run the zsha2 status command to check whether the zsha2 service is running properly.
  8. 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:
  1. On the failed MN, run the zsha2 stop-node command to stop the zsha2 service.
  2. 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.
  3. If you need to install a new node, follow these steps:
    1. Provision a backup server to make the hardware specifications more similar to those of the failed node.
    2. 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.
    3. Install an HA suite for the new node. For more information, see Installation and Deployment.
    4. On the new node, run the zsha2 status command to check whether the zsha2 service is running properly.
    5. 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:
  1. 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.
  2. If you need to install two new nodes, follow these steps:
    1. Provision two backup servers to make the hardware specifications more similar to those of the failed nodes.
    2. 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.
    3. 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:
      [root@localhost ~]# zstack-ctl restore_mysql -f /var/lib/zstack/mysql-backup/xxx.gz --mysql-root-password MYSQL_PASSWORD
      • 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.
    4. On this node, run the install_ha command to reinstall an HA suite. For more information, see Use the Command Line.
    5. On the new node, run the zsha2 status command to check whether the zsha2 service is running properly.
    6. 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 multi-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 multi-MN HA scenario, you can recover a database by following these steps:
  1. 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:
    [root@localhost ~]# zstack-ctl restore_mysql -f /var/lib/zstack/mysql-backup/xxx.gz --mysql-root-password MYSQL_PASSWORD
    • 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.
  2. 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.

Introduction

zsha2, designed by ZStack Cloud for multi-MN HA scenarios, is a command that helps you quickly complete various operations in these scenarios.

-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.
./zsha2 install-ha -slave "root:password@192.168.196.125"
-vip Specifies the VIP for Keepalived communication. ./zsha2 install-ha -vip 192.168.199.151
-myip Optional. Specifies the local IP address. ./zsha2 install-ha -myip 192.168.195.200
-db-root-pw The database root password of the active and standby MNs. Make sure that these two MNs share the same database root password. ./zsha2 install-ha -db-root-pw zstack.mysql.password
-time-server Specifies a time synchronization server for unified time synchronization.
Note: You can specify multiple time servers at a time.
  • ./zsha2 install-ha -time-server 192.168.196.125
  • ./zsha2 install-ha -time-server 192.168.196.125,192.168.196.126
-cidr 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.

Usage

[root@localhost ~]# zsha2 stop-node
stopping zstack-ha service ...
stopping zstack management node ...
stopping keepalived ...

start-node

Description

Starts a MN and its zsha2 service in a dual-MN HA scenario.

Usage

[root@localhost ~]# zsha2 start-node
starting keepalived ...
starting zstack-ha service ...
starting zstack management node ...

upgrade-mn

Description

Upgrades only MNs in a dual-MN HA scenario.

Usage

Parameter Description Example
-force Optional. Force upgrades MNs. zsha2 upgrade-mn -force ZStack-Cloud-installer-4.8.38.bin
-peerpass Optional. Enters the SSH login password of the peer MN. zsha2 upgrade-mn -peerpass password ZStack-Cloud-installer-4.8.38.bin
-yes Optional. Indicates that all settings are allowed. zsha2 upgrade-mn -yes
If you upgrade the MN from the bin package, follow these steps:
  1. Import the new version of ZStack Cloud custom ISO to each MN and run the following command on each MN to upgrade the local repo to the latest version:
    [root@localhost ~]# bash zstack-upgrade -r ZStack-Cloud-installer-4.8.38.bin
  2. Run the following command on either MN. Then, both MNs will be upgraded.
    [root@localhost ~]# zsha2 upgrade-mn -peerpass password ZStack-Cloud-installer-4.8.38.bin
If you choose to upgrade the MN from ISO, follow this step:
  1. Run the following command on either MN. Then, both MNs will be upgraded.
    [root@localhost ~]# zsha2 upgrade-mn -peerpass password ZStack-Cloud-x86_64-DVD-4.8.38-h84r.iso
    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.

Usage

[root@localhost ~]# zsha2 show-config
{
  "nodeip": "192.168.195.200",
  "peerip": "192.168.196.125",
  "dbvip": "192.168.199.151",
  "nic": "br_bond0",
  "gw": "192.168.0.1",
  "dbnetwork": "192.168.0.0/16",
  "repo": "zstack-local",
  "version": 0
}

sample-config

Description

In a dual-MN HA scenario, generates sample configurations to set up an HA environment quickly.

Usage

[root@localhost ~]# zsha2 sample-config
{
  "gateway": "172.20.0.1",
  "virtualIp": "172.20.0.2",
  "myIp": "172.20.0.3",
  "peerIp": "172.20.0.4",
  "peerSshUser": "root",
  "peerSshPass": "somepass",
  "peerSshPort": 22,
  "dbRootPass": "zstack.password",
  "interface": "br_eth0",
  "timeServer": "172.20.0.3"
}

collect-log

Description

Collects logs related to the zsha2 service in a dual-MN HA scenario.

Usage

[root@localhost ~]# zsha2 collect-log
Collecting logs ...
Collected log: zsha2-log-2018-09-17T154358+0800.tgz

# Decompress the log package.
[root@localhost ~]# tar zxvf zsha2-log-2018-09-17T154358+0800.tgz
tmp/zsha2-log588815976/
tmp/zsha2-log588815976/zsha2-status.log
tmp/zsha2-log588815976/zstack-ha.log
tmp/zsha2-log588815976/keepalived.data
tmp/zsha2-log588815976/zs-vip-192.168.199.151.log
tmp/zsha2-log588815976/keepalived_status.log
Dual-MN HA Tutorial | 4.8.38 | ZStack Cloud · ZCF | ZStack Resource Center