OpenStack中SDN泛谈4 (SDN发展与架构)

现实世界的SDN远多于这个系列的介绍,这个系列只是选取了开源的,并且与OpenStack相关的SDN做介绍。还有各种没有与OpenStack做集成的,或者是厂商闭源的SDN。一个个去分析似乎也不太现实,我们这次来看看SDN的共性。毕竟掌握了本质再来看个体更有效。

SDN的发展

有关软件控制网络的想法很早就提出了,在上世纪90年代,网络可编程(programmable network)的概念就在Active Networking中提出。而控制层面(control plane)的分离在2004年也由IETF ForCESWorking Group提出。但是在OpenFlow提出之前,这些都只是小范围的研究讨论,发展并不快。虽然说OpenFlow不能代表SDN,但是不可否认,OpenFlow的出现了加速了SDN的发展。现在的SDN体系也是由早期的OpenFlow Controller发展而来。之后发展成SDN Controller,也就是说SDN的范围不再局限于OpenFlow。近期的SDN发展,更多提的是SDN platform和SDN operating system,讲的都是基于SDN构建平台,构建生态。这两者有什么区别,目前我也很难从字面上给出解释。不过这两者都更进一步,不再局限于网络,而是以网络为中心,做更多的事情。

SDN的发展时间与OpenStack的发展时间有一定的重合。而Cloud Networking是SDN的主要场景之一,两者的碰撞不可避免。一方面,OpenStack的流行能带动SDN的发展,另一方面,SDN的演进可以提升OpenStack集群的规模。以后一定能看到更多的OpenStack + SDN的应用。

SDN架构

这个系列之前介绍了几种SDN,细心的朋友估计也能看出SDN的架构大致来了,下面我来总结一下吧。

Application & Orchestration Tier

传统的SDN架构里面没有这一层,在SDN platform里面新增了这一层。而OpenStack也在这一层。SDN想要接入到OpenStack,必须要在这一层完成适配,将OpenStack的请求转换成SDN的请求。在这一层不需要关心SDN底层的具体实现,因为SDN已经将底层网络抽象成纯软件的概念。

Northbound Interface

Northbound Interface是SDN将底层网络抽象成软件概念,并暴露出来的接口。

Application & Orchestration Tier通过Northbound Interface接入SDN Controller。这个接口通常是,但不局限于是RESTful API。像ODL还提供了OSGI接口,而OVN和Dragonflow直接提供DB读写的接口。

换一个角度,不论底层的SDN是什么,单看OpenStack提供的networking服务,Neutron server也可以看成是一个Northbound Interface。因为它提供了相应的网络数据模型的RESTful API。

Control Plane Tier

SDN的最核心部分。又分成了几个部分:

Database

SDN自己是一个集群内运行的软件。有自己的状态和数据,因此必须要有一个Database来存储相关的数据。而SDN主要是进行网络运算,网络运算的要求就是高速,低延时。因此对Database的性能要求也比较高。基于内存的NoSQL数据库通常具有更好的性能,更快的响应速度,这个系列前面介绍的几乎所有的SDN都是采用的这类数据库。在这类数据库中,Cassandra是选用最多的数据库,OpenContrail,Midonet,Dragonflow都支持Cassandra。并且有报告表明,Cassandra的性能的确优于同类的其他数据库。

鉴于Database的重要性,通常会将Database部署在独立的节点,并且考虑到HA和水平扩展,Database节点也会部署成一个集群。

Message

由于SDN是一个集群内运行的软件,因此SDN需要定义自己的消息通讯机制,以供集群内的各个节点之间通讯。像ODL和Midonet采用的是RPC作为消息机制,OpenContrail则是参考MPLS VPN自己制定的消息通讯机制,OVN和Dragonflow则是简单的消息发布订阅机制。

SDN Controller

终于到了SDN Controller,根据ONF(Open Networking Foundation)的定义,SDN Controller是一个逻辑集中的控制器。逻辑集中的控制器,那物理上就不一定集中了。实际上哪怕是集中式SDN控制器,出于HA和水平扩展的考虑,也不会部署成物理集中。而SDN控制器也朝着分布式的方向发展。像OpenContrail,Midonet,OVN,Dragonflow都有不同程度的分布式。有关集中式,分布式控制器的特点,我在之前的SDN闲聊中有过介绍,这边就不再多说。

