建木持续集成平台是基于建木自动化平台提供的国产开源CI/CD产品，致力于为国内开发者提供简单易用、方便快捷的开发体验，推广DevOps的最佳实践，填补国内开源软件供应链中缺失的一环。

建木持续集成平台v1.1.1现已发布

主要更新：修复若干已知bug，含下列issue

• 事件桥接器删除无明确提示删除桥接器的名称
• 中英文自宽导致删除按钮浮现时会挡住后面的省略号
• 鼠标滑过节点时浮现的操作按钮会出现在其他节点上
• 新增事件桥接器输入目标唯一标识，输入长度问题
• condition后面的节点执行完毕之后，流程没有自动结束
• 可删除运行中的项目，应禁止

“建木”是上古先民崇拜的一种圣树，传说建木是沟通天地人神的桥梁。伏羲、黄帝等众帝都是通过这一神圣的梯子上下往来于人间天庭。《淮南子·墬形训》亦曰：“建木在都广，众帝所自上下。日中无景，呼而无响，盖天地之中也。”

为此项目命名为“建木”，希望本项目也可以成为不同业务场景下系统间相互沟通的桥梁。建木自动化平台以触发器、流程编排、任务分发等功能为平台核心，可以应用在各类使用场景下，包括但不限于，CI/CD、DevOps、自动化运维、多业务系统集成等场景。

所属社区

“木兰开源社区”建立于2019年8月，是国家重点研发计划重点专项“云计算和大数据开源社区生态系统”的核心成果。旨在促进产学研用各方开源领域的交流，推动国家科技创新成果开源，加强企业、科教研单位和行业用户之间的沟通，推动开源成果转化落地，同时为各类开源项目提供中立托管，保证开源项目的持续发展不受第三方影响，通过更加开放的方式来打造和完善开源社区生态。

参与单位

项⽬官⽹：https://jianmu.dev/

项⽬托管：https://gitee.com/jianmu-dev

项⽬文档：

https://docs.jianmu.dev/guide/index.html

在线体验：https://ci.jianmu.run/

关于九州云：

九州云成立于2012年，是中国早期从事开放云边基础架构服务的专业公司。公司成立九年，始终秉承“开源·赋能云边变革”的理念，完成了从中心云到边缘云解决方案的拓展和积累，建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、爱立信等众多重量级客户。

背景

用户Pike版OpenStack，Firewall drivers为Openvswitch。OpenStack内一租户网络下多台虚拟机中部署一个K8S集群，其中OpenStack下租户网络使用VxLAN，K8S集群采用Calico IPinIP网络方案。

故障发生

用户报告K8S集群中Pod偶发网络不通。故障表现随机。并不固定在某些计算节点，也不固定于某些虚拟机，出现时间随机；用户在不变动任何OpenStack内虚拟机或网络资源的情况下，仅仅重建Pod，即恢复正常。而且出现网络中断的Pod原本处于正常通讯的状态。由于前两次用户通过重建Pod解决故障，并未留下现场尸体，排查并没有实质性进展。遂让用户下次出现同样故障时留下现场待排查根源后再恢复。PS：Random failure is quite a challenge.

故障现场

偶发的一次机会让我们再次遇到了这个事故现场。如下图显示位于不同计算节点中的Pod两两互Ping，仅其中一对Pod出现Ping不通的情况。

 

通过对这两个Pod所在节点（下图T1、T2、P1、P1）进行抓包，初步断定了丢包点位于Com1的br-int上。Pod1发出的ICMP Response在br-int上不翼而飞。

在Pod上持续Ping的同时，观察Com1节点br-int上流表定位到了这条流表的计数在同步增长。同步查看该OVS上的连接跟踪记录，可以明显看到VM1至VM2的协议号为4（即IPinIP报文）的流被标记为“mark=1”。基本可以确认VM1至VM2的IPinIP报文命中了这一条流表，导致Pod1与Pod2不通。

持续丢包的流表

cookie=0xcccccccccccccccc, duration=8725.531s, table=72, n_packets=16642, n_bytes=1668970, idle_age=0, priority=50,ct_mark=0x1,reg5=0x362 actions=drop

异常情况下的连接跟踪

4,orig=(src=192.168.0.33,dst=192.168.0.35,sport=0,dport=0),reply=(src=192.168.0.35,dst=192.168.0.33,sport=0,dport=0),zone=49,mark=1

故障分析

Pike版OpenStack br-int 上table 72中的流表项目与虚拟机对应的Port 出向Security Group有关（在Neutron代码中表72的宏定义名称即为rulers_egress_table）。接下来我们分析下为什么会出现这样的状况。

正常情况

