云计算时代携程的网络架构变迁

大家觉得有意义和帮助记得及时关注和点赞!!!

关于我

我是携程云的高级顾问，目前负责网络和存储开发团队，专注于网络虚拟化 和分布式存储。

0 关于携程云

携程的云计算团队始于 ~2013 年。

我们从向内部客户提供计算资源开始我们的业务基于 OpenStack。从那时起，我们开发了自己的裸机平台此外，还部署了 Mesos 和 K8S 等容器平台。

近年来，我们将所有云服务打包到一个统一的平台中，我们将其命名为 CDOS - 携程数据中心操作系统。

Fig 1. Ctrip Datacenter Operation System (CDOS)

CDOS manages all our compute, network and storage resources on both private and public cloud (from vendors). In the private cloud, we provision VM, BM and container instances. In the public cloud, we have integrated public cloud vendors like AWS, Tecent cloud, UCloud, etc to provide VM and container instances to our internal customers.

Network Evolution Timeline

Fig 2. Timeline of the Network Architecture Evolution

Fig 2 is a rough timeline of our network evolution.

At 2013, we started building our private cloud based on OpenStack, and we chose a simple VLAN-based L2 network model. The underlying HW network topolopy was traditional hierarchical network model (3-layer network model).

At 2016, we evolved to a SDN-based large L2 network, and the underlying HW network evolved to Spine-Leaf model.

Starting from 2017, we began to deploy container platforms (mesos, k8s) on both private and public cloud. In the private cloud, we extended our SDN solution to integration container networks. On the public cloud, we also designed our container network solution, and connected the public and private cloud.

Now (2019), we are doing some investigations on cloud native solutions to address the new challenges we are facing.

Let's dig into those solutions in more detail.

1 VLAN-based L2 Network

2013 年，我们开始基于 OpenStack 构建私有云，提供 VM 和 BM 实例提供给我们的内部客户。

1.1 要求

对 network 的要求如下：

首先，相比之下，虚拟化网络的性能应该不会太差使用 BareMetal Networks，使用实例到实例等指标进行测量延迟、吞吐量等

其次，它应该有一些 L2 隔离，以防止常见的 L2 问题，例如泛洪。

第三，这非常重要 - 实例 IP 应该是可路由的。也就是说，我们不能在主机中使用任何 tunnling 技术。

最后，当时的安全问题不那么重要了。如果牺牲几乎没有安全性可以给我们带来显著的性能提升，那就是可以接受。与私有云环境一样，我们还有其他方法可以确保安全。

1.2 解决方案：OpenStack Provider Network Model

图 3.OpenStack Provider Network Model

经过一番调查，我们选择了 OpenStack 提供商网络模型 [1]，如图 3 所示。

提供商网络模型具有以下特征：

主机内 L2 转发 ，主机外 L2 转发 + L3 路由
在 HW 设备上配置的租户网关。所以这是一个 SW + HW 解决方案，而不是纯 SW 解决方案
实例 IP 可路由
高性能 。这主要来自两个方面：
- 无覆盖封装/解封装
- 网关配置在硬件设备上，性能要好得多与 OpenStack 中软件实现的虚拟路由器（L3 代理）相比

我们设计的其他方面：

L2 分段：VLAN
ML2：OVS
L2 代理：Neutron OVS 代理
L3 代理： NO
DHCP：否
浮动 IP：否
安全组：NO

1.3 硬件网络拓扑

我们数据中心的硬件网络拓扑如图 4 所示。

图 4.数据中心中的物理网络拓扑

底部是机架行。机架中的每个刀片都有两个物理 NIC，连接到两个相邻的 ToR 以实现物理 HA。

以上部分是典型的接入-聚合-核心分层网络型。聚合层通过 L2 转发与接入层通信，并且通过 L3 布线使用核心层。

所有 OpenStack 网络网关都配置在核心路由器上。此外，还有硬件防火墙是否连接到核心路由器以执行一些安全性执法。

1.4 主机网络拓扑

计算节点中的虚拟网络拓扑如图 5 所示。

