Integration

 View Only

LinkedIn Share on LinkedIn

NativeHA Cross-Region Replication: MQ on Kubernetes more reliable than ever.

By Jean de Garrigues posted 26 days ago

  

Learn about NativeHA first: https://community.ibm.com/community/user/integration/blogs/david-ware1/2021/03/23/native-ha-cloud-native-high-availability

NativeHA Cross-Region Replication builds on NativeHA with the addition of another queue manager group hosted at a different location. Using this configuration, your original NativeHA queue manager is referred to as the Live group, and the new one is referred to as the Recovery group. The recovery group receives all replicated data from the live via an asynchronous connection. Therefore, in the event of an outage of the live group’s cluster, the recovery group can pick up the work with minimal downtime and data loss.

Depending on your scenario, there are two ways to switch to your recovery group:

Planned Switchover

Suppose that the datacentre hosting your live group is scheduled to undergo maintenance, or you need to carry out a migration. Simply switch the roles of your groups and, once all the live group’s log data has been replicated to the recovery group, it will take over as live and queue manager operations will resume there. Through this process, the queue manager downtime is minimal, and no transactions are lost.

Unplanned Failover

Sometimes, things don’t go to plan, and your live group may go down due to external factors. Should this happen, simply alter your recovery group role to live and inform it that the previously live group is down; any new work will be picked up by the newly live group. Naturally, an unexpected outage will incur data loss as whatever was not replicated to the recovery group via the asynchronous link will be lost, but it sure beats losing everything.

Want to know more? Check out this short video which explains NativeHA CRR and demonstrates all the above on OpenShift:

2 comments
38 views

Permalink

Comments

Jean de Garrigues
7 days ago

Hi Andres, thank you for your comment! Regarding certificates, if the certificates used by each group are signed by the same CA, that works, but if you wish to have different certificates for TLS between the groups, you must ensure that you are adding each group's certificate to the other's trust store. For example, take the .crt portion of the live group's OpenShift secret you want to use for tls and add it as a new secret in the recovery group's cluster. Then in the recovery group's YAML, under the trust section, add a reference to the live group's certificate in your new secret.

Andres Colodrero
23 days ago

Thans for your video!

I just tested on my own environment and i can finally connect two queue managers in 2 separated ocp clusters.

IN my case only works if i setup the same "internal native ha" certificate and key for both queue managers and then i create a second certificate "external" with the same CA authority.