Bug 2125114

Summary: Regional DR requirements
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Naoya Hashimoto <nhashimo>
Component: documentationAssignee: Olive Lakra <olakra>
Status: CLOSED CURRENTRELEASE QA Contact: Neha Berry <nberry>
Severity: unspecified Docs Contact:
Priority: low    
Version: 4.11CC: aclewett, asriram, kramdoss, ocs-bugs, odf-bz-bot, olakra, srangana
Target Milestone: ---Flags: olakra: needinfo? (aclewett)
Target Release: ODF 4.11.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-03-09 12:47:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Naoya Hashimoto 2022-09-08 03:43:38 UTC
Describe the issue: In the regional DR scenario, it's presumably common to use the same URL to host the application so that clients should always access the same URL even if one of the clusters is down, but it doesn't seem there is any statement related to this. It's implicit whether ACM automatically routes the traffic between the clusters or users have to deal with it using GTM or GSLB.

Describe the task you were trying to accomplish:
Let's say I have two managed clusters at each site and want to route the traffic to `myapp.example.com`, and the hostname in the route objects are stored like my-app.apps.cluster1.example.com and my-app.apps.cluster2.example.com as follows in each cluster. Who should deal with the DNS failover to route the traffic from the preferred cluster to the failover cluster? I'm confused when I read the section first since it wasn't clear if it's assumed to set up the DNS failover configuration or if ACM handles it somehow.
----
Client
| myapp.example.com
Route 53 
| my-app.apps.cluster1.example.com (preferred cluster)
| my-app.apps.cluster2.example.com (failover cluster)
----

It may be explicit that ACM fails over only application resources or objects i.e. Pod, PVC, etc from the preferred cluster to the failover cluster as the documentation says application failover but not cluster failover or just failover at https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.11/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#application-failover-between-managed-clusters_rdr.

Suggestions for improvement:
Some use cases or scenarios such as mentioned above may be needed so that it'd be clearer for users what they have to be prepared.

Document URL: https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.11/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#requirements-for-enabling-regional-disaster-recovery_rdr

Chapter/Section Number and Title: 3.3. Requirements for enabling Regional-DR

Product Version: 4.11

Environment Details:

Any other versions of this document that also needs this update:

Additional information:

Comment 4 Annette Clewett 2022-09-29 15:19:12 UTC
@srangana I think the areas and text you added are good. Need to define acronym GTM and GSLB - Global Traffic Manager and Global Server Load Balancing. Also, GLB is used, Global Load Balancer. This blog from last year does a good job of explaining the different methods, requirements - https://cloud.redhat.com/blog/global-load-balancer-approaches.

Comment 5 Shyamsundar 2022-09-29 15:32:10 UTC
(In reply to Annette Clewett from comment #4)
> @srangana I think the areas and text you added are good. Need to
> define acronym GTM and GSLB - Global Traffic Manager and Global Server Load
> Balancing. Also, GLB is used, Global Load Balancer. This blog from last year
> does a good job of explaining the different methods, requirements -
> https://cloud.redhat.com/blog/global-load-balancer-approaches.

Ack! @olakra I assume required information is available to add this to the documentation, let us know otherwise.