Site icon CormacHogan.com

VMware Data Services Manager 2.2.1 and Aria Automation Enhancements

VMware Data Services Manager (DSM) 2.2.1 is now available with General Availability (GA) status and can be accessed directly from the Broadcom Product download Portal. One major new feature is the ability to now do Subnet Customisation during product installation, something many customers have been requesting. We have also included a number of security fixes, predominantly to address the critical security vulnerability CVE-2025-1094 to improve platform security. However, the purpose of this post is too look at another features which became available at the same time as DSM v2.2.1. This is the plugin for Aria Automation which allows the Service Broker to deploy databases through DSM. A lot has changed since the last time I wrote about the Aria Automation integration with DSM v2.0.x here. So I thought that it was high time I revisited it, and highlighted the new support for database replication in the latest release.

Recent Changes

One big change since I last wrote about this integration is the fact that the configuration file which holds the DSM and Aria Automation information has changed from JSON format to YAML format. This makes it so much easier to include certificate authority information if you wish to have a secure connection between DSM and Aria Automation. Now you can simply paste the CA into the config.yaml without trying to do conversions, etc. This is very welcome, and I know some customers who found this quite painful in the past.

A second big change since I last wrote about the integration is that we now support both External and Embedded Orchestrators. While we do not see many External Orchestrators these days, there are still many of you who use them. Thus, after receiving a customer request to have the installer handle deployments with External Orchestrators, we modified the installer to handle this as well.

Otherwise, the installation is exactly as before. Simply download the zip bundle from the support portal, extract it, modify the config.yaml and the run the “python3 aria.py” command. This will then setup all of the object necessary in Aria Automation (Orchestrator, Assembler, Service Broker) to allow you to provide DBaaS to your own customers. Let’s see how we can now deploy a primary and secondary database, and have them replicate.

Deploying Primary Database for Replication

Deploying a primary database for replication is much the same as before, except that there are now some additional fields to consider. From the Service Broker, request a new database.

You deploy the primary in the same way as before, following the same guidelines you would use to populate the database request from the DSM UI. The only additional field that should be selected to set this database up as a primary for replication is the field “Enable Replication Slot1“, as shown below.

Allow the database to deploy. Then we can turn our attention to deploying the secondary database.

Deploying Secondary Database for Replication

There is a piece of information which must be retrieved from the primary database before proceeding with the deployment of the secondary database. This is the Replication Slot Connection String. This can be found by navigating to the Service Broker, selecting Consume > Deployments and clicking on the primary database. Then from the Actions drop-down shown below, select “Get ReplSlot1 Connection String“:

Here is an example of what the Replication Slot1 Connection String looks like.

 

With this piece of information safely stored away, you can now proceed with the deployment of the secondary database. Once again, click on Request to deploy a new database from the Service Broker Catalog DBaaS, just like we did for the primary. Now when the wizard appears with the database details, ensure that the field “Is a secondary” is selected.

Two additional pieces of information now need to be populated on the secondary. The first is the Replication Slot1 Connection String captured in the previous step, and the second is the Replication Slot Name. If the Primary Database was provisioned using the Aria Automation plugin as shown here, the Replication Slot Name is always called “slot1“. If the DSM UI was used to create the Primary, and now you wish to replicate using Aria Automation, you need to retrieve the correct slot name from DSM. With that information, we can now proceed with the deployment.

After a few minutes, the secondary should complete its deployment. It will now be possible to review the state of the secondary database from the DSM UI, and check its remote replication details.

Promoting Secondary to Primary

The Aria Automation plugin for DSM has a new day 2 action which allows you to promote the secondary database to a primary in the event of a maintenance operation or some disaster/recovery (DR) type scenario where the primary database is no longer available or accessible. Follow the detailed instructions in the official DSM documentation on how to do this in a controlled manner, but needless to say that promotion can be achieved via Aria Automation. Go to the database Actions as before in the Service Broker (same place where we retrieved the Replication Slot Connection String) and there you will also see the option to do a Promote.

And that is it. Everything you need to configure Postgres Replication, and promote secondary databases to primary is all included in the latest Aria Automation plugin for DSM, version 2.2.1. Thank you for reading.

Exit mobile version