Shulou(Shulou.com)06/01 Report--

What this article shares with you is that the five key points about the K8S disaster recovery plan are those. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

Disaster recovery is the basic requirement of most enterprise applications.

In the absence of Kubernetes and containers, backup and recovery solutions are usually implemented at the virtual machine (VM) level. When an application runs on a single VM, the disaster recovery system is suitable for such traditional applications. However, when Kubernetes is used for containerized management of applications, such a disaster recovery system cannot be used. An effective Kubernetes disaster recovery solution must be redesigned for the containerized architecture and run in the native way of Kubernetes.

Traditional VM-based backup and recovery solutions use snapshots to collect data, but this data is not sufficient for a specific containerized application. Because any particular VM will contain data from multiple applications. If you try to back up APP 1 through VM snapshots, you will also get excess data from other applications. But this data is not enough from a container point of view: APP 1 may also store data on other VM. Therefore, it is not possible to capture all VM data through a snapshot of a single APP1.

The disaster recovery solution needed by modern applications based on distributed architecture needs to be able to find all the relevant data and configuration information of a specific application, and be able to recover in a way of zero RPO (Recovery Point Objective) and close to zero RPOs (Recovery Time Object, recovery time objective).

An effective Kubernetes disaster recovery solution requires:

Control of container granularity

Ability to back up data and configuration

Kubernetes namespace awareness

Optimization for multi-cloud and hybrid cloud architectur

Maintain application consistency

Disaster recovery solutions must meet the above five standards to ensure that applications with large amounts of data running on Kubernetes meet service level agreement (SLA) or related legal requirements during disaster recovery.

Let's analyze why all five criteria are important.

Container granularity control

The container granularity control disaster recovery scheme means that users can back up specific Pod or Pod groups instead of the entire VM or server. This allows the user to snapshot only the containers that belong to the application.

Suppose you have a three-node Kubernetes cluster with a three-node Cassandra ring and three single-node PostgreSQL databases distributed across three virtual machines. With traditional disaster recovery solutions, the only way to back up a cluster is to back up three virtual machines. This will lead to increased complexity of the extraction, conversion, and loading processes, increased storage costs, and increased RTO. The only way to back up sufficient data is to back up more data than necessary.

Using container granularity, you can back up only one PostgreSQL database or three-node Cassandra ring on three VM without any other backups.

Kubernetes namespace awareness

Traditional backup and recovery solutions are not done in the Kubernetes way.

Namespaces in Kubernetes typically run multiple related applications. For example, a common pattern in enterprise Kubernetes deployment is to have all applications in the company / department run in the same namespace. In this case, it is often necessary to back up all the applications in the Kubernetes namespace together.

However, like each individual application, namespaces are distributed across many virtual machines. Each virtual machine may also have Pod from several different namespaces. If there is no disaster recovery solution that supports namespaces, a full backup will require backing up and storing far more data than is necessary. Even with this excessive backup strategy, it is difficult to restore the entire namespace in the event of a failure, resulting in a higher RTO.

Consistency of application

Even if you want to solve these problems by backing up all the VM in your system, it is difficult to avoid data corruption using traditional disaster recovery solutions. In order to successfully back up distributed applications without the risk of data corruption, all Pods in the application must be locked while the snapshot is in progress. VM-based snapshots cannot do this because they cannot lock the entire application and perform application-consistent snapshots across multiple VM.

Successful snapshots minimize the risk of data corruption and must maintain consistency in the application of distributed architectures. This means that the snapshot is executed while all Pods belonging to the application is locked.

Data and configuration backup

The goal of disaster recovery system is not only to prevent data loss, but also to keep RTO low. You need to restart and run the application as soon as it encounters a problem.

This requires backing up application data and configuration information. If the backup does not contain configuration information, you must rebuild the application in place, which is a slow, manual, and error-prone process. However, if you save only the configuration, you may lose all data.

A true Kubernetes enterprise disaster recovery system will contain both data and configuration backups. In this way, you can quickly redeploy the application with one or two commands after the system fails.

Optimized for multi-cloud and hybrid cloud architectures

In most enterprises, in practice, applications run in at least two environments. This may mean multiple local data centers or multiple Amazon Web Services (AWS) regions. In the case of disaster recovery, one data center is usually used as the primary site and the second data center as the backup site. However, there are also many companies that use a combination of public cloud and local data centers to run applications and meet their business needs. In most cases, enterprises choose the best architectural approach based on their RPO and RTO requirements.

For disaster recovery solutions, it is critical to combine these different architectural approaches to support different levels of RPO and RTO. An effective disaster recovery solution should be able to provide synchronous and asynchronous data replication, depending on the latency between the home cluster and the backup cluster.

Synchronous replication that allows zero RTO and RPO can be achieved when the round trip latency between the primary site and the backup site is usually less than 10 milliseconds. This is usually the case when the primary and backup clusters are located geographically close to each other.

In some cases, enterprises want a greater geographical distance between the primary site and the backup site. In this case, the RTO can still be zero or close to zero. However, with the increase of delay, synchronous replication of data will cause greater performance problems. If the application can accept 15-minute or 1-hour RPO, it is also an acceptable disaster recovery solution.

Kubernetes's enterprise disaster recovery solution should provide users with the choice of synchronous or asynchronous replication suitable for multi-cloud or hybrid cloud architecture. This enables users to choose different disaster recovery solutions based on their own data center architecture and business needs.

Conclusion

When enterprises migrate critical business applications to Kubernetes, it is very important to rethink and design disaster recovery solutions. In fact, it can meet the SLA related to disaster recovery at the same time.

Run the application on Kubernetes.

But it needs to adopt the disaster recovery method specially designed for Kubernetes, which is deeply integrated with the working mode of Kubernetes. Traditional VM-based disaster recovery solutions can not do this.

The Portworx Enterprise storage platform is built specifically for containers and Kubernetes. It can achieve zero RPO and near zero RTO disaster recovery for applications running on Kubernetes. And has container granularity-controlled, namespace-aware, application-consistent disaster recovery. Failure recovery can be fully automated from minimizing RTO.

These are the five key points of the K8S disaster recovery program. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.