Disaster recovery reference architecture: On-premises data center to Skytap – 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.

disaster recovery diagram

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.
1. 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.
2. 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’re 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’s working properly.
3. 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’re 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 don’t 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:
1. Start the remaining VMs in the environment.
2. 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.
3. 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.
4. Save the updated environment as a backup template.
  
  Give the template a unique and discoverable name, such as ApplicationName_DR_2018_04_01.
5. 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:
1. Start the full environment.
2. Use your standard configuration management tooling (Ansible, Puppet, etc.) to update the VMs that had been suspended with the latest operating system and application updates.
3. Update your DNS service to direct traffic to the Skytap public IP address.

For other disaster recovery examples, see Disaster recovery reference architectures.