图 5.在 Compute Node 中设计的虚拟网络拓扑

一些亮点：

两个 OVS 桥接器和直接连接br-int``br-bond
两个物理 NIC 绑定成一个虚拟设备，连接到br-bond
主机 IP 地址也配置在上，用作管理 IPbr-bond
附加到br-int

在图片中，是来自不同网络的两个实例。开始和结束于的编号设备只是数据包遍历两个（跨网络）实例之间的路径。可以 seen，总共有 18 个跃点。inst1``inst2``inst1``inst2

相比之下，图 6 显示了传统 OpenStack 提供商网络中的拓扑结构型。

Fig 6. Virtual Network Topology within A Compute Node in Legacy OpenStack

The biggest difference here is: a Linux bridge sits between each instance and br-int . This is because OpenStack supports a feature called "security group", which uses in the behind. Unfortunately, OVS ports do not support rules; but Linux bridge ports do support, so in OpenStack a Linux bridge is inserted between each instance and .iptables``iptables``br-int

Except this, other parts are similar, so in this circumstance, the total hops is 24.

1.5 Summary

Advantages

First of all, we simplified OpenStack deployment architecture, removed some components that we did not need, e.g. L3 agent, DHCP agent, Neutron metadata agent, etc, and we no longer needed a standalone network node. For a team which just started private cloud with not so much experience, the developing and operating costs became relatively low.

Secondly, we simplified the host network topology by removing security groups. The total hops between two instances from different networks was decreased from 24 to 18, thus has lower latency.

Thirdly, we had our gateways configured on HW devices, which had far more better performance than OpenStack's pure SW solutions.

And at last, the instance IP was routable, which benifited a lot to upper layer systems such as tracking and monitoring systems.

Disadvantags

First, as has been said, we removed security groups. So the security is sacrified at some extent. We compensated this partly by enforcing some security rules on HW firewalls.

Secondly, the network provision process was less automatic. For example, we had to configure the core routers whenever we add/delete networks to/from OpenStack. Although these operations have a very low frequency, the impact of core router misconfiguration is dramatic - it could affect the entire network.

2 SDN-based Large L2 Network

2.1 New Challenges

Time arrived 2016, due to the scale expansion of our cluster and network, the VLAN-based L2 network reached some limitations.

First of all, if you are familiar with data center networks you may know that hierachical network model is hard to scale.

Secondly, all the OpenStack gateways were configured on the core routers, which made them the potential bottleneck and single point of failure . And more, core router failures will disrupt the entire network, so the failure radius is very large.

Another limitation is that our blade was equipped with 2 x 1 Gbps NICs, which was too old for modern data center and morden applications.

Besides, the VLAN has its own limitations: flooding in large VLAN segmentations is still a problem, and number of avialble VLAN IDs is less than 4096.

另一方面，我们也有一些新的需求，例如：

我们公司在过去几年中收购了一些公司，以及这些公司需要连接/集成到我们的公司。在网络级别，我们希望将这些子公司视为租户，因此我们有多租户和 VPC 需求。
我们希望网络配置更加自动化，几乎不需要人工介入。

2.2 解决方案：OpenStack + SDN

针对这些要求，我们与公司的数据中心网络团队 共同设计了硬件+软件、OpenStack+SDN 解决方案。将网络从 L2 转移到大型 L2。

硬件拓扑

对于硬件网络拓扑，我们从传统的 3 层层次结构演变而来模型转换为 Spine-Leaf 模型，该模型在现代数据中越来越受欢迎中心。

图 7.新数据中心中的 Spine-Leaf 拓扑

Spine-Leaf 模型是全网状连接的，这意味着 Spine 中的每个设备层连接到 Leaf 层中的所有设备，并且节点。这种连接模式带来了许多好处：

更短的遍历路径和可估计的延迟：服务器可以到达任何其他服务器正好 3 个跃点（服务器到服务器延迟）
易于扩展：要增加带宽，只需在一个节点中添加一个层并将其连接到另一层中的所有其他节点
更可靠地反映硬件故障：所有节点都处于活动状态，节点故障半径比分层模型小得多

