Tuesday, December 2, 2014

ClusterHQ Flocker

Flocker does multi-host orchestration for Docker containers. It is intended mainly as a means for containerizing and orchestration distributed data stores and databases although in principle it can deploy any app. Unlike some of the other solutions out it, Flocker aims to support checkpointing of stateful and stateless containers to support migration of (running) containers across nodes. This seems like a great feature if one wanted to do work stealing rescheduling of containers as the execution profile changes and other nodes become available. Flocker provides its own NAT layer for mediating communication between containers across nodes. It also supports ZFS persistent volumes to maintain state. Flocker itself does not aim to do any particularly sophisticated scheduling (c.f. Kubernetes) but instead relies on the user to supply scheduling.

Monday, December 1, 2014

Kubernetes and Decking Container Cluster Managers

Fig. 1: Kubernetes Architecture

Kubernetes manages user-defined collections of containers called pods. Note that "pod" refers to the running container and not a static image (in Docker terminology). Besides containers, a pod can also have persistent storage attached as a volume and also define custom container health checks. Pods themselves can be organized together into "groups", a kind of "API object", which in turn can be referenced by label. There are two other main forms of API objects: replication controllers and services. The former produces a fixed number of replicas of a pod template. The latter defines internal and external ports for establishing connectivity across pods.

Sunday, November 30, 2014

Top 5 Container Cluster Managers: Containers and Cloud Management

photo by OneEighteen via PhotoRee

The rapid ascent of containers is nothing less than breathtaking. In the space of a year and a half, Docker has went from initial release to being adopted by every major IaaS cloud host (Google, Amazon, Microsoft, Rackspace's On-Metal CoreOS), VM software vendor, and a few toolchain developers. As a point of reference, VMWare ESX took over 5 years before ever getting near such market penetration. It is interesting to consider at this point what the management tool options are for containers and clusters/networks of containers. There are two main categories of use cases for Docker: devops (e.g., continuous integration) and virtualization infrastructure (e.g., improve utilization of server resources using lightweight containers in place of hypervisor-based virtualization).

This is a series of evaluations of container cluster managers: Part 2 (Kubernetes and Decking) and Part 3 (Flocker).

Saturday, November 29, 2014

Parallel Data Types

True parallelism can be achieved via a wide variety of avenues. Instruction-level parallelism arguably offered a huge value at one point when processor architectures bulked up to execute machine instructions in parallel whenever possible including when instructions can be reordered or delay slots can be filled. All this could have been done without an application programmer's involvement or knowledge, hence it promised the benefits of parallelism for most programs out-of-the-box without modifications. The onus, instead, was on the processor architects and compiler developers to take advantage of such parallelism, which sometimes turned out to be a tall order. Task parallelism, in contrast, typically demands a lot more from application programmers since exposing and taking advantage of parallelism becomes very domain-specific. The focus of parallelism for task parallelism depends on balancing the loads of execution threads. Runtime support can help fill in the gaps here by applying advanced scheduling techniques such as work stealing, but ultimately what constitutes a thread (i.e., how to partition the program) and how to mediate communication and sharing between threads is often up to the programmer. Another way to achieve parallelism at a fine-grain level is to implement and expose a parallel data type in a language, runtime, or distributed computing framework. Apache Spark achieves this using its RDD (Resilient Distributed Dataset) abstraction which can copy data from Scala Seq, Java Collection, and Python iterables. Hadoop uses Java Iterable for MapReduce. For modern distributed computing environments, the pipeline itself might be any DAG (more general than map-reduce), but ultimately parallelism stems from the data representation, hence data parallelism. Note that of all the forms of parallelism it is data parallelism that ultimately has demonstrated straightforward and efficient scaling to truly large problems.