360 奇云的架构演进之路

2018 年 3 月 10 号，在 IT 趣学社技术沙龙第 12 期——《大话运维之弹性运维最佳实践》上，360 奇云团队分享了《360 奇云的架构演进之路》。360 奇云提供灵活的专有网络（VPC）服务。根据业务模型特点，划分出不同的虚拟隔离网络，定制内容包括选择自有 IP 地址范围、划分网段、路由器隔离网络等，实现多业务网络规划管理。本文为大家介绍 360 奇云的 VPC 架构的演变历程。

前言

360 奇云的 IaaS 服务虚拟化网络使用的是 openstack 的 neutron 组件，并在社区的版本上做了较大改动，维护着自己内部的版本。本文介绍奇云的 VPC 方案及在迭代版本时候的考虑，分成两个阶段。

阶段一： 在社区 liberty 版本的基础上做了一些定制化开发（下文介绍）并在奇云北京 A 区上线。

阶段二： 在之前的基础上，做了一次大的架构调整，采用了软硬结合的方案，引入了 EVPN，在奇云上海 C 区上线。

新架构不仅可以提升 VPC 的网络传输性能、节省资源的 CPU 消耗，还可以降低运维复杂度。

基于阶段二的新架构，奇云也将推出云物理机等更多服务与大家见面。

Neutron 项目的结构图

阶段一

在 360 奇云的北京 A 区，网络基本上使用的是社区 liberty 版本的 DVR（分布式虚拟路由器）方案，虚拟网络的路由器会以分布式的形式起在相应的计算节点上，跨物理节点的东西流量（同一个虚拟网络里不同终端交互的流量）使用 openvswitch 的 vxlan 来进行隔离。

我们在 liberty 版本的基础上做了定制化开发，增加了公网 IP 限速、OSPF 协议动态路由通告等功能。

主要改动

1.为了满足对公网 ip 流量限速的需求，我们扩展了 neutron api 的 extensions，新增了 Qos 资源，底层使用 linux tc 来实现。区分虚拟机的管理流量和业务流量，保证管理流量的高优先级。

2.liberty 版本 DVR 方案的虚拟网络的外部网络是个二层网络，每台计算节点的 fip-gateway 虚接口会被分配一个外部网络地址做转发使用，这样就造成了公网 ip 地址的浪费，我们在这个地方进行了改造，给 fip-gateway 设备分配 172.16.0.0/16 的私网段地址以节省公网地址。

3.公司的 IDC 物理网络结构是三层网络（可以理解成网关都在接入交换机上，网络的广播域被终结在接入交换机，这种做法可以避免 IDC 内大面积的广播风暴出现），上面提到 lieberty 的外部网络是个二层网络，这和我们 IDC 物理环境不符。直接使用它这种模式的话，在虚拟机跨接入交换机迁移的场景中，虚拟机南北流量会中断。我们也对这里进行了改造，将外部网络改造成三层网络，在 neutron-l3-agent 上新增了一个运行 ospf 协议的 driver，网络节点和计算节点都会使用这个 driver 和交换机建立 ospf 邻居，来动态通告本物理机的所有公网 ip，实现虚拟机可以在整个 IDC 内迁移，不受物理位置的限制。

4.部分特殊的虚拟机有连通我们内部管理网的需求，我们仿照浮动 ip 的机制扩展了新的资源 serviceip，专门用于虚拟机和我们的管理网互通。

北京 A 区示意图

（备注：物理网络都是高可用架构，由于本文主要介绍虚拟化网络，故全文节省这一部分的画图）

问题

在使用这套架构的过程中发现的一些问题：

1.vxlan 隧道的逻辑控制层是 neutron 的 ml2 pop driver，性能较差。

ml2 pop driver 的工作原理：当集群中有新的 vport（端口）被创建出来，计算节点上的 neutron-openvswitch-agent 会向 neutron-server 请求获取这个 vport 的信息，neutron-server 会通过 ml2 pop driver 从数据里获取这个 vport 的虚拟网络的信息，计算完拓扑后，通过消息队列服务器向集群中的节点通告谁和谁之间应该建立 vxlan 的隧道。在集群规模较大的时候（我们当时集群超过 500 个计算节点）反复测试批量创建虚拟机（100-150 台），发现 ml2 pop driver 的表现非常的差，python 的 orm 模块耗时过长，严重消耗 neutron-server 的 cpu 资源。从测试的结果来看，继续使用这种结构，而不管其他的因素，光是 vxlan 的控制层面就是集群规模的瓶颈，很难将单个集群的规模做到更大。

