Is persistent storage really suitable for containers?

Does the persistence store really fit the container? The author of this article mainly around the twelve elements of the design patterns and container architecture on this topic published their own views.

@Container container technology conference will be held on June 4 at the Shanghai Everbright Convention and Exhibition Center International Hotel, from Ctrip, PPTV, ants gold suits, Jingdong, Zhejiang Mobile, Haier Electric, only goods, eBay, , Tudou, Ali River, point of the network and other technical personnel will bring practical experience to share, March 21 before the purchase of only 238 yuan, welcomed the students interested in buying.

What is the value of the container's persistence storage is what I have been thinking about for a long time, so I hope that the opinions of myself and some of the other people I have heard can raise more attention to this issue. Especially those I can think of than I am clever and in-depth discussion of this issue published by the views of them, such as from EMC {code} Clint Kitson , SolidFire John Griffith , ClusterHQ Ryan Wallner As well as IBM 's Shamail Tahir .
Considering that some friends are still unfamiliar with this topic, please allow me to quickly introduce some relevant historical background. In recent years, containers have quickly become standard deployment units for cloud native applications that follow the 12-factor application design pattern. Two of these models are stateless applications and support services . Its idea is to run an application of a container, the application itself should be stateless and temporary, the need for persistent data is written like a storage volume on the database such support services. Even so, support services should also be considered as additional resources that are loosely coupled to the container and can be swapped at any time without any significant changes to the application. The traditional view that, in that case, then the container should be as much as possible to avoid the use of support services as a persistent storage, even if it is to use a persistent storage, they should be weakly coupled, and should not be used for those hard to change Out of storage resources. As for the specific examples of the latter, it may be possible to include objects that are accessed through the URL and are not tightly coupled to the local as object storage. In addition, solutions for rich data and resilient infrastructure services should no longer be required to support persistent storage, given the temporary characteristics of a given container for a cloud native application. Finally, the cloud native application should be designed to be extensible, but it will be difficult to achieve if the container must be associated with those tightly coupled to the container host and not the default scalable storage resource. There is a lot of information about this piece if you want to start, limited to space, this piece of content I will stay after the article.

In spite of this, there are still some people who insist on the idea of ​​persistent storage for the container, especially the transaction storage of the block volume. There are multiple reasons for this. In some cases, an application that requires data to fall and may be unable to meet its performance requirements like object storage or NFS, which is the most typical one like MySQL or Postgres that can not be designed to be out of the same way as the NoSQL database Extended SQL database. For example, an enterprise that is migrating to a container and cloud native application may want to take advantage of existing technology, such as a storage array. In order to meet this demand, some open source solutions should also be born, they are:

  • Docker's Pluggable Storage Volume – allows the Docker container to store data on third-party storage systems such as Ceph, EMC storage, and so on.
  • ClusterHQ Flocker – allows a data volume and its containers to migrate from one container host to another.
  • EMC's Dogged project and REX-ray project – embed volume management into Docker and make persistence storage easier to implement.
  • SolidFire plug-ins for Docker data volumes – provides the ability to use SolidFire storage clusters as back-end devices in the Docker environment.

If you want to know more about these solutions, please click on the link above to see the specific documentation for the project.

So where is the persistent storage for the container, where is the place where I am worried? I would like to point out that there are two points – one is on the structure, the other is the behavior side. For the sake of brevity, I will try my best to keep my thesis simple.

  • Architecture – I often say that how to run a single container is not a particularly interesting question; the real challenge comes from the large-scale container management. In a small environment with only a few dozen or hundreds of containers, the poor architecture of persistent storage implementations may not be a problem. But once the growth to tens of thousands of container size, the situation is not the case. When a large number of containers are temporarily running and are constantly migrating or re-instantiating on a new container host, the persistent storage they rely on if they are tightly coupled to a particular container host will greatly affect the entire container architecture Extensible and resilient scalability. Imagine the construction of a large cloud native application used by the container host depends on the SAN storage to achieve the persistence of the scene it; your scalability will be firmly limited to the same SAN storage volume can be connected to the number of servers. Or even if you use persistent file systems like ZFS to achieve persistence, the time required to move from one container host to another is usually longer than a new container. This creates a conflict between the need to quickly pull up an application and the time required to mount the persistent storage tier.
  • Behavior model – I also think that the traditional storage model and the solution is precisely the right to deepen the anti-pattern of the original design of the cloud. I have seen some of these cases, the user has the entire application server, including their dependence on traditional storage, from the virtual machine to the container, and then they began to wonder why they can not get the container should bring all the benefits. By providing more persistent storage options, are we targeting users to deviate from the design patterns of cloud native applications like 12-factor applications, and then make them deviate from future trends? As I often say, every architectural solution is bound to be bound by some of the constraints that must be followed. We should not imply users, they can use the old design pattern, and then can still get the cloud of native application containers can bring all the benefits.

There may be a lot of discussion here, here I first come to an end … … when it comes to specific technical aspects when I was not a diehard, and I do not believe that we should abandon all the persistent storage program. I agree with the persistence of storage for the container also have a place of view, but the premise is that it is correctly positioned to the current problems, and we are willing to teach and help users to understand their own environment in which the restrictions. Sometimes if a storage solution is only "technically" feasible, it also means negating it because it does not follow a correct design pattern. Perhaps this also means that all persistent storage provided for the container is subject to the so-called cloud native design pattern. At the very least, it means that we need to let users know about the specific advantages and disadvantages of these persistent storage solutions.

I sincerely hope that this article will open an active discussion on this topic. Now I have expressed what I want to say, as well as Clint, John, Ryan, Shamail and other people's views, which one out of your voice?

Original link: is-persistent-storage-good-for-containers (translation: Wu Jiaxing)

Related Articles: Persistent Storage of Containers (2)

    Heads up! This alert needs your attention, but it's not super important.