跳转到： 导航, 搜索

Octavia/非任意决策

Octavia 非任意决策

在编写 Octavia 项目代码的过程中，开发人员经常会遇到在几种不同的（但通常同样可行的）方法中做出选择的情况。大多数情况下，开发人员应该可以随意做出他们喜欢的选择，只要他们遵循项目 HACKING 指南中制定的最佳实践即可。

然而，通常情况下，一些乍一看似乎是任意的选择，一旦更深入地了解问题，最终却不再是任意的。 （也就是说，出现了一些使两种大致等效但并非完全相同的方法……不太等效的原因。） 对这些选择的评估通常会在邮件列表中、IRC 频道、garret 审查评论等地方引发争论。

为了避免重复讨论这些决策，我们创建了此页面来记录在创建和维护 Octavia 过程中做出的非任意决策。 这并不意味着我们不应该重新评估其中一些决策，而是说我们不应该这样做，除非有新的信息添加到之前的讨论中，或者在做出非任意决策时所处的环境或假设发生了变化。 基本上，应该查阅此页面，以确保您反对的事情不是在过去对它的讨论的重复（以节省每个人的时间）。

如果某个决策在邮件列表或其他地方引发了争论，并且您需要花费几分钟才能解决，请在此处记录它，并为您的团队成员节省一些时间！

现在，我们来讨论这些决策


每个监听器一个 haproxy 进程，还是每个负载均衡器一个 haproxy 进程？（已撤销）

注意：此决策在 stein 中被撤销：https://review.opendev.org/c/openstack/octavia/+/673518
使用每个监听器一个进程时，新的 haproxy 内存预分配模型在重新配置负载均衡器时引入了许多问题。

描述

对于执行实际负载均衡功能的 Octavia nova 节点，初始参考实现将使用 haproxy 完成。 但问题是：我们应该使用每个监听服务一个 haproxy 实例，还是每个负载均衡器（vip）一个 haproxy 实例？

这很重要吗？

  • 此决策将影响许多与创建和操作单个 haproxy 配置文件的方式、评估统计信息和状态以及最终用户可见的体验有关的事情。
  • 此决策不太可能在以后更改，因为它既代表了一种服务交付范例，又影响了代码中足够多的细微领域，以至于以后更改可能会很麻烦。

双方辩论的主要论点总结

支持每个负载均衡器一个 haproxy 进程
  • 减少内存开销
  • 减少 CPU 开销
  • 减少负载均衡器构建时间
  • 减少网络流量和健康监控开销
  • 允许共享后端池
  • 允许单个统一日志（日志聚合也更简单）
  • 单个负载均衡器上的所有监听器的“共同命运”（客户期望如此）
  • 减少使用的 TCP 端口数量
  • 每个 Octavia VM 一个 haproxy 进程是一种“更简单”的设置，我们可以使用标准的 OS init 脚本进行进程管理。
对上述观点的反驳
  • 内存和 CPU 开销的减少实际上可能非常显著——应该运行基准测试。
  • 负载均衡器构建时间的减少微不足道（对于将存在数月甚至数年的进程来说，毫秒级）
  • 由于更少的配置文件而减少的网络流量也微不足道
  • 我们的模型不允许共享后端池。 即使允许，在监听器之间共享池也是一种罕见的边缘情况。
  • 多个进程也可以使用统一日志。 （事实上，多个进程允许在此方面更灵活。） 使用多个 haproxy 进程进行日志聚合同样容易。
  • “共同命运”也称为“没有故障隔离”，这实际上是一件坏事。
  • 两种解决方案将使用相同数量的 TCP 端口
  • 我们从未谈论过每个 Octavia VM 一个 haproxy 进程，我们谈论的是每个负载均衡器一个 haproxy 进程（并且一个 Octavia VM 可能有许多负载均衡器），这意味着我们无论如何都无法使用默认的 OS init 脚本。 也没有理由不能为每个监听器编写 OS init 脚本（例如，systemd 进程管理）。
支持每个监听器一个 haproxy 进程
  • 每个监听器一个进程比每个负载均衡器一个进程更灵活，因为
    • 可以使用多个日志文件（并且可以使用多个日志详细程度）
    • 属于 'defaults' 部分的 haproxy 关键字可以因监听器而异（例如，keepalive 配置和超时）
  • 更简单的 haproxy 配置文件
  • 监听器之间的故障隔离
  • 减少由于正常配置更改而导致的服务中断
  • 更易于解析每个监听器的使用情况/统计数据
  • 更易于解析每个监听器的操作状态
  • 两种模型的 SLA 等效
  • 使用每个监听器一个 haproxy 进程进行故障排除更简单，因为
    • 操作员可以使用标准的 OS 工具轻松查看单个监听器的资源使用情况
    • 操作员可以在不影响同一负载均衡器上的其他监听器的情况下启动/停止/等单个监听器
    • 操作员可以在不影响其他监听器的情况下更改一个监听器的全局日志配置
    • 对于配置的 'defaults' 部分中的任何其他参数也是如此
对上述观点的反驳
  • 未提供

讨论在哪里进行？

其他研究笔记

做出的决定

2014-08-27 的 IRC 会议投票结果是支持每个监听器一个 haproxy 进程。

已撤销

由于 HAProxy 进程之间的内存开销和共同命运，我们撤销了此决定，现在已转为单个进程模型。 请参阅：https://storyboard.openstack.org/#!/story/2005412

我们应该如何称呼后端 VM / 容器 / 机器 / 设备 / 东西？

描述

在最初的 Octavia 设计文档中，“执行实际负载均衡的那个东西”被称为“Octavia VM”。 在某个时候，有人指出这个东西实际上可能不是虚拟机，因为该角色可能由容器填充。 这引发了 IRC 和其他地方的讨论，并且很明显我们需要想出一个其他的名称。

这很重要吗？

  • 代码依赖于我们选择的名称，并且一旦代码依赖于我们选择的名称，就很难更改。
  • 使用通用术语对于确保我们都相互理解至关重要。
  • 虽然我们称呼这个东西是什么在很大程度上是任意的，但选择一个名称并坚持下去实际上更重要。

双方辩论的主要论点总结

有许多名称想法被提出，并且辩论中没有明确的“双方”。 但各方提出的担忧包括

  • 不想使用过于常用的东西
  • 尽量避免具有预先定义含义的名称（尤其是在 OpenStack 或 python 编码世界中。 例如，“instance”是一个糟糕的名称。）
  • 名称应该以某种方式代表虚拟机/容器/主机/设备
  • 名称应该具有复数或群体表示形式，以便我们在将这些东西组合在一起时使用（例如，“bee / swarm”）

讨论在哪里进行？

做出的决定

我们于 2014-09-03 和 2014-09-04 通过 etherpad 投票，获胜的名称是：amphora

从 "https://wiki.openstack.org/w/index.php?title=Octavia/Non-arbitrary_Decisions&oldid=182621" 检索