人们提到SDN，逻辑往往是这样的：控制和转发平面分离，由于有了SDN控制器的中心控制，我们可以做各种天花乱坠的事情。那么SDN控制器和交换机之间是通过怎样的网络进行通信的呢？一个与之相关的更大的问题是：作为一个完整的SDN解决方案，我们应该如何规划Management Network呢？这个问题也是所有客户最关心的前三个问题之一。博主想通过这篇文章抛砖引玉，聊聊在设计数据中心Management Network时要考虑的问题。
在没有SDN和orchestration系统之前，数据中心里往往只需要两张网：management network和data network。前者用于让管理员登陆到各个设备上进行配置，后者用于转发业务流量。本文不会涉及任何关于power network和console port network的讨论，因为那已经是太成熟的技术了。在orchestration系统大行其道的今天，网络的规划变得复杂了很多。
我们不妨脑补一下这样一个场景：一个数据中心的租户连接到Openstack的GUI[1]，在GUI上配置了一个network和一台VM，这台VM被nova安排在了一个compute node上[2]，对network的配置则通过neutron plugin转换成为了对SDN控制器的一系列配置并发送给SDN控制器[3]。SDN控制器将收到的配置转化为OpenFlow message或者对交换机的配置下发到各个物理交换机与OVS上[4]。这样，那台vm就可以与外界进行通信了[5]。
以上这个例子是一个非常典型的由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。在以后的文章中，博主会陆续涉及。
