How to check Centralized Administration in a multi-regional architecture


#1

Hi Team,

Recently I’m setting up a multi-regional architecture of CF 4.5 (EVM 5.8.0.17), with several appliances in Remote regions (1…4) and a Master Region (99).
In all Remote regions there are Cluster of Local VMDB in dedicated appliance, the same case that Master region (VMDB in cluster + 2 UI dedicated appliance + DNS RR). This setup was created to provide HA in all regions, plus replication, to enable Centralized Administration. So, the issue is here, I know that there is no button to ‘Enable Centralized Administration’ anymore, and this feature is enable when I suscribe all Remote databases (VMDB Cluster Active node) to the Master (active node too), but, after more than 48 hours of sync, I can’t see remote objects, so this make me doubt about my config.

Please, help… How can I check if the Centralized Administration was succesfully enabled? :slight_smile:


#2

Hi @carbonin, do you know something that can help me checking the feature? Recently I’ve attached a Satellite 6.2 in a Remote region expecting that objects where synced and showed in the centralized UI but it’s not happening too.

Thanks a lot! :v:
Regards.


#3

So for Centeralized Administration to work, all you need is a working replication configuration and to use the same encryption key (v2_key) on all of the appliances in all the regions.

It sounds like your issue is with a working replication configuration, not necessarily with central admin.

Can you attach a screenshot of the Configuration -> Region -> Replication page (one for each region)? Feel free to obfuscate any IP addresses or user names.

As far as more in-depth debugging, you can check that replication is enabled on all the remote region databases by ensuring that the following command returns “true” from bin/rails console

irb(main):001:0> MiqPglogical.new.provider?
=> true

You can do a similar check on a global region appliance:

irb(main):002:0> MiqPglogical.new.subscriber?
=> true

If those both return true, you can take a look at the postgresql logs on the global region database server. pglogical (the application we use to do replication on the back-end) is usually pretty good about printing status there.

If all else fails you can look at the result of the following query in the global database to determine the sync status of particular subscriptions:

SELECT
  sub.sub_name,
  sync_kind,
  sync_relname,
  sync_status
FROM
  pglogical.local_sync_status stat JOIN pglogical.subscription sub ON
    sub.sub_id = stat.sync_subid;

That should return the status of every table in every remote region. It will be a lot of output. If the status is anything other than ‘r’ you probably have an issue.

Hope this helps.


#4

Hi @carbonin,

Thank you for your response. I’ve checked the feature in all regions and I’ve upload some images to show that the configs were OK. Thank you for that.

!
!

I’m thinking that this issue is related to this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1391095 because I have the master database (high level vmdb) on a cluster (w/ out-of-the-box solution: repmgr) and in the bugzilla assumes that “[RFE] Replication does not support HA”. So, a few direct questions:

  • The Master VMDB (region 99) can’t be setting up in a cluster if we want enable this database like a high-level one?

  • On the remote regions, the other way around, if we need provide HA to our remote regions, we will can’t setup the replication towards high-level database? (doesn’t matter if the master vmdb are in cluster or not)

I’ve attached a diagram of the solution (I made this fast just to clarify the architecture). Please help me checking if that setup is correct or if we need delete some components.

Thanks a lot!
Regards.


#5

No, neither of those accurately describe the issue.

If you want to set up the global region in a HA configuration, that will not cause a problem with replication from remote regions.

If you want to set up a remote region in a HA configuration, replication will fail after a failover event has occurred.
This is because replication is a subscription model. The global region “pulls” changes from the remote region. When a failover occurs, the IP address of the primary database in the remote region changes so replication no longer knows where to pull the changes from.

The work around for that issue is to remove and re-add a region’s subscription after a failover occurs in that region. This will prompt a new data sync which should put things back to a working state.


#6

Hello all,

I’m having a similar problem but my configuration failed on the first test:

As far as more in-depth debugging, you can check that replication is enabled on all the remote region databases by ensuring that the following command returns “true” from bin/rails console

irb(main):001:0> MiqPglogical.new.provider?
=> true
You can do a similar check on a global region appliance:

irb(main):002:0> MiqPglogical.new.subscriber?
=> false

How can I correct this issue?

Best regards
PM


#7

So I tried to redo the global region deployment, added zone 2 and zone 0 (sub-region) to the new global region 99 and got this message from the UI. Can you please give me a litlle help resolving this issue? :slight_smile:

Thank you!