Block storage, object storage, and file systems: What do they mean for a container? _ File System

When an administrator first starts using the Docker container, it is often surprising that the container itself takes a non-persistent storage. When the container is removed, the container's storage is also removed.

Of course, if there is no way to implement permanent storage, the use of container applications will be very limited. Fortunately, some methods can implement persistent storage in a containerized environment. Although the native storage of the container itself is non-persistent, you can connect the container to a store outside the container. This operation allows storage of persistent data because the external store will not be removed when the container is stopped.

The first step in determining how to implement persistent storage for a container is to determine the underlying type of storage system that you will use. In this context, there are typically three primary options: File system storage, block storage, and object storage. In this article, I'll explain the differences between each type of storage and what happens when you use them to set up storage for a container environment. File System Storage

File system storage is a stored form that stores data as a file for decades. Each file has a file name and usually has an attribute associated with it. Some common file systems include NFS and NTFS.

File system storage is one of the most common ways to implement persistent data storage when it comes to configuring containers to persist data. The most known examples of file system storage (related to containers) may be host-based persistence.

The idea behind host-based persistence is very common. The container resides on the host server. This host server contains its own operating system and its own file system. You can configure a container to store persistent data in a private folder on the host server's file store. The Docker container typically combines the container layer into a cohesive file structure using the Federated file system. host-based Persistence bypasses federated file systems that require data that is persisted and stores data with the same file system used on the host.

The main problem with common host persistence is that it completely destroys the portability of the container. When using host persistence, a dependency resource (persistent storage) resides outside the container of the host server's native file system. To resolve this issue, additional host persistence has been created. For example, a distributed file system is used to replicate persistent storage across multiple host servers through multiple host persistence.

Conclusion: File system storage may be the most clumsy method, because the file system did not take portability into account at the beginning of the design. However, as I mentioned earlier, there are some ways to implement a container-friendly file storage system, which is typically done by distributing file systems across multiple servers. Block storage

Block storage is another storage option for a container. As mentioned earlier, file system storage organizes data into a hierarchy of files and folders. Instead, the block stores the block of data in the storage block. Block is identified only by its address. Block has no file name and no metadata of its own. Only when a block is combined with other blocks to form a complete block of data does it make sense.

Because of its performance, block storage is typically used for database applications. Block storage is also commonly used to provide snapshot functionality, which allows volume to be rolled back to a specific point in time without having to restore the backup.

For containers, block storage is sometimes implemented in the form of container-defined storage. A container-defined storage is a software-defined form of storage, but is specifically used in a container environment. This store is typically implemented inside a dedicated storage container.

Rancher Labs has launched its own distributed block storage project, named Project Longhorn. The basic idea behind Longhorn is relatively simple.

The storage system can contain multiple block storage volumes, and each of these volumes can only be loaded by a single host. In this case, Longhorn attempts to divide the block storage controller into a large number of smaller block storage controllers, each of which can be mapped to a different block storage volume. If all of these block storage volumes reside in the public pool of the physical disk, the Longhorn method will allow the orchestration engine to create block storage volumes as needed. For example, you can create a block storage volume automatically while creating a container.

Conclusion: Block storage is more flexible than file system storage, which makes it easier to adapt to block storage of container environments. The only challenge is to ensure that block storage data is available in an environment composed of multiple hosts. This can be addressed through distributed storage. Object storage

Object storage differs from file system storage or block storage. Instead of referencing data by block address or filename, it stores the data as an object and is referenced by the object ID. The advantage of object storage is that it is highly scalable and has a high degree of flexibility in the ability to associate attributes with objects. The disadvantage of using object storage is that it does less than block storage.

Because object storage is primarily designed to achieve scalability, it is a popular choice for public cloud providers. The Docker container can link to object storage on Amazon Web Services or Microsoft Azure, but doing so requires specialized design of a container application to take advantage of object storage. Typically, a typical application may be designed to access data through a file system or SCSI call, and object storage requires rest calls based on HTTP, such as GET or put. Therefore, object storage should be stored on applications that require large scale scalable storage or on storage that needs to be geographically spanned.

Conclusion: Object storage can be more complex because it relies on rest calls. But the scalability of object storage makes it a good choice, because in a container environment, massive scalability is often a priority.

Original Source: Rancher Labs

September 27, Beijing Hna Marriott Hotel, container Technology conference container Day 2017 is about to be held.

Cloudstack's father, HNA technology director,general manager of Hengfeng Bank Science and technology, Aliyun PAAs Engineering Director, Minsheng Insurance CIO Have joined the deluxe instructor package.

11 container Landing Enterprises, 15 real cloud computing, 13 pure technical speech, combined with actual combat scene, focus on landing experience. Free Attendance + Super HIGH specification, detailed agenda and registration link please stamp