Summary
Use your favorite automation and infrastructure management tooling to backup your data to OpenMetal’s On-Demand OpenStack Private Cloud. OpenMetal’s On-Demand OpenStack Private Cloud provides the tools and high-density storage infrastructure operators need to create a secure, durable mirror of critical data for disaster recovery and business continuity.
Supported Tooling and APIs
Automation and Orchestration
Storage
Example Workflows
Mirror Your Infrastructure
Your cost for your OpenMetal On-Demand OpenStack Private Cloud is the same whether you use 0% of your cloud resources of 100% of your cloud resources, unlike in public cloud deployments. A private cloud enables you to create the infrastructure you need without having to worry about incurring overages for resource utilization.
This workflow literally is creating a 1-to-1 copy of your production infrastructure on your private cloud. The copy of your infrastructure can be a cold copy with a relatively recent copy (usually more than 1 hour old but less than 24 hours old) of your production data, a warm copy with near up-to-date information (data is more than a few minutes old but less than 1 hour old) or a hot copy (data is actively being synced as it is generated in the production infrastructure).
Mirroring your infrastructure can provide some of the fastest response times for maintaining service continuity during times of disaster and disruption; however, maintaining a mirror of your infrastructure can require additional labor maintaining the mirror of your infrastructure. In many cases, infrastructure operators will run the mirror of their infrastructure as an additional availability zone with enough capacity to roll over a second availability zone’s utilization in the event an availability zone fails.
Mirror Your Data
Infrastructure operators often choose to mirror only their critical data to their OpenMetal On-Demand OpenStack Private Clouds and recreate their application infrastructure if a failure occurs. In this approach, the private cloud normally has the minimum amount of hardware required to receive, process, and store a mirror of application data. When a failure occurs, the infrastructure operator can quickly and easily add compute resources to the private cloud to facilitate recreating application infrastructure. The OpenMetal platform can add huge amounts of CPU and RAM resources to existing clouds within minutes to meet any surge in demand and remove those resources once the surge has ended.
In this workflow, the infrastructure operator manages backing up data to the private cloud. The exact approach will vary based on the data, databases, and other data storage in use. Generally, the infrastructure operator will either run tooling that backups data to the private cloud or will run read-only replicas of the database or data storage software in use. Most popular database and data storage solutions support configuring automatic replication of data to remote database instances; infrastructure operators should consult the documentation and manuals for the software they use.
This approach provides a good balance between ensuring service continuity and minimizing on-going costs and maintenance. The OpenMetal platform offers high-density storage hardware designed for this approach to disaster recovery. Infrastructure operators can maintain a secure, safe copy of their critical data at minimal cost and with minimal maintenance.
Tips for More Successful Disaster Recovery
Building reliable, maintainable disaster recovery infrastructure can be time-consuming, difficult, and expensive. Infrastructure operators can achieve better disaster recovery outcomes if they apply the following strategies and techniques whenever possible:
- Document your infrastructure deployment process
- What resources does an application deployment require?
- How many separate instances?
- How many vCPUs?
- How much RAM?
- How much storage?
- What are the application stack’s dependencies and requirements?
- Which operating system?
- What runtime environments or binaries are used?
- What are the steps someone has to take to deploy the different software components of the application stack?
- What commands are manually executed?
- What configuration files or settings are required for deploying the application stack?
- Where can someone find documentation, configuration files, settings, and other reference artifacts related to an application deployment?
- Who is responsible for managing or performing application deployment tasks?
- Who is responsible for managing a disaster recovery situation?
- What resources does an application deployment require?
- Automate deployment tasks whenever possible
- Use tools like Terraform, Ansible, Chef, Salt, Puppet, or other automation solutions to perform application deployment tasks in a repeatable, automated fashion
- Create operating system images with pre-installed dependencies, required software, and configuration to speed instance deployments
- Deploy applications using container technology when possible
- Warning: Benefiting from container technology can require rewriting and rearchitecting applications
- Rehearse disaster recovery situations
- Periodically go through the process of failing over to your disaster recovery solution
- Conduct load testing and performance testing on your disaster recovery solution to ensure the solution can handle your production load during failure situations
- Host your critical tools and infrastructure management solutions outside of your production environment if possible
- If your tools for managing your infrastructure are in the same availability zone as your production environment, you will be unable to manage your infrastructure if the availability zone fails