SDN控制器包含了各个网络功能的实现。也就是一个个Network service。具体的来说,Network service就是将Northbound的抽象数据和Southbound的具体网络协议做了适当的转换和翻译。也就是这样,原本生硬晦涩的network element,经过Network Service可以灵活的通过软件来定义。

SDN Controller还包括了数据层面(Data plane)的接口,当然,这个接口一般不会太具体。

Southbound Protocol

各类控制协议和网络协议。虽然感觉上很多,但是最常见的还是OpenFlow和NetConf。这是network elements暴露出来的接口,只有支持相应协议的网络设备才有可能成为SDN的一部分。

Data Plane Tier

这一层就是实际的网络设备层,包含各种网络设备。网络设备本身也分为physical device和virtual device。Physical device就是支持OpenFlow或者NetConf或者其他控制协议的交换机,路由器和其他的网络设备。这些硬件设备目前占据SDN市场的最大份额,也是各大传统网络设备厂商的地盘。Virtual device,就是支持OpenFlow或者其他控制协议的虚拟网络设备。像OVS,OpenContrail的vRouter。Virtual device被认为是最有发展前景的,并且在成本上也优于physical device。

SDN的功能

虽然Cloud computing对SDN的意义非常大,但是SDN并非是为了Cloud computing而诞生的。SDN的提出是为了简化日趋复杂的网络架构,降低网络管理的难度和成本。随着SDN和Cloud computing的发展,数据中心趋于虚拟化。SDN的初衷倒也是契合Cloud networking的目的。从发展趋势上看,SDN具备了以下功能才能算是功能完善。

Cloud Networking:为数据中心和云提供虚拟化的网络服务。这是所有SDN的标配,要是没有这个功能,都不好意思跟别人说自己是SDN。

NFV: 作为虚拟网络界的另一股发展力量。NFV在电信运营商场景非常受欢迎。借助SDN可以更好的实现NFV。像ODL和OpenContrail明确表示了支持NFV场景,而ONOS主打SP场景,在NFV领域也当仁不让。在OpenStack环境下,还可以借助networking-sfc项目实现NFV,Dragonflow目前在这方面有所动作。

Container Network:容器这几年的发展是如火如荼,容器网络作为容器技术的一部分,也是各个SDN发展的重点。在OpenStack环境下,可以借助kuryr项目实现容器网络和SDN的结合。Midokura和Huawei作为kuryr项目的发起者和最大贡献者,对应的Midonet和Dragonflow自然借助kuryr项目实现容器网络与SDN的集成。OVN自己也在做一些容器网络集成的尝试ovn-kubernetes。OpenContrail自己实现了容器网络的集成。从容器的发展来看,基于CNI的kubernetes网络模型接受程度更高。

Physical provider Network:SDN虽然管理的是虚拟网络,但是有些应用场景也要求与物理网络的连通。

SDN与开源

开源只是技术的开发手段,与SDN并非强相关。一些闭源的SDN市场和口碑都不错,例如VMware的NSX。但是从OpenStack的发展来看,SDN的开源之路似乎是趋势。OpenStack通过开源,统一了IaaS层面的标准,为整个云计算带来了新的发展。现在SDN仍然没有一个压到一切的方案,虽然ODL和ONOS背景强大,但是似乎也并没有让其他SDN臣服。开源SDN仍然是一条漫漫长路。

SDN未来

SDN被认为是Next generation networking。传统的IT、BFSI(银行金融服务)、电信等领域,都在积极探索SDN。在移动服务和大数据分析场景下,对SDN也有一定的诉求。根据Allied Market Research的研究,在2022年,SDN的市场将达到1.3亿美金。过段时间专门分析一下这个研究报告。

就像随着数据中心的发展,Cloud computing也随着发展一样,随着网络技术的发展,SDN的发展只会越来越成熟,应用越来越广。

本文转载自:https://zhuanlan.zhihu.com/p/26002521

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容