Openstack 中的负载均衡(第 2 部分)

В 上一篇文章 我们讨论了使用 Watcher 的尝试并提供了测试报告。 我们定期进行此类测试,以平衡大型企业或运营商云的其他关键功能。

所解决的问题非常复杂,可能需要多篇文章来描述我们的项目。 今天,我们发布该系列的第二篇文章,专门讨论平衡云中的虚拟机。

一些术语

VmWare公司引入了DRS(分布式资源调度程序)实用程序来平衡他们开发和提供的虚拟化环境的负载。

正如他写的 searchvmware.techtarget.com/definition/VMware-DRS
“VMware DRS(分布式资源调度程序)是一种实用程序,可平衡虚拟环境中的计算负载与可用资源。 该实用程序是名为 VMware Infrastructure 的虚拟化套件的一部分。

借助 VMware DRS,用户可以定义在虚拟机 (VM) 之间分配物理资源的规则。 该实用程序可以配置为手动或自动控制。 VMware 资源池可以轻松添加、删除或重新组织。 如果需要,可以在不同业务部门之间隔离资源池。 如果一台或多台虚拟机上的工作负载发生显着变化,VMware DRS 会在物理服务器之间重新分配虚拟机。 如果整体工作负载减少,一些物理服务器可能会暂时离线并整合工作负载。”

为什么需要平衡?


在我们看来,DRS 是必备的云功能,尽管这并不意味着必须随时随地使用 DRS。 根据云的目的和需求,对于 DRS 和平衡方法可能有不同的要求。 可能存在根本不需要平衡的情况。 甚至有害。

为了更好地了解哪些客户需要 DRS,我们需要考虑他们的目的和目标。 云可以分为公共云和私有云。 以下是这些云和客户目标之间的主要区别。

私有云/大型企业客户
公有云/中小企业、个人

经营者的主要标准和目标
提供可靠的服务或产品
在竞争激烈的市场中降低服务成本

服务要求
各个级别和所有系统元件的可靠性

保证性能

将虚拟机分为几个类别 

信息和物理数据安全

SLA 和 XNUMX/XNUMX 支持
最大程度地轻松接收服务

服务比较简单

数据的责任在于客户

不需要虚拟机优先级

标准服务水平的信息安全,客户责任

可能会有故障

没有 SLA,质量得不到保证

电子邮件支持

不需要备份

客户端特点
应用范围非常广泛。

公司继承的遗留应用程序。

为每个客户提供复杂的定制架构。

亲和力规则。

该软件在 7x24 模式下不间断运行。 

即时备份工具。

可预测的循环客户负载。
典型应用 – 网络平衡、Apache、WEB、VPN、SQL

应用程序可能会停止一段时间

允许在云中任意分布虚拟机

客户端备份

大量客户端的可预测统计平均负载。

对建筑的影响
地理聚类

集中式或分布式存储

保留肠易激综合症
计算节点本地数据存储

平衡目标
负载分布均匀

最大的应用程序响应能力 

最小平衡延迟时间

仅在明显必要时进行平衡

取出一些设备进行预防性维护
降低服务成本和运营商成本 

在低负载的情况下禁用某些资源

省电

降低人员成本

我们自己得出以下结论:

对于私有云向大型企业客户提供的 DRS 可以在以下限制条件下使用:

  • 信息安全并在平衡时考虑亲和力规则;
  • 发生事故时有足够的资源储备;
  • 虚拟机数据位于集中式或分布式存储系统上;
  • 随着时间的推移错开管理、备份和平衡程序;
  • 仅在客户端主机聚合内进行平衡;
  • 只有在存在强烈不平衡的情况下进行平衡,才是最有效、最安全的VM迁移(毕竟迁移可能会失败);
  • 平衡相对“安静”的虚拟机(迁移“嘈杂”的虚拟机可能需要很长时间);
  • 平衡考虑“成本”——存储系统和网络的负载(为大客户定制架构);
  • 考虑每个虚拟机的个体行为特征进行平衡;
  • 平衡最好在非工作时间(晚上、周末、节假日)进行。

对于公共云为小客户提供服务时,DRS 的使用频率更高,具有高级功能:

  • 缺乏信息安全限制和相似性规则;
  • 云内平衡;
  • 在任何合理时间进行平衡;
  • 平衡任何虚拟机;
  • 平衡“吵闹”的虚拟机(以免打扰其他人);
  • 虚拟机数据通常位于本地磁盘上;
  • 考虑存储系统和网络的平均性能(云架构统一);
  • 根据一般规则和可用的数据中心行为统计数据进行平衡。

问题的复杂性

平衡的难点在于DRS必须与大量的不确定因素一起工作:

  • 每个客户信息系统的用户行为;
  • 信息系统服务器操作的算法;
  • DBMS 服务器的行为;
  • 计算资源、存储系统、网络的负载;
  • 服务器之间的交互以争夺云资源。

