【论文】略读笔记79-前沿-存算分离集群、跨地域集群调度

📖《Adaptive QoS-Aware Microservice Deployment With Excessive Loads via Intra- and Inter-Datacenter Scheduling》

2024 年 上海交大团队 发表于 CCF-A 类期刊 TPDS。

🎯需求

• 面向用户的应用程序经常会遇到过多的负载，并正在转向微服务架构。
  • 具有严格服务质量 (QoS) 要求的面向用户的应用程序部署在数据中心上，以获得高性能和可扩展性。
• 为了充分利用异构资源，当前的数据中心采用了分散的存储和计算架构，其中存储和计算集群分别适合部署有状态和无状态微服务。
  • 虽然流行的互联网服务提供商和云提供商经常在不同的地理区域构建多个数据中心，但应用程序通常部署在靠近最终用户的数据中心上，以缩短响应延迟。
  • 在数据中心内部，当前许多云提供商都采用了分散的存储和计算架构，其中存储集群具有更高的数据处理能力，而计算集群具有更好的计算性能。应用程序的IO密集型操作通常部署在存储集群上，而其他计算密集型操作通常部署在计算集群上。
• 此外，当本地数据中心没有足够的资源来承载过多的负载时，合理的解决方案是将部分微服务迁移到远程数据中心。
  • 对于面向用户的应用程序，除了常规的昼夜负载模式（除高峰时段外负载较低）之外，偶尔可能会发生不可预测的极高用户查询负载。例如，在线购物节期间电子商务服务会出现过多查询，突发新闻发生时社交网络服务会出现过多查询。某一区域的数据中心的计算能力通常可能无法满足过多的查询负载，并且面向用户的应用程序通常会遇到严重的服务质量违规。
  • 在托管数据中心添加更多服务器可以解决过多的服务负载。然而，这种方法对于偶尔出现的超负荷情况会显着增加运行成本。
  • 另一个解决方案是利用远程数据中心来提供所需的计算能力。特别是，许多面向用户的应用程序已经从单体软件架构转向微服务架构。在微服务架构中开发，通过连接许多解耦的微服务来实现复杂的应用程序，这些微服务可以独立部署并通过网络相互交互。仅在远程数据中心部署必要的微服务会更加节省资源。

🚧现状

• 然而，在本地数据中心内决定适当的微服务部署并确定向远程数据中心的适当迁移决策并非易事，因为微服务表现出不同的特征，并且本地数据中心表现出不同的资源争用情况。
  • 微服务分为有状态（例如磁盘或内存数据库）和无状态（例如推荐业务）微服务，并且需要部署在本地数据中心分解架构下的存储或计算集群上。
    • 一方面，有状态微服务适合部署在存储集群上。
      • 磁盘数据库（如mongodb）需要固定在存储数据的存储集群上。
      • 对于内存数据库（例如，redis），由于内存中的数据更新或卸载数据的请求，它们必须在运行时频繁地与磁盘数据库同步数据。因此，它们需要与磁盘数据库部署在同一集群上，以避免较高的数据通信开销。此外，由于在运行时更改内存数据库部署时可能会产生大量内存副本，因此需要修复它们的部署以避免损害应用程序的 QoS。因此，将内存数据库固定在存储集群上是有好处的。
    • 另一方面，无状态微服务可以部署在两个集群上，但更适合部署在计算集群上，因为它们大多数都是计算密集型的。部署在计算和存储集群上的微服务通过局域网（LAN）相互通信，会消耗相当大的网络带宽，甚至可能在负载过大时造成网络带宽瓶颈。通过在存储集群上部署一些无状态微服务，可以节省计算和存储集群之间的带宽使用。
      
• 图 1 显示了使用本地和远程数据中心来支持基于微服务的面向用户的应用程序的过度负载的示例。据观察，高效的数据中心内和数据中心间调度需要：
  • 1） 最好地管理本地数据中心的有限资源，
  • 2） 在本地数据中心内的存储和计算集群之间正确部署微服务，
  • 3） 识别要迁移的适当微服务
  • 4） 最大限度地减少远程数据中心的资源使用。
