编者按：本文系SDN实战团技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。

--------------------------------------------------------------------------------------------------
分享嘉宾：王为，ZStack技术总监，目前负责ZStack产品网络相关技术工作，在OpenStacksequence和云网络业界活跃多年，积极推动SDN在云计算中的应用和整合，多次在OpenStack Summit、Arch Summit上分享云计算架构设计与云网络技术发展等主题的演讲。

最近关注的重点包括：EVPN/VXLAN，OVN，Vyos，Contrail
--------------------------------------------------------------------------------------------------
大家好，我叫王为，目前在 ZStack 负责网络技术的一些工作。之前在 SDN 群里也做过一次分享，分享的内容是 VXLAN 的技术进展，偏技术一些；这次打算分享更多的想法与大家多多讨论。

先说些题外话

SDN 群里大牛很多，从平时讨论中学习到不少，我的背景相对更偏云计算一些，我对 SDN 的角度可能也与大家有一些不同。

举例来说，前段时间发生了一个关于 VPC 的大讨论，从吃瓜群众到技术大神纷纷被炸了出来参与讨论，可如果我们只说 VPC 最基本这些点：VPC 间相互隔离、允许自由的定义自己的网络各种资源，其实在 SDN 中很久前无论基于软件还是硬件都有实现。

VXLAN 的 RFC 在 2014 年就发布了正式版，OTV 更早，如果你去查 OVS 的代码记录，12 年底 Kyle Mestery（之前还是 OpenStack Neutron 的 PTL）就提了 VXLAN 支持的代码。

总之，NVGRE/VXLAN 等协议之争似乎很早就开始，也在很久之前已然结束，OpenStack Neutron 里你在很久之前就可以体验到任意选取 IP 段、配置网络资源，一些厂商的定制版甚至能够帮你任意设计多层的复杂拓扑。然而当VPC 讨论出来之时，可以看到很多人、用户对网络的了解实在让 SDN 背景的朋友汗颜。

为什么造成这种现象呢，我觉得可能有几方面原因：

• 技术和业界应用脱节，特别是国内很多客户部署规模下，对高大上的技术不感冒；
• SDN 技术往往很难单独体现价值，除非在运营商等专业网络环境，大部分用户对自己的需求很难有明确的描述；
• 很多时候客户就想要“一把梭”，而不是仔细考量网路规模、技术价值、未来扩展这些

所以当我们探讨技术的前景、能力、想象空间的时候，可能也不妨考虑下这些，这样才能避免手持屠龙技但发现无用武之地或很难标准化地落地到客户的局面。
回到技术上哈，由于一众开源 IaaS 软件的流行，搭一个 IaaS 或者自己做一点定制已经变成一个入门门槛越来越低的事情，但这并不意味着 IaaS 本身越来越简单，有很多挑战其实是需要长时间解决的：

第一是执行路径长。有一句经典的话，叫做 IaaS 就是管理数据中心的 MetaData，这个活听起来没那么难——数据库存取数据，通过消息中间件或者其他可以远程执行的什么东西传递命令，idea 有了，就缺个程序员了。

用户想一键启动一个虚拟机，实则需要调配计算、存储、网络各类资源•、配置参数、跟踪状态、避免竞争一大堆活，而且需求可能不是启动一个虚拟机，而是一批可能上千个虚拟机，这对无论系统架构还是性能都提出了很大挑战。

熟悉 Linux 的同学都知道很多开源 IaaS 绕不开 libvirt、iptables、openvswitch、net namespace 这些东西，但是这些来自 Linux 生态系统的礼物有时并不万能.

一些程序没有 API，难以编程；
一些程序状态复杂且不提供全局的查询，需要自己的 Agent 小心翼翼的跟踪；
一些程序设计时没有考虑并发问题，需要系统自行控制运行的并行度，不然就是 Bug 横生。

更惨的是，这些程序乃至内核有时还会有自身的 Bug 或者设计缺陷或者在一些场景下性能跟不上。这些事情在小规模下都不太容易遇到，看起来都 work，但一旦拿来做一些严苛的测试，很快一个问题引发十个问题，体验极差，恢复困难。

再一个就是升级问题。升级几乎是各种复杂系统都绕不开的老大难，只要涉及分布式，升级难度就提高一倍；如果是微服务的，难度再提升一倍，举个例子 OpenStack 几十个项目，不知几百近千个进程运行在你的一百台服务器上，堆满了上千行的配置文件，想想都头大。