2.第二个问题：由于 vxlan 本身性能的问题，openvswtich 封装和解封装 vxlan 包头消耗较多计算节点上的 CPU 资源。

3.当时我们用户有需求是在虚拟化里提供裸机和其他的一些硬件设备（如防火墙）的服务，在这个方案中，很难将这部分硬件设备接入到租户的 VPC 里。

阶段二

为了解决现存的问题以及满足新的功能需求，我们在迭代下个版本的时候做了较大的改动。采用了软硬结合的方案。硬件接入交换机也作为云虚拟化网络的一部分（之前的方案中，交换机仅仅只提供传统的二三层网络转发）。

在新版本的虚拟化网络中引入了较新的技术：硬件 EVPN+Vxlan。

EVPN 协议是一种二层 VPN 技术，控制平面采用 MP-BGP 通告 EVPN 路由信息，数据平面采用 VXLAN 封装方式转发报文。

在考虑是否使用这套方案的时候，一方面是硬件 EVPN+VXLAN 和接入交换机作为 VTEP 的方案能解决我们上一代架构中的主要问题以及可以满足我们的后续需求, 另一方面是我们已经将这种 EVPN+Vxlan 的方案应用到了公司 IDC 的内部网络中并取得了一定的网络优化效果及积累了这方面较为丰富的运维经验，使得我们有信心做这一次虚拟化网络较大的改动。

上海 C 区示意图

主要改动

1.将 vxlan 的 VTEP 从 openvswitch 移交到接入交换机从而减少 openvswitch 封装/解封装 vxlan 包消耗的计算节点 cpu 资源。计算节点的虚拟网络的流量在 openvswitch 上封装成普通的 vlan 包，送到交换机后，再由交换机根据 vlan 和 vxlan 的对应关系封装 vxlan。每台接入交换机下的 vlan 号由 neutron-server 动态分配和回收。这种模式下，可以很轻松地将硬件设备接入到租户的 VPC 网络中。

2.接入交换机充当虚拟化网络的分布式网关，使用 VRF 来隔离不同租户的路由表。

3.使用 EVPN 协议来充当 Vxlan 隧道的控制层，不再使用 ml2 pop driver。降低了 neutron-server 的压力，另一个好处是网络中的终端信息（MAC+IP）可以通过 EVPN 协议以 BGP 路由形式在邻居之间同步，减少了网络中的泛洪流量。

4.因为整套架构基于 BGP 协议，在网络节点上的 neutron-l3-agent 上新增了 BGP driver 来动态通告公网浮动 ip，不再使用 OSPF 协议。

5.无公网 ip 的虚拟机 snat 出口的高可用，社区采用的是 keepalived 机制在多台网络节点之间进行主备切换，我们的在新结构中的解决方案是多台网络节点向租户的 VRF 通告不同 metric 的 bgp 路由，通过 bgp 协议的选路机制来实现出口的切换，相比于 keepalived 有更快的切换速度和更好的可维护性。

总结

为了兼容不同网络硬件的厂商的网络操作系统，我们在 neutron 的 ml2 和 l3 flavors 里各新增了一个二层和三层 driver 组装 netconf 的请求向集群中的硬件交换机同步配置。使用过程中发现，由于 neutron-server 直接向设备发送请求，前端过来的请求会在这里消耗较多的时间，造成用户体验不佳。

我们做了后续的优化，社区里 neutron 的资源如：network，subnet,，router， port 一直以来没有状态这个属性。为了优化用户体验，给 neutron 的各类资源增加状态这个属性，将 netconf 模块从 neutron-server 拆分出去，两者之间的交互采用 https 协议交互，整个工作流以异步的形式运行，netconf 模块根据操作结果更新 netron 里对应资源的状态、前端轮询资源的状态。

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/RgjF5WM3RS50AE7rZKuGpQ