SDN与OpenStack集成需要解决的三大问题

admin

最近这大半年，博主花了不少精力在SDN与OpenStack neutron的集成上。快到年底了，有必要稍微总结一下这大半年来究竟都解决了些什么问题。抛砖引玉，希望同行们一起探讨。

首先聊一个话题：各个SDN厂家都是做控制器和交换机操作系统的，干嘛去淌OpenStack的浑水？这个问题的确小困扰过博主一段时间。因为就在半年多前，博主面临过一个选择：是花时间在SDN控制器和交换机上做一个大feature，还是把neutron和我们的SDN产品集成起来？博主最终选择了后者。想借这篇文章分享一下博主的想法。
OpenStack的强劲发展势头第一次教育了整个市场多租户数据中心长什么样子，也第一次比较彻底的颠覆了传统数据中心的网络设计和运维方式。SDN在这里找到了迄今为止最好的切入点：市场真实并且巨大。从这个意义上说，只有OpenStack继续这样强劲的发展势头，SDN厂家才会有更多的机会去占领市场。绝大多数客户不会因为SDN是一种更优秀的技术而去采购SDN解决方案，反而是因为他们认可OpenStack的技术和商业模式而不得不去采购SDN解决方案。面对使用OpenStack的客户，初创的SDN厂家和各个传统交换机大厂第一次有了平等竞争的机会。从这个意义上来说，如果哪个SDN厂家还没有涉足neutron，那么就已经犯了一个重大的战略错误。
从战术层面上来说，虽然neutron已经有了飞速的发展，但还有几个大问题是reference implementation在现有的框架下很难解决漂亮的：比如如何管理过多的agent以及它们的HA，如何scale全相连的隧道，如何支持bare metal服务器以及bond，如何支持动态路由协议等等。这些问题不是说neutron upstream没有解决方案，而是如果没有对物理交换机的控制，针对这些问题的解决方案就会有各种各样的局限。而SDN厂家却有机会利用ml2 plugin和service plugin把这些问题从根本上解决掉。博主会专门写文章讨论为什么SDN厂商能够更好的解决以上这些问题，这篇先聊一聊SDN和neutron集成的三个大问题。
1. Testing Matrix & CI
OpenStack和SDN的集成是一件很复杂的工程。需要砸大量的资源。首先是巨大的testing matrix，它有三个维度。第一个维度：OpenStack每半年一个release，而且还会cherry pick不少bug fix到上一个版本。第二个维度：操作系统至少要支持三到四家：ubuntu, redhat, centos, fedora。第三个维度：SDN解决方案的各个release。这三个维度相乘便是SDN和OpenStack集成的Testing Matrix。虽然各个厂家都会在这个三维坐标系里进行一些剪枝，但工作量仍然巨大。
解决以上问题的唯一办法就是搭建CI进行测试的自动化。这个CI和一般应用的CI有两点不同。第一，它有两个moving targets: neutron upstream以及SDN solution upstream。来自任何一方的代码变化都要引起CI进行一次测试。第二，在控制平面和数据平面都要进行测试。在控制平面，来自neutron的任何一个配置变化，SDN控制器都要作出正确的响应。在数据平面需要跑smoke test，比如在不同的compute nodes上起多台虚拟机，配置floating ip，做full mesh ping。
这些都需要专人负责，偷不得懒。否则我们如何应对客户这样的问题：我们能在ubuntu 14.04上装OpenStack kilo跑在你们x.y.z版本的SDN解决方案上吗？
2. Multiple OpenStack Environments & One SDN controller
现有的SDN与OpenStack的集成方案大概都长这个样子：租户在OpenStack上建立了一个network/router/vm，neutron plugin会向SDN控制器发送相应的REST call，SDN控制器便会对物理交换机或者虚拟交换机进行流表下发或者配置更改。这个应用场景里面有一个隐藏的需求：一个SDN解决方案需要同时支持多个OpenStack环境。比如客户用一个SDN控制器管理了几个机架，在上面跑了多个OpenStack环境，那么这个SDN控制器是需要对这多个OpenStack环境进行区分的：环境1上的租户老王和环境二上的租户老王不能影响彼此在SDN控制器上做出的配置，即便他们在共享同样的物理网络资源并且都叫老王。
3. Consistency
OpenStack的每一个配置都会存在OpenStack的数据库里，通过REST发给SDN控制器每一个配置也会被保存在SDN控制器的数据库里。当由于某种的原因，两个数据库不一致怎么办？这个时候，一定要以OpenStack数据库的信息为准，更新SDN控制器的配置，因为OpenStack数据库中的信息才是租户真正希望的配置。这个道理很简单，但实现起来却有不少挑战。比如，如何检测到两个schema完全不同的数据库所存储的信息不一致？用hash是最直接的办法。但问题也随之而来：hash计算昂贵，由谁来做？多频繁？如果监测到不一致，如何能够快速的定位并且仅仅更新不一致的地方？
一个成熟的SDN与OpenStack的集成方案，一定需要把以上这三个问题解决好，否则希望借助OpenStack的东风让SDN落地会很困难。
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。