Bug 1322068 - [RFE] Native Highly Available (HA) VMDB Deployment
Summary: [RFE] Native Highly Available (HA) VMDB Deployment
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.7.0
Assignee: Nick Carboni
QA Contact: Alex Newman
Whiteboard: database
Depends On:
TreeView+ depends on / blocked
Reported: 2016-03-29 17:43 UTC by Dustin Scott
Modified: 2020-02-14 17:43 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2017-01-04 12:54:33 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2605621 0 None None None 2016-09-07 04:11:10 UTC
Red Hat Product Errata RHBA-2017:0012 0 normal SHIPPED_LIVE CFME 5.7.0 bug fixes and enhancement update 2017-01-04 17:50:36 UTC

Description Dustin Scott 2016-03-29 17:43:25 UTC
-What is the nature and description of the request?
Ability to natively deploy an HA VMDB for CloudForms without having to configure a complicated reference architecture.
-Why does the customer need this? (List the business requirements here)
Eliminate the single point of failure with only one VMDB in a single region to meet uptime requirements.
-How would the customer like to achieve this? (List the functional requirements here)
Possibly via HA PostgreSQL cluster with the ability to deploy the cluster either via the appliance_console or the UI.
-For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Test operability of HA cluster to see if meets customer needs.  Ensure that cluster can be deployed in automated fashion.  Ensure cluster failover happens properly when one VMDB fails.
-Is there already an existing RFE upstream or in Red Hat Bugzilla?
I have not found one.
-Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
Before the customer goes into production.  This is tentatively scheduled for now depending on the success of the current implementation in development.
-Is the sales team involved in this request and do they have any additional input?
Yes, sales in involved.  Input pending depending on future meeting.
-List any affected packages or components.

Comment 2 Nick Carboni 2016-07-14 20:38:44 UTC
Work on this is being tracked via the Pivotal Tracker Epic here https://www.pivotaltracker.com/epic/show/2561569

Comment 3 Nick Carboni 2016-08-31 14:26:52 UTC
The pivotal epic is now completed and native HA is now available to be configured using the upstream appliances.

To do this we have one important requirement:

The PostgreSQL database servers must be running on our shipped virtual appliances. This is because we make use of some very particular packages and services for use during failover. This may pose a problem for customers using "external" PostgreSQL servers. We will look into documenting how to set up the packages required for running this HA implementation in the future.

For now, the steps to set up the newly implemented HA architecture are as follows (for a two database cluster):

1. Deploy an appliance to serve as the primary database server (DB1).
  - Configure this appliance as a *database-only* appliance
  - When prompted "Do you also want to use this server as an application server?" in the console, answer no.
2. Deploy an appliance to serve as an evm server appliance
  - Configure this appliance to point to the database appliance configured in step 1 (DB1)
3. On DB1, configure the database for replication using the appliance_console
  - Select "Configure Database Replication"
  - Select "Configure Server as Primary"
  - Follow the prompts
  - Note: The IP address entered here must be the address which will be used to contact the primary server by all the *standby* servers and all the *application* servers
4. Deploy standby database server appliance (DB2)
  - Select "Configure Database Replication"
  - Select "Configure Server as Standby"
  - Follow the prompts
  - Note: The IP address entered for the Standby server must be the address which will be used to contact the current standby server by all the *other standby* servers and all the *application* servers
  - This initialization may take some time
5. On all application servers (not database servers) start the failover monitor service
  - In the appliance_console select "Configure Application Database Failover Monitor" -> "Start Database Failover Monitor"

Now the database servers will execute automatic failover upon failure of the primary server and the application servers will detect the new primary server upon failover.

Comment 8 errata-xmlrpc 2017-01-04 12:54:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.