论文阅读 Application Oriented Dynamic Resource Allocation for Data Centers Using Docker Containers

Abstract

Docker提供了一个进一步提高数据中心(DCs)效率的机会。然而，现有的模型和方案不能有效地用于基于Docker容器的资源分配。我们设计了一个新的基于应用程序的Docker容器(AODC)资源分配框架，以最小化DCs中的应用程序部署成本，并支持云应用程序工作负载变化时的自动扩展。然后，我们考虑Docker的特性、各种应用的需求以及云数据中心的可用资源，对AODC资源分配问题进行建模，提出了一种适用于分布式控制系统的可伸缩算法，该算法具有多样化、动态性的应用和海量的物理资源

1. INTRODUCTION

为了节约成本，提高资源使用效率，数据中心(DCs)中的资源分配和管理得到了广泛的研究。对于部署在多层结构中的应用程序，单个计算作业由一个中央管理器划分为多个任务，每个任务分配给一个工作节点。虽然工作负载会发生变化，但是通过调整分配给每个任务[1]的物理资源数量，可以很容易地进行扩展。对于复杂的应用程序，如游戏托管、视频会议等，在应用程序级别将资源分配为基于Hypervisor的虚拟机[2]、[3]。随着工作负载的变化，分配给应用程序的资源可以自动地从水平方向扩展，即，增加更多的VMs[4]，和垂直方向，将更多资源分配给已部署的vm[5]。然而，水平扩展可能需要几十秒来部署vm或唤醒物理机器(PM)，而垂直扩展则需要主机操作系统(OS)和客户OS的额外支持。功率管理技术，例如动态电压频率缩放(DVFS)，已经被用于在各种云环境[6]、[7]中提高能效，但可能会降低性能并增加延迟。
作为基于虚拟机监控程序的vm的替代方案，Linux容器[8]提供了优越的系统效率和隔离性。由于其重量轻，容器可以迅速部署和迅速迁移到不同的PMs之间。与基于Hypervisor的vm相比，使用容器部署应用程序有三个主要区别:1)不需要指定容器的数量及其容量，而是根据可用的物理资源和动态应用程序的工作负载进行自适应调整。2)利用最近发明的容器管理工具Docker[9]，可以分层复用操作系统和应用程序的支持库，提高容器的内存效率。3)考虑到库的重用，同一容器在不同PMs上的部署成本可能不同。尽管有几个文章[10]，[11]关注的是基于容器的云中的资源分配，但是他们没有考虑容器的特性。介绍了一种基于面向应用的Docker容器(AODC)资源在DCs中的分配框架，并结合容器和Docker的特点将AODC资源分配问题转化为一个优化问题。AODC框架和模型的新特性可以概括为以下几点:1)容器的数量和容量是根据应用程序的需求和可用的PMs资源自适应地确定的。2)容器部署成本与PMs上可用的支持库和应用程序所需的库相关。3)资源管理与应用执行功能解耦，资源管理以分布式方式执行。据我们所知，我们是第一个使用Docker容器研究资源分配机制的。针对AODC优化问题，提出了一种通信效率高、可扩展的算法。通过实例验证了该框架和算法的有效性。

2. APPLICATION ORIENTED RESOURCE ALLOCATION

为了有效地部署具有多样化需求和不同工作负载的网络应用程序，我们引入了一个基于AODC的资源分配框架，包括一个新的调度器和两种容器，即托盘容器(PCs)和执行容器(ECs)，它将资源管理和任务执行从各个应用程序中分离出来。与基于虚拟机监控程序的VM布局不同，ECs的数量及其对物理资源的需求不仅由应用程序的工作负载动态决定，而且由DC中的可用资源动态决定。

图1(a)说明了AODC框架的概述。在部署应用程序时，将资源作为一组分布在多个PMs上的容器分配给应用程序。特别是，每个应用程序都有一个PC和至少一个EC。PC做出资源分配决策，为ECs请求资源，跟踪ECs上的任务状态，管理ECs的生命周期，完成分配的任务，并向PC报告任务执行状态与预期进度的对比。