最后再说一个问题就是扩展的事情。特别是集成第三方厂家、产品这类事情，IaaS 由于要管理数据中心所有资源，这个活太大，往往需要一些帮手，比如我们在云计算里引入 ODL 的集成管理网络，引入 Ceph 管理存储，再集成一下 LDAP 整合企业账户，再整合一下 Zabbix 的监控系统，光举着一个例子就很痛苦了，如果考虑到 IaaS 面对的不是一个 ODL，而是可能有 OVN、ONOS、Calico 这些，还可能是 ACI、VTS、Contrail 等等，抽象和整合都具有很大挑战。

因为我对 OpenStack 比较熟所以常举一些 OpenStack 的例子哈，OpenStack 现在是光环最鼎盛的开源 IaaS，支持厂商众多，但是经过这么多年，一些问题依然很突出——抽象不满足厂商需求，比如 FWaaS，受到所有防火墙厂商的吐槽，由于路径长而导致在并发场景下不稳定，参考 ODL 上一个版本对 OpenStack 集成的设计和 Dragonflow 上个版本。

由于配置文件复杂，用户迷失在配置文件里，如果说配通了一个一定是要装裱起来流传在公司其他同事电脑里，万一哪天不 Work，就还得找之前那个哥们再研究研究，这并不是说 OS 设计有什么问题，相反我觉得很厉害，整合了数百个厂家的能力，联合几千号开发者，架构设计上必然有可圈可点之处，但是只能说 OpenStack 采取了一种它走的思路。ZStack 因为一些后发优势，参考吸取了很多其他 IaaS，从设计之初定下来一些原则。

尽量简单，到现在，ZStack 依然可以从官网上下载一个 war Java 安装包，一键部署，如果你用了定制版镜像（免去安装远程包的问题），大概十几分可能就好了。有人说其他 IaaS 很多经过优化或者厂商封装也可以啊，但是表象看起来类似，内里其实区别很大。安装了 ZStack 的管理节点上只有一个 ZStack 进程，这样避免了很多服务依赖、内部执行因为环境原因发生错误等等问题。

同样是“微服务”架构，ZStack 说实话看起来一点都不像，这是因为 ZStack 的微服务是基于线程的，得益于 Java 语言的成熟，ZStack 用线程来做微服务好问题。怎么实现呢？我们认为微服务的核心好处在以下几点：

• 信息流转透明——这样你可以很方便地观察服务状态、加入自己的插件
• 解耦——每个服务专心自己的事情，对外暴露有限的接口，提升模块本身的健壮

参考这些，我们通过在系统中运行独立消息中间件，线程通过中间件而不是内部通讯，每个服务达成独立的 jar 包，通过 build 工程整合在一起，由线程池调度执行，一样完成了这些好处，而且规避了配置复杂、管理复杂的一些问题。

说到消息中间件，我知道搞过 OpenStack 在生产环节的同学可能印象深刻，很多对 IaaS 或者分布式系统的调优都很注重消息这方面，ZStack 的用法比较特别：——没有使用动态队列。

我们分析了 OS 中消息中间件常成为瓶颈的原因，与动态队列关系很大，ZStack 通过静态队列、一致性哈希调度消息，很大程度避免了这些问题，因此说 ZStack 在很小的资源占用下完成上万的物理机资源管理毫不夸张——内部 CI 也常常会做这些测试，当然也有别的设计原因，后面也会提到。

不提上万个物理机，一千个物理机各种服务如果相互通信就是个很恐怖的事情，如果你用一些比较重的消息实现的话，特别是 RabbitMQ 这种有 Broker 的设计，ZStack 在 Agent 通信上选择了 HTTP 这种无状态、轻量级的方式，说实话 Debug 方便、库成熟，效果很好，无状态服务、异步消息可以说是 ZStack 架构的几个特点，在最近公众号发的一些文章也有讲到。

刚才提到了一致性哈希，是存储中比较常用的一个东西，在 ZStack 中，主要用来保证对同一个服务的操作总落到一个节点上，这样避免对资源操作上频繁加减全局锁。

只要能确保落在同一个节点上，通过内存锁或者队列，可以极大地提高系统的 API 吞吐，如上面第二个图所示，500个线程的线程池可以服务 10000 以上的并发 API 请求，由于 ZStack 是开源的，代码里有模拟器系统，大家好奇的话也可以自己尝试测试。

然而有个问题，管理平面性能很强，并不代表底层资源操作也很快, 这就系要无锁队列通过并发度来控制，避免对底层资源压榨太厉害，反而报出很多 Bug，尤其是像 iptables 这种很久以前开发的，一些地方没有适应现代高并发的调用这种场景。