正常情况下，通过IPinIP的ICMP Response报文会在表72中命中下述流表，进行正常的转发。

cookie=0xcccccccccccccccc, duration=8725.528s, table=72, n_packets=68693, n_bytes=12470448, idle_age=0, priority=77,ct_state=+est-rel-rpl,ip,reg5=0x362,nw_proto=4 actions=resubmit(,73)

异常情况

异常情况下，对应上述的流表依旧存在，却没有命中；而是命中了低优先级的

ct_mark=0x1,reg5=0x362 actions=drop。若要命中该流表，对应流量就必须先行命中ct_state=+est,ip,reg5=0x362

actions=ct(commit,zone=NXM_NX_REG6[0..15],exec(load:0x1->NXM_NX_CT_MARK[]))，将连接跟踪表中的mark置为1(invalid)但这些状况在正常情况下不应出现。

cookie=0xcccccccccccccccc, duration=8725.528s, table=72, n_packets=68693, n_bytes=12470448, idle_age=0, priority=77,ct_state=+est–rel–rpl,ip,reg5=0x362,nw_proto=4 actions=resubmit(,73)

cookie=0xcccccccccccccccc, duration=8725.531s, table=72, n_packets=16642, n_bytes=1668970, idle_age=0, priority=50,ct_mark=0x1,reg5=0x362 actions=drop

cookie=0xcccccccccccccccc, duration=8725.531s, table=72, n_packets=2, n_bytes=156, idle_age=8725, priority=40,ct_state=+est,ip,reg5=0x362 actions=ct(commit,zone=NXM_NX_REG6[0..15],exec(load:0x1->NXM_NX_CT_MARK[]))

进一步观察流表（duration值），可以发现三条流表的生存周期有0.03s的轻微时间差，本应正确命中的流表比当前异常情况下命中的流表晚下发了0.03秒。至此可以得出一个初步的故障原因结论：0.03秒的流表下发时间差导致了当前流量的中断。具体分析如下图。

仔细观察Neutron代码，也可以发现流表的下发流程之中，_initialize_tracked_egress，也发生在create_flows_from_rule_and_port之前。

def _initialize_tracked_egress(self, port):

    # Drop invalid packets

    self._add_flow(

        table=ovs_consts.RULES_EGRESS_TABLE,

        priority=50,

        ct_state=ovsfw_consts.OF_STATE_INVALID,

        actions=‘drop’

    )

    # Drop traffic for removed sg rules

    self._add_flow(

        table=ovs_consts.RULES_EGRESS_TABLE,

        priority=50,

        reg_port=port.ofport,

        ct_mark=ovsfw_consts.CT_MARK_INVALID,

        actions=‘drop’

    )

    ……

 

def add_flows_from_rules(self, port):

    self._initialize_tracked_ingress(port)

    self._initialize_tracked_egress(port)

    LOG.debug(‘Creating flow rules for port %s that is port %d in OVS’,

              port.id, port.ofport)

    for rule in self._create_rules_generator_for_port(port):

        # NOTE(toshii): A better version of merge_common_rules and

        # its friend should be applied here in order to avoid

        # overlapping flows.

        flows = rules.create_flows_from_rule_and_port(rule, port)

        LOG.debug(“RULGEN: Rules generated for flow %s are %s”,

                  rule, flows)

        for flow in flows:

            self._accept_flow(**flow)

 

    self._add_non_ip_conj_flows(port)

 

    self.conj_ip_manager.update_flows_for_vlan(port.vlan_tag)

安全组流表的更新通常发生在安全组更新之后，通过对上述流表生存周期与排查时间的反推，得到的安全组更新时间与OpenStack显示的用户更新安全组时间一致。根据用户的反馈，故障察觉时间也与安全组更新时间高度吻合。

最终结论

用户更新虚拟机的安全组，OVS agent更新安全组流表规则存在的时间差，好巧不巧，恰好在该短暂的时间差内，虚拟机中容器正在进行通信，导致流量被先行下发的流表错误标记为invalid，并记录了conntrack，后续流量进而持续被drop，无法继续正常通信。

关于九州云：

九州云成立于2012年，是中国早期从事开放云边基础架构服务的专业公司。公司成立九年，始终秉承“开源·赋能云边变革”的理念，完成了从中心云到边缘云解决方案的拓展和积累，建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

Skyline 是由 OpenStack 资深厂商九州云捐献给 OpenStack 社区的一款现代化的 OpenStack 管理界面（Dashboard），可以在 OpenStack 社区代码托管网站 OpenDev 上了解项目详情：

https://opendev.org/skyline/skyline-apiserver/src/branch/master/README-zh_CN.md

