SDS and Docker: The Beginnings of a Beautiful Friendship

Software-defined storage (SDS) has usually meant storage that augments, optimizes, aggregates, and presents some form of cloud gateway. It is storage manipulated by an automation with an orchestration layer that ties differing data functions together. The ultimate in automation and orchestration for storage is the inclusion of Docker. Docker, or any container technology, needs storage—persistent storage. How storage is presented to Docker is unimportant to Docker. It is, however, important to the storage team. SDS is about making storage simpler by reusing, improving, or automating delivery. How does your storage fit with Docker?

SDS and Docker go hand in hand. Docker does not care what storage is there, but you can use the Docker manifest as well as the metadata within Kubernetes or Mesos to set up requirements for storage. Such requirements could be required IOPS, presentation method, latency, etc. Once you have those, a good SDS platform will map the requirements to what and how it will present to Docker. Here is a look at three tools that are used currently with containers as persistent and other forms of storage.

Product ioFABRIC Hedvig SwiftStack
Docker Persistent Storage
Flocker Support
Delivered as Container
Presents as API
Runs Local
8: Presents Local Storage to Docker Containers on each VSA Node

SDS and Docker Integration Definitions

Here are some definitions for the elements above. This is not the complete list—just the basics.

  • Persistent Storage: A platform that will natively present persistent storage to Docker and other containers. Persistent storage in Docker is often presented either directly via NFS or iSCSI mounts or up through the file system.
  • Flocker Support: Support for the ClusterHQ open-source container data volume orchestrator, Flocker. Flocker provides more than presentation: it provides availability, control, and resource balancing.
  • Delivered as Container means the product itself is delivered as a container and therefore can be integrated into the container build process directly.
  • Present as API means the product presents its storage to the container via an API. Object storage always has this capability.
  • Runs Local means that Docker containers can run locally within the software-defined storage. There is no requirement for SDS to integrate better if anything runs locally, but having containers run close to storage can improve performance.

Added to this list should be the ability to set definitions for the storage directly within the container manifest—to build out example manifests for all forms of storage requirements, but mostly around performance. We could also include the ability to move the Docker container closer to the storage, as well as to move the storage closer to the container (adaptive data fabric and data movement).

Where to Go?

Ultimately, we are considering where to go when we think of SDS. Docker and other container technologies point us in a direction: a direction of increased automation, hardware abstraction, and improved analytics for understanding the performance of any underlying hardware. Docker integrations are well and good, but there is a distinct need for the integration to be broader than just Docker, Flocker, and presentation. The criteria to be met for any container is the crucial part: the SDS platform must meet that criteria and act appropriately in our ever-changing hybrid cloud environment.

Most folks using containers consider persistent storage a necessity for saving state information. Even if we use a NoSQL database, eventually it will be written to disk. Where do we store that data? We still have the same issues we have always had getting our storage to perform better. That is where software-defined storage comes into play. It is the glue that binds the Docker container to the storage and allows the developer to pick the requirements for the storage itself. SDS just delivers on those requirements. If those requirements change, which they will, software-defined storage will change with them. If the storage changes or becomes unavailable, SDS knows how to handle that as well.

No-nonsense storage is where SDS is going. Using Docker with SDS is the start of a beautiful friendship, one where the relationship is about criteria.

Share this Article:

The following two tabs change content below.
Edward Haletky
Edward L. Haletky, aka Texiwill, is an analyst, author, architect, technologist, and out-of-the-box thinker. As an analyst, Edward looks at all things IoT, big data, cloud, security, and DevOps. As an author, he has written about virtualization and security. As an architect, Edward creates peer-reviewed reference architectures for hybrid cloud, cloud-native applications, and many other aspects of the modern business. As a technologist, Edward creates code prototypes for parts of those architectures. Edward is solving today's problems in an implementable fashion.

Related Posts:

Leave a Reply

Be the First to Comment!

wpDiscuz