Container Availability and Disaster Recovery
It’s no secret that containers have begun to emerge as the new building blocks for modern cloud-base applications. While containers have been supported in the Linux world for some time, they became a viable option for Microsoft oriented businesses when Docker support was included with Windows Server 2016.
Containers are essentially a lighter weight construct than VMs. Like VMs, containers enable you to run applications that are isolated from the underlying host. Containers are designed to be stateless and changes made to the container are sandboxed and they do not affect the container host. Unlike VMs, containers do not provide hardware virtualization.
Instead, they provide virtualization at the operating systems level. Containers share portions of the host operating system kernel which is why Windows containers are limited to Windows hosts and Linux containers can only run on Linux hosts. However, recent changes in Windows Server container support include using a small specialized Linux VM to enable the running of Linux containers on Windows hosts. A container host can be a VM or it can be a physical system. Today, most businesses are using VMs as container hosts. Let’s look at some of the issues to consider in container availability and disaster recovery (DR).
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
Container Orchestration and Availability
Unlike most monolithic legacy applications, containerized applications are composed of multiple microservices that run independently and communicate with one another using various protocols like HTTP, REST, AMQP, or TCP. Containers are often the foundation for these microservices and since containers are stateless recovering from a service failure simply involves starting another instance of the container.
Container orchestration technologies like Docker Swarm and Kubernetes enable you to create relationships between the different containers that comprise an application and the orchestrator is responsible for monitoring and scaling the containers. If a container dies or doesn’t respond to the orchestrator it will automatically spin up another instance of the container. Since containers are typically designed to be stateless it doesn’t matter what the container was doing – you get a fresh instance of the container and your application keeps on running.
Protecting the Container Host and Persistent Volumes
Some of the key aspects of container DR are protecting the underlying container hosts, repositories and persistent volumes. Since containers themselves are stateless it doesn’t make any sense to back up a running container. However, containers run on hosts –physical or virtual – and those hosts should be protected. Like a virtualization host, a container host needs to be backed up. Depending on your RTOs (Recovery Time Objectives) and RPOs (Recovery Point Objectives) you might want to include those container hosts in a replication process where the hosts are replicated to the cloud or a separate site for DR.
In addition, you need to protect container repositories and any container data volumes. While containers are stateless, container images are required to start new containers and those container images are typically stored in local repositories that are accessible to the container host. Those repositories must be available in order to start new containers so your DR plan needs to include protection for those container repositories.
Likewise, some containerized applications like SQL Server will need to persist their data changes and they do this using external data volumes. A data volume essentially maps a portion of the file system in the container to a physical disk that might be on the container host or it might be on external storage. For an application like SQL Server, the databases files would be stored on a data volume. The changes made in these databases would be persisted in the external volume beyond the life of the container. From a DR perspective, this means that the host or storage subsystem that contains the data volume needs to be backed up and optionally replicated to a DR target location.
Containers Need Protection Too
While containers are stateless and highly resilient to failure you still need to take steps to protect the IT infrastructure that supports your containers. A complete DR plan for containers needs to include host protection as well as protection for your image repositories and container data volumes.