DPDK based Open vSwitch热升级设计与实现( 二 ) _DPDK

释放资源之后，新老进程开始进行状态同步，主要是一些 OVS 的 megaflow 同步，网络 tap 设备的 fd 同步等。

同时，老的 ovs 会将所有的 OpenFlow 规则进行备份。

这一切完成之后，老进程会返回 JSON-RPC 的请求的响应。如果上述过程无问题，则返回成功，升级继续。否则返回失败，新进程会退出，升级失败。同时老进程会状态回滚，将之前释放的资源又重新申请回来，回到正常的工作状态。

新进程获得各种状态信息，开始正常初始化。包括 DPDK 初始化内存， ovs 从 ovsdb 中获取网桥、网卡等各种配置开始初始化等。在这个过程中，如果出现异常，新进程 crash ，会导致 JSON-RPC 这个 unix socket 连接中断。一旦老进程检测到这个连接中断，就认为新进程初始化失败，自动回滚。

新进程加载之前备份的 OpenFlow 规则。这之间的 OpenFlow 规则变更，会由 local controller 记录并下发。

新进程发起第二阶段 JSON-RPC 请求。

第二阶段：

老进程退出。
新进程开启 pmd 线程开始转发。
升级结束。

下图简单的描述了升级时序图：

文章插图

由升级时序图可以看出，热升级第一阶段里新 ovs 进程完成了最耗时的初始化工作，同时老 ovs 进程一直在进行转发，并没有断网。断网只是在第二阶段老 ovs 退出和新 ovs 启动 PMD 线程之间发生。
在升级过程中，我们利用了 MLNX 网卡一个特性：同一个网卡设备可以被两个独立的 dpdk 进程同时打开，并且流量会被同时镜像到两个进程中去。如果使用其他的网卡，可以通过多 VF 配合流表规则切换的方法达到同样效果。这里就不再展开叙述了。
断网时间评估我们考察了两种虚拟网卡后端的断网时间：

采用 representer + VF 的方式，
采用 vhost-user + virtio 的方式。

测试方法两台宿主机上两台虚机互相 ping ，使用ping -i 0.01 。两次 ping 之间相隔 10ms ，最后统计在升级中， ping 包未回的数量即表示升级断网时间。iperf -i 1测试，观察 TCP 吞吐是否会受到影响。
representer + VF 方式ping 测试10 次试验结果如下：

1524 packets transmitted, 1524 received, +36 duplicates, 0% packet loss, time 16747ms623 packets transmitted, 622 received, +29 duplicates, 0% packet loss, time 6830ms662 packets transmitted, 662 received, +30 duplicates, 0% packet loss, time 7263ms725 packets transmitted, 724 received, +28 duplicates, 0% packet loss, time 7955ms636 packets transmitted, 635 received, +28 duplicates, 0% packet loss, time 6973ms752 packets transmitted, 750 received, +27 duplicates, 0% packet loss, time 8251ms961 packets transmitted, 961 received, +31 duplicates, 0% packet loss, time 10551ms737 packets transmitted, 737 received, +29 duplicates, 0% packet loss, time 8084ms869 packets transmitted, 869 received, +27 duplicates, 0% packet loss, time 9543ms841 packets transmitted, 840 received, +28 duplicates, 0% packet loss, time 9228ms

发现最多出现 1 个丢包，说明断网时间最长 10ms 。但是发现了很多 duplicates 的包，这个是因为 mlnx 网卡在 switchdev 模式下有一个 bug：当出现双进程时，本应该流量被镜像到另一个进程，结果 mlnx 网卡让一个进程收到了两个重复包，而另一个进程没有包。目前 mlnx 已经确认了这个问题。
iperf 测试观测到升级期间，有 1s 速率减半，由满速率 22Gbps 到 13Gbps ，估计是和 MLNX bug 引发的重传包和升级断网有关。1s 之后迅速回到 22Gbps 。
vhost-user + virtio 模式ping 测试断网时间在 70~80ms 左右。通过对日志分析，发现是老进程在退出时，反复进行了 vhost 重连导致，这块通过继续优化，断网时间会进一步降低。这里就不再展开了。
iperf 测试和 VF 方式结果类似，也是吞吐会有一定的下降，升级完成后立刻恢复。