对于刀片式服务器，我们将 NIC 升级到 10 Gbps，并进一步升级到 25 Gbps。

SDN：控制和数据平面

我们有单独的控制平面和数据平面 [2]：

数据平面：VxLAN
控制平面：MP-BGP EVPN

这些是标准的 RFC 协议，更多协议细节和用途请参考 [2] 例。

此模型的另一个好处是它支持分布式 gateway，这意味着所有叶节点都充当（主动）网关，这消除了核心路由器上传统网关的性能瓶颈。

此解决方案在物理上支持多租户（通过 VRF）。

SDN：组件和实施

我们开发了自己的 SDN 控制器携程网络控制器 （CNC）。

CNC 是一个中央 SDN 控制器，管理所有 Spine 和 Leaf 节点。它通过 Neutron 插件与 Neutron 服务器集成，并能够动态地将配置添加到 Spine/Leaf 节点。

Neutron 变化：

添加CNC ML2和L3插件
用于端口状态的新有限状态机（FSM）
新的 API 与 CNC 交互
数据库架构更改

下面是真实数据中心中 neutron 端口状态的监控面板。

图 8.中子端口状态的监控面板

2.3 硬件 + 软件拓扑

图 9.设计的 SDN 解决方案的硬件 + 软件拓扑

图 9 是整体硬件 + 软件拓扑。

VxLAN encap/decap 在枝叶上完成节点。如果我们绘制一条水平线来穿过所有叶节点，这条线会分裂将整个网络划分为底层和叠加层。底部（叶子下方）属于底层，并被 VLAN 隔离;上述部分（叶子上）是叠加层并由 VxLAN 隔离。

底层由 Neutron 服务器、OVS 和 neutron-ovs-agent 控制，覆盖层是由 CNC 控制。CNC 通过 Neutron 插件与 Neutron 集成。

如前所述，这是云网络团队和数据中心的联合工作网络团队。我们的云网络团队主要关注底层部分。

2.4 生成实例

在此解决方案中，生成实例时，如何访问实例的网络？

图 10.Spawn An Instance 的流程

图 10 中描述的主要步骤：

Nova API（控制器节点）：为一个计算节点创建实例 -> 计划
Nova compute：在此节点上生成实例
Nova compute -> Neutron 服务器：创建 neutron 端口
Neutron 服务器：创建端口（IP、MAC、GW 等）
Neutron 服务器 -> CNC 插件 -> CNC：发送端口信息
CNC：将端口信息保存到自己的 DB 中
Neutron server -> Nova compute：返回创建的端口信息
Nova compute：例如创建网络设备（虚拟 NIC），配置设备（IP、MAC、GW 等），然后将其连接到 OVS
OVS 代理：检测连接的新设备 -> 配置 OVS（添加流） -> Underlay network OK
Nova compute -> Neutron 服务器：更新端口 .消息类似于：port is on hosthost_id``1234``node-1
Neutron 服务器 -> CNC：更新端口，如下所示：端口在主机上host_id``1234``node-1
CNC：检索数据库，获取连接的叶接口，动态地向这些接口添加配置 -> 覆盖网络正常 node-1
底层网络和覆盖网络 OK - > 实例可访问

在图 10 中，黑线是遗留的 OpenStack 流，蓝线是新的由我们添加。

2.5 总结

基于 SDN 的大型 L2 网络解决方案的摘要。

硬件

首先，硬件网络模型从分层（3 层）网络演变为 Spine-Leaf（2 层）。借助 Spine-Leaf 全网状连接，服务器到服务器的延迟变得更低。Spine-Leaf 还支持分布式 gateway，这意味着所有叶节点都充当同一网络的网关，而不是不仅减少了遍历路径，还缓解了中央网关。

全网状连接的另一个好处是硬件网络现在更加对故障有弹性。所有设备都是主动的，而不是主动备份的（传统的 3 层模型），因此当一个设备发生故障时，它有更多的更小的故障半径。

西南部

对于软件部分，我们开发了自己的 SDN 控制器，并将其与 OpenStack neutron 通过插件。SDN 控制器云动态发送配置复制到 HW 设备。

