| dc.description.abstract | Hardware virtualization fulfills users’ computing demands by providing users software compute instances namely virtual machines, which emulate how physical machines work. It is widely used in various computing platforms in the cloud era due to its manageability, flexibility and elasticity. In recent years, a similar light-weight technology, usually called OS containerization (or OS-level virtualization), has gradually become a hot issue in IT industry. The OS containerization technology provides a logical compute instance, known as the software container, as the fundamental compute unit to host applications or services. A software container is emulated by the host OS. Therefore, it has light-weight overheads in terms of instance creation/deletion time and consumed memory space, when compared with hardware virtualization. Docker is one of the popular open-source projects for OS containerization. It allows people to create and to manage software containers on a host OS. Docker Swarm is another open-source project for building a compute pool of Docker containers. Based on our study, Docker Swarm does not well support the high availability (HA) feature for its Docker containers in the current version. For example, the failover mechanism of Docker Swarm cannot handle failures on linked containers, which can be viewed as a virtual container cluster where each member can directly or indirectly communicate with each other. To this end, this research focuses on the HA issue of Docker Swarm. In this paper, we present a light-weight HA architecture as well as its implementation based on Docker Swarm. The HA architecture uses shared Docker volume to prevent data loss. It also uses Docker overlay networks to enable communication among software containers on different hosts. We also implement a light-weight monitoring mechanism to detect whether a software container fails, as well as a recovery mechanism to recover a failed software container in a second. With the proposed mechanisms, we can reduce the downtime of any failed software container on Docker Swarm, and improve the ability of the applications/services running on the software containers consequently. | en_US |