Operator Maintenance Guide¶
本文档面向操作员。有关开发人员指南，请参阅此文档仓库中的 Developer / Operator Quick Start Guide。有关最终用户指南，请参阅此文档仓库中的 Basic Load Balancing Cookbook。
监控¶
监控负载均衡器 Amphora¶
Octavia 将自行监控负载均衡 amphora，并在它们发生故障时启动故障转移和/或替换。因此，大多数安装不需要监控运行负载均衡器的 amphora。
Octavia 会将每次故障转移记录到相应的健康管理器日志中。建议使用日志分析来监控故障转移趋势，以便及早发现 OpenStack 安装中的问题。我们已经看到 neutron（网络）连接问题、拒绝服务攻击和 nova（计算）故障导致故障转移率高于正常水平。或者，其他服务的监控也显示了问题，因此，这可能取决于您的整体监控策略而选择性地进行。
如果需要额外的监控，请查看 amphora agent REST 接口上的相应调用（请参阅 Octavia HAProxy Amphora API）
监控池成员¶
Octavia 将使用底层负载均衡子系统中的健康信息来确定成员的健康状况。此信息将被流式传输到 Octavia 数据库，并通过状态树或其他 API 方法提供。对于关键应用程序，我们建议定期轮询此信息。
监控负载均衡器¶
您应该监控负载均衡器的置备状态，并在置备状态不是 ACTIVE 时发送警报。当应用程序正在对池进行常规更改并进入多个 PENDING 阶段时，不应触发警报。
负载均衡器对象的置备状态反映了控制平面能够联系并成功置备创建、更新和删除请求的状态。负载均衡器对象的运行状态报告了负载均衡器的当前功能状态。
例如，负载均衡器可能具有 ERROR 的置备状态，但具有 ONLINE 的运行状态。这可能是由于 neutron 网络故障阻止了上次请求的负载均衡器配置更新成功完成。在这种情况下，负载均衡器继续通过负载均衡器处理流量，但可能尚未应用最新的配置更新。
处于 PENDING 置备状态的负载均衡器是不可变的，不能被另一个进程更新或删除，此 PENDING 状态充当资源的锁。如果数据库发生故障，而负载均衡器正在被删除、创建或更新，Octavia 控制平面将尝试删除 PENDING 状态并在很长一段时间内将其设置为 ERROR（默认设置约为 2 小时 45 分钟），以防止资源保持不可变状态。
监控负载均衡器功能¶
您可以使用 openstack loadbalancer status show 命令监控负载均衡器的运行状态。它报告负载均衡器及其子对象的当前运行状态。
您可能还需要使用连接到负载均衡器侦听器并从云外部监控它们的外部监控服务。这种类型的监控表明了外部故障是否会影响负载均衡器的功能，例如路由器故障、网络连接问题等。
监控 Octavia 控制平面¶
要监控 Octavia 控制平面，我们建议监控主要的 Octavia 进程
octavia-api
octavia-worker
octavia-health-manager
octavia-housekeeping
Monasca 项目为此类监控提供了一个插件（请参阅 Monasca Octavia plugin）。请参阅此项目以获取更多信息。
Octavia 的控制平面组件是无共享的，可以线性扩展。为了控制平面的高可用性，我们建议在每个可用区中运行至少一组组件。此外，octavia-api 端点可以位于负载均衡器或其他 HA 技术之后。也就是说，如果一个或多个组件发生故障，系统仍然可用（尽管可能降级）。例如，如果您在三个可用区中的每个可用区安装了一组组件，即使您丢失了一个可用区，Octavia 仍然响应并可用 - 只有当您在所有三个可用区丢失 Octavia 控制平面时，该服务才不可用。请注意，这仅解决了控制平面可用性；负载均衡功能的可用性高度依赖于所选拓扑和反亲和性设置。请参阅我们即将发布的 HA 指南以获取更多详细信息。
此外，我们建议监控 Octavia API 端点。目前没有特殊的 URL 可用，因此定期轮询根 URL 就足够了。
日志文件中包含大量可用于日志分析的信息。可以监控的一些示例是
Amphora 构建速率 - 确定系统负载
Amphora 构建时间 - 确定构建 amphora 所需的时间
故障/错误 - 尽早收到系统问题的通知
轮换 Amphora 镜像¶
Octavia 将使用预构建的镜像启动负载均衡器，这些镜像包含 amphora agent、负载均衡应用程序，并在启动时通过 config drive 播种加密证书。
轮换镜像意味着使运行旧镜像的负载均衡器 amphora 故障转移到具有新镜像的 amphora。在使用 ACTIVE/STANDBY 拓扑时，这应该不会有任何可测量的负载均衡功能中断。独立负载均衡器可能会经历短暂的中断。
您可能需要轮换 amphora 镜像的原因如下
底层操作系统已进行（安全）更新
您想要部署新版本的 amphora agent 或 haproxy
amphora 上的加密证书和/或密钥已被泄露。
虽然与轮换镜像无关，但如果切换到底层虚拟机的不同风味，也可能会调用此过程。
准备新的 Amphora 镜像¶
要准备新的 amphora 镜像，您需要使用 diskimage-create.sh，如 diskimage-create 目录中的 README 中所述。
例如，在 octavia/diskimage-create 目录中，运行
./diskimage-create.sh
创建新镜像后，您需要将其上传到 glance。以下显示了如果在 Octavia 配置文件中设置了镜像标签该如何操作。确保使用与 Octavia 服务帐户相同的租户
openstack image create --file amphora-x64-haproxy.qcow2 \ --disk-format qcow2 --tag <amphora-image-tag> --private \ --container-format bare /var/lib/octavia/amphora-x64-haproxy.qcow2
如果您没有配置镜像标签而是配置了镜像 ID，则需要使用新的 ID 更新 Octavia 配置文件并重新启动 Octavia 服务（不包括 octavia-api）。
生成要轮换的负载均衡器列表¶
生成列表最简单的方法是列出所有负载均衡器的 ID
openstack loadbalancer list -c id -f value
记下这些 ID。
轮换负载均衡器¶
Octavia 具有一个 API 调用来启动负载均衡器的故障转移
openstack loadbalancer failover <loadbalancer id>
您可以通过查询 octavia openstack load balancer show <loadbalancer id> 直到负载均衡器再次变为 ACTIVE 来观察故障转移。
最佳实践/优化¶
由于故障转移会对 OpenStack 安装施加重大负载，通过创建新的虚拟机和端口，因此应该以非常慢的速度进行，在负载较轻的时间进行，或者在 Octavia 中启用正确的节流控制。节流控制将确保优先处理故障转移高于其他操作，并且，根据启动的故障转移数量，这可能会挤出其他操作。
轮换加密证书¶
Octavia 使用双向 SSL 加密来保护 amphora agent 和控制平面之间的通信。为此，几个证书分布在系统中
控制平面
Amphora 证书颁发机构 (CA) 证书：如果 Octavia 充当证书颁发机构来颁发新的 amphora 证书，则用于验证 amphora 证书
客户端证书：用于向 amphora 进行身份验证
Amphora
客户端 CA 证书：用于验证控制平面客户端证书
Amphora 证书：呈现给控制平面进程以证明 amphora 身份。
从 amphora 发出的心跳 UDP 数据包使用对称加密密钥进行保护。这由 health_manager 部分中的 heartbeat_key 配置选项设置。我们建议将其设置为足够长度的随机字符串。
轮换 Amphora 证书¶
对于服务器部分，Octavia 将充当证书颁发机构，为每个 amphora 颁发 amphora 证书。Octavia 还会监控这些证书并在它们过期之前刷新它们。
有三种方法可以手动启动轮换
更改数据库中的证书到期日期。然后，Octavia 将使用新颁发的证书轮换 amphora 证书。这需要以下条件
客户端 CA 证书尚未过期，或者控制平面上的相应客户端证书尚未由不同的客户端 CA 颁发（如果颁发机构被泄露）
控制平面上的 Amphora CA 证书没有以任何方式更改，从而危及 amphora 证书的验证（例如，证书已使用新的私钥/公钥重新颁发）
如果 amphora CA 以危及 amphora 证书验证的方式更改，操作员可以手动上传新颁发的 amphora 证书，方法是关闭旧 amphora 证书的验证。这需要一个可以由 amphora 上的客户端 CA 文件验证的客户端证书。有关更多详细信息，请参阅 Octavia HAProxy Amphora API。
如果控制平面上的客户端证书以无法由 amphora 上的客户端证书颁发机构证书验证的方式更改，则需要启动所有 amphora 的故障转移（请参阅 Rotating Amphora Certificates）。在完成故障转移之前，amphora 无法由控制平面控制。
轮换客户端证书¶
如果客户端证书已过期，则需要颁发新的证书并安装到系统中
颁发新的客户端证书（如果使用自签名证书，请参阅 bin 文件夹中的脚本）或使用证书颁发机构提供的证书。
将新的证书复制到 Octavia 可以找到它的位置。
如果以前的证书文件未被覆盖，请在配置文件中调整新证书的路径。在所有情况下，重新启动所有 Octavia 服务，不包括 octavia-api。
如果客户端 CA 证书除了轮换客户端证书之外还被替换，则需要在系统中安装新的客户端 CA 证书。之后，启动所有 amphora 的故障转移以分发新的客户端 CA 证书。在完成故障转移之前，amphora 无法由控制平面控制。
更改心跳加密密钥¶
更换心跳加密密钥需要特别小心。一旦更改，Octavia 将无法读取任何心跳，并将假定所有 amphora 处于错误状态并立即启动故障转移。
作为准备，请阅读故障转移部分中的 Best Practices/Optimizations 章节。
鉴于更改此密钥涉及的风险，不应在常规维护期间更改，而仅在强烈怀疑存在泄露时更改。
注意
对于 Octavia 的未来版本，计划有一个“update amphora”API，该 API 允许在不进行故障转移的情况下更改此密钥。届时，将有一个过程来暂停健康监控，同时轮换密钥，然后恢复健康监控。
处理 VM 节点故障¶
如果运行 amphora 的节点发生故障，Octavia 将自动将 amphora 故障转移到不同的节点（如果容量允许）。在某些情况下，可以恢复节点（例如，通过硬重置），并且 hypervisor 可能会将 amphora vm 恢复。在这种情况下，操作员应手动删除该特定节点上的所有 amphora，因为 Octavia 假定它们已被删除作为故障转移的一部分，并且不会再接触它们。
注意
作为安全措施，操作员可以在删除之前手动检查 VM 是否正在使用。首先，使用 Amphora API 获取当前 amphora 列表，然后将 nova 实例 ID 与 amphora API 响应中的 compute_id 列进行匹配（目前无法按 compute_id 过滤 amphora）。如果有任何匹配项，并且 amphora 状态不是“DELETED”，则 amphora 仍被认为正在使用。
从主机撤离特定的 Amphora¶
在某些情况下，需要撤离 amphora，要么是因为主机正在关闭进行维护，要么是作为故障转移的一部分。Octavia 具有丰富的 amphora API 来执行此操作。
首先使用 amphora API 找到特定的 amphora。然后，如果尚未执行，请在 nova 中禁用对此主机的调度。最后，使用 amphora API 上的故障转移命令启动特定 amphora 的故障转移。
或者，如果它发生得足够快，Octavia 无法注意到过时的 amphora，则实时迁移也可能有效（默认配置为 60 秒）。
