OpenShift and container-native workloads have made many advancements in deploying, running, and managing modernized applications. Many of the management processes which were necessary for deploying and maintaining applications in traditional environments are no longer necessary. But what about data protection, and specifically backup as data protection. Does backup continue to play a central role in application management, and if so, what does backup in a container-native environment look like?
In this series of articles, we are going to take a deeper look at:
- Why backup continues to be critical for OpenShift workloads and the new challenges that OpenShift applications bring to traditional backup which require an additional level of backup orchestration that wasn’t required in legacy environments.
- IBM Storage Fusion’s unique solution to providing backup and recovery orchestration through a feature called “recipes.”
- A real-life example of using IBM Storage Fusion recipes to protect an OpenShift application.
Why backup and why now? Haven’t we evolved?
Many of us have heard many claims that OpenShift and container virtualization make about workloads and managing workloads that could lead us to conclude that backup as a form of data protection is no longer necessary. For example, we have seen claims such as:
- OpenShift manages stateless applications which use ephemeral storage which do not need to be protected by backup.
- OpenShift applications are declarative and can easily be recreated through their manifests.
- More complicated applications utilize operators which provide the ability to back up their operands.
While all these statements are truthful, we must be careful forming a conclusion that backup is no longer necessary in OpenShift.
- While it is true that OpenShift applications use ephemeral storage and are often stateless, many OpenShift applications rely on persistent storage which needs to be protected by backup.
- Many legacy applications that have been ported into OpenShift are not purely declarative and cannot simply be recreated by preserving a desired state in a set of manifest files.
- Not all applications in OpenShift are managed by operators, and not all operators are offer “Level III – Full Lifecycle” capabilities. Even operators that have this level of operator capabilities might only have rudimentary definitions of backups.
It is probably worthwhile to take a moment to explore what we mean by “backup as a form of data protection in this article.” We are specifically talking about these capabilities:
- Make a copy of the application resources (stateful data and container resources, that is, the information stored in the cluster etcd database) to a storage location outside of the storage cluster.
- Recover the application to a running state in the same cluster or in another cluster.
- Minimize the amount of time that the production application is affected by the backup process. Ideally, the effects of the backup application are negligible. This is often referred to as an “online” or “non-disruptive” backup.
Hopefully you are convinced that backup is still a very necessary form of data protection in OpenShift environments. But what is this need for additional orchestration? Why can’t I just backup the stateful data (PVC) and the resources (etcd)?
The simple answer is that it is complicated by several factors. The main issue is of ordering of how resources are backed up and restored. In a perfect world, all applications would be fully declarative and could simply rebuild themselves from nothing to the desired state without any human intervention. Many applications, like legacy databases, evolve over time as a series of discrete events, for example, the database environment is established at some time t0, a database instance is then created at time t1. When recovering such an application, you might need to be aware of how the applications evolve over time and whether this needs to be reflected in the backup and recovery plan. For example, you need to ensure that you are potentially not restoring database instances before the environment is established, or that you are trying to instantiate an instance of a database before the persistent data is recovered.
Many of the standard backup and recovery tools for OpenShift have a good, basic set of capabilities to orchestrate recovery (and backup as necessary). These tools include Velero, OpenShift APIs for Data Protection (OADP), Restic, and others. While these tools can provide basic semantics for orchestration, they don’t provide sufficient semantics to produce repeatable, recoverable backups especially for application platforms that are composed of several individual application services, such as IBM Cloud Pak for Data.
Another area where ordering becomes important is in backup when preparing the data to be put into a consistent backup state so that it can be recovered properly. We are all familiar with how traditional applications provide frameworks to put the application into a consistent state. An example is IBM Db2 which provides database write suspend and resume utilities to put the data into a consistent state while continuing to service requests to the live application. What happens if you have more than one of these applications in your application platform? Is there a prescribed order which you need to invoke these utilities so that the entire application platform is put into a consistent state so that it can be recovered?
In conclusion, despite the claims and capabilities of the OpenShift platform, backup as way to provide data protection continues to play a crucial, central role for complex application platforms which rely on stateful, persistent data storage like IBM Cloud Pak for Data. In the next blog installment, we will examine how IBM Storage Fusion provides a technology tool called “recipes” which allows the user or the application platform to define an orchestrated way to provide backup and recovery to ensure that data can be restored properly anywhere at any time.
Read the next blog in this series: How IBM Storage Fusion Simplifies Backup and Recovery of Complex OpenShift Applications - Part 2 "Orchestrations and Recipes"