OpenStack 自 2010 年问世以来，历经十多年的快速发展，其社区贡献者之多，参与厂商之广，影响之深远，可谓前不见古人，后难见来者。Horzion 是 OpenStack 社区默认推荐的 Dashboard 平台，但因其 UI 简陋、技术栈陈旧、性能和用户体验性较差等原因，被广大 OpenStack 用户诟病已久，可谓“天下苦 Horizon 久矣”。但遗憾的是，社区一直没能对 Horizon 进行整体技术升级，或者推出另一款更优秀和现代化的 Dashboard 供用户选择。今天我们很高兴看到，九州云捐献的 Skyline 项目填补了这一空白。

九州云是 OpenStack 黄金会员，自 2012 年开始参与 OpenStack 社区贡献，拥有多名 Core Developer 和 PTL，此次捐献的 Skyline 项目也另我们耳目一新。

1. 简单至上

Skyline 秉承了“Less is more”的设计哲学，保持“简单至上”，包括安装部署、用户操作、架构设计等方方面面。

1.1 简单上手：从一个 Docker 镜像开始

从官网可以看到，如果想试用 Skyline，可以从一个 Docker 镜像轻松开始。

1.2 框架简明清晰

从 Skyline 官网可以看到，Skyline 分为两个模块：apiserver 和 web console。

Skyline apiserver 模块基于 Python Fastapi 框架（一个高性能的 Python 异步 Web 框架）实现，相当于 Horizon API，但简单得多。Skyline apiserver 将绝大多数 OpenStack API 直接透传给 OpenStack endpoints，而不像 Horizon API 一样增加适配层。这样一来，我们就可以轻松地从浏览器的开发者工具中看到绝大多数的 OpenStack API 请求被直接发送到 OpenStack endpoints，请求和返回信息都会非常直观，这样就大大降低了系统出错时 Trouble Shooting 的难度。

Skyline console 是一个 JavaScript React 纯前端框架，不包含 Node.js，完全运行在浏览器上，非常轻量，且保持无状态。

Skyline 支持扩展，可以支持诸如计费、监控、计划任务等增值服务。

2. 功能强大

2.1 覆盖了 IaaS 云平台的几乎所有功能

得益于九州云多年来深耕 OpenStack 的技术和客户需求经验积累，Skyline 从捐献之初其功能就已经非常完整，除了对计算、存储、网络的虚拟化支持完备之外，对于安全中心、计费分析、运维管理、Heat 编排、监控告警也有了很全面的支持（部分模块需要企业扩展包支持）。

在管理界面上，Skyline 也覆盖了所有管理员需要的几乎所有功能模块，包括 workflow（需要企业扩展包支持）和全局设置等。

2.2 在细节上更懂你

Skyline 界面在很多细节颇具匠心，令人赞叹。

比如虚拟机详情页中，我们可以直观地看到 VM 的所有信息，包括 USB 和 GPU 信息。

在网络模块中，不仅包含了 VPN / 负载均衡 / QoS / 虚拟网卡，还以更清晰的 topo 展示了网络。

在个人中心，可以总览该用户相关的项目、工单、和审批流程。

3. Skyline的发展动向

Skyline 还在快速成长中，预计 2021 年国庆前会完成与社区 Zuul CICD / DevStack / Kolla 等工具和项目的融合，届时 Skyline 会更稳定可靠，其部署安装也会更方便快捷。

Skyline 开发团队与 Horizon 项目开发者的合作讨论也在同步进行中，我们希望看到尽快看到社区开发团队能精诚合作，合力打造出优秀的 OpenStack Dashboard 项目。

4. 小结

Skyline 是九州云捐献到社区的诚意和匠心之作，正如其官网所述：“Skyline 的吉祥物是九色鹿。九色鹿源自于敦煌壁画《九色鹿本生》，其寓意是佛理因果和知恩图报，这与九州云自创办以来秉持的拥抱和反馈社区理念一致。我们也希望 Skyline 像九色鹿一样，轻巧、优雅，而又能力强大，为 OpenStack 社区和用户提供更优质的 Dashboard。”

我们很高兴看到国内的云计算企业开始向社区回馈贡献高质量的项目，希望这个项目能茁壮成长，也希望看到更多的优秀开源项目不断涌现出来。

关于九州云：

九州云成立于2012年，是中国早期从事开放云边基础架构服务的专业公司。公司成立九年，始终秉承“开源·赋能云边变革”的理念，完成了从中心云到边缘云解决方案的拓展和积累，建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