虽然我们这里只提到了 VM，但这个解决方案实际上支持 VM 和 BM 配置。

多租户和VPC支持

最后，该解决方案支持多租户和 VPC。

3 K8S 和混合云网络

2017 年，我们开始部署容器平台，迁移了一些从 VM/BM 到容器的应用程序。

相比之下，容器编排器（例如 Mesos、K8S）具有不同的特性与 VM 编排器（例如 OpenStack）结合使用，例如：

大型实例，每个集群 10K ~ 100K 个容器很常见
更高的部署/摧毁频率
更短的生成/摧毁时间：~10 秒（VM：~100 秒）
集装箱故障/漂移是常态，而不是例外

3.1 私有云中的 K8S 网络

容器平台的特性对网络提出了新的要求。

3.1.1 网络要求

首先，网络 API 必须具有高性能，并支持并发。

其次，无论是使用代理还是二进制文件来配置网络（创建 vNIC 并配置它们），它应该足够快。

为了成功地向客户销售集装箱平台，我们必须保持与现有系统有相当大的兼容性。

其中之一是：当容器漂移时，我们必须保持 IP 地址不变从一个节点到另一个节点。这是容器平台的理念，因为这些编排器注定要削弱 IP 地址：用户应该只看到容器公开的服务，而看不到单个容器。我们之所以在这里不得不解释一下，是因为在 OpenStack 时代，VM 迁移保持 IP 不变。如此多的外部系统假设 IP 地址是实例的不可变属性，在其生命周期，他们根据这个假设设计了他们的系统。如果我们突然打破这个假设，很多系统（SOA、SLB 等）都需要重构，这超出了我们的控制范围。

3.1.2 解决方案：扩展 SDN 以支持 Mesos/K8S

在私有云中，我们决定扩展我们的 SDN 解决方案以集成容器网络。我们重用了现有的基础设施，包括 Neutron、CNC、OVS、 Neutron-OVS-Agent 的 Agent。然后开发了一个 neutron 的 CNI 插件。

下面列出了一些更改或新添加的组件。

中子变化

首先，我们添加了一些新的 API，例如，传统的 Neutron 只支持分配端口通过网络 ID，我们为 Neutron 模型添加了标签属性，支持通过网络标签分配端口。例如，CNI 插件会说***："I want 从任何带有 'prod-env' 标签的网络分配的端口"。*** 这将使 K8S 解耦并且更具可扩展性，因为标签可以映射到任意数量的网络。networks

接下来，我们做了一些性能优化：

添加批量移植 API
数据库访问优化
用于高并发的异步 API
关键路径重构

我们还从上游向后移植了一些新功能，例如优雅的 OVS 代理重启，这对网络运营商来说是一个很大的好处。

用于 neutron 的新 K8S CNI 插件

K8S CNI 插件为每个 Pod 创建和删除网络。它所做的工作是与其他 CNI 插件（例如 Calico、Flannel）大致相同：创建 veth 对，附加到 OVS 和容器网络，配置 MAC、IP、GW 等。

它与其他插件的两大区别：

与 Neutron（中央 IPAM）通信以分配/释放端口（IP 地址）
完成后将端口信息更新到 neutron 服务器

现有网络服务/组件升级

我们还升级了一些网络基础设施。例如，我们遇到了一些 OVS 错误在过去几年中：

ovs-vswitchd 100% CPU 错误 [3]
OVS 端口镜像错误 [4]

因此，我们将 OVS 升级到最新的 LTS，它解决了这些错误。2.5.6

3.1.3 Pod 漂移

启动容器的网络步骤与在图 10 中生成一个 VM，因此我们在这里不详细介绍。

图 11 显示了 IP 地址在容器漂移期间如何保持不变。这关键点是： CNI 插件知道如何将一些 Pod 标签加入到 port 中。这是唯一索引，因此第二个节点（节点 B）可以获取 IP 地址信息来自 Neutron 的 ThisName 的地址信息。name``name

图 11.在 K8S 集群中使用相同的 IP 的 Pod 漂移

