【问题标题】：OpenvSwitch port missing in large load, long poll interval observed大负载中缺少 OpenvSwitch 端口，观察到长轮询间隔
【发布时间】：2018-01-14 04:54:14
【问题描述】：

问题描述

我有一个通过 ovs (Open vSwitch) 端口的带有 HA 管理网络 (VIP) 的 OpenStack 系统，它在这个系统中找到，具有高负载（同时创建卷从一瞥图像创建），VIP 端口（ovs 端口）将丢失。

分析

目前，使用日志文件中的默认日志级别，观察到的唯一内容如下Unreasonably long 62741ms poll interval。

2017-12-29T16:40:38.611Z|00001|timeval(revalidator70)|WARN|Unreasonably long 62741ms poll interval (0ms user, 0ms system)

暂时的想法

我将为文件打开调试日志并尝试重现问题：

sudo ovs-appctl vlog/set file:dbg

问题

在问题再现期间/之后我还应该做什么？

这个问题是典型的吗？是什么原因造成的？

我搜索了OpenvSwitch trouble shoot 或其他相关关键词，而信息都在data flow/table 级别而不是ovs-vswitchd 级别（我说的对吗？）

非常感谢！ BR//Wey

【问题讨论】：

什么Linux内核版本和什么OVS版本？ HA，您使用的是 LACP 还是？在 OVS 级别还是在 nic 中？你在使用 STP 吗？
@gdahlm 这是一个通过 kvm 运行的虚拟 openstack 控制器 Ubuntu 14.04 来宾，我还没有这些版本信息。关于 HA，它实际上是一个 mirantis openstack : ocf::fuel:ns_IPaddr2 起搏器资源。注册 STP 我现在还不知道，稍后会更新。谢谢！
在 14.04 上发布的 OVS 不能很好地处理负载，因为 mirantis 将系统与正常的包管理流程隔离开来。我不知道是什么版本，但看看它是否至少是 ovs 2.5。 1.但如果它使用 ubuntu 云存档，更新版本并添加数据平面开发工具包 (DPDK) 将有很大帮助。有一些 numa pinning 和其他选项可能会对您有所帮助，但更新的 ovs 和 dpdk 确实有助于 ml2 驱动程序模型。
@gdahlm 它使用 2.6.1 和 DPDK（两个 numa 节点上的专用 cpu 上的 pmd）和 numa 感知 cpu 固定。谢谢！我将尝试使用调试日志级别进行复制以查看发现了什么。

标签： openstack openvswitch

【解决方案1】：

这个问题没有复现所以我忘记了，直到最近，2年后，我有机会在不同的环境中接触到这个问题，这一次我对它的根本原因有了更多的想法。

这可能是由于绑定中的转变引起的，由于某种原因，交通模式适合一次又一次触发转变的情况（我会说条件相当强，但无论如何都有机会被击中对吧？）。

班次条件引用如下，请参阅此处的完整文档：https://docs.openvswitch.org/en/latest/topics/bonding/

绑定包输出当数据包从绑定端口发送出去时，实际使用的绑定成员是根据数据包的源 MAC 和 VLAN 标签选择的（请参阅bond_choose_output_member()）。特别是，源 MAC 和 VLAN 标记被散列成 256 个值之一，然后在 struct port 的 bond_hash 成员中保存的散列表（“绑定散列”）中查找该值。哈希表条目标识绑定成员。如果尚未为该哈希表条目选择任何绑定成员，vswitchd 将任意选择一个。

每隔 10 秒，vswitchd 会重新平衡绑定成员（请参阅 bond_rebalance()）。为了重新平衡，vswitchd 检查每个成员在大约过去一分钟内传输的字节数的统计信息，最近发送的数据比最近发送的数据的权重更大。它按从最大负载到最小负载的顺序考虑每个成员。如果负载高的成员 H 的负载明显高于负载最小的成员 L，并且成员 H 携带至少两个散列，则 vswitchd 将 H 的一个散列转移到 L。但是，vswitchd 只会将散列从 H 转移到 L，如果它将使 H 和 L 之间的负载比减少至少 0.1。

目前，“负载显着增加”意味着 H 必须承载至少 1 Mbps 以上的流量，并且该流量必须至少比 L 的大 3%。

【讨论】：