OpenStack社区正式发布第23个版本 – Wallaby， OpenStack专注于开源基础设施软件的广泛开发与部署，作为全球三大活跃的开源项目之一（包括Linux kernel与Chromium），始终注重激发全球社区活力，提升社区开发者的参与度。

 

最新版Wallaby增强了安全性能，实现了与其他开源技术的进一步集成，进而强化了开源基础设施在云原生领域的应用。来自45个国家140家组织/机构的800多位贡献者所提交的17,000代码修改已成功合并至Wallaby版本。

 

OpenStack Wallaby版本现已上线！欢迎体验!

https://www.openstack.org/software/wallaby/

 

Wallaby版本要点：

除广泛改进OpenStack内核的稳定性与可靠性，提升项目集成功能的灵活性外，Wallaby版本还强化了安全性能，包括改进回退权限及Ironic、Glance及Manila组件中基于角色的访问控制(RBAC)权限，在该版本的开发周期中，社区重点关注将RBAC策略文件格式由JSON迁移至YAML。此外，Ironic还扩展了UEFI（统一可扩展固件接口）的功能，包括NVMe的安全擦除。

 

Wallaby版本的其他特性：

• 数个项目团队通过强化对其他开源项目的支持，将OpenStack作为开源集成引擎持续进行开发：Kolla（可用于生产实践的容器化部署工具）添加了对Prometheus version 2的支持，Magnum（容器编排服务引擎，可提供统一API）同步了Kubernetes、containerd的更新版，Cinder（块存储服务）添加了对Ceph后端驱动程序Ceph iSCSI的支持。

• Tacker（NFV编排）添加了与ETSI NFV所定义的标准一致的新功能，包括增加了可用于虚拟网络功能（VNF）扩展、更新及回滚操作的APIs，并可为ETSI NFV中的订阅和通知提供基本的VNF生命周期管理支持。

• Nova（计算资源配置）与Cyborg（加速器管理）持续集成，新功能使用户可释放/取消释放增强实例、附带Cyborg加速器的Nova实例。

• Cinder（块存储）添加了新的后端驱动程序，多个驱动程序添加了对不在驱动功能范围内的某些功能的支持，在本次开发周期中，恢复快照及后端QoS功能尤其流行。

• 运营商可通过Neutron将网络端口中的固定IP地址路由到外部世界，而不受IPv4地址范围的限制。

 

了解更多版本详情：

https://releases.openstack.org/wallaby/highlights.html

Kendall Nelson，开源基础设施基金会OpenStack社区上游开发倡导者表示：“OpenStack已经发布至第23版，很开心这个全球性的社区正持续成长且充满活力，不断为OpenStack项目进行贡献。OpenStack社区一直是全球最活跃的三大开源社区之一，OpenStack Wallaby版本的发布展示了成功的社区协作模式如何保持软件的茁壮成长与高效开发，持续推动创新，为新兴用例提供技术支持，并实现跨项目与平台间的交互操作。”

 

开源基础设施的演进

OpenStack于10年前率先提出开源基础设施理念，并逐步成为开源基础设施即服务（IaaS）的事实标准。近年来，人工智能、机器学习、边缘计算及物联网等领域涌现出众多新的需求，推动OpenStack项目为新的芯片架构及裸金属的自动化扩展等提供支持，实现了与众多开源组件的集成。如今，OpenStack为全球75个公有云数据中心以及上千个私有云的运行提供技术支持，整体部署规模逾1500万计算核心，OpenStack基础设施平台适用于裸金属、虚拟机（VMs）、图形处理单元（GPUs）及容器等多种架构的部署。

 

线上项目小组集会（PTG）

开源基础设施基金会将于4月19-23日举行线上项目小组集会，基金会统一安排活动时间及地点，并提供必要的活动设施，让那些为OSF项目（包括代码提交、文档生产、运维人员或用户等）做贡献的各技术团队成员进行高效协作与交流，推动基金会各项目的发展。PTG对各项目下一个软件版本的开发至关重要，各小组成员不仅会讨论如何改进软件的核心功能，还会开展跨项目协作，解决复杂问题。运营商、开发人员和其他活跃的贡献者将讨论团队在未来几个月的优先事项，以及如何高效实现各项目小组的目标，建立互信互助关系，最终达成统一意见，并按照既定计划协作完成各项工作任务。如需注册参会或了解本次项目小组集会详情，请访问：openstack.org/ptg。

 

关于OpenStack®

OpenStack是唯一可在单一网络中提供APIs来编排裸机、虚拟机及容器资源的开源集成引擎，该项目背靠全球社区的支持，来自188个国家的100, 000多名社区成员进行技术协作与创新，与行业伙伴共同构建开源生态，为全球公有云和私有云平台的运行提供技术支持，进而实现软件开发的成本节约、可控和可移植性。

 

