In this post, three aspects of lifecycle management of VMware Data Services Manager are reviewed. An upgrade from DSM v1.3.2 to v1.4 will be used to demonstrate the various aspects of lifecycle management. First, the provider administrator will upgrade the DSM provider. This will be followed by an upgrade of the DSM agents, before finally upgrading the databases. Upgrading from DSM v1.3.2 to v1.4 introduces a new minor version of the supported versions of PostgreSQL and MySQL. If the Allow Minor Version Upgrade option is enabled, then the databases are updated during the next maintenance slot automatically. However, the provider administrator can also upgrade the databases on-the-fly if necessary, as we shall see shortly.
If a customer has connected their DSM deployment to the Tanzu Network, then once a new release or update becomes available from VMware, a notification is automatically displayed in the DSM UI. As the provider administrator, select the Update Manager view. If there is an update available, it will be listed under Available Updates. Below, we can see that there is an update to v1.4 available.
At this point, the Stage option can be selected to download the appropriate updates. Once the update has been staged, the status is set to Ready For Install and an Install operation can be initiated.
If the Provider is not configured in a highly available configuration, then it will be unavailable for the duration of a reboot operation. Once the reboot completes and all of the services are back online, the History view should show details of the Stage and Install operations.
The Provider has been successfully upgraded. It is now time to turn our attention to the Agents.
To check to see if there is an Agent update available, the provider administrator navigates to the Environments view. This will show any available updates. To initiate an Agent update, simply click on the “Initiate Next Update” option in the top-right of the UI.
If the Agent has not yet detected that there is an update available, it may fail with “Feature is not available at agent”. To remedy this situation, simply login to the Agent VM and restart the update service using the command:
# systemctl restart update-manager.service
After a few moments, the agent status should enter “Maintenance Mode”, indicative of the fact that the upgrade is underway. The Agent will not be online during this process. The Agent should reboot and once the update is complete, should return to an Online state. Repeat this process for all agents.
The agent is now upgraded. We can next turn our attention to the databases.
As mentioned in the introduction, upgrading from DSM v1.3.2 to v1.4 introduces a new minor version of the supported versions of PostgreSQL and MySQL. If the Allow Minor Version Upgrade option is enabled, then the databases are updated during the next maintenance slot automatically. However, the provider administrator can also upgrade the databases on-the-fly. Let’s see how to do this.
To initiate an immediate database upgrade, simply navigate to the database in the DSM UI. Select the Maintenance & Updates view as shown below. Note that the OS version and the Engine version both have updates available. The OS version reflects the fact that it is behind the Provider and Agent, whilst the Engine version is a reference to the fact that there is now a newer version of PostgreSQL available (184.108.40.206). To trigger an immediate update, simply click on the Update Now link. Note that this also reboots the virtual machine on which the database is installed, so the database will be unavailable which this activity takes place.
The alternate is to enable the Maintenance Policy for the database so that the database is automatically updated out of normal working hours. This can be done by clicking on the Edit button associated with the Maintenance Policy shown above, and enabling the Allow Minor Version Upgrade option.
That concludes this overview of lifecycle management in VMware Data Services Manager. Feel free to reach out with any questions. Thank you for reading.