Disaster recovery reference architecture: On-premises data center to Skytap Cloud – warm recovery
The following diagram shows a high-level overview of a disaster recovery workflow in Skytap.
In this example, Skytap is a warm, off-site disaster recovery location for an application running in a corporate data center. For an overview of the various disaster recovery scenarios, see Disaster recovery reference architectures.
This disaster recovery workflow uses several Skytap features:
Create a VPN or Private Network Connection between your on-premises network and your Skytap account.
After a one-time set up, this connection lets you securely send updated build files, operating system patches, and other assets from your corporate network to one or more virtual environments in Skytap.
For more information, see Overview of Private Network Connections and VPNs.
Create a virtual copy of your on-premises application stack in Skytap.
Use our import tools to bring your Power LPARs, x86 VMware VMs, and x86 VMware vApps into Skytap.
During this process, your VMs are uploaded to a Skytap region. Each VM retains everything installed on it, including the operating system, installed applications, containers, etc. For more information, see Overview: Importing VMs and vApps into Skytap.
Configure the environment as needed.
Your Skytap virtual environment can be configured to replicate your on-premises application stack, down to the IP address and hostname assigned to each VM. For more information, see Editing environments and networks.
If you are using a third-party software product for application recovery, install that agent inside of the virtual machines in your Skytap virtual environment. Test the agent to ensure it is working properly.
Share the virtual environment with any Skytap users who will need access to it during disaster recovery.
Add the virtual environment to a project, and give access to any users who need to view, use, or edit the environment. Users can have different levels of access, depending on their project role.
Give the project an easily identifiable name, such as Disaster recovery resources.
For more information, see Sharing resources with projects.
Keep a subset of the critical VMs running. Suspend the other VMs in the environment.
For example, keep the domain controller and database servers running and connected to your on-premises environment via the VPN or Private Network Connection. Synchronize the data in real-time or on a regular schedule (depending on your business requirements) to reduce your data recovery time. Follow the vendor’s recommendations for data replication and failover best practices.
Alternately, if you are using a third-party application recovery agent, use the standard capability of that agent to keep a subset of critical VMs up-to-date.
To manage costs, suspend VMs that do not need to be updated as frequently, like your application or web servers.
Attach a public IP address to the network appliance in the environment.
For more information, see Attach a public IP address to a VM.
Periodically update the entire application stack and create a template backup.
On a schedule based on your business requirements:
- Start the remaining VMs in the environment.
- Use your standard configuration management tooling (Ansible, Puppet, etc.), or your third-party application recovery software, to update the VMs that had been suspended with the latest operating system and application updates.
- Perform a “smoke test” of the recovery environment. Use your standard test process to validate that the application works as expected and that it functions properly as a disaster recovery environment.
Give the template a unique and discoverable name, such as ApplicationName_DR_2018_04_01.
- Add the template to the project you created earlier. Validate that the project members have the appropriate level of access to create environments from the template.
During disaster recovery cutover
Follow your organization’s documented disaster recovery procedures to:
For other disaster recovery examples, see Disaster recovery reference architectures.