访问OpenStack官网，了解更多详情：www.openstack.org

 

关于开源基础设施基金会(OpenInfra Foundation)

开源基础设施基金会致力于构建多样化的开源社区，推进开源基础设施软件在实际生产中的应用。在全球188个国家/地区100,000余名社区成员的支持下，OIF托管了多个开源项目和实践社区，涉及人工智能、容器云原生应用、边缘计算及数据中心等基础设施领域。欢迎加入开源基础设施基金会！www.openinfra.dev

九州云成立于2012年，是中国早期从事开放云边基础架构服务的专业公司。公司成立九年，始终秉承“开源·赋能云边变革”的理念，完成了从中心云到边缘云解决方案的拓展和积累，建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

1. 前言

新⼀代数据中⼼的典型特点是从 “物理服务器互联” 转变为 “虚拟机” 互联。虚拟化技术为数据中⼼带来了服务器整合、业务连续性和弹资源性等优势，也给数据中⼼带来了新的挑战，即：如何实现针对虚拟机的服务器⽹络接⼊技术。

2. VEB技术

VEB（Virtual Ethernet Bridge，虚拟以太⽹交换机）是虚拟机与服务器⽹络接⼊层之间的⼀个新的⽹络层。解决的是同⼀服务器中不同虚拟机如何通过同⼀张物理⽹卡与外部⽹络进⾏通信，以及这些虚拟机之间如何互相通信的问题。最初为通过纯软件⽅式实现的 vSwitch，后续为了解决性能问题也出现了基于 SR-IOV ⽹卡的 Hardware-based VEB 实现。

vSwitch

以软件实现的 vSwitch：实现⽅式简单，技术兼容性好，典型软件有：Open vSwitch、VMware ESXi。

• VMware ESXi，由 VMM 内嵌的 VEB：

• Open vSwitch，在服务器上运⾏的（第三⽅）VEB：

vSwitch ⽅案具有以下优点：

• 本地虚拟机之间的报⽂转发性能好，流量不出卡。

• 节省接⼊层物理交换机设备，⼀张物理⽹卡⽀持多个虚拟机。

与外部⽹络的兼容性好，不需要对外部⽹络进⾏改造。缺点：

• 占⽤服务器的 CPU 资源。

• 只能实现简单的 L2 转发。

• 缺乏⽹络流量的可视性，例如：端⼝报⽂统计、端⼝流镜像、Net Stream 等，导致虚拟机之间的流量⽆法被⽹管系统所监管，另⼀⽅⾯也使得⽹络发⽣故障时，难于定位问题原因。

• 缺乏⽹络控制策略的实施能⼒，例如：端⼝安全，QoS、ACL 等，导致限制了数据中⼼的端到端⽹络控制策略的部署能⼒。

• 缺乏管理可扩展性，vSwitch 数量剧增，且与外部⽹络⽆法进⾏统⼀管理。

• VEB 的以上这些缺陷，最终导致了计算资源和⽹络资源的管理界⾯模糊，继⽽解决了服务器团队和⽹络团队的管理定界问题。

HW VEB

以硬件实现的 SR-IOV ⽹卡设备：借助⽀持 SR-IOV 特性的⽹卡可以实现基于 HW VEB。

HW VEB 的设计思想是：将 vSwitch 的交换功能 offload 到硬件设备，通过⽹卡硬件改善 vSwitch 占⽤ CPU 资源⽽影响虚拟机性能的问题。HW VEB ⽅案必须采⽤⽀持 SR-IOV（Single-Root I/O Virtualization）特性的 PCIe⽹卡，否则⼀张物理⽹卡⽆法映射到多个虚拟机上。

• Intel x710 VEB

在 HW VEB ⽅案中的 VMM（e.g. ESXi、KVM）只需要实现 SR-IOV ⽹卡设备的驱动程序（e.g. 资源分配、中断处理等）⽽不再参与虚拟机与外部⽹络，以及虚拟机之间的报⽂转发流程。

• 对于虚拟机发往外部⽹络的报⽂，由虚拟机操作系统的驱动程序直接操作⽹卡寄存器进⾏发送；

• 对于外部⽹络发往虚拟机的报⽂，⽹卡设备根据 dstMAC，将报⽂放⼊虚拟机对应的接收队列，虚拟机操作系统的驱动程序再通过 DMA 或中断⽅式进⾏接收处理；

• 对于同⼀物理服务器中的虚拟机之间的报⽂转发，⽹卡通过查讯内部 MAC table（静态配置，通常不⽀持 MAC 学习）进⾏转发处理。

