What Do I Do If the HSS Upgrade Fails?
About the Upgrade
- Servers are displayed on both the old and new console of HSS, regardless of whether their agents have been upgraded. The server statuses are properly displayed on the console that you are using.
- Agent upgrade is free of charge.
- Before the upgrade, ensure the Agent Status is Online.
- The upgrade does not affect the workloads on your cloud servers.
- After the upgrade, the billing stops on the old console and starts on the new console.
- After the upgrade, your servers will be protected by HSS (New).
How the Agent Is Upgraded
After you start agent upgrade on the HSS console, the system automatically uninstalls agent 1.0 and then installs agent 2.0.
- On the old console, agent statuses during the upgrade are as follows:
- Upgraded: The agent has been upgraded. You can go to the HSS (New) console to check the protection status.
- Upgrading: The agent is being upgraded.
- Upgrade failed: The agent failed to be upgraded.
- On the new console, agent statuses during the upgrade are as follows:
- Uninstalled: The target server has not installed an agent on the new console.
- Online: The agent is running properly.
- Offline: The agent communication is abnormal.
Possible Causes
After the automatic upgrade is complete, it takes 5 to 10 minutes for the agent status to be refreshed.
Possible causes for abnormal agent statuses are as follows:
- DNS resolution failure. The agent can be upgraded only through the intranet DNS resolution. Ensure the private DNS server address is correct.
- Access to port 10180 is restricted. The agent upgrade requires accessed to port 10180.
- The available memory of the server is insufficient. The agent upgrade occupies certain memory. If the available memory is less than 300 MB, the upgrade will be affected.
- Failed to obtain the metadata. To upgrade the agent, you need to obtain the ID, name, and region of the server.
Locating and Fixing the Problem
- DNS Resolution Failure
- Troubleshooting Procedure
- Use a remote management tool, such as SecureFX or WinSCP, to log in to the server.
- Run the following command to check the private DNS address of the server:
- Make a note of the DNS address and region of the server and check whether they are correct. For details, see Private DNS Server Address.
- If your region and DNS server address match, the problem was not caused by DNS resolution. In this case, check for other causes.
If your region and DNS server address do not match, the problem was caused by a DNS resolution failure.
- Solution
Check whether your services will be affected if the private DNS server address configured on the server is changed.
- If your services will not be affected by the address change, correct the private DNS server address and retry the upgrade. For details, see Changing the Private DNS Server Address.
- If your services will be affected by the address change, create the mapping between your server name and the current IP address, and retry the upgrade. Perform the following steps:
- Log in to your cloud server.
- Run the following command to switch to user root:
sudo su -
- Run the following command to edit the hosts configuration file:
vi /etc/hosts
- Press i to enter the editing mode.
- Add statements in the following format:
[Example]
192.168.0.1 hostname01
192.168.0.2 hostname02
- Press Esc to exit the editing mode.
- Run the following command to save the configuration and exit:
- Troubleshooting Procedure
- Restricted Access to Port 10180
Ensure the server where the agent is to be installed or upgraded can communicate with the network segment. The security group of your server must allow outbound access to port 10180 on the 100.125.X.X/16 network segment.
- Troubleshooting Procedure
- In the upper left corner of the page, select a region, click , and choose Compute > Elastic Cloud Server.
- Click the name of the server. On the server details page that is displayed, click the Security Groups tab.
- Click the Outbound Rules tab and check whether port 10180 is specified in the deny policy.
- If it is not specified, the problem was not caused by port access restriction.
- If it is specified, the problem was caused by port access restriction.
- Solution
Allow access to the port. For details, see step 8 in Configuring Security Group Rules.
- Troubleshooting Procedure
- The available memory is insufficient.
- Troubleshooting Procedure
- Linux
- Use a remote management tool, such as SecureFX or WinSCP, to log in to the server.
- Run the following command to check the memory usage of the server:
- Check the value of free in the command output, as shown in Figure 1.
- Windows
- Use a remote management tool, such as mstsc and RDP, to log in to the server.
- Open the Task Manager.
- Choose Performance > Memory, and view the available memory on the Memory page.
If the available memory is less than 300 MB, the memory is insufficient.
- Linux
- Solution
- Close the applications with high memory usage.
- Expand the memory and then retry the installation. For details about how to expand the memory capacity, see General Operations for Modifying Specifications.
- Troubleshooting Procedure
- Failure to Obtain Metadata
- Troubleshooting Procedure
For details about how to check whether metadata can be obtained, see Obtaining Metadata.
- Solution
Set the route to 169.254.169.254. For details, see Why Can't My Linux ECS Obtain Metadata?
- Troubleshooting Procedure
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot