华为交换机学习指南 pdf_虚拟交换机热升级及在网易轻舟云原生的落地实践

最新推荐文章于 2024-07-04 11:13:03 发布

weixin_39724009

最新推荐文章于 2024-07-04 11:13:03 发布

阅读量327

点赞数

文章标签：华为交换机学习指南 pdf

本文链接：https://blog.csdn.net/weixin_39724009/article/details/111344338

版权

本文介绍了虚拟交换机的热升级方案，特别是以Open vSwitch+DPDK为例，探讨了两种热替换策略，重点阐述了一种将中断时间控制在ms级的方案，并分享了该方案在网易轻舟云原生的实践情况，强调了云原生环境下网络组件热升级的重要性。

摘要由CSDN通过智能技术生成

导读：虚拟交换机作为云计算基础设施的网络数据面核心软件组件，本身有bug修复、特性增加导致的升级需求，而升级过程中，业务中断时间长短是评价升级方案优劣的首要指标，本文给出一种通用的虚拟交换机热升级方案，将整个升级过程中业务中断时间控制到ms级，并介绍该方案在网易轻舟云原生容器网络实践中的落地情况。

一、背景

一个典型的虚拟交换机架构如下：

南向接口对接外部物理网络，北向接口对接虚拟机或者容器。实际使用过程中，虚拟交换机作为一个软件组件，本身有bug修复、特性增加导致的升级需求，而升级过程中，业务中断时间长短是评价升级方案优劣的首要指标。从业务的角度来看，升级引起的业务中断时间越短越好，这就要求虚拟交换机具备热升级的能力。

目前针对虚拟交换机的热升级，有热迁移、热补丁以及热替换几种方式。热迁移涉及到资源的腾挪转移从而导致管理开销较大；而热补丁开销小但限制较多，比如无法更改数据结构，不支持内联函数等；热替换可以实现基于进程的热替换，具有开销小、业务中断时间小及限制少的优点。

而针对热替换，从思路上来说也有不同的实现方式。

第一种方式采用了主备的实现思路，引入了中间交换单元，流量需要先从当前交换单元切换到中间交换单元，待当前交换单元升级完成后再将流量从中间交换单元切换回当前交换单元。这种方式非常直接，依赖于流量切换的实现方式，也可以将中断时间做的足够短，不过整个过程中流量会有两次中断，即流量从当前交换单元切换到中间交换单元会导致业务有一次中断，而之后将流量从中间交换单元切换回当前交换单元又会导致中断。

另一种方式是在第一种方式上的改进。流量从当前交换单元切换到中间交换单元后，会一并将所有的配置和状态信息都同步给中间交换单元，这样中间交换单元就完成了对于当前交换单元的完全替代，待流量切换成功后，也就不需要再将流量切回当前交换单元。所以整个过程中也就只会导致一次流量中断。

目前业内比较多采用第二种方式来实现热替换。实现过程中又会有不同的变体，比如直接替换进程中调用的动态库，还是替换掉整个进程。替换动态库可以做到中断时间非常小，但同时也会带来框架和动态库之间接口无法变动，以及无法实现框架代码变更所要进行的热替换等限制。替换进程则不会有这些限制，但是中断时间会稍长。

二、通用实现

本文以开源的Open vSwitch虚拟交换机来说明具体实现，其他的虚拟交换机实现也是类似的。目前业内用的比较多的是Open vSwitch+DPDK的用户态转发方案，本文也以此进行说明。

Open vSwitch承担报文转发的数据面的组件包括OVS-VSWITCHD(以下简称OVS)和DPDK(Data Plane Development Kit)两个组件，其中DPDK是作为动态库被OVS集成，所以最终呈现的是OVS这个进程。这个进程也是整个热替换的对象。其他的组件，如ovsdb-server是保存配置的数据库组件，也是一个单独的进程，由于此进程不涉及具体的报文转发任务，所以可以单独升级，不会引发业务中断，不在本文讨论之列。而ovs-ofctl和ovs-vsctl组件只是二级制工具，其中ovs-ofctl进行流表(流表是OVS的转发规则，确定转发的具体原则)的下发，而ovs-vsctl则进行虚拟端口配置管理，所以他们也可以独立进行升级，故也不在本文讨论之列。