3.1.4 总结

快速总结：

我们在短时间内将集装箱平台集成到现有的基础设施中
单个全局 IPAM 管理所有 VM/BM/容器网络

综上所述，这是私有云最新的网络解决方案。

此新解决方案的当前部署规模：

4 个可用区（AZ）
每个可用区最多 500+ 个物理节点（VM/BM/容器主机）
每台主机最多 500+ 个实例
每个可用区最多 20K+ 个实例

3.1.5 未来架构

图 12.未来网络架构的分层视图

图 12 是我们希望在未来实现的架构。

首先，网络将拆分为底层和叠加平面。IaaS 和其他基础设施服务部署在底层网络中，例如 OpenStack、CNC。然后创建 VPC 在覆盖网络中，并在 VPC 中部署 VM 和 BM 实例。这些已经实现。

一个 K8S 集群将保存在一个 VPC 中，每个集群管理自己的网络。所有通过 IP 地址的访问都应保留在该集群内，并且所有从集群外部访问应通过 Ingress - K8S 原生道路。我们还没有实现这一点，因为它需要大量的软件和硬件系统重构。

3.2 公有云上的 K8S

3.2.1 要求

携程近年来开始国际化，在技术层，我们应该能够支持全球部署，这意味着 Provisioning 中国大陆以外的资源。

在海外搭建私有云不切实际，因为设计和构建过程将花费太多时间。所以我们选择购买公有云资源，部署和管理我们自己的 K8S 集群（而不是使用供应商管理的集群，例如 AWS EKS [10]）并将它们集成到我们的私有云基础设施中，从而将 CDOS 导入到混合云平台中。CDOS API 将抽象出所有特定于供应商的详细信息，并为我们的内部客户/系统提供统一的 API。

这项工作涉及公有云平台上的网络解决方案。

3.2.2 AWS 上的 K8S 网络解决方案

以 AWS 为例，让我们看看我们的 K8S 网络解决方案。

图 13.公有云供应商（AWS）上的 K8S 网络解决方案

首先，在 AWS 上将 EC2 实例生成为 K8S 节点。然后我们开发了 CNI plugin 将 ENI 动态插入/拔出到 EC2 [5， 6]。ENI 被赋予 Pod 作为其 vNIC。

我们开发了一个全球 IPAM 服务（就像 OpenStack 中的 Neutron）并进行了部署在 VPC 中，它管理所有网络资源，并真实调用 AWS API 分配/释放。

CNI 插件还支持将浮动 IP 附加到 Pod 上。同样，当 Pod 从一个节点漂移到另一个节点时，IP 地址保持不变。这是通过 ENI 漂移实现。

3.2.3 全球 VPC

图 14 是我们在私有云和公共云中的 VPC 的全局图片。

我们在上海和南通的私有云中有一些 VPC。在中国大陆以外，我们在公有云区域拥有 VPC，包括首尔、莫斯科、法兰克福、加利福尼亚、香港、梅尔本等等。

图 14.分布在全球的 VPC

私有云和公有云上的 VPC 网段都排列为非重叠，因此我们使用 Direct Connect 技术将它们连接起来，并且 IP 是可路由的（如果需要）。

好，就在这里，我已经介绍了我们网络的所有主要方面演化。接下来，让我们看看云原生时代的一些新挑战。

4 种云原生解决方案

当前的网络解决方案在云原生时代面临着一些新的挑战：

中心 IPAM 可能是新的瓶颈，而 Neutron 并不是为性能而设计的
云原生首选本地 IPAM（每个主机的 IPAM）
故障半径大：整个可用区之间的 IP 漂移
容器的密集部署将达到叶节点的硬件限制
日益强大的主机防火墙（L4-L7）需求

因此，我们正在对新的解决方案进行一些研究，例如 Calico、Cilium。 Calico 现在已经被广泛使用，所以我就跳过它并给出一些一个相对不太知名的解决方案的介绍：Cilium。

4.1 纤毛概述

Cilium 是一个全新的解决方案 [7]，它需要 Kernel 4.8+。

