While a growing number of organizations are turning to containers for their storage needs, many adopters are still unsure exactly how the technology works and what it can ultimately achieve. Such widespread unfamiliarity and inexperience has led to a number of potentially destructive and expensive misconceptions about container storage capabilities and functions.
Are you on the fence about using data storage containers? In this tip, we take a look at five pervasive container storage myths that have led many storage managers down the road to poor performance and unnecessary costs.
Hopefully, clearing up these common misconceptions can provide a more accurate assessment of the technology and how to best incorporate it into an organization's storage strategy.
1. The applications running inside data storage containers are temporary and, therefore, don't require persistent storage.
Imagine an organization is running a database, such as PostgreSQL, MySQL or Microsoft SQL, inside of a container and the database contains customer data, patient records or other extremely important information. "Shutting down the container that's running this database, which can be done deliberately by the host, or caused by an unexpected user error, hardware error or power outage, will result in massive data loss," said Itzik Reich, Dell EMC vice president of technology for the XtremIO and VxFlex OS product lines. Without persistent storage, this critical data could be lost forever. "And, as we all know, a storage data loss event can make for a very, very bad day for a database administrator," Reich said.
2. Data storage containers are not at risk and do not need to be included in risk mitigation strategies.
Locked down containers can provide a smaller attack surface, but that doesn't preclude a successful attack on the applications and services that remain on the container or container host.
Peter DuthieCo-CEO and chief architect, Ground Labs
With the understanding that a container is a partitioned application space within another server, it's easy to overlook the fact that writing to the container file system results in disk writes to the underlying host server file system, said Peter Duthie, co-CEO and chief architect at Ground Labs, a data discovery software provider. "Even though the changes to the file system may be discarded on termination of the container instance, files written during the lifetime of the container are as available as any other files during that container's lifetime," he said.
Internal and external threats don't care if a target's storage is temporary or persistent. "An attacker, upon successfully accessing either the container or container server host, can access the container file system the same way as any other virtual machine or server," Duthie said. "Locked down containers can provide a smaller attack surface, but that doesn't preclude a successful attack on the applications and services that remain on the container or container host, in which case, any sensitive data stored on the container file system, such as temporary files, log files and local data caches, are compromised."
3. CSI, the container storage interface recently added to Kubernetes and adopted by large storage vendors, can automatically make any storage system "container-native storage."
CSI is an important interface positioned between a storage system and Kubernetes. "It provides a way for Kubernetes to speak to an underlying storage system to provision and access the storage resources necessary to run data services like databases in containers," said Michael Ferranti, vice president of product marketing for container storage software firm Portworx.
While CSI provides an interface for any storage system to communicate with Kubernetes, it does not define any particular behavior for the storage system itself. "As a result, storage systems designed for relatively static VM-based applications struggle to keep up with the dynamic nature of container deployments," Ferranti said.
He added that storage managers adopting microservices and DevOps practices along with data storage containers should be extremely cautious when using a traditional storage array with a CSI plug-in to back their container deployments. "They will find that the scale and flexibility of containers are a mismatch for traditional storage, even with a CSI plug-in," he said.
4. You can simply attach existing external storage systems to a container cluster.
Although it's possible to attach databases and persistent external volumes to a Kubernetes cluster, for instance, such storage is not necessarily architected for a large cluster of small processes. "It's important to realize that the reason to use containers is typically so that you can break down code into many small services -- microservices -- and then replicate them to enhance resiliency and performance," said Tom Petrocelli, a research fellow at technology advisory firm Amalgam Insights. A large cluster could easily generate a greater-than-usual number of connections to the storage. "The number of connections will also increase and decrease as the cluster scales up and down," he said. "Most storage is not designed for this many connections or this type of rapid scaling."
5. You shouldn't run stateful workloads, such as relational databases, using container orchestration frameworks like Kubernetes.
This mistaken belief has stopped enterprises from migrating their databases into Kubernetes, thus splintering their infrastructure deployments, noted Jitendra Vaidya, co-founder and CEO of PlanetScale, a database-as-a-service provider. "They run their stateless services in Kubernetes but manage the databases outside Kubernetes, thus having to maintain and manage two different sets of tools."
A database clustering system, such as Vitess, can solve this problem by providing a stateless proxy layer and using an etcd cluster for storing cluster topology, enabling fast master failovers without the applications seeing any data loss.