这个是以前别人的分享数据，模拟器反映的是控制平面性能，真实环境下带了底层实际操作的效果，还有一个常见问题，就是组合、关联查询，由于 IaaS 中管理的资源众多，管理员可能需要查询在 条件 A 下查到的资源 B 关联的资源 C 的父资源的 D 属性，ZStack 在设计早起就考虑了这个问题，并通过技术手段允许用户任意组合、管理几乎所有条件。

所以之前号称 400 万个查询条件，无数个组合条件，由于 API 一直在增长，所以现在可能更多了，说到 API，ZStack 的 API 是消息式为主，同时提供 Restful 的，为什么这样做也会在后边谈与网络集成是说到。

下面聊一聊扩展性

Plugin-Driver 不是什么新鲜事，就不多说了，ZStack 由于内部是全异步——消息驱动的，每个消息会通过消息中间件流转，因此第三方集成时完全可以通过监听、发送消息而与系统交互，而消息在 ZStack 中往往不是触发一个什么过程，而是 Flow。

如果下载下来 ZStack 的代码，你会发现业务逻辑全都在一个个 Flow 里，这样做的目的是确保整个系统的稳定性，通过 Flow 控制流程，随时考虑失败的情况，这个 Flow 可以通过 XML 控制，方便扩展或者第三发代码的集成。

说完资源的创建，可以在说说删除，IaaS 中有很多资源，这些资源往往相互关联，如果你随意删除一个资源，很可能会得到一个提示，因为与 XX 资源关联，不允许删除，这样做自然也有道理——一来规避资源大规模误删风险，二来省下好多问题，但考虑到企业实际中不乏整个区域的搬迁、整片网络的迁移，整个账号的删除，ZStack 还是提供了一个集连删除的框架。

每个资源都会根据其依赖关系自动生成一个关联树，这样当你确定要删除或变更一个顶层资源时，下面的资源都会随之变化，而不是直接告诉你不可以修改——因为关联着 XX，等你删 XX，又提示关联着 YY……关于 ZStack 的测试系统我就不多说了，虽然其实也很有意思，但毕竟说了这么多还没到网络我都不好意思了。

谈谈网络。

计算存储网络里，目前大部分云计算项目、产品最痛的莫过于网络

• 一来所有问题都会先被误认为网络不通——虚拟机挂了，ping 不通；存储挂了，网不通；简直是云时代背锅侠，
• 二来网络解决的是连接的问题，不像其他资源相对独立、耦合

由于复杂系统的状态繁多，想在 IaaS 中解决好网络并不容易，简单来讲，IaaS 中的网络有几个流派。先说开源的，一派是自己撸一个网络管理系统，比如 OpenStack neutron，完全为 OpenStack 而生，对自身支持功能最丰富，利用 Linux 上丰富的软件资源，而且由于是默认选项，占用了不少客户，当然，这里主要说的是 Neutron + OVS，在纯软方案中用户还是不少的。

另外一种名头不那么正，但也是冲着云计算来的，比如 OVN、DragonFlow，前者由 OVS 社区开发，雄心壮志很多，但说实话挑战也同样不上特别是在信息同步、高可用这些问题。因为 OVS 以前是个单机程序，不需要考虑这些，自然经验没那么丰富，至今应用案例相对少，后者做的早一点，也曾被寄予厚望，架构上也不乏亮点，但支持功能数量和原生还是少一些，虽然发展情况也不错，但名气还是小了一些，除此之外又一个清新脱俗的存在那就是 (Open)Contrail，Contrail 做的很早，称赞者多，部署者少，在很多方面，Contrail 至今走在前列，但由于开源版与商业版的关系、本身的复杂性等等原因，我觉得在虽然在吃瓜群众中了解的不多，但是在企业市场下还是大有可为的。

另外还有其他有公司在支持的比如 MidoNet，和 Contrail 状况有些相近，目前很多私有云规模小，而规模大的往往要投入很多时间精力到架构设计、解决方案上，偏于项目而非产品（我指国内），所以像纯提供云网络管理这种比较难吃香，当然你可以在其他方面独树一帜，比如 DPI、可视化、性能等等。

这些都在模型上很迎合云计算的管理，也有一些不那么好直接集成的，比如 Calico，实际上 OpenDayLight、ONOS 也有类似问题，本身是独立项目，发展的也不错，没必要跟一个 CMS 死磕它发展出来那些“allowed_address_pair”、"address_scope"这些概念，这还是云网络管理，如果到了应用面，差异化就更多了，也因此 ACI 与 CMS 整合之路也往往不能一帆风顺。