Cilium 的核心依赖于 eBPF/BPF，这是 Linux 内核中的字节码沙箱。如果你从来没有听说过这个，可以把 BPF 想象成 iptables，它可能会钩住修改 kernel stack 中的 packets，我们后面会分辨出来。

Cilium依赖BPF来实现连接性和安全性。它包含以下组件：

命令行界面
用于 orchestrator（Mesos、K8S 等）集成的插件
策略存储库（etcd 或 consul）
主机代理（也充当本地 IPAM）

图 15.纤毛

4.2 主机联网

任何网络解决方案都可以分为两个主要部分：

主机联网：实例到实例的通信和实例到主机的通信
多主机联网：跨主机和/或跨子网实例到实例通信

让我们看看 Cilium 的主机网络。

图 16.Cilium 主机联网

首先，每个主机都运行一个 Cilium 代理，该代理充当本地 IPAM，并管理其 CIDR。启动时，它会创建一个名为、和将 CIDR 的第一个 IP 地址设置为，然后充当 gateway 的 CIDR 的 gateway 的 IP 文件。cilium_host <--> cilium_net``cilium_host

在此主机中启动 Pod 时，CNI 插件将：

从此 CIDR 分配 IP 地址
为 Pod 创建一个 veth 对
配置 IP、网关信息到 Pod

然后拓扑将如图 16 所示。请注意，没有 OVS 或 Pod 的 veth 对和之间的 Linux 桥接。实际上，也没有特殊的 ARP 条目或路由条目来连接 veth 对。那么，当数据包到达 veth 时，它是如何转发的对子结束？答案是 BPF 代码 。CNI 插件将生成 BPF 规则，编译它们并将它们注入内核 以弥合 VETH 对之间的差距。cilium_host <--> cilium_net

cilium 主机组网总结：

Inst-to-inst：BPF + 内核堆栈 L2 转发
实例到主机：BPF + L3 路由

4.3 多主机联网

对于多主机联网，Cilium 提供了两种常用的方式：

VxLAN 叠加
BGP 直接路由

如果使用 VxLAN，Cilium 将在每台主机中创建一个设备，并执行通过软件进行 VxLAN 封装/解封。性能将是一个大问题，尽管 VxLAN 硬件卸载将部分减轻负担。cilium_vxlan

BGP 是另一种选择。在这种情况下，您需要在每个主机中运行一个 BGP 代理， BGP 代理将与外部网络进行对等互连。这需要数据中心网络支持。在公共云上，您还可以尝试使用 BGP API。 BGP 解决方案与 VxLAN 叠加相比具有更好的性能，等等重要的是，它使容器 IP 可路由。

4.4 优点和缺点

以下是根据我的理解和实验进行的简单比较。

优点

K8S 原生 L4-L7 安全策略支持
高性能网络策略实施
理论复杂度：BPF O（1）与 iptables O（n） [11]
高性能转发平面（veth 对、IPVLAN）
双堆栈支持（IPv4/IPv6）
支持 run over flannel（Cilium 仅处理网络策略）
活跃的社区
- 由公司驱动发展
- 来自内核社区的核心开发人员

缺点

**需要最新的内核（至少 4.8+，最好 4.14+）。**很多公司 PROD 环境运行的内核早于此时间。

还没有足够的用户故事和最佳实践 。大家都说 Cilium 是太棒了，但没有人声称他们已经在他们的 PROD 环境。

高开发和运营成本。与基于 iptables 的解决方案（例如 Calico）相比，大公司通常出于各种原因而有定制需求，例如与旧系统兼容，不会破坏业务。发展需要对 Kernel Stack 有一个温和的理解：你应该是 familir 使用内核数据结构，了解数据包遍历路径，拥有丰富的 C 编程经验 - BPF 代码是用 C 语言编写的。

故障排除和调试。你应该给自己配备 Cilium 麻烦射击技能，这与基于 iptables 的解决方案不同。在很多情况下，他们可能缺乏合适的故障排除工具。

但最终，Cilium/eBPF 仍然是最令人兴奋的技术之一近年来，它仍在快速发展中。所以，试一试好玩！