Merge pull request #55852 from lahinson/hcp-dr-diagram-osdocs-4998

[OSDOCS-4998]: adding diagrams to hypershift DR doc

Author: mburke5678

backup_and_restore/control_plane_backup_and_restore/disaster_recovery/dr-hosted-cluster-within-aws-region.adoc

@@ -104,17 +104,25 @@ EXTERNAL_DNS_DOMAIN="hc.jpdv.aws.kerbeross.com"
 
 The backup and restore process works as follows:
 
-. On management cluster 1, which you can think of as the source management cluster, the control plane and workers interact by using the ExternalDNS API.
+. On management cluster 1, which you can think of as the source management cluster, the control plane and workers interact by using the external DNS API. The external DNS API is accessible, and a load balancer sits between the management clusters.
++
+image::298_OpenShift_Backup_Restore_0123_00.png[Diagram that shows the workers accessing the external DNS API and the external DNS API pointing to the control plane through a load balancer]
 
-. You take a snapshot of the hosted cluster, which includes etcd, the control plane, and the worker nodes. The worker nodes are moved to the external DNS, the control plane is saved in a local manifest file, and etcd is backed up to an S3 bucket.
+. You take a snapshot of the hosted cluster, which includes etcd, the control plane, and the worker nodes. During this process, the worker nodes continue to try to access the external DNS API even if it is not accessible, the workloads are running, the control plane is saved in a local manifest file, and etcd is backed up to an S3 bucket. The data plane is active and the control plane is paused.
++
+image::298_OpenShift_Backup_Restore_0123_01.png[]
 
-. On management cluster 2, which you can think of as the destination management cluster, you restore etcd from the S3 bucket and restore the control plane from the local manifest file.
+. On management cluster 2, which you can think of as the destination management cluster, you restore etcd from the S3 bucket and restore the control plane from the local manifest file. During this process, the external DNS API is stopped, the hosted cluster API becomes inaccessible, and any workers that use the API are unable to update their manifest files, but the workloads are still running.
++
+image::298_OpenShift_Backup_Restore_0123_02.png[]
 
-. By using the External DNS API, the worker nodes are restored to management cluster 2.
+. The external DNS API is accessible again, and the worker nodes use it to move to management cluster 2. The external DNS API can access the load balancer that points to the control plane.
++
+image::298_OpenShift_Backup_Restore_0123_03.png[]
 
-. On management cluster 2, the control plane and worker nodes interact by using the ExternalDNS API.
-
-// When the updated diagram is available, I will add it here and update the first sentence in this section to read, "As shown in the following diagram, the backup and restore process works as follows:"
+. On management cluster 2, the control plane and worker nodes interact by using the external DNS API. The resources are deleted from management cluster 1, except for the S3 backup of etcd. If you try to set up the hosted cluster again on mangagement cluster 1, it will not work.
++
+image::298_OpenShift_Backup_Restore_0123_04.png[]
 
 You can manually back up and restore your hosted cluster, or you can run a script to complete the process. For more information about the script, see "Running a script to back up and restore a hosted cluster".