【论文】略读笔记36-前沿-弹性资源调配实现实时请求更新

📖《TRUST: Real-Time Request Updating with Elastic Resource Provisioning in Clouds》

🎯需求

• 在商业云中，服务提供商（例如，视频流服务提供商）从云供应商（例如Google Cloud Platform）租用资源并向云用户提供服务，从而从价格差距中获利。云用户通过将请求转发到相应的服务器来获取服务。
  • 云主要有三种角色：云供应商、服务提供商和云用户。
    • 云供应商（例如 Amazon Web Services 和 Google Cloud Platform）负责构建和维护物理服务器。他们将一定数量的 VM/容器租给每个服务提供商。
    • 然后，服务提供商可以实现他们的服务，如安全、存储、审计等，也称为网络功能 （NF） 实例。
    • 云用户可以根据自己的需求购买服务，从而将他们的请求调度到相应的NF。
  • 例如，VPN 服务提供商从云供应商处租用多个 VM 来实现 VPN 功能。然后，云用户可以从服务提供商处购买VPN服务，并通过将流量转发到相应的VPN来获取服务。
• 在实践中，作为常见场景，流量动态会导致服务器过载或负载不平衡。
  • 在大规模的多租户云中，流量巨大，流量动态是一个长期存在的问题，导致NF之间的负载不均衡甚至过载，这将严重影响业务可用性和执行效率。因此，它会降低用户的 QoS。

🚧现状

• 现有工作主要通过请求更新和弹性资源配置两种方式来处理该问题。
  • 虽然请求更新是一个免费的解决方案，但它会导致严重的延迟，导致用户的 QoS 不佳。为了处理云中的流量动态并改善 QoS，请求更新已被广泛采用，这意味着将请求转移到另一个可用的 NF。现有工作通常为NF负载均衡或最小化makespan设计请求更新方案。
    • 例如，提出了一种分布式请求调度机制，以便通过公平分配来自边缘交换机的流量来实现数据中心服务器之间的负载均衡；
    • 通过基于免疫的粒子群优化算法找到在截止日期约束下降低云资源成本的最优解决方案。
  • 尽管许多工作已经设计了合理的请求更新方案来处理流量动态，但请求更新存在三个基本缺点。
    1. 首先，控制器容量有限。控制器的处理速度取决于不同的因素，例如控制器的类型和控制器的位置。
    • 例如，根据测试结果，在网络拓扑由 81 台交换机组成的网络拓扑结构下，发送 1000 条流模消息以重新路由流需要 71.2ms。
    • 作为比较，相关文献还测试了更新延迟，并表明ONOS每秒可以处理40K的flow-mod消息，拓扑结构由32个交换机组成。
    • 对于相同的拓扑结构，另一篇相关文献还证明了OpenDayLight（也是SDN中使用的主流控制器）每秒只能处理0.3K的flow-mod消息。
    • 因此，生成大量用于请求更新的新规则将大大增加控制器的响应时间，使控制器成为网络的瓶颈。因此，控制器可能会拥塞并阻止新的到达请求，从而导致用户体验下降。
    2. 其次，请求更新涉及交换机上的延迟。
    • 相关研究指出，发送更新消息和更新交换机上的相应条目之间的持续时间可能为数十毫秒。由于过时的条目，交换机上的延迟将导致流的错误操作。
    3. 最后，更新请求时存在状态不一致问题。
    • 相关研究揭示了每个交换机上的更新延迟是异构的，异步更新操作会导致规则更新的部分执行，从而导致网络状态不一致。在瞬态循环中发送数据包、增加链路负载或绕过重要的航点（如流分类器）时，可以观察到这种不一致。
    • 此外，由于 NF 需要记录已处理请求的状态，因此请求更新将带来额外的延迟和开销，以保持 NF 上请求的状态一致性。
  • 由于这三个缺点，请求更新很难保证用户在大规模云中的QoS，迫切需要替代解决方案作为补充方法。
  • 弹性资源配置是一种快速敏捷的解决方案，但由于服务提供商需要从云供应商处购买额外的资源，因此成本可能太高。
    • 通过启用虚拟化技术，弹性资源配置已成为处理云中流量动态的新趋势。弹性资源配置意味着系统可以添加或删除资源（如CPU内核、内存、虚拟机或容器实例），以实时适应负载变化。
    • 在实践中，云供应商通常会提供几种与固定资源组合相关的合适配置类型，每个NF将选择一种资源配置类型来满足云用户的请求。
      • 例如，在 Google Cloud Platform （GCP）中，具有 4 个 CPU 内核和 15 GB 内存的虚拟机的价格为 每月 97。
    • 之前关于弹性资源供应的研究主要集中在如何提高网络性能、增加资源容量或节能上。
      • 例如，相关研究中的作者提供了多个同时 Web 应用程序方法的自动部署和主动扩展，以提高基础设施性能，这些方法已部署在 Amazon Elastic Compute Cloud 中。
