HCloud: Resource-Efficient Provisioning in Shared Cloud Systems【ASPLOS 2016】

好久没有写东西了，赶紧保持自己读论文的这个习惯。这篇文章是我开始读论文已来读的第二篇顶会文章，第一篇当然是PARD，这篇文章也是我第一次在组会上讲的文章（都已经是前年的事情了），当时的自己居然是用英文讲的。由记得当时是CC哥哥直接发给我的一篇文章，因为当时的自己连去哪里找文章还不知道，读了特别久还没明白这篇文章的意思，当然当时对整个背景还处于不了解的状态。

现在重读这篇文章，对于之前没懂的地方有了新的体会，看来一些文章还是要多读的。

这篇文章发表在ASPLOS 2016，也正是我刚来所里的那一年，出自于Christina Delimitrou，还是要多膜拜大佬~

云平台为用户提供了两大优势：灵活度和实惠的价格。用户不需要每次都花费时间来配环境，就可以很快的来运行一个作业，但是用户需要为运行的作业提供一些信息，就是要选择是使用reserved的资源还是on-demand的资源，reserved资源是针对于长时间运行的作业（一般是1-3年），并且为用户提供一致的服务，但是前期成本较高；on-demand是根据作业运行的需求来对其使用的资源进行动态的调整，用户仅为每个点使用的资源来付费，但是与reversed资源相比，每小时的成本要高出2-3倍，并且在获取新实例的时候会引入实例化开销。同时，用户还需要决定作业具体需要多少资源（实例的大小），虽然专用的机器可以提供更可预测的性能，但它们的成本很高，另外，较小的实例又容易受到外界的干扰，导致服务质量（QoS）无法预测。作者通过实验发现，单纯的fully reserved策略和fully on-demand策略在作业的性能方面和开销方面都并不理想，因此需要一种新的资源提供方式。

基于上述的背景，本文提出了一种使用reserved资源（long-term）和on-demand资源（short-term）的混合provisioning系统，混合供应策略可以利用reserved资源来实现长作业的稳定运行，以及针对短作业的on-demand资源来保证其对资源的需求。HCloud通过获得作业对于资源的偏好来决定将其调度到reserved资源上运行还是on-demand资源，并且决定需要多少资源来运行这个作业。

HCloud主要解决了两个挑战：

• 决定每个作业需要多少资源来保证其服务质量（QoS）
• 决定是将作业调度到reserved资源上还是on-demand资源上。

对于第一个挑战它使用资源管理系统Quasar[ASPLOS’14]来对新提交上来的作业进行资源偏好的估计和干扰敏感度的判断来提升provisioning的质量，一旦作业被调度到相应的实例上运行，就会对其性能进行实时监控并将性能指标和其期望的QoS相比较，当性能低于其设定的阈值，就会触发一些动作（由Quasar来做）。对于第二个挑战，它采用了一个应用mapping的策略来进行调整，如下图所示，首先是一个soft limit（60-65% utilization），在这个限制下，所有的应用都运行在reserved资源上，一旦利用率超过了这个限制，策略就会对作业进行判断，判断其对于性能不可预测性是敏感的还是不敏感的，然后根据target resource quality来判断是将这个作业重新调度到on-demand上运行还是reserved上运行；第二点就是hard limit，在这个点作业需要排队等待reserved资源，当利用率超过这个阈值之后，对于不敏感的应用，则将重新调度到on-demand资源上运行，对于敏感的应用则让其继续排队，此时有一个例外，如果作业的排队时间大于实例化一个大的instance（16 vCPUs）时间的话，则选择将其重新调度到一个大的实例上来运行。