Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The following sections explain the Disaster Recovery model in detail.

Table of Contents
maxLevel3

Overview

Having a robust Disaster Recovery (DR) plan in place helps you recover from a failure of the production environment and continue using the application. Adeptia recommends you that you have the DR environment ready as a failover if anything unpredictable happens to your application, storage, or the database.

...

  • Region 1 and Region 2 are the physical locations of the Kubernetes Cluster where the production and DR environment are set up respectively.

  • Production environment governs the Adeptia Connect application that is in action and executes all the requests. It also has a storage and two databases (Primary Database and Sync Database).

  • DR environment has another copy of the Adeptia Connect application and a storage. The application in the DR environment remains inactive until the application in the production environment goes down and there is a need to switch to the DR environment. This environment is connected to the same database being used in the production environment. However, the application deployed here neither interacts nor stores any data in the database until it gets active and starts processing the requests in the face of a disaster. 

  • Database is shared by both the environments. This model has a Primary Database synced to a Sync Database. When the Primary Database fails, the Sync Database takes over.

  • Storage in production environment is synced to the storage in the DR environment that comes into picture when the application in the DR environment is in use.

Deploying the application in production and DR environments

The DR model encapsulates the environments – Production and DR – to be set up in Kubernetes Clusters located in two different zones in the cloud.

...

Tip
titleUpgrading the environments

The prerequisites for upgrading the production and DR environments remain the same as that for the deployment of the application discussed in this section.

Anchor
prodToDev
prodToDev
Switching from PROD to DR Environment

You may want to switch from production to DR environment based on your business requirement. To achieve this, follow the steps given below.

...

  1. Scale down the Runtime and Listener deployments in the PROD environment.
    To scale down the Runtime deployments, use the following format:

    Code Block
    languagecss
    themeMidnight
    kubectl scale --replicas=0 deployment <Release Name>-ac-runtime -n <namespace>

    To scale down the Listener deployments, use the following format:

    Code Block
    languagecss
    themeMidnight
    kubectl scale --replicas=0 deployment <Release Name>-ac-listener -n <namespace>


  2. Pause Scheduler in the PROD environment.

    Code Block
    languagecss
    themeMidnight
    https://<webapp_Gateway_URL>/event/schedulerservice?_dc=1670999141899&query=Pause&page=1&start=0&limit=25


  3. Scale down Rabbit MQ statefulset in the PROD environment.

    Code Block
    languagecss
    themeMidnight
    kubectl scale --replicas=0 statefulset <Release Name>-ac-rabbitmq -n <namespace>


  4. Scale down Rabbit MQ statefulset in the DR environment.

    Code Block
    languagecss
    themeMidnight
    kubectl scale --replicas=0 statefulset <Release Name>-ac-rabbitmq -n <namespace>


  5. Initiate failover for the storage account using the following steps:

    Info

    >> Initiating failover is required only when the Azure File Share is not accessible due to any failure.

    >> As per Microsoft documentation, the time it takes to failover after initiation can vary though typically less than one hour.

    1. Login into your Azure Portal.

    2. Go to the Storage Account being used in the PVC of Prod environment.

    3. Within that storage account go to Data Management > Redundancy section.

    4. Click Prepare for failover and follow the instruction given on the screen. The failover process starts.

    5. Once the Account Failover process completes the data from secondary region will be accessible from the existing endpoint of the storage account.

  6. Copy the web/repository folder from PROD to DR environment.

    Code Block
    languagecss
    themeMidnight
    ./azcopy sync "https://[account].file.core.windows.net/[PVC]/web/repository/?[SAS]" "https://[account].file.core.windows.net/[PVC]/web/repository/?[SAS]" --recursive=true

    For example:
    ./azcopy sync "https://fxxxxxxxxxxxxxxxxxxxxx1b6a.file.core.windows.net/pvc-e38eca50-xxxx-xxxx-xxxx-828efd6d49df/web/repository/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:18:24Z&st=2023-03-05T17:18:24Z&spr=https,http&sig=VxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxaXBmSAKm4%3D" "https://fxxxxxxxxxxxxxxxxxxx3aeb.file.core.windows.net/pvc-1a6f1c1b-xxxx-xxxx-xxxx-44ff485d707f/web/repository/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:25:19Z&st=2023-03-05T17:25:19Z&spr=https,http&sig=vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGazWA%3D" --recursive=true

  7. Copy the recovery folder from PROD to DR environment.

    Code Block
    languagecss
    themeMidnight
    ./azcopy sync "https://[account].file.core.windows.net/[PVC]/recovery/?[SAS]" "https://[account].file.core.windows.net/[PVC]/recovery/?[SAS]" --recursive=true

    For example:
    ./azcopy sync "https://fxxxxxxxxxxxxxxxxxxxxx1b6a.file.core.windows.net/pvc-e38eca50-xxxx-xxxx-xxxx-828efd6d49df/recovery/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:18:24Z&st=2023-03-05T17:18:24Z&spr=https,http&sig=VxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxaXBmSAKm4%3D" "https://fxxxxxxxxxxxxxxxxxxx3aeb.file.core.windows.net/pvc-1a6f1c1b-xxxx-xxxx-xxxx-44ff485d707f/recovery/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:25:19Z&st=2023-03-05T17:25:19Z&spr=https,http&sig=vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGazWA%3D" --recursive=true

  8. Copy the reprocessing folder from PROD to DR environment.

    Code Block
    languagecss
    themeMidnight
    ./azcopy sync "https://[account].file.core.windows.net/[PVC]/reprocessing/?[SAS]" "https://[account].file.core.windows.net/[PVC]/reprocessing/?[SAS]" --recursive=true

    For Exampleexample:
    ./azcopy sync "https://fxxxxxxxxxxxxxxxxxxxxx1b6a.file.core.windows.net/pvc-e38eca50-xxxx-xxxx-xxxx-828efd6d49df/web/reprocessing/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:18:24Z&st=2023-03-05T17:18:24Z&spr=https,http&sig=VxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxaXBmSAKm4%3D" "https://fxxxxxxxxxxxxxxxxxxx3aeb.file.core.windows.net/pvc-1a6f1c1b-xxxx-xxxx-xxxx-44ff485d707f/reprocessing/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:25:19Z&st=2023-03-05T17:25:19Z&spr=https,http&sig=vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGazWA%3D" --recursive=true

  9. Copy the Rabbitmq PVC content from PROD to DR environment.

    Code Block
    languagecss
    themeMidnight
    ./azcopy sync "https://[account].file.core.windows.net/[PVC]/?[SAS]" "https://[account].file.core.windows.net/[PVC]/?[SAS]" --recursive=true --mirror-mode=true

    For Exampleexample:
    ./azcopy sync "https://fxxxxxxxxxxxxxxxxxxxxx1b6a.file.core.windows.net/pvc-ef345e9d-xxxx-xxxx-xxxx-54e38de9cbd1/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:18:24Z&st=2023-03-05T17:18:24Z&spr=https,http&sig=VxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxaXBmSAKm4%3D" "https://fxxxxxxxxxxxxxxxxxxx3aeb.file.core.windows.net/pvc-4a47fa22-xxxx-xxxx-xxxx-f6538dfff1a7/?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-03-06T01:25:19Z&st=2023-03-05T17:25:19Z&spr=https,http&sig=vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGazWA%3D" --recursive=true --mirror-mode=true

  10. Scale up RabbitMQ statefulset in the DR environment.

    Code Block
    languagecss
    themeMidnight
    kubectl scale --replicas=1 statefulset <Release Name>-ac-rabbitmq -n <namespace>


  11. Scale up Listener in the DR environment.

    Code Block
    languagecss
    themeMidnight
    kubectl scale --replicas=1 deployment <Release Name>-ac-runtime -n <namespace>


  12. Resume Scheduler in the DR environment.
    https://<webapp_Gateway_URL>/event/schedulerservice?_dc=1670999141899&query=Resume&page=1&start=0&limit=25
  13. Update DNS record to route all request the requests to the DR environment.