基于 SR-IOV 技术的 HW VEB ⽅案的优点：

• 硬件设备、SR-IOV VF 直通，所以报⽂转发性能⾼。

但是，HW VEB 依然存在不能有效解决虚拟机流量可视化、⽹络策略实施及管理可扩展性等问题，甚⾄会由于硬件设计、成本等原因还恶化了这些问题。

3. 虚拟机流量感知技术

为了解决 VEB 技术存在的问题：缺乏⽹络流量的可视性、缺乏⽹络控制策略的实施能⼒、 缺乏管理可扩展性，需要反思两点原因：

1. 虚拟机之间的本地流量不出卡。

2. 虚拟机在外部⽹络的流量没有标识信息。

所以，解决问题的办法⾃然是：

1. 把虚拟机的⽹络流量纳⼊传统⽹络交换设备的管理之中

2. 同时还需要对虚拟机的流量做标识。

这就是所谓的虚拟机流量感知技术。对此，思科和惠普两⼤联盟分别提出了⾃⼰的解决⽅案：

• 思科和 VMware 主推的是 VN-Tag 技术，标准为 802.1Qbh BPE（Bridge Port Extension，端⼝扩展设备）：尝试从接⼊层到汇聚层提供⼀个完整的虚拟化⽹络解决⽅案，尽可能达到软件定义⼀个可控⽹络的⽬的。它扩展了传统的⽹络协议，因此需要新的⽹络设备⽀持，成本较⾼。

• 惠普、Juniper、IBM、Qlogic、Brocade 主推的是 VEPA（Virtual Ethernet Port Aggregator，虚拟以太端⼝汇聚器），标准为 802.1Qbg EVB（Edge Virtual Bridging，边缘虚拟交换机）：尝试以较低成本利⽤现有设备改进软件模拟的⽹络。

EVB

EVB 将 VEPA 作为基本实现⽅案，将多通道技术（Multi-Channel Technology）作为扩展⽅案。由于EVB 要求将所有的虚拟机流量都引向外部的物理交换机，因此与虚拟机相关的流量监管、控制策略和管理可扩展性问题得以解决。但同时也带来了更多⽹络带宽开销和转发时延的问题。需要注意的是，EVB的出现并不是完全替换 VEB ⽅案，但是 EVB 对于需要对虚拟机流量进⾏感知的场景⽽⾔，是⼀种优选的⽅案。

• VEPA

上图显示了 VEPA 的基本概念：在服务器中，物理⽹卡将虚拟端⼝根据⼀定的规则进⾏分组，完成端⼝分组（Port Group）功能。同时这个⽹卡设备能够对外抽象出被分为⼀组的端⼝，将属于同⼀组端⼝的数据⼀起投递出去，完成端⼝汇聚功能（Port Aggregation）。

VEPA 的核⼼思想是：将虚拟机产⽣的⽹络流量（包括本地流量和外部流量）全部强制地交由与服务器相连的物理交换机进⾏处理，然后物理交换机再将数据返回进来，⽽不再通过本地虚拟交换机来处理。我们知道，传统物理交换机的数据帧是不能从进⼝出去的，所以需要对物理交换机硬件作修改，允许其绕回。如下图，由 VM1 发往 VM2 或 VM3 的报⽂，⾸先被发往外部交换机，查表后，报⽂沿原路返回服务器，这种⼯作模式称之为发卡弯（hairpin turn）转发。

NOTE 1：以太⽹交换机在处理报⽂转发时，对于从⼀个端⼝上收到的报⽂，不会再将该报⽂从该端⼝发回。因此，当使能 VEPA 特性的服务器接⼊到⼀个外⽹交换机上时，该交换机相应端⼝必须⽀持上述 “发卡弯” 转发⽅式。可幸的是，当前⼤多数交换机的硬件芯⽚都能⽀持这种 “发卡弯” 转发特性，只要修改驱动程序即可实现，不必为⽀持 “发卡弯” ⽅式⽽增加新的硬件芯⽚。

NOTE 2：另⼀个由 VEPA 技术引起的变化是服务器对从外部⽹络接收到组播或⼴播报⽂的处理⽅式。由于 VEPA 从物理⽹卡上收到的报⽂可能是来⾃外部交换机的 “发卡弯” 报⽂，也就是说 srcMAC 可能是服务器上的虚拟机的 MAC 地址，这种报⽂必须进⾏过滤处理，以避免发送该报⽂的虚拟机再次从⽹络上收到⾃⼰发出的组播或⼴播报⽂。因此，当前的操作系统或⽹卡驱动都需要做相应的修改。

