Elastic Clusters and Container Pools

A core tenet of enterprise-ready infrastructure is multi-tenancy. What’s multi-tenancy? Let’s take an example. You are managing two clusters of physical machines for three departments: HR, Finance and Developers.

admin1

These are their requirements

Department Application Requirements
HR Wiki Medium non-transactional load
Finance Database High transactional load
Persistent storage
Only DBA user can manage the container
Dev Custom build and tests High load
Stateless
API driven container orchestration

How can you meet these requirements?

Multi-tenant container infrastructure

This translates to an enterprise-ready container infrastructure that can support

  1. Isolation. HR, Finance and Devs need to co-exist, while their apps are isolated. Finance also has an additional requirement of running a production stateful database.
  2. Elasticity. You have to be able to add resources to the infrastructure without needing to reallocate resources.
  3. Security. Authentication and authorization for different users
  4. Self-service. Developers should be able to directly orchestrate containers using docker APIs.

We take these features for granted in VM infrastructure (often powered by VMware’s vSphere), but today’s container infrastructure platforms (still in their infancy) are sorely lacking in these areas.

Enter ContainerX!

We solve these challenges by providing simple but powerful constructs called Elastic Clusters and Container Pools. Elastic clusters allow you to build clusters of container hosts on any type of infrastructure (on-premise and cloud) for both Linux and Windows environments. Container pools allow you to slice those resources into multi-tenant virtual clusters, while allowing strong isolation. If you are familiar with vSphere DRS, we bring the concept of DRS clusters and resource pools to the world of containers.

Elastic clusters

Elastic cluster (EC) is a collection of hosts, which are either bare-metal physical machines or VMs (on-prem vSphere or public cloud). Irrespective of their location, ECs allow admins to aggregate resources and group them as one giant host which resizes itself automatically. ContainerX automatically monitors the usage of EC and adds hosts (supported only for VM based infrastructures) to meet increasing demand. Root admins can delegate EC administration to a specific user.

admin2

Container Pools

Once the cluster is created, an IT admin can slice the resources into any number of container pools. A container pool looks like a docker host for users and can be accessed with docker APIs. The cool part about pools is that they allow over-commitment. For each pool, admin can set a limit and priority.

  • Limits provide a cap on the amount of resources that can be consumed by the pool. For example, a 30% limit on a pool created on top of a cluster with 3 hosts makes sure that the containers in the pool cannot exceed one hosts worth of resources
  • Priorities allow a way of prioritizing across pools, when they contend for resources.

Let’s get back to our earlier example.

admin3

You can meet all the requirements (shown in bold font) mentioned above by

  1. Creating an elastic cluster aggregating all the hosts in both clusters. CX will automatically add and remove resources as required. (Elasticity)
  2. Creating three pools: HR_Pool, Finance_Pool and Dev_Pool (Isolation)
  3. Since HR and Finance apps are production apps, set limits for HR_Pool and Finance_Pool to 50% to make sure that under resource contention each pool’s usage cannot exceed 50% (of the cluster’s total resource) to inadvertently throttle the other pool’s resource usage.
  4. Set Dev_Pool’s limit to 30% thereby over-committing CPU resources. We also set Dev_Pool’s priority to ‘low’ so that in the presence of contention, HR and Finance will get a higher proportion of available resources.
  5. Since Finance runs a database, set their priority to high.
  6. Devs can access the pool through any docker API thus allowing them to do self-service and build automation. (Self-service)
  7. When a dev logs in to ContainerX console, they can only see the pools that they are authorized for. They can download credentials to access their pool and start accessing the pool as if like it were a Docker host. (Security)

We will be covering more details about elastic clusters and container pools in the next few blog posts highlighting specific use-cases, infrastructure providers and applications.

Want to try elastic clusters and container pools? Sign up for our beta!

3 Comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s