ACI 本身个性极强，你也不能说有错，只能说两方个性都太鲜明可能不适合做夫妻，为什么会产生这样的现象我们认为与 API 设计也很有关系，如果 API 与资源模型是一个很优雅的 Restful 的资源模型，是很好看，但有些时候扩展起来确实不那么方便，由于要改数据库 Schema，导致用户用了你的集成之后升级、变更都与标准版有所差异。

ZStack 提供了另一种思路。其一是 API 以 消息形式优先，换句话说，我们不定义“标准”的资源模型，在代码中提供了一些供大家方便使用的模版，但你尽可以传你想要的消息。有人问如果我用标准的消息怎么办？数据库想加一些信息怎么办？ZStack 还提供了一个东西叫做系统标签，你可以把它理解为一个内置的 KV 数据库，集成的时候往往不是需要重新定义资源，而是扩展、改造，这是这样几乎无限灵活的标签带来了很大的可能性，既不影响升级和已有业务，还能在 API 中被传递使用。

ZStack 的网络模型是很鲜明的。大家查看文档都应该很快就能上手，但由于上面这些原因，我们在一些项目中为用户设计他该如何整合自有的系统或者心仪的 SDN 也极为方便，前段时间某大型互联网厂商尝试与 SDN 系统整合，整体并没有加多少代码，很快就能work起来。

所以 ZStack 非常欢迎各家厂商与 ZStack 提供整合，也不打算像 Neutron + OVS 实现一个非常复杂的 Driver，毕竟专业的事情还是要交给专业的人来做，在不久的将来 ZStack 将开始支持 VXLAN，我们比较了几家的 VXLAN 网络管理模型，觉得我们的还是蛮先进的。特别是通过 vxlan-pool 管理 vxlan（vxlan-pool 可以理解为 under-lay 网络），很多在其他厂商只能通过配置文件管理的事情，在 ZStack 都可以通过 API 管理，而且管理员可以轻易的批量管理、定义网络资源。

如果说产品能给用户带来好的体验，作为开发者的我们就感觉出力有所值了。ZStack 是一个开源系统，欢迎大家每个人去下载、尝试，欢迎网络厂商集成、支持，希望能和大家一起实现一个更好的 IaaS。

Q&A

Q1： 以“消息优先”和“系统标签”实现网络API接口管理网络资源感觉蛮新颖，能简单分享个场景用例吗？
A：举个例子哈，最近我正好在做 VXLAN 网络实现，可以拿出来说一下。关于消息，我们可以举创建这个例子，系统目前已经定义了创建网络这个消息，如果是创建 VXLAN 网络的话，我只要继承这个消息，添加我想要的字段就可以了，还是 Overide 原有的字段，这样既保证了系统的方便（都继承自同一类型），又保证了个性（任意添加字段）。

关于标签，正好可以说网络 Attach 集群这个事情，ZStack 中资源都有所属的集群，网络也不例外，但是我们知道像 VXLAN 这种 Overlay 网络跨集群并不是不可能的，而底层 VTEP 的属性可能在不同集群并不一致，因此在设计消息时，我们允许网络 Attach 集群可以带一个标签，就是 这个集群下的 VTEP 信息，这样很松耦合的将信息传递到系统内部

Q2：虚拟网络和物理网络怎么衔接的？
A2：关于衔接 这个是个老大难问题，目前 ZStack 中的 VLAN 网络通过“二层网络”完成物理资源的创建（网桥啊、Vlan 标签啊），如果你想要做互通的话，可以通过网络设计来完成，在数据中心内预先划好资源比如 Vlan、IP 段这些。VXLAN 通过 Pool 映射底层 VTEP 资源，如果是 Overlay 网络的话，通过自己添加 VTEP 等等方式可以打通网络，如果是需要 VXLAN 网关的话，目前大家应该还是建议用物理设备，毕竟性能有差距

Q3：可以再聊聊contrail么？有什么新进展？
A：Contrail 这个比较不好说，因为开源版更新没那么多，而且本身成熟度也蛮高了。比较能拿出来说的大概就是去年说 Service Chain 的时候又被提起，支持的很优秀

Q4：确认下刚才网络Attach“集群”指的是这里的host的集群对吧？这cluster可以理解是zstack资源组织的核心载体/对象吗？或说这个“framework”是？

A：是的，集群是一个逻辑概念，方便用户分隔资源，每个集群需要有自己的主存储、备存储、网络，当然这些比如网络也可以共享于多个集群

--------------------------------------------------------------------------

SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。