Backup & Storage|Cloud Computing|SQL Server|Virtualization

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).

Sponsored Content

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.


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Michael Otey is president of TECA, a technical content production, consulting and software development company in Portland,
Don't leave your business open to attack! Come learn how to protect your AD in this FREE masterclass!REGISTER NOW - Thursday, December 2, 2021 @ 1 pm ET

Active Directory (AD) is leveraged by over 90% of enterprises worldwide as the authentication and authorization hub of their IT infrastructure—but its inherent complexity leaves it prone to misconfigurations that can allow attackers to slip into your network and wreak havoc. 

Join this session with Microsoft MVP and MCT Sander Berkouwer, who will explore:

  • Whether you should upgrade your domain controllers to Windows Server
    2019 and beyond
  • Achieving mission impossible: updating DCs within 48 hours
  • How to disable legacy protocols and outdated compatibility options in
    Active Directory

Sponsored by: