Containers are lightweight, fast, agile, and solve all dependency issues related to the applications. With such benefits, why aren’t we using containers for stateful database / apps? It certainly isn’t because of vendors not certifying their applications on containers. Oracle supports its RDBMS on LxC containers, while its entire middleware stack is available as Docker containers. Containerized DataStax Cassandra, Postgres, MySQL, Hadoop, etc all have been successfully deployed on various clouds, using various general purpose orchestrators. Then why haven’t containers gained mainstream adoption for stateful apps?
Stateful database applications are like pets
As discussed in my previous blog, most container platforms treat stateful apps just like stateless. Often focusing just on initial provisioning, scale, or failover. Unfortunately, to use the cattle vs pets analogy, stateful apps like databases, Hadoop, ELK, etc are pets and not cattle. This means losing an instance of a database can lead to data loss, scaling them out is not simple, and restoring does not imply simply bringing up another instance on a different host. Containers were designed to simplify application development and deployment, and hence container platforms need to ensure that their solutions indeed address all aspects of application management, like consolidation, data management, node failures, scaling out (add instances) and scaling up (add resources), etc.
Another aspect to stateful apps, is predictable performance. This directly relates to storage, and the IOPs delivered by the storage volumes per container. Most container orchestrators, either do not understand storage, or indirectly deal with it via storage plugins. Unfortunately, this arms-length approach gives you limited control over data and IOPS, and forces you to use expensive, and archaic SAN storage arrays.
Making the right container platform choice for stateful database applications
Based on the discussion so far, selecting a container platform that is right for stateful applications seems rather challenging. So to simplify the task, here is my checklist of features to look for in a modern application containerization platform:
|1.||Multiple Container formats||Support multiple container formats like docker, rkt, LxC, and even VM formats like VMware, KVM for special cases.
The application dictates the container format to use, not vice versa. Docker works for modern applications, while for traditional apps like Oracle, SAP, etc which require ssh access or the ability to do in-place patching, LxC is a better choice.
|2.||Application-awareness||For long, application administrators have dealt with servers, storage, virtual machines, network switches, etc.
The next generation platform should be about applications, and make infrastructure invisible. This includes all activities like provision, scale, backup, clone, failover, etc
|3.||Storage Volume Management||Provide in-built support for storage and volume management.This includes creation of multiple volumes per container, of different media types (SSD, HDD, Flash), with different levels of data protection, and also auto repair any disk failures.|
|4.||Snapshot, clone, time-travel||Storage vendors typically provide these capabilities at the volume level, but this still leaves a lot to be done for the application administrators.
A modern platform should take into consideration that an application is comprised of multiple containers, and each container can have multiple volumes, each of different type and size. Ability to snapshot, clone, restore should thus seamlessly work across the entire application.
|5.||Quality of Service (QoS)||Predictable performance is key for stateful applications. Especially, when you are trying to achieve higher levels of consolidation.
While containers give you process isolation, the modern platform should provide performance isolation – all the way across compute, network, and storage via mature QoS policies. QoS will allow you to run clusters with different load profiles and criticality all on the same infrastructure without impacting each other. Imagine running prod and test databases on the same server without impact. This is key to achieve consolidation goals.
|6.||As-is Auto Failover||Unlike stateless applications, a failed container cannot simply be replaced with another container with a different IP address and volumes. Each node in a stateful app is critical, and hence failover mechanism needs to ensure that a node, when recovered, has the same identity, data, and configuration.|
|7.||Networking||Network configuration is a vital function and can easily derail any application automation effort. Imagine having to contact your n/w admin for a static IP every time you deploy an app.
Modern platform should support features like default DNS, IP-per-container, multiple subnets, VLAN tags, etc. Without network automation, your container story will easily fall apart.
|8.||Multi-tenancy support||Unless you cluster deployment is localized to a single team, most enterprises would like to use the same platform across multiple divisions. This implies support for multiple user tenants and the ability to choose between hard (dedicated) and soft (shared) isolation of resources.|
|9.||Ease of Setup & Management||
Last but not the least, the modern platform should be easy to deploy, patch, upgrade, backup. A simple single binary that includes all required packages.
It should also provide resiliency and HA by default. You only add unnecessary complexity by deploying numerous unrelated packages, that follow their own update cycle.
The Robin differentiation
- How NoSQL databases like Cassandra can benefit from container technology
- If the current storage systems can support containerized databases
- How to alleviate data management challenges for large databases
- How Robin Containerization Platform can deliver bare-metal-like performance, while retaining all virtualization benefits