Management Network

网络
人们提到SDN,逻辑往往是这样的:控制和转发平面分离,由于有了SDN控制器的中心控制,我们可以做各种天花乱坠的事情。

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

责任编辑:何妍 来源: 简书网
相关推荐

2012-09-24 11:49:12

IBMdw

2012-09-20 10:47:52

IBMdw

2012-12-25 10:44:06

IBMdW

2009-06-14 19:06:30

ibmdwWebSphere

2018-03-05 21:48:10

IoT设备AWS IoT管理

2010-04-12 08:43:45

Visual Stud

2018-05-17 22:47:20

AWS服务资源

2022-08-30 22:22:23

developerArchitectu

2009-12-03 18:22:44

Visual Stud

2012-02-14 13:59:08

虚拟化桌面虚拟化SRM

2010-07-23 12:55:29

SQL Server

2010-06-24 10:59:56

APP-V虚拟化应用虚拟化

2010-06-23 10:09:31

APP-V虚拟化应用虚拟化

2021-03-11 09:11:48

Dish NetworRepublic Wi运营商

2010-08-06 11:26:15

路由器ospf

2009-11-23 20:09:03

ibmdwLotus

2013-11-15 09:39:22

SUSE Linux服务器管理

2022-08-30 20:40:02

Big Datacomputing

2022-10-28 19:19:11

ChromeNetwork网络

2014-08-28 10:16:17

HTML5
点赞
收藏

51CTO技术栈公众号