Switching back from DR to PROD Environment

  1. Scale down Runtime and Listener deployments in the DR environment.

  2. Pause Scheduler in the DR environment.

  3. Scale down Rabbit MQ statefulset in the DR environment.

  4. Scale down Rabbit MQ statefulset in the PROD environment.

  5. Copy web/repository folder from DR to PROD environment.

  6. Copy recovery folder from DR to PROD environment.

  7. Copy reprocessing folder from DR to PROD environment.

  8. Copy Rabbitmq PVC content from DR to PROD environment.

  9. Scale up RabbitMQ statefulset in the PROD environment.

  10. Scale up Listener in the PROD environment.

  11. Resume Scheduler in the PROD environment.

  12. Update DNS record to route all request the requests to the PROD environment.

Using DR to recover from a failure

Adeptia's DR model covers the following three scenarios and the action steps you need to perform to address the failure and recover the infrastructure, application, and the data with a quick turnaround time.

When the production application goes down

Follow the steps given in the Switching from PROD to DR environment section.

When the Primary Database fails

Perform the following step to switch to the Sync Database:

...

Tip
titleSwitching back to the Primary Database

Once the Primary Database is restored, you need to do the followings to switch back to it from the Sync Database:

  1. Ensure that the Primary Database is connected and performing Read/Write operations.
  2. Replicate the data from the Sync Database to the Primary Database.
  3. Update the DNS records to point to the Primary Database.

When the Storage is not accessible

Follow the steps below to point to secondary storage location:

  1. Log in to your Azure Portal.

  2. Go to the Storage Account being used.

  3. Initiate “Account Failover”. The failover process starts.

  4. Once the Account Failover process completes the data from secondary region will be accessible from the existing endpoint of the storage account.

Appendix

...

: Getting the Shared Access Signature (SAS) of your Azure Storage Account

  1. Login into Log in to your Azure Portalportal.

  2. Go to the Storage Account.

  3. Within In the Storage account Account, go to Security + Networking > Shared Access Signature.

  4. Enable Grant the required permission permissions as show below:

  5. Update the expiry date/time as per your need.

  6. In the Allowed Protocol enable HTTP and HTTPS bothprotocols field, select HTTPS and HTTP.

  7. Click Generate SAS and Connection String as shown belowconnection string:

  8. Use the File Service service SAS URL.