数据中心网络管理场景分析

人们提到SDN,逻辑往往是这样的:控制和转发平面分离,由于有了SDN控制器的中心控制,我们可以做各种天花乱坠的事情。那么SDN控制器和交换机之间是通过怎样的网络进行通信的呢?一个与之相关的更大的问题是:作为一个完整的SDN解决方案,我们应该如何规划Management Network呢?这个问题也是所有客户最关心的前三个问题之一。博主想通过这篇文章抛砖引玉,聊聊在设计数据中心Management Network时要考虑的问题。

Management-Network

在没有SDN和orchestration系统之前,数据中心里往往只需要两张网:management network和data network。前者用于让管理员登陆到各个设备上进行配置,后者用于转发业务流量。本文不会涉及任何关于power network和console port network的讨论,因为那已经是太成熟的技术了。在orchestration系统大行其道的今天,网络的规划变得复杂了很多。

我们不妨脑补一下这样一个场景步骤:

[1]一个数据中心的租户连接到Openstack的GUI;
[2]在GUI上配置了一个network和一台VM,这台VM被nova安排在了一个compute node上;
[3]对network的配置则通过neutron plugin转换成为了对SDN控制器的一系列配置并发送给SDN控制器;
[4]SDN控制器将收到的配置转化为OpenFlow message或者对交换机的配置下发到各个物理交换机与OVS上;
[5]此台vm就可以与外界进行通信了。

这个例子是一个非常典型的由orchestration系统所驱动的数据中心(Openstack只是一个例子)。在这个例子里,博主标出了五个数字,每一个数字都表示有信息从数据中心的一个部分流向另外一个部分,也就意味着每个数字背后都一定要有一张网来传递信息。这五张网可能彼此独立,也可能几张网合并成一张网。不同厂家会有不同的解决方案。

对于[1],博主更愿意仅仅把它叫做Management Network,因为这张网承担的任务就是:让管理员与用户登录orchestration系统,对整个数据中心进行管理。这张网一定得存在并且往往会是客户已有的Management Network的一部分。几乎所有orchestration系统的服务节点(service node)和SDN控制器都要有管理端口接入这张网。由于这张网上流动的几乎全部是控制信息,数据量不大,[3]和[1]可以是一张网。

对于[2],不同的厂家有不同的解决方案。有些厂家把每一个compute node的管理端口都接入到了上一张management network当中,这样做最大的好处是可以充分共享management network当中已有的各种基础服务,比如PXE和DHCP。但博主个人不太喜欢这样的方案,主要是因为这样的方案不独立,绝大多数情况下它甚至依赖于客户去扩容已有的management network。比如有客户要部署一个数据中心,并且已经采购了服务器和SDN交换机,开始兴冲冲的连线了,忽然发现如果要把每一台新服务器的管理端口都接入到现有的management network当中,端口会不够用,怎么办?只能再去采购几台传统的交换机接入到management network当中,配置STP...当这一切发生的时候,所有的客户都会质疑:我们不是在部署SDN吗,为什么还要配置STP?我们不是从你家采购了那么多SDN交换机吗,为什么还要采购额外的并且是传统的交换机来扩容management network呢?当客户抛出这些问题的时候,生意基本就黄了一半。博主更倾向的方案是把[2]直接安排在SDN网络的数据平面,比如在SDN网络中直接配置一张网(比如一个vlan)来处理所有的orchestration系统和compute node之间的控制信息。这样做就最大程度的避免了繁杂的布线以及对management network的扩容。

终于讲到了[4],这张才是属于OpenFlow message(或者其他南向API)的网。其实我们也可以将这张网和[1][3]一起放到management network上,但是这张网上的控制信息往往会比较繁重,包括所有的FlowMod, packet-in, 甚至是stats collection。于是这张网往往采用传统交换机,2/3层协议以及必要的path redundancy来确保南向API准确快速的传递和执行。看到这里,也许有兄弟会质疑:博主不是在[2]中刚刚反驳了采用传统交换机扩容management network的方案吗?怎么在这里就大张旗鼓的用起来了呢?事实是这是一个鸡和鸡蛋的问题:在[2]中博主建议采用SDN控制器在SDN交换机上部署一张专门用于orchestration的网络,问题是SDN控制器如何将OpenFlow message发给SDN交换机呢?在这里,我们一定得借助传统网络,不然就是一个无止境的递归。于是一定又会有兄弟质疑:那岂不是说SDN控制器也要通过传统网络给每个OVS发送openflow message了?那样的话,每一台compute node就又要有一个端口接入到传统网络上,在[2]中的努力不就白费了?这个问题引入了SDN数据中心设计中的一个难题:inband management,也就是说:如何在数据平面上配置一张属于控制平面的网,让SDN控制器通过这张网控制OVS甚至是物理交换机。关于这个问题,博主会在以后专门讨论。

对于[5],其实没有太多可讲的,因为它就是数据平面,我们之前所做的所有努力都是为了让这张网容易管理,畅通无阻。

关于由orchestration系统驱动的数据中心网络规划,这篇文章仅仅开了一个头。还有两个特别重要也特别有趣的话题博主还没来得及展开:数据中心的first boot以及inband management。在以后的文章中,博主会陆续涉及。

转载自:《简书》中SDN & NFV的博客文章《Management Network》


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/9272.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于15-03-17
0