OVS的南北向接口有很多种方式。这里全部以VF口作为虚拟端口，其功能划分如下：

VF0通过DPDK接入虚拟交换机，并通过PF口对接外部网络；
VF1通过DPDK接入虚拟交换机，作为和其他VM或者容器通信的端口；
VF4接入虚拟机；
VF5接入容器；

整个热替换的总体实现步骤如下：

系统启动热替换升级，安装新版本的OVS和DPDK组件；
OVS1正常运行过程中，再启动一个新版本的OVS2(含DPDK2)进程，OVS2需要对接不同的VF口；
OVS2中恢复流表配置；
启动业务切换，将流量从OVS1切换到OVS2；
退出OVS1；

可见，热替换升级过程中，在步骤4之前，流量都是没有中断的，只有在步骤4触发业务切换时有流量中断。所有比较耗时的操作(DPDK初始化，流表恢复)都是预初始化好的，这样在步骤4完成的工作很少，从而整个流量中断的时间也非常短，可以控制到100ms左右。

另外，需要特别提到一点，就是后端虚拟端口的选择。我们使用VF口作为虚拟端口适用性会更强，可对接虚拟机，也可以对接容器。而如果使用vhost_user虚拟端口，仅可以对接虚拟机，但无法对接容器。

三、网易轻舟容器网络落地实践

网易杭研研发的轻舟云原生应用管理平台，包括容器云、微服务和中间件等三类核心组件，已在网易多个业务线的生产环境规模应用。上述热替换方案整体思路比较简单，但在网易轻舟容器网络实际落地过程中还有一些细节问题需要考虑。这里列几个比较常见的点。

1、物理网卡适配

轻舟容器网络可以支持多种网卡类型，如Mellanox 的CX4/CX5，Intel的82599/X710等。DPDK本身是可以对接不同的网卡类型，但是不同的网卡针对DPDK接入的限制不同。如Intel的同一网口是不能同时接入两个DPDK实例进程的，除非启用secondary模式，但secondary模式会带来诸多限制，所以一般来说，第二个OVS进程会接入不同的网口，这也会导致流量切换时要做特殊处理。而Mellanox同一网口可以同时接入两个DPDK实例，所以就不存在这个问题。

2、虚拟网卡后端适配

轻舟容器网络中管控面报文依赖于内核进行传输，同时为了提升性能，摒弃了internal口，而使用了virtio-user+vhost-net方式来打通用户态和内核态的传输路径。virtio-user口的收发逻辑是在DPDK层面实现的，目前还无法支持两个DPDK实例初始化相同的virtio-user口，需要做相应的适配开发。

3、代理

轻舟容器网络有完善的运维体系，整个热替换的升级过程需要能和现有的运维系统结合。而热替换过程为了降低OVS进程之间的耦合，2个OVS进程之间是不会相互通信的，也感知不到对方的存在，这就要求有一个代理来协调整个升级过程，并和运维系统无缝集成。

4、回退和回滚

整个热替换的过程从可用性的角度，需要能支持回退和回滚。

回退指的是版本已经热替换升级完成，但是现网运行过程中发现了版本中存在bug，需要通过热替换升级的方式进行回退升级到老的版本。这个过程应该和老版本升级到新版本一样，对过程中的业务中断时间也是一样的要求。

回滚指的是版本在热替换升级的过程中出现了问题，需要能回滚到升级前的版本。这里根据问题出现的阶段不同，回滚也会有不同的影响，在业务切换前完全可以做到业务不中断。

四、总结

随着微服务、服务网格以及Serverless等云原生技术的兴起，网络沉淀成为基础设施组件而对用户越来越不可见，但同时这也对整个网络的运维提出了更大的挑战，网络核心组件的热升级能力逐渐成为各大云厂商的标配。而类似热升级这种运维能力一向是开源软件的软肋，所以在产品化落地过程中不可避免的需要进行定制和增强，这也对云厂商的研发能力提出更高的要求。