12
运营与应用
DOI:10.3969/j.issn.1006-6403.2017.08.003
基于
OpenDaylight
和白盒机的通用
SDN
系统设计与实现
黄志兰
硕士,
2007
年毕业于中山大学,现就职于中国电信股份有限公司广州研究院,
主要研究方向为
SDN/NFV
、云计算、
IPv6
。
陈楠
2008
年毕业于华南理工大学,获工学博士学位,现就职于中国电信股份有限公
司广州研究院,
ITU-T Q14/SG11
联合报告人,
Q18/SG13
编辑人,主要研究方向包
括
SDN
,
NFV
,服务器虚拟化、数据中心网络、管理平台技术等。
刘京松
硕士,
2011
年毕业于宁波大学,现就职于中国电信股份有限公司广州研究院,
主要研究方向为云计算。
关天强
本科学士,
2014
年毕业于中山大学,现就职于中国电信股份有限公司广州研究院,
主要研究方向为云计算、
SDN
、
OpenStack
。
林宝洪
2015
年毕业于广东工业大学,现就职于中国电信股份有限公司广州研究院,主
要研究方向为云计算、
SDN/NFV
。
[黄志兰 陈楠 刘京松 关天强 林宝洪]
研究了云数据中心网络虚拟化的关键业务需求,分析了现有
Overlay SDN
数据
中心网络虚拟化产品存在的问题,提出了基于
OpenDaylight
和白盒交换机实现支持
异构云平台网络虚拟化的通用
SDN
系统方案,并给出了相应的系统实现。
关键词:
Overlay SDN OpenDaylight
白盒交换机
异构云平台互通
1
引言
云计算的规模化发展对传统数据中心
(
IDC
)
网络提
出了巨大的挑战
,
要求数据中心网络具备大规模虚拟机
/
服务器接入
、
多租户隔离承载
、
按需自动配置
、
灵活调整
等方面的能力
[1]
。
传统数据中心网络技术以静态配置为主
,
面临
VLAN
个数限制
、
Mac
表容量有限
、
资源利用率偏低
(
STP
冗余链路
)、
网络配置复杂等问题
,
难以满足上述
需求
,
已经无法支撑云计算业务的发展
,
需要引入
SDN
摘要
13
运营与应用
2017.08·
广东通信技术
(
Software Defined Network
,
软件定义网络
)
技术
。
SDN
是近年来网络通信领域最热门发展最为迅速的
新兴技术
,
被视为下一代互联网的核心技术
。
其核心思想
是通过软件编程的方式定义网络的行为
,
从而提高网络的
灵活性
、
释放网络的创新能力
[2]
。
SDN
技术流派众多
,
其中以
OpenFlow
和
Overlay
最为典型
。
OpenFlow SDN
强调物理网络
(
Underlay
网络
)
的集中控制和开放可编程
,
要求底层网络设备具备按照流表的方式进行数据处理及转
发的能力
。
Overlay SDN
则通过隧道技术在现有网络架构
上叠加虚拟的逻辑网络
(
Overlay
网络
),
强调
Overlay
网络的集中控制和开放可编程
。
Overlay SDN
对现网改动
较小
,
部署容易
,
技术成熟度相对较高
,
是当前实现数据
中心网络云化的主要技术手段
。
通过部署
Overlay SDN
,
网络能够与计算
、
存储一起池化成资源并按需提供给客户
,
从而满足云计算灵活多变的业务需求
。
Overlay SDN
在现网的应用部署主要以商业方案为
主
,
如威睿
(
VMware
)
的
NSX/NVP
、
阿尔卡特朗讯的
Nuage VSP
、
瞻博网络
(
Juniper
)
的
Contrail
等
。
这些
商业方案多为单厂商封闭方案
,
在实际应用时不可避免面
临兼容性问题
,
限制了其在云数据中心的规模部署和应用
。
以
Midonet
[3]
、
OpenContrail
[4]
、
OpenDove
[5]
为代表的开
源
Overlay SDN
方案在成熟度方面相对较弱
,
尚不具备
直接可用的能力
,
并且这些开源项目多为单厂商主导的方
案
,
发展前景受厂商策略影响
。
随着
OpenStack
[6]
、
OpenDaylight
[7]
、
KVM
[8]
、
Open vSwitch
[9]
等软件定义数据中心
(
SDDC, Software Defined Data Center
)
组件式开源项
目的日趋成熟和稳定
,
这些开源软件在云数据中心的应用
也越来越广泛
。
基于对这些开源项目的集成和二次开发
,
我们设计和实现了一套面向云数据中心网络虚拟化的通用
SDN
系统
,
该系统相比于现有商业和开源方案的优点在
于云网融合
、
分层解耦
、
异构互通
、
标准开放
。
本文的余
下章节将对通用
SDN
系统的设计和实现及相关的关键技
术进行详细的介绍
。
2
数据中心通用
SDN
系统设计
2.1
云数据中心网络虚拟化业务需求
随着虚拟化技术的不断发展和云计算业务的深化
,
云
数据中心的
ICT
环境变得更加复杂
,
异构虚拟化平台
、
异
构基础设施共存
。
以虚拟私有云
(
VPC
,
Virtual Private
Cloud
)
和业务链
(
SFC
,
Service Function Chain
)
为代
表的云业务也朝混合
、
层级
、
差异化方向发展
[10]
,
对网络
虚拟化产品的云网融合能力
、
异构兼容性
、
开放性
、
灵活
性提出了更高的要求
。
通用
SDN
系统应能满足如下业务
需求
:
(
1
)
支持
OpenStack
等主流云管理平台
,
实现云网
融合
。
通用
SDN
系统的目标是实现云数据中心网络的虚拟
化
,
使网络能够池化成与计算
、
存储一样的虚拟资源
,
由
云管理平台根据用户需求进行统一调度和协同编排
,
从而
实现云网融合
。
开源
OpenStack
作为云管理平台的行业
事实标准
,
已被广泛应用于云资源池管理
。
通用
SDN
系
统应能支持
OpenStack
,
实现
OpenStack Neutron
定义
的核心网络模型
,
实现租户网络基本的
L2
、
L3
互通能力
。
(
2
)
支持异构虚拟化平台
,
实现不同云平台间的网
络互通
。
云数据中心呈现多虚拟化平台共存的趋势
,
例如多
数数据中心可能同时部署
VMware
资源池和
KVM
资源
池
,
用于承担不同类型的业务
,
部分数据中心还设有独立
的物理资源区
。
随着混合云业务的开展
,
部分租户的云业
务可能同时承载在多个不同类型的云资源池上
,
要求通用
SDN
系统应能兼容不同类型的云平台
,
并能实现不同云
平台之间的网络互通
。
(
3
)
支持来自不同厂商不同型号的异构网络设备
,
避免厂商锁定
。
数据中心的每次扩容都可能带入新的来自不同厂商
的不同型号的硬件设备和软件资源
,
通用
SDN
系统应能
支持任意类型的网络设备
,
而不应指定厂商品牌和型号
,
以避免设备层面的厂商锁定
。
通用
SDN
系统对网络设
备的支持包括两个层面
:
①对
Underlay
网络设备的无感
知
,
仅要求底层网络
IP
可达
;
②
VNE
(
Virtual Network
Edge
,
虚拟网络边缘
)、
VXLAN
网关
、
L3
网关等系统组
件级网元要求突破厂商限制
,
能够支持功能
、
协议及接口
符合标准定义的通用设备
。
基于
OpenDaylight
和白盒机的通用
SDN
系统设计与实现
14
运营与应用
》
运营与应用
(
4
)
支持
NFV
,
能够管理和配置
NFV
网元
,
并支
持网络编排
。
随着
NFV
技术的快速发展
,
专业网元由硬件向软
件形式转变已经成为趋势
。
越来越多不同类型的虚拟
网元设备需要承载在云平台之上
,
如
vIMS
、
vEPC
、
vFW
、
vBRAS
等
,
相应对数据中心网络提出了新的要求
。
通用
SDN
系统应具备通过自身或者外部第三方系统管
理和配置
VNF
网元
,
以及对
VNF
网元进行网络编排的
能力
。
2.2
主流
SDN
网络虚拟化系统的问题
主流的商业和开源
SDN
网络虚拟化方案均未能很好
满足云数据中心网络虚拟化的业务需求
。
目前
,
市场上主
流的商业
Overlay SDN
方案以单厂商封闭方案为主
,
这
些方案虽然大都支持
OpenStack
云管理平台
,
但在开放性
、
异构兼容性和
NFV
支持等方面能力较差
。
具体表现在
:
(
1
)
控制器私有实现
,
与他厂商互通能力差
,
并
且对外开放的北向接口数量有限
,
导致网络应用创新能
力差
;
(
2
)
VNE
、
网关等关键组件绑定自家设备
,
导致对
异构虚拟化平台的兼容能力有限
;
(
3
)
南向控制协议大多存在私有定制的情况
,
或者
采用私有协议
,
或者基于标准协议进行私有扩展
,
进一步
加剧了兼容性问题
,
无法兼容第三方网元设备
;
(
4
)
对
NFV
的支持有限
,
通常仅支持自家的
VNF
网元
,
如表
1
所示
。
表
1
总结了主流商业
Overlay SDN
的兼容特性
,
可
Overlay SDN
方案
支持的
Hypervisor
支持的网关设备 他厂商方案互通的能力
VMware NSX ESXi Edge
(
软件
)
-
ALU Nuage VSP ESXi
,
KVM
,
Xen VRS-G
(
软件
),
7750
(
硬件
)
7750
网关支持
evpn
协议
Juniper Contrail KVM
,
Xen MX
系列路由器
(
硬件
)
-
HUAWEI FusionNetwork FusionCompute
(
基于
Xen
)
Network Node
(
软件
),
CE
系类路由器
(
硬件
)
-
H3C VCF CSA
(
基于
KVM
)
VSR
(
软件
),
6800
、
9800
(
硬件
)
6800
网关支持
evpn
协议
中兴
ZXCPP
(
基于
KVM
)
M6000
(
硬件
)
M6000
网关支持
evpn
协议
表
1
商业
Overlay SDN
的兼容性
见大多数厂商的
SDN
产品都对
Hypervisor
类型
、
网关设
备型号存在要求
,
通常只支持自家产品
,
与他厂商方案的
互通能力较差
。
以
MidoNet
、
OpenContrail
、
OpenDove
为代表的开
源
Overlay SDN
方案同样面临兼容性问题
,
其兼容能力
如表
2
所示
。
虽然
MidoNet
支持
VMware ESXi
,
但是该
模块是闭源的
,
并且作为收费插件提供
。
除了兼容性问题
外
,
开源
Overlay SDN
方案还面临厂商主导
、
社区中立
性不足和整体成熟度不足等问题
,
这些问题也在一定程度
上限制了这些开源方案在行业的应用及推广
。
Overlay SDN
方案 支持的
Hypervisor
支持的网关设备 他厂商方案互通的能力
MidoNet KVM
、
LXC
、
ESXi(
收费插件
) Midonet
网关
-
OpenContrail KVM
,
Xen OpenContrail vRouter -
OpenDove KVM OpenDOVE
网关
-
表
2
开源
Overlay SDN
的兼容性
2.3
基于
OpenDaylight
和白盒交换机的通用
SDN
系统设计
针对云数据中心网络虚拟化业务需求及现有商业
和开源解决方案存在的问题
,
我们设计和实现了基于
Overlay
技术的通用
SDN
系统
,
该系统在设计时遵循下
述原则
:
(
1
)
基于目前主流
、
成熟
、
具备商用能力的开源
项目二次开发
。
采用
OpenStack
作为协同编排层
,
采用
OpenDaylight
作为集中的控制器
。
在架构层面实现云网
融合及分层解耦
。
(
2
)
通过解耦计算与网络
,
实现对异构虚拟化平台
的支持
,
网络边缘节点可以灵活设置
。
(
3
)
采用基于开放标准的通用软
、
硬件设备
,
采用
白盒交换机作为二层网关
,
采用虚拟路由器
vRouter
作为
三层网关
,
避免设备层面的厂商锁定
。
(
4
)
采用标准接口和协议实现开放兼容
,
转
发面采用
VXLAN
、
VLAN
协议
,
管理及控制面采用
OVSDB
、
NETCONF
、
OpenFlow
协议
,
北向接口则支持
15
运营与应用
2017.08·
广东通信技术
OpenStack
标准接口和
OpenDaylight RESTCONF
接口
。
通用
SND
系统理论上支持遵循上述标准协议的所有设备
。
(
5
)
尽量采用
NFV
网元实现系统的
L4-L7
功能
。
根据以上原则
,
我们给出下图所示的通用
SDN
系统
的系统架构设计
,
如图
1
所示
。
其中
,
OpenStack
作为协同编排层
,
由
Neutron
提
图
1
通用
SDN
系统架构
供租户网络模型
,
Tacker
作为
NFV
网元管理及编排组
件
。
OpenDaylight
作为控制层
,
负责管理和控制物理和
虚拟网络设备
,
实现
Neutron
定义的租户网络模型
。
隧
道端点分别由
OVS
和
SDN TOR
充当
,
对于开源
KVM
,
将隧道端点设置在虚拟化层的
OVS
;
对于
ESXi
等商业
Hypervisor
,
则将隧道端点设置在外部
SDN TOR
,
虚拟
机通过
Hyervisor
层的虚拟接入交换机以
VLAN
的方式接
入
SDN TOR
,
由
SDN TOR
完成
VLAN
与
VXLAN
的互换
。
转发面采用
VXLAN
协议实现跨虚拟化平台的二层互通
,
L3
转发功能则由虚拟路由器
vRouter
实现
。
OpenDaylight
通过
Neutron ML2
插件对接
OpenStack
,
ODL Neutron
项目提供与
Neutron
一一对
应的接口服务
,
ODL Netvirt
实现
Neutron
虚拟网络模型
,
并相应调用
OVSDB
南向插件管理和配置
SDN TOR
和
OVS
,
调用
NETCONF
南向插件管理和配置
OVS
,
调用
REST API
配置
VMware DVS
的端口组
。
3
关键技术
3.1 Neutron
及
networking-odl
Neutron
是
OpenStack
的网络组件
,
目标是实现
“
网
络连接即服务
”,
在设计时遵循
“
软件定义网络
”
实现网
络虚拟化的原则
[11]
。
Neutron
定义了一套面向租户的虚拟
网络模型
,
包括网络
(
network
)、
子网
(
subnet
)、
端
口
(
port
)、
路由器
(
router
)
等网络组件
,
并提供操作
这些网络资源的标准
API
接口
。
Neutron
将这些接口分为
核心接口
(
Core API
)
和扩展接口
(
Extensive API
),
核
心
API
用于操作网络
/
子网
/
端口三种
L2
网络资源
,
扩
展
API
则用于操作路由器
、
浮动
IP
、
负载均衡等更高层
次的网络资源
,
如图
2
所示
。
Neutron
支持
FLAT
、
VLAN
、
VXLAN
、
NvGRE
等多
种类型的租户网络
,
但本身并不提供租户网络的具体实
现
,
而是通过标准化的插件
(
plugin
)
架构来支持底层
不同的网络技术平台
,
包括核心插件
(
Core Plugin
,
实
现核心
API
)
和服务插件
(
Service Plugin
,
实现扩展
API
)。
ML2
(
Modular Layer 2
)
是
Neutron
的核心插件
之一
,
提出了将网络拓扑类型和底层虚拟网络分离的机
制
,
并分别通过
Driver
的形式进行扩展
,
使得
Neutron
能够同时支持多种网络架构
、
网络分区和网络设备
。
在
ML2
中
,
不同的网络拓扑类型对应不同的
Type Driver
,
由
Type Manager
管理
,
不同的网络实现机制对应不同的
Mechanism Driver
(
如
Linux bridge
、
OVS
、
NSX
等
),
由
Mechanism Manager
管理
。
OpenDaylight
控制器提供
networking-odl
插件实
现对
Neutron
的支持
,
其作用主要是将
Neutron
的资源
基于
OpenDaylight
和白盒机的通用
SDN
系统设计与实现