Updating HCP for cloud scale
The following procedures describe how to update the HCP for cloud scale software.
Updates are managed by the System Management (Admin) application. Instances are shut down, updated, and restarted one at a time automatically, so you can update the HCP for cloud scale software to a newer version without interrupting availability or reingesting data. S3 API methods remain available, so that users can continue to read and write data and create and configure buckets.
During an update, management API methods that don't change the configuration remain available. Tracing and the collection of metrics aren't affected.
You cannot downgrade HCP for cloud scale to a previous version.
You cannot upgrade to v1.3.0 from any previous version.
During an update, you cannot make changes to the configuration. After an update, you might need to reconfigure services.
Items and information you need
To update an HCP for cloud scale system, you need the appropriate update archive file hcpcs-version_number.update
and, for verification purposes, its MD5 checksum file hcpcs-version_number.md5
.
This document shows the path to the HCP for cloud scale folder as install_path. The best folder path is /opt.
Verify and place the update archive
Procedure
Download the update archive and MD5 checksum file and store the files in a folder on the server or virtual machine.
The best practice is to verify the integrity of the update archive:
md5sum -cproduct-version_number.update.md5
If the archive integrity is verified, the command displaysproduct-version_number.update: OK
.In the largest disk partition on the server or virtual machine, create a product update folder:
mkdir update_path/productMove the update archive from the folder where you stored it to the product update folder:
mv product-version_number.update update_path/product/product-version_number.updateNavigate to the update folder:
cd update_path/product
Use the System Management application to update the system
The update process is controlled by the System Management application (the Admin App).
Procedure
From the System Management application, select Configuration.
The Configuration page opens.Click Update.
The Update page opens.Select the Install tab.
The Upload area opens.Click and drag the update file into the Upload area, or click Click to Upload, select the update archive, and click Open.
The update archive is uploaded and verified. These processes will take several minutes. When the archive is verified, the page displays information about the update process. If the update contains a new service, you can optionally configure network, volume, or log file settings.When you're ready to begin, click Apply Update.
The System Management application displays the message Successfully started update package installation and then applies the update to the cluster (each server or virtual machine in the HCP for cloud scale system).
Results
- The Successfully started banner message is removed.
- In the Status tab, the Update Status displays None and the event Update Completed appears.
- The
- The update version appears in the lower right corner of the Login page.
Configure the system for your users
For information about these procedures, see the applicable topic in the help that's available from the HCP for cloud scale application.
The overview of tasks is:
Procedure
Configure the connection to an IdP and create user accounts.
Define storage components.
Configure DNS servers to resolve both the fully qualified domain name for your HCP for cloud scale cluster and the wildcard
*.hcpcs_cluster_name
.Obtain S3 authorization credentials.
Troubleshooting
You might encounter these issues during an update.
Rarely, a system deployment, service management action, or system update fails because a service fails to start. When this happens, the System Management application is inaccessible from the instance where the failure occurred.
The logs in the watchdog-service log folder contain this error:
Error response from daemon: Conflict. The name "service-name" is already in use by container Docker-container-id. You have to remove (or rename) that container to be able to reuse that name.To resolve this issue, restart the Docker service on the instance where the service failed to start. For example, if you are using systemd to run Docker, run:
systemctl restart dockerAfter restarting Docker, try the system deployment, service management action, or system update again.
After you turn on encryption, PUTS and GETS of objects require the key management server (KMS) to be up and unsealed. During an update the KMS can restart multiple times, including when the master nodes and services are upgraded and when the Vault service is updated. When the KMS service restarts, it is sealed, which can interrupt service.
If you are using encryption, monitor the Vault service closely during an update to prevent interruptions. Whenever the service restarts and gets sealed, unseal it.
If you have access to the Aspen administration app, you can monitor the health of the KMS by checking for the alert "Failed to connect to KMS server." When you see this alert, you know that the KMS is either down or sealed.
Another approach is to load the KMS page, which is at port 8200 of the system. The status of the KMS is displayed in the upper right corner. A red dot indicates that it is sealed.