pc和ECs都嵌入到PMs中。图1(b)描述了PM中的主要组件。在这里，每个PM都有一个操作系统，Docker在这个操作系统上运行一个引擎来维护容器的操作环境，帮助嵌入容器，并隔离在同一个PM上运行的容器。在Docker引擎中，我们引入了一个新的调度程序来管理pc的生命周期。当激活一个应用程序时，调度器会根据应用程序的需求和PM上可用的资源来重新计算PC并分配资源。此外，Docker引擎允许多个执行容器共享操作系统内核和公共库，因此聚合共享一些公共库的应用程序可以通过减少冗余进一步节省成本。

我们在图1©中演示了在DC中部署应用程序的工作流。当应用程序请求到达时(步骤(1-2))，此应用程序的调度器启动PC并为PC分配物理资源(步骤(3))。PC机分析应用程序的需求，使用AODC算法进行资源分配决策，并根据决策在PM B上请求资源(步骤(4))。AODC算法在第三节中讨论。如果在PM B上的调度器已经批准了请求，就会提供资源并创建一个EC(步骤(5-6))。之后，根据资源分配决策将任务分配给EC。PC可以根据资源分配决策重复步骤(4-6)来创建多个ECs。创建的ECs在分配的任务上工作，并将任务执行状态更新到PC上(步骤(7))。PC机可以根据应用程序的实时工作负载动态调整ECs的数量、位置和分配的资源。当应用程序被停用时，PC被终止，它的资源被调度程序收集。

使用这个框架，为每个应用程序分配的物理资源可以根据应用程序的需求、实时工作负载和DC中的可用资源动态地收缩或扩展。为了进一步降低在框架中部署应用程序的成本，我们将基于AODC的资源分配建模为一个优化问题，并开发了一个可伸缩的算法来解决这个问题

3. SYSTEM MODEL AND ALGORITHM

我们将基于AODC的资源分配问题建模为一个优化问题，目的是在满足QoS要求的同时最小化应用程序部署成本。考虑到可扩展性，我们设计了一个分布式的AODC算法，由pc机调用，逐步搜索合适的PMs，并做出资源分配的决策。

A. System Model

我们考虑一个物理网络G(N p)，它有一个PMs的集合N p。每个PM j∈Np都具有有限的物理资源。c pj表示PM j上的剩余资源。这里，我们以计算资源为例，对资源分配问题进行建模。我们假设这些PMs在容量和价格上是相同的。但是，PMs可能会预先安装不同的库来支持不同的应用程序。

我们将每个应用程序作业Ai作为一个元组(wi, Ti,αi Fi)。wi是工作Ai的workload。我们将wi量化为单位时间量，即一个单位计算资源可以完成任务的时间量。Ti指定完成作业Ai允许的最大服务延迟。作业可以分为多个小任务，这些小任务在不同的ECs上并行执行。假设所有服务于作业Ai的ECs同时启动和终止，至少需要单位Ti的计算资源来保证服务延迟约束Ti。同时，任务不能小于原子操作。使用αi表示Ai的总负载工作的一个原子操作的工作量,每个任务应该比wi·αi。Fi表示PC和所有ECs之间的预期内部流量总量。在此应用程序的调度程序启动PC后，将确定此PC的PM嵌入。我们将这样的PM表示为Ii。