相对于 VN-Tag，VEPA 的优点在于：完全基于 IEEE 标准，不需要专⽤的报⽂格式，⽽且容易实现。通常只需要对⽹卡驱动、VMM 的 Bridge 模块和外部交换机的软件做很⼩的改动，从⽽实现低成本⽅案⽬标。

与 VEB 类似，VEPA 也同样具有纯软件和基于 SR-IOV 技术的硬件两种实现⽅式：

Intel x710 VEPA：

• Multi-Channel

在数通⽹络⾥，想要标识流量，肯定是要使⽤特定的字段来做。HP 使⽤的是 QinQ（802.1ad），在标准 VEPA 的基础上使⽤ QinQ 的 S-TAG 来标识虚拟机流量，形成了增强型 VEPA，即：802.1Qbg MultiChannel（多通道技术）。

多通道技术是⼀种通过给虚拟机报⽂增加 IEEE 标准报⽂标签，以增强 VEPA 功能的⽅案。通过标签机制，可以实现 VEB、Director IO 和 VEPA 的混合部署⽅案，借助多通道技术，管理员可以根据⽹络安全、性能以及可管理等⽅⾯的需求，灵活的选择虚拟机与外部⽹络的接⼊⽅案（VEB、Director IO 或 VEPA）。

多通道技术由 HP 公司提出，最终被 IEEE 802.1 ⼯作组接纳为 EVB 标准的⼀种可选⽅案。多通道技术⽅案将交换机端⼝或⽹卡划分为多个逻辑通道，并且各通道间逻辑隔离。每个逻辑通道可根据⽤户需要定义成 VEB、VEPA 或 Director IO 的任何⼀种。每个逻辑通道作为⼀个独⽴的到外部⽹络的通道进⾏处理。多通道技术借⽤了 802.1ad S-TAG（QinQ）标准，通过⼀个附加的 S-TAG 和 VLAN-ID来区分⽹卡或交换机端⼝上划分的不同逻辑通道。

多通道技术使外部物理交换机通过报⽂的 S-TAG 识别⽹络流量来⾃哪个 VEAP/VEB，或来⾃哪个Director IO 的⽹卡。反之亦然。

如上图，多通道技术可组合出多种⽅案：

1. 管理员通过多通道技术解决 VEB 与 VEPA 共享⼀个外部⽹络（⽹卡）的需求，多个 VEB 或 VEPA共享同⼀个物理⽹卡。管理员可以为特定的虚拟机使⽤ VEB，以获得较好的交换性能；也可以为其他虚拟机使⽤ VEPA，以获得更好的⽹络控制策略可实施性和流量可视性。

2. 直接将⼀个虚拟机映射到物理⽹卡上（SR-IOV VF Director IO），⽽其它的虚拟机仍然通过 VEB 或VEPA 共享物理⽹卡。

BPE

BPE（Bridge Port Extension，端⼝扩展设备）是⼀种功能有限的物理交换机，通常作为⼀个上⾏物理交换机的线卡使⽤。端⼝扩展技术需要在标准的以太⽹数据帧中增加⼀段 TAG，端⼝扩展设备借助 TAG中的信息，将端⼝扩展设备上的物理端⼝映射成上⾏物理交换机上的⼀个虚拟端⼝，并且使⽤ TAG 中的信息来实现报⽂转发和策略控制。当前市场上的端⼝扩展设备主要由思科的 Nexus 2K 和 Nexus 5K。

BPE 有 VN-Link 和 FEX 两⼤部分组成。VN-Link 部署在服务器的交换组件上，负责虚拟机的接⼊，⽽FEX 部署在接⼊层的物理交换机上，负责虚拟机间的互通。两者配合在⼀起实现了虚拟机的实时感知和分布式接⼊，接⼊配置和策略的集中式分发保证了虚拟机的⽆缝迁移。

图中，Port Extender 向下为 VN-Link 技术，向上为 FEX 技术：

• VN-Link 由⽀持 VN-TAG 的⽹卡实现，如 Cisco UCS ⼑⽚服务器中集成的 Palo，该⽹卡只负责 VNTAG 的封装/解封装，不做任何策略相关的⼯作。

• FEX 技术由 Cisco 的 N2K/N5K 组合实现，⽀持以级联⽅式组⽹，其中 N5K 负责寻址转发和策略的制定，N2K 则作为 N5K 的远端板卡部署在 TOR 实现分布式接⼊，N5K 通过 VIC 协议分发给N2K，实现分布式转发。