• 弹性资源配置的思想在解决流量动态问题方面具有很好的希望。与请求更新解决方案相比，调整虚拟机/容器的大小只需要几十毫秒，无需担心请求状态一致性的问题。因此，可以保证用户的QoS。但是，这将增加服务提供商的成本，因为他们应该向云供应商支付更多额外的资源。
• 相比之下，使用请求更新方式，服务商无需支付额外的费用，但由于更新延迟和请求状态一致性的要求，用户的 QoS 可能会受到影响。
• 因此，我们发现这两种方法可以相互补充，以帮助服务提供商在用户QoS保证下支付更低的成本。

🛩创新

• 在本文中，我们提出了一种新的方案，称为使用弹性资源配置（TRUST）进行实时请求更新，以帮助服务提供商在云中保证用户的QoS，从而降低成本。

  • 具体来说，由于请求更新会增加更新延迟并降低用户的 QoS，因此我们尝试在时间阈值下完成更新操作T ，这将由用户的 QoS 需求决定。例如，在蜂窝通信网络中，相关研究中表明，当传输延迟低于150ms时，仍然可以保证传播质量。

• 此外，我们提出了一种基于渐进舍入的有界近似因子的高效TRUST算法。

  • 同时，我们试图将购买云资源的基础设施成本降至最低。简而言之，TRUST可以启发一种方法，帮助服务提供商在用户QoS保证方面花更少的钱。

• 本文的主要贡献可归纳如下：

  1. 我们综合分析了目前云端流量动态的处理方法，并展示了请求更新和弹性资源供应的优缺点。
  2. 我们给出了弹性资源预配（TRUST）实时请求更新的表述，可以保证用户的QoS，为服务商节省资金。据我们所知，这是第一个利用弹性资源配置和请求更新来处理流量动态的工作。
  3. 我们提出了一种基于随机舍入的算法。性能分析表明，我们的算法能够高概率地达到最优值。
  4. 我们利用真实世界的拓扑结构和数据集进行了小规模实验和大规模仿真，表明所提出的算法与最先进的解决方案相比，可以实现更优越的性能。

📊效果

• 无论是小规模的实验结果还是大规模的仿真结果，都表明了所提算法与现有基准相比的优异性能。
  • 指标：
    • （1）基础设施成本;
    • （2）系统吞吐量;
    • （3）不良率;
    • （4）更新延迟;
    • （5）丢包率;
    • （6）往返时间（RTT） 和
    • （7）流量完成时间 （FCT）。

🧠疑问

1. 效率如何？
2. 随机舍入算法如何应用于本场就？（核心思想：将原问题松弛，求近似最优解）

---

---

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

🗺参考文献

[1] Jingzhou Wang, *Gongming Zhao, *Hongli Xu, Yangming Zhao, Xuwei Yang, He Huang, “TRUST: Real-Time Request Updating with Elastic Resource Provisioning in Clouds “, INFOCOM’22, May. 2022.