Cloud Foundry in Use: High Availability, Backup, and Disaster Recovery
Having highly available applications and services is a necessity in a global world where users require 24-hour-a-day access to your resources. For this reason, the ability to maximize operational performance becomes critical to businesses and directly affects their revenue and customer satisfaction. From the article, get to know what Cloud Foundry offers its users to ensure system reliability, recoverability, and continuous operations.
High availability
Cloud Foundry achieves HA through capabilities of its own architecture and BOSH. The platform functionality for meeting HA requirements includes the ability to:
- Restore failed application instances. Health Manager detects the lost instances and Cloud Controller takes care of their replacement.
- Restart failed platform processes. If a platform process on a BOSH-managed VM is not present, Monit starts the process again.
- Recreate failed virtual machines. If a VM goes down, BOSH with the Resurrector plugin enabled starts a new VM.
- Deploy application instances and Cloud Foundry components to different availability zones and keep traffic served if one or more zones are compromised.
At the same time, the platform does not provide HA for databases deployed outside Cloud Foundry.
Find recommendations for scaling platform availability in Cloud Foundry Documentation. Additionally, the levels of HA in Pivotal CF—one of the major Cloud Foundry distributions—are explained in this CF Live review.
Backup and disaster recovery
In general, procedures for a Cloud Foundry backup and recovery involve creating persistent disk snapshots and using database functionality to back up and restore data.
Factors to consider when planning for a Cloud Foundry backup and disaster recovery:
- Colocation. To minimize risks, install your deployment, BOSH, and the BOSH deployment manifest in physically separate instances.
- Configuration information. Keep
.ymland other configuration files backed up and up to date. - Data. Cloud Foundry does not perform a data backup. It can be done through an IaaS or other backup and restoration tools.
- Disaster recovery recommendations. The BOSH project has a disaster recovery guide.
Recovering CF deployment
To recover Cloud Foundry deployment, you need a copy of your Cloud Foundry deployment manifest previously backed up.
You can find and download the YAML file with the following commands in the BOSH CLI:
| BOSH Command | Description |
|---|---|
$ bosh deployments | Shows the list of created deployments on the BOSH Director as well as stemcells and releases used by each deployment. |
$ bosh download manifest your-deployment-name [file-path] | Saves the deployment manifest of your deployment to file-path. |
Recovering BOSH
The BOSH deployment manifest is the first thing you need to bring back the BOSH Director.
In addition to the Director, information about Cloud Foundry deployments also has to be restored. Options for making the recovery possible include:
- restoring an internal BOSH database and Blobstore from a snapshot of the BOSH persistent disk volume
- using an external BOSH database and Blobstore
Head to bosh.io to learn more about the tool chain specifics.
Diego—the next generation of the Cloud Foundry runtime—replaces DEAs and Health Manager in the PaaS architecture. It also makes the life of Cloud Controller easier taking responsibility for application scheduling and management. With the new player, however, the roles of Cloud Foundry components in providing functionality for HA will change as well as some procedures for backup and disaster recovery.
The article uses the terminology of a pre-Diego era, which means it should work for deployments that have not been migrated to Diego yet.
Find out more about Cloud Foundry security, scaling, and HA with our Architect’s Guide to Implementing the Cloud Foundry PaaS.
Related resources
In the video, the Pivotal team shares best practices on how to build a robust Cloud Foundry system.
