ovs 热升级
将 Open vSwitch 从当前版本升级到下一个版本，同时最小化系统中传输的流量中断，需要考虑一些因素：
-
如果升级只涉及升级 Open vSwitch 的用户空间实用程序和守护进程，请确保新的用户空间版本与之前加载的内核模块兼容。
-
用户空间守护程序的升级意味着它们必须重新启动。重新启动守护程序意味着 ovs-vswitchd 守护程序中的 OpenFlow 流将丢失。恢复流的一种方法是让控制器重新填充它。另一种方法是使用像 ovs-ofctl 这样的实用程序保存先前的流，然后在重新启动后重新添加它们。只有当新的 Open vSwitch 接口保留旧的 ofport 值时，恢复旧流才是准确的。
-
当新的用户空间守护程序重新启动时，它们会自动清除内核中设置的旧流量。如果有数百个新流量进入内核，但用户空间守护程序正在忙于从控制器或 ovs-ofctl 等实用工具设置新的用户空间流量，那么这可能会很昂贵。Open vSwitch 数据库提供了通过 Open_vSwitch 表的 other_config:flow-restore-wait 列解决这个问题的选项。有关详情，请参阅ovs-vswitchd.conf.db(5)手册。
-
如果升级还涉及升级内核模块，就需要卸载旧内核模块，然后加载新的内核模块。这意味着 Open vSwitch 所属的内核网络设备将被重新创建，内核流量将丢失。如果立即重新启动用户空间守护程序并尽快恢复用户空间流量，可以减少流量中断时间。
-
在由 ovn 管理的主机上运行在容器中的 ovs 进行升级时，只需停止 Docker 容器，使用具有更新 ovs 版本的新 Docker 镜像进行删除和重新运行即可。
-
在容器中运行 ovs 时，如果 ovs 在桥接模式下使用，其中管理接口由 ovs 管理，Docker 重新启动将导致网络连接丢失。因此，请确保从 ovs 删除物理接口的桥接映射，通过 Docker 升级 ovs，然后将接口重新添加到 ovs 桥接器。如果管理接口不由 ovs 管理，则可以在多个网络接口的情况下不需要删除此映射。
ovs-ctl 实用程序的重启功能仅重新启动用户空间守护程序，确保 ofport 值在重新启动时保持一致，使用 ovs-ofctl 实用程序还会还原用户空间流，并使用 other_config:flow-restore-wait 列来将流量中断时间最小化。
ovs-ctl 实用程序的 force-reload-kmod 功能执行以上所有操作，还会用新的内核模块替换旧的内核模块。Debian 和 RHEL 的 Open vSwitch 启动脚本使用 ovs-ctl 的功能，建议其他软件平台也使用这些功能。
