Deterministic I/O and Resource Isolation for OS-level Virtualization In Server Computing

Docker container technology is applied to diverse computing domains such as datacenter, serverless, cloud, and highperformance computing thanks to its predictable development and efficient resource isolation [1,2]. Docker can isolate the execution of specific applications from running other applications as Sandbox [3]. Specifically, users can explicitly set a resource limit for each service by using control groups (cgroups) and namespace. Therefore, different services can be free from conflicting dependencies and resource contention. Since this consistent environment supports completely isolated tenants, it is used to improve computing utilization and portability [4,5]. For example, LEMP (Linux, Nginx, MySQL, & PHP) in the Google cloud platform can create multiple tenants per node, each running a separate web server (Nginx), fast CGI (PHP-FPM), and database (MySQL) [6]. While Docker is one of the best options to increase the computing utilization by sharing and/or isolating its resources, it does not yet well manage underlying storage [7]. Docker’s virtualized environment enables multiple container executions atop the host-side kernel directly, which is different from hardware stack virtualization of the conventional virtual machines (VMs) [8]. Because of this OS-level virtualization, launching a container is much faster and lighter than executing a VM [9]. However, the multiple containers and host kernel often share the persistent states on a solid-state drive (SSD), which can unfortunately interfere with their executions and I/O services of any peers at a device-level (Figure 1). As modern SSDs in practice exploit internal parallelism to enhance performance [10, 11], such interference introduces many storage resource conflicts, thereby degrading the performance. To manage the storage resource, ones may utilize proportional bandwidth of the blkio cgroup adopted by Docker [12] and assign different proportions to each of multiple containers, individually. However, this approach cannot address the interference issue for multi-container execution due to two root causes. First, even though the blkio cgroup throttles the target I/O queue with different proportions [13], the flash-level resource conflicts cannot be resolved as the host is unaware 0 30 60 90 120 0 400 80