vPostgres for vRealize Automation Gotcha

If you’re planning on doing a full distributed installation of vRealize Automation, you’ll likely want to have some protection for the vPostgres database.  Having a single point of failure defeats the purpose of doing a full distributed install.  I’ve been doing a bunch of work on this lately and wanted to warn people of a gotcha if you’re using a load balancer.

Non-Distributed Install

To give us a better understanding, take a look at a pair of vRealize Automation Appliances that aren’t in a high availability solution.  In the picture below, there are two vRealize Automation Appliances and each of them is communicating with their own embedded vPostgres Database.  This is the default configuration when deployed from VMware and works just fine.

Taking a look at the configuration inside the cafe appliance, we can see that the local host address is being used for the database.

High Availability vPostgres

The version of vPostgres that ships with vRealize Automation will allow you to setup a one way replication but does require a manual failover in the event of an outage.  The setup requires you to make several changes to allow vPostgres to listen on additional addresses, adding some replication paramaters etc.  Once the configurations are done the solution would look much like the picture below, with a load balancer in the middle.

One embedded vPostgres database is active, the other is passive and is receiving replication traffic from the primary.  Each of the appliances will then point their database connection to a virtual IP (VIP) on the load balancer and the load balancer will point to the active vPostgres database.

The Gotcha

When you go to the vRealize Automation appliance and change the database to use a network address that is not 127.0.0.1 or the IP Address of the appliance, the vRealize Automation appliance will SHUT DOWN THE DATABASE.

Before the database is changed to use the load balancer, we can see the vpostgres service is running on the appliance.

We then make the change on the appliances to use the VIP.  When you click save, you’ll see that the database configuration change happened, but the connection status shows an error.

Another check on the service and we notice that the vPostgres database is not longer running.

To fix this, start the service.

Afterwards you’ll see that the connection is working.  Be aware though, that anytime these appliances reboot, the service may need to be manually started as noted in the KB Article from VMware.