Documentation PortalBack to Self Assist PortalBack
Documentation Portal
Contents

Getting Started with CloudOne Disaster Recovery (DR) - V 4.5

This guide aims to provide you with essential information and instructions to set up and configure the DR capabilities using the migration tool. Disaster recovery ensures the availability and continuity of your applications in the event of an unforeseen disaster or disruption.

All Stacks

  • Upgrade Pipelines to v4.5 (Both AppStacks and DB Stacks)
    Before initiating the migration process, ensure that all stacks and applications are upgraded to version 4.5. This upgrade includes the necessary enhancements and bug fixes required for a smooth migration process. For detailed information about the upgrade process, refer to the documentation available at https://selfassist.cloudone.netapp.com/docs/cloudone-pipeline-upgrade?v4.5.
    We have also made the apps backward compactible so that the app teams doesn't have to upgrade their source file to use our latest pipeline.We highly recommend that you review the upgrade documentation relevant to the app stack you are currently working on. By following these guidelines, you can ensure that your application remains compatible with the latest pipeline while benefiting from its advanced features and improvements.
    We reccomend you to make use of our piepeline upgrade tool to upgrade your pipeline to 4.5. Refer the document here, but if you are to manually upgrade the pipeline version to 4.5 do the following steps.

    1. Change the azurepipelines.yml automation reference.
    - { repository: templates, type: git, name: devexp-engg/automation, ref: release/v4.5 }
    - { repository: spaces, type: git, name: spaces, ref: devops/v1.0 }
    1. Change the helm charts (config map and Ingress files) - refer to https://selfassist.cloudone.netapp.com/docs/configmap-ingress-update
    2. To address the DR transition and ensure compatibility with the latest pipeline version, please refer to the "DR Changes" section in the documentation for Version 4.5 of your application. This section provides specific instructions and guidelines on how to adapt your app to the changes introduced in the latest version.
  • Make Necessary Firewall Rule Changes
    Depending on your application requirements, it may be necessary to make changes to the firewall rules. This step ensures that the application can seamlessly run on the current cluster as well as the target cluster during and after the migration process.

Appstacks Only

Review & Setup DNS

Before starting the migration process, it is essential to review and set up the Domain Name System (DNS) for the application. Proper DNS configuration is crucial for ensuring the correct routing of traffic between the on-premises environment and the AWS environment. Detailed instructions for reviewing and setting up DNS can be found at https://selfassist.cloudone.netapp.com/docs/cloudone-dns.

  • Primary DNS Setup
    Configure the primary DNS setup to enable automated DNS failover. This setup offers the following benefits:

    • Simplifies troubleshooting of application services by providing the namespace through an nslookup.
    • Sets a Time-to-Live (TTL) of 10 minutes, compared to the default 60 minutes. Complies with CloudOne standards. For detailed instructions, refer to the documentation available at https://serfassist.cloudone.netapp.com/docs/cloudone-dns?v1.
  • DR DNS Setup
    Similar to the primary DNS setup, configure the DR DNS setup to achieve the same benefits as mentioned above. This ensures that DNS failover is automated during a disaster. For instructions, refer to the documentation available at https://selfassist.cloudone.netapp.com/docs/cloudone-dns?v1.

Setup configmaps

Configmaps play a vital role in the migration process by storing configuration data for applications running in Kubernetes clusters. It is necessary to set up the required configmaps to ensure a smooth transition of the application to other clusters.
Refer steps to setup configmap here.

  • Configure Primary Configmap
    Create a configmap with a name suffixed by '-primary'. The deployment must reference this configmap. This step consolidates all environment variables into a single config file, eliminating the need to set individual environment variables in the deployment spec.
  • Configure DR Configmap
    Create a configmap with a name suffixed by '-dr'. This configmap allows for the automation of the failover process. During the DR failover process, the environment variables required for DR will be automatically applied. This simplifies the failover process and ensures the application's availability in a disaster scenario.

Make INgress Changes

Update the Inress configurations to allow both primary and DR URLs for services. By allowing multiple URLs for each service, including DR URLs, you can test services during the DR validation state before the final cutover. This step enhances the resilience and reliability of the application.
Refer steps to setup Ingress changes here.

Register DR URLs with Azure Authentication (if required)

If the application requires Single Sign-On (SSO) login functionality, ensure that the DR URL is added as an endpoint in Azure Portal for Authentication here.

DB Stacks Only

If your application involves database stacks, verify that the backup schedule is enabled and functioning correctly. During the DR failover process, the latest backup will be used to restore the database and ensure data integrity.
Note: The latest backup will be used when performing the DR failover Set the `ondemand.enabled: true` for all production database deployments

Benefits of using DR for AWS Migration:

  • Same space names in AWS environment as On-Prem
    Migrating your applciation using this method ensures that the application's space names remain consistent in the AWS environment, eliminating confusion and making it easier to manage and reference resources during and after the migration.
  • Similar process as Disaster recovery
    The migration process shares similarities with disaster recovery, leveraging familiar procedures and methodologies. This familiarity reduces the learning curve and simplifies the migration process for users who are already familiar with disaster recovery practices.
  • One-time pre-requisites setup required for both DR and AWS Migration
    These prerequisites, such as reviewing DNS, scheduling database backups, and configuring Ingress, are essential for a successful migration. Moreover, they align with the requirements for disaster recovery, maximizing the value of the preparatory work.
  • Self-service from ServiceNow Portal
    The entire DR/AWS migraton is a self-service experience through the ServiceNow Portal. Users can access and initiate/finalise the migration process independently, reducing reliance on external resources and streamlining the overall migration workflow.
  • Allows migration of all pipelines at once for the application
    The self service tool offers the capability to migrate all pipelines associated with an application simultaneously. This feature ensures consistency and minimizes disruptions during the migration process, allowing for a cohesive transition to the AWS environment.
  • Allows adhoc backup feature
    The self service tool includes an adhoc backup feature, providing users with the ability to create on-demand backups during the migration process. This feature adds an extra layer of data protection and flexibility, allowing users to take snapshots of critical data whenever necessary.

    By following the outlined prep work and leveraging the migration tool, users can confidently migrate their applications from on-premises environments to the AWS cloud, benefiting from consistent naming conventions, familiar processes, and self-service capabilities.