云资源上的大量虚拟应用程序服务器和数据库的负载随着时间的推移而发生,其后果可能会在不可预测的时间内显现出来并相互重叠,产生不可预测的影响。 即使要控制相对简单的过程(例如,控制发动机、家里的热水系统),自动控制系统也需要使用复杂的 比例积分微分 带反馈的算法。

Openstack 中的负载均衡(第 2 部分)

我们的任务要复杂许多数量级,并且存在系统无法在合理时间内将负载平衡到既定值的风险,即使没有来自用户的外部影响。

Openstack 中的负载均衡(第 2 部分)

我们的发展历史

为了解决这个问题,我们决定不是从头开始,而是在现有经验的基础上,开始与该领域有经验的专家进行互动。 幸运的是,我们对问题的理解完全一致。

步骤1“

我们使用了基于神经网络技术的系统,并尝试基于它来优化我们的资源。

这个阶段的兴趣在于测试新技术,其重要性在于应用非标准方法来解决问题,在其他条件相同的情况下,标准方法实际上已经耗尽了自己的力量。

我们启动了系统,我们真正开始平衡。 我们的云规模不允许我们获得开发人员所说的乐观结果,但很明显,平衡正在发挥作用。

与此同时,我们也有相当严重的局限性:

  • 为了训练神经网络,虚拟机需要在没有重大变化的情况下运行数周或数月。
  • 该算法旨在根据早期“历史”数据的分析进行优化。
  • 训练神经网络需要相当大量的数据和计算资源。
  • 优化和平衡可以相对较少地进行——每隔几个小时一次,这显然是不够的。

步骤2“

由于我们对现状不满意,我们决定修改系统,为此,请回答 主要问题 – 我们为谁而做?

首先 - 针对企业客户。 这意味着我们需要一个快速运行的系统,而这些公司限制只会简化实施。

第二个问题 ——“及时”这个词是什么意思? 经过短暂辩论,我们决定可以从 5-10 分钟的响应时间开始,这样短期的波动就不会导致系统共振。

第三个问题 – 选择多少数量的平衡服务器?
这个问题自行解决了。 通常,客户端不会将服务器聚合设置得非常大,这与本文将聚合限制为 30-40 台服务器的建议是一致的。

此外,通过对服务器池进行分段,我们简化了平衡算法的任务。

第四个问题 – 学习过程漫长且平衡性极少的神经网络有多适合我们? 我们决定放弃它,转而采用更简单的运算算法,以便在几秒钟内获得结果。

Openstack 中的负载均衡(第 2 部分)

可以找到使用此类算法的系统及其缺点的描述 这里

我们实施并启动了这个系统,并收到了令人鼓舞的结果 - 现在它会定期分析云负载并提出移动虚拟机的建议,这些建议基本上是正确的。 即使现在,我们也可以清楚地看到,我们可以为新虚拟机释放 10-15% 的资源,同时提高现有虚拟机的工作质量。

Openstack 中的负载均衡(第 2 部分)

当检测到 RAM 或 CPU 不平衡时,系统向 Tionix 调度程序发出命令以执行所需虚拟机的实时迁移。 从监控系统可以看到,虚拟机从一台(上层)主机移动到另一台(下层)主机,并释放了上层主机(黄色圆圈)的内存,分别占用了下层主机(白色圆圈)的内存。界)。

现在我们正在尝试更准确地评估当前算法的有效性,并试图找出其中可能存在的错误。

步骤3“

看来可以先冷静一下,等效果出来了再结束这个话题。
但以下明显的优化机会推动我们进行了一个新的阶段

  1. 统计数据,例如, 这里 и 这里 显示两处理器和四处理器系统的性能明显低于单处理器系统。 这意味着与单处理器系统相比,所有用户在多处理器系统中购买的 CPU、RAM、SSD、LAN、FC 获得的输出显着减少。
  2. 资源调度器本身可能存在严重错误, 这是其中一篇文章 关于这个话题。
  3. Intel 和 AMD 提供的用于监控 RAM 和缓存的技术使得研究虚拟机的行为成为可能,并将它们放置在“吵闹”的邻居不会干扰“安静”的虚拟机的位置。
  4. 参数集的扩展(网络、存储系统、虚拟机的优先级、迁移成本、迁移准备情况)。

在总

我们改进平衡算法的工作结果得出了明确的结论:使用现代算法可以实现数据中心资源的显着优化(25-30%),同时提高客户服务质量。

基于神经网络的算法当然是一种有趣的解决方案,但需要进一步开发,并且由于现有的限制,它不适合在私有云典型的卷上解决此类问题。 同时,该算法在规模相当大的公有云中也表现出了良好的效果。

我们将在接下来的文章中向您详细介绍处理器、调度程序和高级平衡的功能。

来源: habr.com

添加评论