如何应用开源软件构建企业数据中心内SDN

最新推荐文章于 2024-07-30 10:22:13 发布

iqifenxia

最新推荐文章于 2024-07-30 10:22:13 发布

阅读量200

点赞数 1

文章标签： spring

原文链接：https://www.fgba.net/forum-53-1.html

版权

本文来自本人于Open Networking Summit 2019北美峰会上的演讲。Linux基金会发布了会议所有的演讲视频，但是观看需要支付49美金。[1]

内容

内容分为四个部分：

首先简单介绍数据中心网络架构
其次介绍如何在一个已有的数据中心内应用开源软件构建SDN
第三介绍如何将SDN规模扩大
第四介绍如何将SDN网络连接到已有的物理网络

数据中心网络-三层网络架构

传统三层网络架构分为核心，汇聚和接入层。接入层用来连接服务器并且执行L2转发，L2和L3的分界通常在汇聚上。因为汇聚一下是L2网络，而同时有多个汇聚，所以STP协议通常用来避免L2 loop。也正是这个原因，在L2网络里面只有一条工作的链路。所以图中，两个汇聚交换机，只有一个是active，另一个是standby。

在这种架构下，需要扩展数据中心，只需要在core下面再增加一个Segment即可。

数据中心网络-CLOS网络架构

CLOS架构在现代数据中心逐渐成为主流，因为它具有更高的性能和更好的弹性。CLOS架构中，最基础需要两层，spine/leaf。leaf用来连接物理服务器，如三层架构中的access一样。但是现在L2和L3的分界在Leaf上，这样的好处是可以通过ECMP可以实现服务器之间的active-active链路。

在CLOS架构下，可以通过增加super spine，来简介多个POD，从而实现数据中心扩容。引入superspine之后，服务器之间仍然是active-active的多路径，区别是现在多了一跳。

在数据中心内构建SDN

因为数据中心是现成，所以只能构建软件SDN，软件SDN灵活性也要胜出一些。虚拟机配合VxLAN的方案通常也成为主机网络虚拟化（host networking virtualization），就是在已有的主机网络上实现网络虚拟化。

主机内部通过OpenVSwitch连接所有本地的VM，OVS基于OpenFlow并且广泛被SDN系统采用，因为这里它是首选。

每个主机内部运行一个基于RYU的SDN controller，这样可以避免当规模扩大时，集中式SDN控制器带来的瓶颈问题。RYU本身是一个模块化的SDN控制器，它支持将定制的代码以app的性质运行在自己的框架中，从而方便用户开发各种网络功能。

为了避免物理网络的改动，虚机网络数据被封装成VxLAN，这样物理网络看到的都是主机间的UDP包。

因为SDN controller运行在每个主机，所以，为了将这个controller逻辑统一起来，需要一个数据库。这里使用的是etcd，etcd官网有吹自己多厉害的文字我这就不写了。不过现在no-sql数据库中，etcd应该是应用最多的。etcd是一个key-value store，非常轻量级。在这次ONS的keynote上，电信NFV也号称要开始采用类似的数据库。

SDN controller中的代码连接etcd，并从中同步数据，这样，只要etcd中有网络数据，它们就能被同步下来并应用在本地。那现在问题来了，etcd的数据需要谁去写？

这使用OpenStack Neutron来写etcd。Neutron本身是一个plugin system，并且有大量定义好的网络模型，因此这里在这里定义了多个plugin，并将Neutron的数据转换成etcd数据，写在etcd中。

这样，分布式的SDN controller有了一个统一的数据仓库。任何用户的请求只要写到这个数据仓库，就能最后应用在主机的OpenVSwitch中。

为了提高SDN系统的响应速度，这里还采用了一个消息队列，ZMQ。吹ZMQ的信息可以从ZMQ官网找到。Neutron中定制的plugin不仅会向ETCD写数据，还是通过ZMQ将消息发给分布式的SDN controller。而SDN controller收到消息之后，再从etcd拉数据。

至此一个基本的SDN架构已经构建出来，这样的卖二手域名架构在SDN或者其他软件系统中非常流行。

扩大SDN规模

刚刚介绍的架构在中小规模没有问题，但是当规模增大，ZMQ和etcd压力变大，最终会导致某个主机上的SDN controller因为连接失败而不能正常工作，从而导致整个SDN系统局部故障。这种局部故障在构建一个生产可用的SDN系统时是不可接受的。

对于这个架构本身可以有一些优化，例如合并读操作，可以减少etcd的压力，又例如可以在MQ的消息里面带上实际的数据，进一步减少数据库的读操作。

但是在优化过程中，本身有一个很有意思，与网络也相关的特点。尽管SDN中，有辣么多网络数据模型，network，subnet，QoS，SecurityGroup等等，但是所有的这些网络数据模型，都没有port特殊。因为其他的网络模型，用户一旦创建了，基本不会修改，因为对整个SDN系统带来的压力也不大。但是Port是跟虚机密切相关的资源，用户创建、删除、停止、重启、迁移虚机，都会导致Port有变化。所以Port数据对SDN系统的负载造成了更多的影响。

在说明解决方案之前，先看EVPN。EVPN我专栏里介绍很多了，这里直接看MAC/IP address route，可以很好的用来传输Port的信息。

所以，这里在SDN系统中通过GoBGP引入了EVPN。吹GoBGP的文字可以在GoBGP官网找到。使用GoBGP，当Port发生变化时，只会将这个变化发送给Port所在的主机的SDN controller。这样ZMQ压力降到了最低。

主机上的SDN controller会进而将这个Port数据，转换成EVPN数据，发送给BGP路由反射器，路由反射器再将这个EVPN数据发给其他主机。这样就相当于将ZMQ的压力转嫁给了EVPN系统。

EVPN或者BGP本身是经过时间检验的协议，因此在可靠性和稳定性上是能承受住这样的考验。

为了更好的使用EVPN，这里还是用了RTC4684和EVPN MAC mobility。这里就不展开了，感兴趣可以去找相关的资料。

连接SDN网络与物理网络

既然已经有GoBGP了，那再用GoBGP来传一个IPv4的路由到物理网。这样物理网如果要访问虚机网络，就知道将网络数据发送到相应的节点。为了减少物理网中的路由条数，这里采用特定的网关节点，所以，实际是通过网关节点+BGPv4，实现了一个VxLAN到物理网的gateway。当然，为了网络性能，这里采用了DPDK。

总结