给定一个物理网络G和一组应用程序{Ai|i∈{1，…，我们要确定ECs的数量和位置，以及分配给每个EC的任务量，从而使应用程序的总成本最小化。AODC框架中应用程序的成本主要来自于节点成本U(node-i)和链路成本U（link-i)。具体来说，U(node-i)包括ECs的部署成本和执行成本，而U(link-i)量化了PC和ECs之间的通信成本。

我们遵循广泛接受的能耗模型[3]，[12]来估算一个PM j的成本，包括基线成本Ps和运行成本Po。这里，我们假设操作成本与分配给PM j的工作负载成比例。为了节省能源成本，我们利用支持睡眠/清醒模式的PM，并且假设在睡眠模式下没有PM的基线成本。除了基本成本和运作成本外，部署 EC会为安装和配置应用程式的支援程式库带来额外的成本。除了基线成本和操作成本外，部署一个执行容器可能会为安装和配置应用程序的支持库带来额外的Pd成本。

考虑PM的休眠/唤醒状态和可用的库，我们将节点成本Unode建模为唤醒不活动PM的成本、安装支持库的成本和执行分配任务的成本的总和，如Eq.(1)所示。

这里，sj表示PM j的睡眠/清醒状态。如果PM j处于睡眠模式，则sj设置为1，否则为0。c(b-ij)是在PM j上部署作业Ai的EC的附加库的数量。pij是分配给PM j的作业Ai的部分，wi是作业Ai的总工作量。我们使用一个二进制变量xij来表示EC的位置。如果工作Ai的EC被放置在PM j上，则xij = 1，否则为0。目前认为PMs的电压和频率是固定的。在未来，我们将考虑动态电压和频率进一步节能，如[6]。
链路成本U(link-i)描述PC和ECs之间的数据交换成本，它与所考虑的技术高度相关。在这里，我们考虑的是对底层技术没有任何假设的一般情况。我们进一步假设PC和ECs之间的流量是不可分割的，并且总是通过最短路径来简化。然后，将链路成本建模为路径长度与两个容器之间的期望流量量的乘积:

这里，表示PM嵌入job Ai的PC。lIi j是PM Ii和PM j之间最短路径的长度。注意lIi j是已知的，因为PM Ii是在job Ai到达某个DC时确定的。我们不考虑链路失效和重新配置，所以lI j对于job Ai和PM j, j∈Np是固定的。fij表示通过该路径的流量，我们假设fij = Fi·pij。因此，流量较大的ECs最好嵌入在PC附近。
为了使部署一组M应用程序的总成本最小化，同时考虑节点成本和链路成本，我们有

同时满足一组约束条件:

约束(4)确保分配的资源不会超过PM j上的可用资源。约束(5)确保作业的每个部分都已分配。约束(6)检查作业的每个部分的下界和上界。约束(7)建立变量之间的关系。

B. Algorithm

我们设计了一个基于AODC的资源分配算法来计算ECs布置和任务分配的可行解。AODC算法以分布式方式在每台PC上独立运行，从数量有限的Docker引擎获取资源状态，并进行资源分配决策。对于每台PC, AODC资源分配问题变成如下优化问题:

受限于：

如算法1所示，PC开始在一个小的本地区域内查询可用的物理资源，例如，一个机架(步骤(1))。基于Docker引擎报告的每个PM的可用资源，可以采用线性规划求解器(如CPLEX)来解决AODC优化问题(步骤(2))。然后，PC根据优化问题的解决方案(步骤(4))请求物理资源。如果请求被批准，则在选定的PM上构建一个EC，并将PM标记为已使用(步骤(6-7))。如果请求被拒绝，这个PM将被标记为不可行的，并且分配的任务将被移动到setu(步骤(9))。当优化问题没有可行的解决方案，或者某项任务没有成功分配时，PC会大规模查询PMs，例如a pod，对于未分配的任务重新求解优化问题(步骤(13-15))。

注意，每个PM最多被PC查询一次，如果当前搜索区域有足够的可用资源，那么每个PC不需要查询物理网络中的每个PM。因此，AODC算法在大规模物理网络中具有良好的通信效率和可扩展性。

4. EVALUATIONS

我们比较AODC资源分配算法的性能与VM位置通过最大化策略的最优解(Optimal-VM),贪婪的最佳适应算法VM位置(最好Fit-VM),和贪婪最适合虚拟机放置(Fit-VM最差)的算法,对总能量成本和使用各种参数设置的接受率。
我们在[3]中使用相同的设置。每个PM的状态被随机设置为awake，概率为0.8。每个作业的工作量随机设置在[50,80]之间，内部流量总量随机设置在[5,20]之间。此外，我们将每个PM和每个应用程序的类型随机设置为[0,5]之间的整数。类型隐式地确定在不同PMs上安装和配置支持库的成本。具体来说，部署应用程序所需的附加库的数量被量化为PM类型与应用程序类型之间的差异，而每个库的平均大小被设置为25 MB, VM的大小被设置为100 MB。
我们首先将pm的数量从60调整为140，而vm的数量则固定为10。在图2中，AODC在接受率和总成本方面优于所有VM布局算法。当只有少量PMs可用时，VM放置算法不太可能找到有足够资源的PMs，以满足对资源有固定需求的VM，而AODC可以根据可用资源自适应地调整容器大小。在图3中，我们还研究了vm数量在5到20之间变化时的影响。在四种算法中，AODC以最小的总成本获得最佳的接收比。

5. CONCLUSION

针对突发Docker容器的特点，设计了面向应用的动态资源分配框架，提出了一种通信效率高、可扩展的资源分配算法，使受容量和服务延迟约束的应用部署成本最小化。仿真结果表明，所提出的AODC资源分配框架和算法在接受率和总成本方面都优于现有的基于虚拟机监控程序的虚拟机布局方法。

REFERENCES

[1] Z. Liu, Q. Zhang, M. F. Zhani, R. Boutaba, Y. Liu, and Z. Gong, “DREAMS: Dynamic resource allocation for MapReduce with data skew,” in Proc. Int. Symp. Integr. Netw. Manage., May 2015, pp. 18–26.
[2] Z. Xiao, W. Song, and Q. Chen, “Dynamic resource allocation using vir- tual machines for cloud computing environment,” IEEE Trans. Parallel Distrib. Syst., vol. 24, no. 6, pp. 1107–1117, Jun. 2013.
[3] X. Guan, B.-Y. Choi, and S. Song, “Energy efficient virtual network embedding for green data centers using data center topology and future migration,” Comput. Commun., vol. 69, pp. 50–59, Sep. 2015.
[4] J. Jiang, J. Lu, G. Zhang, and G. Long, “Optimal cloud resource auto- scaling for Web applications,” in Proc. Int. Symp. Cluster, Cloud Grid Comput. (CCGrid), May 2013, pp. 58–65.
[5] X. Shi, J. Dong, S. Djouadi, Y. Feng, X. Ma, and Y. Wang, “PAPMSC: Power-aware performance management approach for virtualized Web servers via stochastic control,” J. Grid Comput., vol. 14, no. 1, pp. 171–191, Mar. 2016.
[6] E. Baccarelli, D. Amendola, and N. Cordeschi, “Cover image minimum- energy bandwidth management for QoS live migration of virtual machines,” Comput. Netw., vol. 93, pp. 1–22, Dec. 2015.
[7] M. Shojafar, N. Cordeschi, and E. Baccarelli, “Energy-efficient adaptive resource management for real-time vehicular cloud services,” IEEE Trans. Cloud Comput., vol. PP, no. 99, p. 1, preprint, doi: 10.1109/TCC.2016.2551747.
[8] S. Soltesz, H. Pötzl, M. E. Fiuczynski, A. Bavier, and L. Peterson, “Container-based operating system virtualization: A scalable, high- performance alternative to hypervisors,” ACM SIGOPS Oper. Syst. Rev., vol. 41, no. 3, pp. 275–287, Jun. 2007.
[9] Docker, accessed on Dec. 31, 2016. [Online]. Available: https://www.docker.com/
[10] A. P. M. de la Fuente Vigliotti and D. M. Batista, “Energy-efficient virtual machines placement,” in Proc. Brazilian Symp. Comput. Netw. Distrib. Syst. (SBRC), May 2014, pp. 1–8.
[11] X. Xu, H. Yu, and X. Pei, “A novel resource scheduling approach in container based clouds,” in Proc. 17th Int. Conf. Comput. Sci. Eng. (CSE), Dec. 2014, pp. 257–264.
[12] X. Chen, C. Li, and Y. Jiang, “Optimization model and algorithm for energy efficient virtual node embedding,” IEEE Commun. Lett., vol. 19, no. 8, pp. 1327–1330, Aug. 2015.