• 之前有一些关于管理微服务资源分配的工作，以确保具有每日负载模式的面向用户的应用程序的 QoS。然而，他们忽略了本地数据中心的分解存储和计算架构，并假设本地数据中心具有足够的计算资源用于面向用户的应用程序。而且，他们没有考虑数据中心之间的公共网络状况，只是简单地使用Kubernetes来放置微服务。
• 与传统数据中心内部的调度相比，在分解存储和计算架构下的数据中心内部以及跨数据中心的微服务调度需要解决三个新的挑战。
  • 1）首先，当分配相同数量的资源（CPU 时间、内存等）或部署在不同集群上时，微服务会表现出不同的性能（延迟和吞吐量）。
  • 2）其次，分散的存储和计算架构导致大量的本地网络带宽消耗。结合微服务之间，尤其是有状态和无状态之间频繁的数据通信，一种方法是将部分微服务部署到存储集群中，同时满足其资源需求。
  • 3）第三，数据中心之间公网的带宽和延迟比数据中心内部的要差。数据中心之间的微服务放置很重要，因为通过公共网络进行的大量数据通信可能会损害服务的 QoS。

🛩创新

• 因此，我们提出了 ELIS，这是一种数据中心内和数据中心间的调度系统，可确保微服务应用程序的服务质量 (QoS)，同时最大限度地减少网络带宽使用和计算资源使用。

• ELIS 由资源管理器、跨集群微服务部署器和基于奖励的微服务迁移器组成。

  • 1）资源管理器： 为微服务分配近乎最优的资源，同时保证 QoS。
    • 对于要部署的微服务应用程序，微服务最初部署在本地数据中心。随着负载的变化，资源管理器根据微服务的性能状况确定微服务的资源调整顺序，并使用贝叶斯优化（BO）算法来最小化资源使用。
  • 2）微服务部署器： 在本地数据中心的存储和计算集群之间部署微服务，在满足微服务资源需求的同时最大限度地减少网络带宽的使用。
    • 微服务部署器通过集群算法调整存储集群和计算集群之间微服务的部署，在满足各个微服务的资源需求的同时，最小化本地网络带宽的使用。
    • 资源管理器和微服务部署器共同使本地数据中心支持最高负载。
  • 3）微服务迁移器： 当本地资源无法承受过多负载时，会将部分微服务迁移到远程数据中心。
    • 迁移器在保证QoS和吞吐量目标的同时，最大限度地减少公共网络带宽使用和远程资源使用。

• 主要贡献如下：

  • 1）对具有分解存储和计算架构的数据中心内以及跨数据中心的微服务部署进行全面分析。此分析有助于解决设计数据中心内和数据中心间微服务调度系统的挑战。
  • 2）本地数据中心基于BO的资源管理策略设计。该策略从某些微服务中回收资源，并将其重新分配给容易导致 QoS 违规的微服务。它最大限度地提高了本地数据中心所支持的峰值负载。
  • 3）设计一种在存储和计算集群之间部署微服务的方法。我们提出了基于集群的方法来确定微服务部署，以最大限度地减少本地数据中心的存储和计算集群之间的本地网络带宽使用。
  • 4）设计一种搜索待迁移微服务的方法。我们确定了两个准则，通过它们可以确定要迁移的微服务，这些微服务在负载过大时可以最大程度地减少网络带宽使用和尾部延迟。

📊效果

• 实验结果表明，ELIS保证了面向用户的应用程序的QoS。同时，公网带宽占用、远程计算资源占用和本地网络带宽占用平均分别减少49.6%、48.5%和60.7%。

🧠疑问

1. 是很规范的写作方式，非常清晰。
2. 三个挑战带来的难点不够突出，感觉只要简单考虑一下就能解决，没看到简单贪心算法无法解决的“矛盾点”。未来自己撰写挑战时也需要注意这个问题。
3. 本文最大的特点可能是“引入集群内计算存储分离架构”，但说服力似乎有些待商榷，来源是 AWS的 EBS 产品、Azure 的 blob storage 产品和 Facebook 的博客:[P. Kestutis and J. Amisha, “Facebook’s disaggregated storage and compute for map/reduce,” 2016.]
4. 迁移过程中对请求的影响似乎没有考虑。
5. 没有测试算法执行时间，实验中仅面向8台服务器执行了真实实验，“在多大规模下能达到多少效率”是一个问题。

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手给我一个follow或star。

🗺参考文献

[1] J. Shi, K. Fu, J. Wang, Q. Chen, D. Zeng and M. Guo, “Adaptive QoS-Aware Microservice Deployment With Excessive Loads via Intra- and Inter-Datacenter Scheduling,” in IEEE Transactions on Parallel and Distributed Systems, vol. 35, no. 9, pp. 1565-1582, Sept. 2024, doi: 10.1109/TPDS.2024.3425931.