Comware是H3C自主研发的一款应用于网络设备的网络操作系统,包含了丰富的网络功能,支持从SOHO到数据中心、从企业级到运营商级的全系列网络设备。
Comware的发展主要有两个方面:
• 功能的不断丰富:针对网络技术的发展以及设备应用场合的变化,增加新的功能,以适应不断变化的用户需求。
• 体系结构的不断完善:优化系统,使其更加简洁、通用及开放,以适应不同类型设备的要求以及网络设备的发展。
上一代的Comware V7版本,采用多进程的方式实现了完全的模块化。通过模块化使得系统在可靠性、虚拟化、多核多CPU应用、分布式计算、动态加载升级等方面都有了很大的改进。同时,Comware V7使用主流的Linux操作系统,使得网络操作系统从一个封闭的专用系统向更加通用、开放转变。Comware V7在一些细节上也进行了改进,例如使用抢先调度提高了系统的实时性。
但是,随着网络技术的不断演进,Comware V7在系统架构上也表现出一些不足,例如:开放性差,不支持容器;主要的转发功能都是在Linux内核态实现,无法利用业界先进经验;对内核强依赖,导致内核版本升级困难。
在Comware V7的基础上,Comware V9针对开放性、容器化、可编程性、可视化等需求,在体系架构上进行升级和调整,以更好地适应当前网络操作系统的发展趋势。
Comware V9具有如下优势:
• 采用原生Linux内核,Comware V9的功能完全在用户态实现。因此,Comware V9内核版本升级方便,且内核升级不会对业务功能产生大的影响。
• 支持容器化,支持以容器的形式发布Comware,同时支持在运行Comware V9的设备上部署容器运行第三方应用,提升Comware的开放性。
• 深化模块化设计思路,使得业务间相互独立,可以独立部署,或采用独立软件的形式发布Comware的某一个软件功能。
• 架构上充分考虑虚拟化形态产品的需求,实现轻量化的支撑架构,使得虚拟化形态产品的部署更加灵活快捷。
• 对于不间断业务升级(ISSU),Comware V9增加了对于单机ISSU的支持,解决单机情况下的升级问题。
图1 Comware V9总体架构
Comware V9的总体架构如图1所示,它由如下四个平面组成:
• 基础设施平面
在操作系统的基础上提供业务运行的软件基础,包括操作系统基础服务和业务支撑功能。基础服务功能是与业务无关的各种软件功能,包括Linux操作系统的各种基本功能、C语言库函数、数据结构操作、标准算法等。业务支撑系统是整个系统业务运行的基础,为Comware各业务提供软件和基础设施,后面提到的各种系统架构中涉及的基础功能均在这部分提供。
• 数据平面
提供数据报文转发功能,包括本地报文的收发,即socket、基于各层转发表的数据转发功能等。Comware V9的数据平面,支持基于DPDK(Data Plane Development Kit,数据平面开发套件)的转发模型。
• 控制平面
运行路由、MPLS、链路层、安全等各种信令和控制协议,生成各种转发表项以控制数据平面的转发行为。Comware V9的控制平面主要可以分为Layer2、Layer3、DC、MPLS等几类业务。
• 管理平面
对外提供设备的管理接口,如CLI、Telnet、SSH、SNMP、HTTP、Netconf、Restful和gRPC等。通过管理平面,实现对Comware V9进行设置、监控、管理。
Comware V9在模块化设计上做了增强。Comware V7版本虽然也实现了模块化,各个网络服务功能独立运行在各自的进程,但是对于支撑系统强依赖,无法独立发布。Comware V9在原有基础上,将支撑系统轻量化。实现业务之间完全独立,并且可以独立发布。
Comware V9的模块化具有如下特点:
• 粒度模块化:实现独立模块的软件故障封闭和故障修复,增强系统的稳定性。
• 模块间解耦:通过数据库+消息机制,减少模块间强依赖,实现各模块之间松耦合。
• 支撑系统轻量化:通过将支撑系统轻量化,最终实现可以独立发布的轻量化的网络功能。
• 业务独立部署:业务间相互独立,可以通过容器实现业务独立部署。
图2 Comware V9容器化结构
如图2所示,Comware V9采用了容器化架构,为Comware以及第三方应用提供独立的运行环境:
• Comware的基本功能运行在Comware容器中。
• Comware本身支持基于容器发布,以容器镜像形式发布虚拟化产品,通过业界广泛使用的K8S等管理工具进行管理。
• 可以通过独立的容器运行Comware的基本功能,并通过增加容器来运行扩展功能。例如,交换机上插无线插卡,无线功能部分可以封装成一个容器镜像文件,运行在独立的容器中。它运行时依附Comware基本功能,但是可以独立地升级而不影响基本功能部分。
• 在Comware V9的设备上,支持通过容器部署第三方软件。相对于Comware V7需要将第三方软件的源代码通过Comware V7的交叉编译环境,编译过才能运行在Comware上的集成方式,通过容器来部署第三方应用更加灵活方便,使得Comware的开放性有显著提升。
Comware容器和用户创建的容器均运行在Linux内核之上,直接使用物理设备的硬件资源,利用Linux namespace和cgroups等技术来实现容器间的隔离和资源分配控制。此外,Comware V9还支持Kubernetes技术,可作为一个节点接受Kubernetes Master的调度和管理,实现第三方应用的大规模、集群化部署。
图3 Comware V9支持K8S
Comware V9集成了K8S和Docker daemon,可作为一个节点接受Kubernetes Master的调度和管理,实现通过K8S对设备上运行的第三方容器进行大规模、集群化部署和集中式管理。对于管理员来说,在Comware V9设备部署和管理容器,和在服务器部署和管理容器使用的命令行和参数基本一致,不影响管理员的配置习惯。
1. 容器网络互通概述
Comware可以为第三方容器中的应用提供网络支持。运行在设备上的第三方应用,可以与Comware中的应用通信,也可以通过Comware与外界通信。
Docker使用命名空间来实现容器间的隔离。其中,网络命名空间用于隔离网络资源,例如IP地址、IP路由表、/proc/net目录、端口号等。用户在设备上创建容器时,可以选择是否和Comware共享网络命名空间。是否共享网络命名空间会影响容器和外界的通信方式以及网络参数的配置。
图4 Comware V9对容器的网络支持
2. 第三方容器与Comware共享网络命名空间
共享网络命名空间时,第三方容器中的应用类似于Comware的应用,使用Comware的网络参数,包括接口、IP地址、路由表、端口号等,与目的节点通信。
第三方应用与目的节点通信时,分为以下两种情况:
• 如果目的节点和Comware位于同一网段,则管理员不需要为第三方应用配置其他网络参数,目的节点使用Comware的IP地址即可与第三方应用通信。Comware根据报文协议号或目的端口号将报文发送给对应的应用处理,如果Comware中的应用和第三方应用侦听的协议号或目的端口号相同,则优先发送给Comware中的应用处理。
• 如果目的节点和Comware位于不同网段,则需要为第三方应用配置源IP地址,目的节点与这个源IP地址之间必须路由可达。第三方应用使用这个源地址与目的节点进行跨网段通信。
3. 第三方容器与Comware不共享网络命名空间
如果希望第三方容器使用独立于Comware的IP地址与其它容器/设备通信,或者不希望第三方应用看到Comware的地址和接口,在创建第三方容器时,可以选择第三方容器不与Comware共享网络命名空间。
不共享网络命名空间时,Comware使用Virtual-Eth-Group0接口为第三方容器及其应用提供网络支持。用户创建Virtual-Eth-Group0接口时,Comware会同时创建一个TPA(Third-party Application,第三方应用) bridge,不同容器中的第三方应用通过TPA bridge互相通信以及和外界通信。
4. 为宿主机上的应用提供网络支持(与Comware不共享网络空间)
宿主机和Comware不共享网络空间。宿主机上的接口由Comware来驱动和管理,直接运行在宿主机上的应用需要通过Comware的接口与外界通信。例如,Docker和Kubelet虽然是Comware中集成的功能,但是它们直接运行在宿主机上,Docker、Kubelet应用与Comware不共享网络空间。当Docker应用从Docker hub上拉取镜像或者向Docker hub上传镜像时,需要Comware为Docker提供网络支持。当Kubelet要接受Kubernetes Master的调度和管理时,也需要Comware为其提供网络支持。Comware通过Linux内核创建的缺省网桥Docker0 bridge为宿主机上的应用提供网络支持。
Comware V9通过数据库+集群的软件架构,提供基于网络功能的轻量化NFV(Network Function Virtualisation,网络功能虚拟化)软件,部署更加灵活、快捷,并可成倍提高部署效率、扩大部署规模,以满足云网融合的需求。
• Comware V9通过数据库架构,实现特性间的解耦以及高可靠性。解耦后的特性便于组合出各种功能结合的网络软件。Comware提供多种数据库功能(内部数据库、外部数据库、分布式数据库等)。特性可根据不同场景选择合适的数据库,从而兼顾灵活性与性能。
图5 Comware V9的数据库架构
• Comware支持软件集群,将Comware软件在多个网络节点上部署,这些节点组成一个集群,以实现软件特性的横向扩展及故障恢复。
图6 Comware V9的集群架构
数据库+集群的软件架构,使得Comware V9可以动态部署网络特性,并按需提供。Comware V9将网络设备的软件功能解耦,独立打包成镜像文件,真正做到按需将网络功能打包为容器化的NFV组件。这使得网络功能可以脱离交换机和路由器的硬件基础,部署在云网系统中,实现真正意义的NFV,而不是将设备软件简单运行在服务器上。
Comware V9提供各种基于网络功能的NFV组件,包括vBGPRR、vDHCP、vAAA、vBRAS、vLAS、vSR、vIPSec、vNAT、vFW和vAC等,并利用DPDK技术大幅提升了各NFV组件的报文处理性能。
Comware V9提供的NFV组件可以运行在不同硬件上,提供不同的网络功能,并彼此协同工作。通过扩展软、硬件资源,可以灵活、快捷地增加网络功能及处理能力,最终实现云网融合。
图7 Comware V9云网融合示意图
现代网络规模日益庞大,管理员希望网络管理工具拥有更高效的网络部署能力、反应快速的运维和调度手段。网络设备的可编程性可以满足上述需求。
Comware V9的可编程框架
Comware V9运行在原生的Linux系统上,使用不做任何修改的内核,为第三方软件提供标准的Linux运行环境,可以无缝运行第三方软件。
另外,Comware V9的可编程框架提供了丰富的配置手段,可以适配各种自动化配置模型,提升网络部署效率;并提供对外发布的编程环境和接口,第三方软件可以利用编程接口开发独有功能。
1. 丰富的配置手段
Comware V9支持丰富的配置手段,包括:
• 传统的命令行(CLI)和SNMP
• 服务于SDN架构的NETCONF和RESTful接口
• 广泛应用于Telemetry技术的gRPC软件框架
2. 支持多种脚本工具
Comware V9支持基于bash、TCL、python、Ansible的脚本工具。
3. 支持丰富的自动化工具
Comware V9支持puppet、chef、openstack等自动化配置工具。
4. 支持VCF Fabric服务
支持通过Neutron插件,在H3C VCF Fabric架构下进行自动组网配置。
5. 提供原生的Linux环境
Comware V9提供原生的Linux CLI环境。可以通过Linux的CLI对Comware V9系统进行配置和管理。
6. 第三方软件包管理
Comware V9支持在Comware中安装第三方RPM软件包。
7. 容器管理和编排支持
Comware V9集成Docker CE和K8S,支持通过K8S动态部署Comware扩展业务和第三方软件。
8. Comware V9 SDK可编程环境
Comware V9对外提供软件开发套件Comware V9 SDK(Software Development Kit,软件开发工具包)。第三方软件可以通过Comware V9 SDK与Comware来通信,通过编程实现功能定制。
Comware V9 SDK
SDK是软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。Comware V9 SDK为第三方软件或者配置工具提供编程接口或插件。第三方软件通过SDK与Comware通信;配置工具通过H3C插件实现对运行Comware V9设备的自动配置。
图8 Comware V9 SDK组成部分
如图8所示,Comware V9 SDK包括如下组成部分:
• SDK核心部分,包括: CSRE:SDK运行环境,支持C、Python、RESTful等。 CSDK Cores:SDK核心功能实现。 Plugins:为一些常见应用提供的官方插件。
• NES和APP,包括: NES:为SDK提供网络服务,运行在设备和NFV上。 CSDK APP:使用CSDK编程的第三方程序。 3rd APP:使用Plugins与CSDK交互的第三方程序。
图9 基于Comware V9 SDK开发的第三方软件的两种部署模式
如图9所示,Comware V9 SDK支持如下两种第三方软件部署模式:
• 本地部署模式 第三方软件所在的容器可以部署在Comware所在的物理设备或服务器上,通过Comware V9 SDK与本地Comware通信,实现数据获取、配置下发等功能。
• 云部署模式 第三方软件可以部署在云端,通过Comware V9 SDK与远端的Comware通信。
Comware V9 SDN屏蔽了两种部署模式的实现差异,第三方软件根据需要选择任何一种部署方式,均可以达到相同的效果。
网络运维的过程中,需要实时收集网络设备的运行状态、流量统计、告警信息等数据,对网络进行实时监控,以便及时发现和排除网络故障。传统的手段是用网管软件通过SNMP获取设备的信息。这种手段无法解决目前的网络监控需要解决“看不见”的问题,如快速定位哪台网络设备的哪个端口丢包、实时监控每台网络设备buffer的使用情况、端到端延时定位到具体链路等。
Network Telemetry(网络遥测)技术通过在网络设备上实现主动推送数据的能力,解决了SNMP时效性差、CPU消耗高等问题。
Comware V9支持如下几种Telemetry实现方式:
• 基于gRPC(Google Remote Procedure Call,Google远程过程调用)或GNMI(gRPC Network Management Interface,gRPC网络管理接口)的Telemetry
• 基于INT(In-band Telemetry,带内遥测)的Telemetry
• 基于ERSPAN(Encapsulated Remote Switch Port Analyzer,封装远程端口镜像)的Telemetry
Telemetry通过gRPC、INT或ERSPAN将网络设备上的数据主动推送给网管或监控软件。基于网络中各个设备推送的数据,整个网络对网管或监控软件“可见”,实现网络的可视化,为网络维护、突发流量处理、流量调度等提供支持。
目前,应用最为广泛的是基于gRPC/gNMI的Telemetry。它是一种模型驱动(model-based)的Telemetry技术。第三方软件可以直接使用gRPC/gNMI与Comware通信,也可以使用基于gRPC封装的Comware V9 SDK接口与Comware通信。gRPC支持Dial-in和Dial-out两种模式,可以实时将订阅的数据从设备主动推送给网管或监控软件。
图10 基于gRPC/gNMI的Telemetry
对于系统虚拟化有两种方式:一种是将多个物理设备虚拟为一个逻辑设备,称为N:1的虚拟化;另一种是将一个物理设备虚拟为多个逻辑设备,称为1:N的虚拟化。Comware V9同时支持这两种虚拟化,并且支持两种虚拟化的混合使用。
IRF(N:1)
IRF堆叠是将多台设备通过堆叠口连接在一起形成一台虚拟的逻辑设备的技术。此逻辑设备在管理上可以看作是单一实体,用户使用Console口或者Telnet方式登录到IRF中的成员设备,可以对整个IRF进行管理和配置。逻辑设备在网络中也相当于一台单一的设备运行,无论对控制协议还是数据转发来说,都是网络中的单一节点。
IRF是一种通用的N:1虚拟化技术,可以应用于多种类型的网络设备,进行多种形式的虚拟化:
• 可以进行同种设备的虚拟化:将多个盒式设备进行堆叠,形成一个分布式的设备,每个盒式设备相当于逻辑的分布式设备的一个主控板;将多个分布式框式设备进行堆叠,形成具有更多的主控板、接口板的分布式设备;进行核心设备的级联。
• 可以进行异种设备的虚拟化:将盒式设备与其他设备连接,作为逻辑设备的一个接口板使用。
图11 IRF虚拟化
IRF技术忽略拓扑的差异,将各种方式连接的多个物理设备虚拟为有多个主控系统和接口板系统的普通分布式设备。由于IRF技术产生的逻辑设备与普通分布式物理设备相同,因此在功能上没有任何损失,可以支持普通设备的全部功能。并且每个功能在IRF逻辑设备与普通物理设备上没有任何差异,用户可以像使用普通设备一样使用IRF生成的逻辑设备,这样给用户的管理和维护带来很大的方便。
图12 IRF形成的逻辑设备
由于通过IRF技术可以将较低端的设备虚拟成为一个相对高端的设备使用,因此IRF同时具有了高端设备和低端设备的优点。一方面可以像高端设备一样具有更高的端口密度和带宽,以及主备主控板冗余保护的功能,具有更高的可用性。另一方面成本却像低端设备一样低廉。
IRF虚拟化保留了被虚拟化的物理设备的全部能力,对原有设备能力的发挥没有任何限制。例如,对于分布式设备,本身就具有主备主控板的冗余保护功能,将分布式设备堆叠时,原有的主备主控板保护功能仍然起作用,IRF技术只是在原有可用性功能的基础上进一步提高了系统可用性。
IRF链路故障会导致一个IRF变成两个新的IRF,这两个IRF拥有相同的IP地址等三层配置,会引起地址冲突,导致故障在网络中扩大。Comware V9可以通过LACP、ND、ARP、BFD等多种方式快速检测出这种故障,以避免冲突的发生。
总之,IRF作为一种N:1虚拟化技术,可以简化网络,使得网络更加易于管理,同时具有强大的扩展能力,保护用户投资,对系统的可靠性、性能也有很大提升。IRF技术在支持设备类型的广度上,以及功能的全面性上也有自己的特点。
M-LAG(N:1)
M-LAG(Multichassis link aggregation)是一种跨设备链路聚合技术,将两台物理设备在聚合层面虚拟成一台设备来实现跨设备链路聚合,从而提供设备级冗余保护和流量负载分担。
如图13所示,Device A与Device B组成Multichassis link aggregation系统,通过peer-link链路交互协议报文、同步信息。当其中一台设备发生故障时,流量可以快速切换到另一台设备,保证业务的正常运行。
图13 M-LAG网络模型示意图
MDC(1:N)
图14 MDC虚拟化
MDC技术是一种1:N虚拟化技术,它将一台物理设备虚拟成多台逻辑设备。
从软件上看,它将网络操作系统的数据平面、控制平面、管理平面进行了完全的虚拟化,形成多个虚拟的逻辑设备,各逻辑设备软件完全隔离。在内核态,各逻辑设备虽然共用一个内核,但内核中逻辑设备间数据是分离的;在用户态,每个逻辑设备独立启动运行各自的用户态进程,一个逻辑设备的进程异常,对其他逻辑设备完全不会造成影响。在数据转发方面,各逻辑设备有独立的转发表及协议栈,每个物理端口可以被一个逻辑设备独占使用,因此各逻辑设备的数据流不会相互干扰。
在硬件上,可以将端口、单板、存储空间、CPU等资源划分给独立的逻辑设备使用,使得逻辑设备非常接近于一个单独的物理设备。逻辑设备具有完全的设备功能,各程序在逻辑设备内运行与在物理设备上运行没有差异。可以像重启一台物理设备一样,单独重启一个逻辑设备,不会影响物理设备上其他逻辑设备的正常运行。
使用MDC技术可以方便地将一个物理网络虚拟成多个网络,满足不同的组网需求。同时,MDC技术还可以用于网络技术培训,将一台设备虚拟为多台设备供多人分别使用,可以有效的提高设备使用效率,降低成本。
IRF与MDC配合使用(N:M)
Comware V9还支持两种虚拟技术的混合使用,可以将物理设备组合成需要的逻辑设备使用。即,可以将多个设备通过IRF技术形成一个大的虚拟的逻辑设备,再通过MDC技术将此逻辑设备进一步分割为多个虚拟设备使用。
图15 虚拟化的混合使用
这两个技术一起使用可以最大限度的整合设备资源,将设备按照组网需要虚拟成逻辑设备使用,提高设备的使用效率。另一方面通过两种虚拟化技术一起使用可以同时获得两种技术的优点。例如,使得每个逻辑设备同时获得IRF的主备主控板保护,相对于使用单个设备组网,提高了可用性。
两个技术的混合使用,还提高了系统的扩展性和使用的灵活性。在已经使用MDC技术的设备上,可以通过IRF技术在不改变网络部署的情况下扩展设备的端口数、带宽及处理能力。而在已经使用IRF技术的场合,再使用MDC功能时也无需重新构建网络,可以直接在IRF的基础上使用MDC功能,部署新的网络,对现有网络不产生任何影响。
M-LAG与MDC配合使用(N:M)
Comware V9还支持M-LAG和MDC两种虚拟技术的混合使用。使用方法为:先通过MDC技术将每台物理设备划分为多台虚拟设备,再通过M-LAG技术在多台虚拟设备之间建立M-LAG系统。
图16 M-LAG和MDC虚拟化技术的混合使用
M-LAG和MDC混合使用具有如下优点:
• 能够根据组网需求灵活配置虚拟设备的资源,从而可以最大限度地整合设备资源,提高设备的使用效率。
• • 在不同物理设备虚拟出的MDC之间,通过M-LAG形成冗余保护和流量负载分担。
对于集中式设备,以及分布式设备的单主控场景,无法通过主备依次升级来实现ISSU,可以采用单机ISSU的形式来升级。
单机ISSU是通过双容器来实现不间断服务的版本升级。如图17所示,老版本在容器C1中运行,升级版本时,先创建容器C2运行新版本的Comware。两个容器中的Comware以主备身份存在,其中C1中的老版本Comware为主节点,C2中的新版本Comware为备节点。主备节点通过HA备份数据,主节点将必要的运行数据写入共享数据库。数据备份与保存完成后,关闭C1,触发主备倒换,C2中的Comware完成备升主的操作,C2中的新版本Comware通过共享数据库恢复数据,最终实现了版本升级。
而在此过程中,由于整个操作系统并未重启,底层芯片的转发依然在正常进行。而对于协议报文的处理,只是在两个Comware主备倒换的瞬间受到影响。配合协议模块的NSR,可以保证协议不断链、不产生路由震荡等不良影响。
图17 Comware V9单机ISSU过程
作为Comware系列网络操作系统的最新一代版本,Comware V9在继承了Comware系统原有特点(功能丰富、性能高、单一系统可以支持多种硬件结构设备等)的基础上,针对行业发展对网络操作系统的新要求,扩展了开放性、容器化、可编程架构等功能,可以更好地支持各种新业务场景和用户需求。