VN-TAG 体系将数据中⼼的接⼊⽹络虚拟成了⼀个⼤的接⼊交换机，由 VN-Link 充当⽹线，由 N2K 充当分布式线卡，N5K 充当主控板，处于任何物理位置的虚拟机都好像连接在这个⼤的接⼊交换机上。⾼带宽、⽆阻塞和低时延的优良特性使得 N2K/N5K 间⽹络连接能够与单机内总线相当，保证了分布式接⼊的性能。在 N5K 上可以基于虚拟机对应的 SVI_ID/DVI_ID 制定 ACL，QoS 和流控等⾼级接⼊策略，⽀持⽹络策略随虚拟机任意的漂移。

• VN-Tag

为了实现端⼝扩展（Port Extension），思科和 VMware 共同推出了 VN-TAG 标准。其核⼼思想是：在标准以太⽹数据帧中增加⼀段专⽤的标记 VN-Tag，⽤以区分不同的 vNIC（虚拟机的虚拟接⼝），从⽽识别特定的虚拟机的流量，并且标明了报⽂的⼴播域。可⻅ VN-Tag 技术是思科的⼀套闭源的全栈⽅案，VN-Tag 报⽂格式并不建⽴在 IEEE 已定义的各种标准之上的。

VN-TAG 将 6 个字节的新字段插⼊到 VLAN 的前⾯，这些字节只在 VN-TAG 设备中出现，现有的协议（包括 VLAN 的使⽤）不会受到任何的影响。其中，DVIF_ID/SVIF_ID 是⽬的/源虚拟机被分配的唯⼀标识，各有 12 位，通过 Port Profile 的配置与虚拟机接⼊端⼝进⾏⼀对⼀的通道绑定，VN-TAG 物理交换机将根据这个标识来识别虚拟机，实现⽹络接⼝虚拟化。其他的标志位⽤于 FEX 系统中，D 位标识报⽂的⾛向，P 位标识报⽂是否需要复制，L 位标识源主机和⽬的主机是否连接在同⼀台物理交换机上，R 位作为保留。

通信流程：服务器中的交换组件不进⾏ MAC 寻址，它接受源虚拟机的流量，封装好 VN-TAG（标记SVI_ID），然后直接交给上游的物理交换机，上游的交换机完成 SVI_ID 对源 MAC 地址、VLAN 和⼊端⼝的学习，根据⽬的 MAC 地址标记 DVI_ID，然后转发给⽬标服务器，⽬标服务器根据 DVI_ID 进⾏通道转发，剥掉 VN-TAG 后转发给⽬标虚拟机。

思科针对 VN-Tag ⼜推出了名为 Palo 的虚拟服务器⽹卡，Palo 卡为不同的虚拟机分配并打上 VN-Tag 标签。如下图，上联交换机与服务器之间通过 VN-Tag，使上联交换机能区分不同虚拟机产⽣的流量，并在物理交换机上⽣成对应的虚拟接⼝ vIF（Virtual InterFace），和虚拟机的 vNIC ⼀⼀对应起来，这就好像把虚拟机和物理交换机直接对接起来，全部交换⼯作都在上联交换机上进⾏，即使是同⼀个物理服务器内部的不同虚拟机之间的流量交换，也通过上联交换机转发。

相对于 VEPA，VN-TAG 技术有⼀些缺点：

• VN-TAG 是⼀种新提出的标签格式，没有沿⽤现有的标准（如 IEEE 802.1Q、 IEEE 802.1ad、IEEE 802.1X tags）。

• 必须要改变交换机和⽹卡的硬件，⽽不能只是简单的对现有的⽹络设备软件进⾏升级。也就是说，VN-TAG 的使⽤需要部署⽀持 VN-TAG 的新⽹络产品（⽹卡、交换机、软件）。

最初 IEEE 802.1 ⼯作组曾考虑将 “端⼝扩展” 作为 EVB 标准的⼀部分，但是最终决定将端⼝扩展发展成⼀个独⽴的标准，即 802.1 Bridge Port Extension。Cisco 曾向 IEEE 802.1Q ⼯作组建议，将其私有的VN-TAG 技术作为实现 EVB 的⼀种可选⽅案，但⼯作组最终没有接纳这个提案。Cisco 后来修改了 VN-TAG 技术草案，修改后的草案称为 M-TAG，该⽅案的主要⽬标仍是为了实现端⼝扩展设备与上⾏交换机

之间的通信标准化。

参考⽂档：

https://wenku.baidu.com/view/fc085465312b3169a551a41d.html 

https://www.internet2.edu/presentations/jt2009jul/20090719-congdon.pdf

---

 

关于九州云99Cloud

九州云成立于2012年，是中国早期从事开放基础架构服务的专业公司。公司成立八年，秉承“开源 · 赋能变革”的理念，不断夯实自身实力，先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户，被用户认可为最值得信赖的合作伙伴。