SDN与NFV技术在云数据中心的规模应用探讨

2016-1-29 | 发表评论

编者按：以云数据中心为切入点，首先对SDN领域中的叠加网络、SDN控制器、VxLAN 3种重要技术特点进行了研究，接下来对NFV领域中的通用服务器性能、服务链两类关键问题展开具体分析。最后，阐述了前期开展的SDN/NFV技术试验工作进展及相关结论，并对VDC应用产品进行了展望。

1 引言

伴随着云计算技术的兴起，数据趋于大集中，传统电信系统网络架构成为阻碍云数据中心发展的巨大桎梏。为满足数据中心在云计算环境下的虚拟网络资源调度和共享需求，未来的数据中心资源池运营需要解决以下关键问题。

用户需求的快速响应。云资源池内部网络设备多，网络特征复杂，采用点对点手工配置，将会延迟用户需求的响应速度。
清晰的网络拓扑视图。云资源池本身的网络拓扑难以清晰呈现，特别是租户网络与云资源网络无法呈现对应关系，导致运维复杂。
灵活的资源共享与调度。资源池很难实现相互隔离的多租户环境，而且在跨数据中心组网时很难实现网络资源的灵活共享与调度。
动态感知租户的网络资源需求。不同租户的网络流量、安全策略、性能要求等不同，资源池网络无法动态感知租户的需求，造成资源浪费或过载。

SDN（software defined network，软件定义网络）、NFV（network function
virtualization，网络功能虚拟化）等技术可增强网络差异化服务提供能力以及云、管、端协同组网能力。因此，在云数据中心中规模引入
SDN/NFV技术可以有效解决上述问题，同时基于SDN/NFV技术的云数据中心组网也是电信网络未来演进的重要方向。

2 SDN重要技术

在诸如骨干网、数据中心、企业网、城域网边缘、接入网等众多网络环境中，数据中心是最早遭遇传统网络技术束缚的地方，也是SDN技术最早进行商业化
应用的场景。为了满足日益增长的互联网服务需求，数据中心逐步向大型化、自动化、虚拟化、多租户等方向发展，在网络性能和灵活性等诸多方面遭遇挑战。在满
足虚拟化和多租户的按需灵活组网需求时，特别是IaaS服务的基础设施构建时，SDN技术成为首选方案。

SDN不应被定义为一种网络技术，更为准确的说法是，SDN是由多种重要技术、解决方案形成的一种下一代网络体系架构，本节将重点讨论云数据中心组网中采用的3种SDN重要技术：叠加网络（overlay）、SDN控制器、VxLAN。

2.1 叠加网络（overlay）

叠加网络是指以现行的IP网络为基础，在其上建立叠加的逻辑网络（overlay logical
network），屏蔽掉底层物理网络差异，实现网络资源的虚拟化，使得多个逻辑上彼此隔离的网络分区以及多种异构的虚拟网络可以在同一共享网络基础设施
上共存。根据上述内容可知逻辑网络叠加层的概念并非由SDN发明，VLAN（虚拟局域网）就是典型的代表，但在云数据中心网络领域，叠加网络已成为当今
SDN发展的重要动力之一。它的主要思路可被归纳为解耦、独立、控制3个方面。

解耦：是指将网络的控制从网络物理硬件中脱离出来，交给虚拟化的网络层处理。这个虚拟化的网络层加载在物理网络之上，屏蔽掉底层的物理差异，在虚拟
的空间重建整个网络。因此，物理网络资源将被泛化成网络能力池，正如服务器虚拟化技术把服务器资源转化为计算能力池一样，它使得网络资源的调用更加灵活，
满足用户对网络资源的按需交付需求。

独立：是指叠加网络方案承载于IP网络之上，因此只要IP可达，那么相应的虚拟化网络就可以被部署，而无需对原有物理网络架构（如原有的网络硬件、
原有的服务器虚拟化解决方案、原有的网络管理系统、原有的IP地址等）做出任何改变。该类方案可以便捷地在现网上部署和实施，这是它最大的优势。

控制：是指叠加后的逻辑网络将以软件可编程的方式被统一控制。通过应用该方案，网络资源可以和计算资源、存储资源一起被统一调度和按需交付。以虚拟
交换机为代表的虚拟化网络设备可以被整合在服务器虚拟化管理程序（hypervisor）中统一部署，也可以以软件方式部署在网关中实现与外部物理网络的
整合。这两类部署方式正代表了业界目前在叠加网络方案中两大主要流派（前者是以VMware为代表的“软”派，后者则是以华为、阿朗为代表的“硬”派）。
各种虚拟化网络设备协同工作，在资源管理平台的统一控制下，通过在节点间按需搭建虚拟网络，实现网络资源的虚拟化。

2.2 SDN控制器

控制和数据平面的分离应是SDN最基本的原则之一，其思想是将网络设备的控制平面迁移到集中化的控制器中，利用标准化的南向接口替换了网络设备中的控制平
面，并在控制器中增加了可编程的北向接口供上层调用。因此，控制器在SDN架构中具有非常重要的地位，在SDN系统中，各个层次之间的接口都以它为中心进
行定义。理想化的SDN控制器应是一个提供如下功能的软件系统集合。

网络状态管理。对于网络状态的管理与分布可以使用一个数据库实现，它负责保存来自于被控制的网元设备和相关软件的信息。
高级数据模型。这个数据模型描述被管理的资源、策略和控制器提供的其他服务之间的关系。YANG建模语言可以用来构建这个数据模型。
使用RESTful（representational state transfer，表征状态转移） API来将控制服务提供给应用程序使用，为控制器与应用程序间的交互提供便利。
安全的控制会话，即控制器和网元设备中相应的代理之间的TCP会话。
一个基于标准的、用于在网元设备上配置应用程序驱动的状态协议。
一个设备、拓扑和服务发现机制，一个路径计算系统。

目前，在云数据中心SDN解决方案中，对于控制器的选择分为两大阵营，一个是由商业公司主导的封闭式SDN控制器，这其中有NSX
Controller（VMware）、VCFC（H3C）、NetMatrix/SNC（华为）、Contrail（瞻博）等多种产品。另一个则是由开
源社区推进的开放式SDN控制器，包括NOX/POX（Nicira）、Ryu（NTT）、Floodlight（Big Switch
Networks）等开源项目。从实际应用情况来看，无论是商业SDN控制器还是开源SDN控制器，都存在各自的优缺点。例如，商业SDN控制器由厂商独
立研发，成熟度、可靠性通常较高，但由于采用私有技术实现，使得多厂商间的互操作性大幅降低。开源SDN控制器由于协议、代码的开放，确保了较高水平的互
操作性，但在可靠性方面仍存在不足之处。

2.3 VxLAN

VxLAN（virtual extensible local area
network，虚拟可扩展局域网）是一种网络虚拟化技术，目标在于改善现有VLAN技术在部署大规模云数据中心时遇到的扩展性问题。该技术是由
VMware、Cisco、Arista、Broadcom、Citrix共同提出的IETF草案，它把基于MAC的二层以太网帧封装到三层UDP分组
中。通过这种MAC-in-UDP封装技术，VxLAN为虚拟机提供了与位置无关的二层抽象，使得位于不同数据中心的虚拟机通过大二层网络实现通信，虚拟
机跨站点热迁移也更加便捷。和VLAN类似，VxLAN也是通过逻辑网络实现对多租户的彼此隔离，同时由于VxLAN采用24位标示符，它所标示的虚拟化
空间数量可以到达1 600万个，远超VLAN所标示的4 096个数量限制，VxLAN报文封装格式如图1所示。

图1 VxLAN报文封装格式

通常VxLAN的运作依赖于VTEP（VxLAN tunneling end
point，VxLAN隧道终端）组件，该组件可以为终端系统提供二层以太网服务所需的所有功能。其工作原理大致为：VTEP检查帧中的目标MAC地址，
查找目标VTEP的IP地址。当一个虚拟机要与其他虚拟机通信时，通常会先发送一个广播ARP分组，VTEP会将其发送到对应的VNI多播组。其他所有
VTEP从该分组中学习到发送方虚拟机的内层MAC地址和其VTEP的外层IP地址，目标虚拟机会给发送方返回一个单播消息来响应ARP，原有VTEP也
可以由此学习到目标地址映射。

目前，业界各厂商对VTEP的实现方式主要分为3种类型，第一种是在虚拟化软件hypervisor层中实现该功能，如VMware的解决方案就是
在其ESXi内核中创建了VTEP组件，由于该种方式最接近虚拟化层，其效率是最高的；第二种是在虚拟交换机中集成了VTEP功能，H3C所提供的解决方
案就是这一类，该种方式的优点在于支持多虚拟化环境（vSphere、KVM、Xen、Hyper-V）；第三种是在硬件网络设备中新增VTEP功能，该
种方式更适用于非虚拟化环境，华为、阿朗等传统网络设备厂商多采用这一类方法。

在此，需要提醒运维人员注意的一点是，由于VTEP对普通IP报文进行了再次封装，这将带来约50多个字节的额外开销，当现网运行的设备MTU值设
置为1 500
byte，而数据分组大小超过该值需进行分片处理时，将导致基于VxLAN封装的IP报文无法到达目的端。此时有两种解决方法，一是将IP报文发送端的操
作系统MTU值改为1 450 byte以下，二是在IP报文沿途所有网络设备上开启jumbo
frames相关功能，推荐采用第二种方法解决该问题，因为在骨干网的核心网络设备中通常默认开启了jumbo
frames相关功能，运维人员仅需确认本端及对端接入层网络设备是否开启该功能。

3 NFV关键问题

NFV和SDN都是近些年为了满足新的应用需求提出的下一代网络技术，总体而言，它们各
有侧重，分别从不同的角度去解决不同的网络问题，同时它们又有着非常密切的关系。虽然两者都能够改进网络的整体可管理性，但是它们的目标和方式有所差异。
SDN通过将控制平面和数据平面分离来实现集中的网络控制，而源自运营商需求的NFV技术则是通过软硬件分离，实现网络功能虚拟化，其关注的重点是优化网
络服务本身。这两种技术看起来属于不同维度，却具有很强的互补性，利用SDN技术在流量路由方面所提供的灵活性，结合NFV的架构，可以更好地提升网络的
效率，提高网络整体的敏捷性，NFV与SDN关系如图2所示。

图2 NFV与SDN关系

业界普遍认为若要NFV技术真正实现商用，有两个关键问题是必须要关注的，它们分别是与硬件相关的通用服务器性能问题、与软件相关的服务链问题，下文将重点讨论这两个关键问题。

3.1 通用服务器性能

通过在云数据中心中引入NFV技术，可以将路由器、防火墙、负载均衡器等任何类型的网络功能运行在共享的通用服务器上，并将它们按需划分为虚拟机软件实
例。这样做的好处是可以有效地降低投资成本（capital expenditure，CAPEX）和维护成本（operating
expense，OPEX），并缩短业务部署与上线时间。但同时必须面对一个较为棘手的问题，即通用服务器能否完全代替旧有专用硬件网络设备。

ASIC、NP、CPU
3类芯片构建了IT架构的基础。ASIC和NP基于pipeline模式的传统做法，对网络报文的转发和处理可以达到很高的性能，但业务固化，应用灵活加
载的能力欠缺。新IT融合架构的本质在于“面向应用”，因此以x86架构为代表的CPU通用架构异军突起，得到了广泛的关注。CPU在计算能力上优势明
显，适合处理L4~L7层业务，但短板是没有专用的数据面操作系统，导致I/O转发能力弱。而英特尔公司在2013年正式推出的DPDK（data
plane development
kit，数据平面开发套件）技术可以有效弥补这一短板，它主要用于快速的分组处理，可以显著提升数据分组处理性能，按照英特尔最新发布的实验室测试数据，
基于DPDK的数据平面转发能力已经可以达到220
Gbit/s。虽然离规模商用仍然尚待时日，但已经让业界看到了摩尔定律在NFV领域再续辉煌的潜力。另外，由于英特尔开放了DPDK源代码，使得广大网
络厂商均可以利用DPDK技术来提高网络设备的转发性能。通过上述技术使得通用服务器可以完全替代专用硬件网络设备，甚至提供更高性能的网络应用，这为
NFV走出实验室，大规模商用奠定了坚实的基础。

3.2 服务链（service chain）

随着云业务的交付，尤其是面向多租户的环境，网络业务越来越复杂化。数据报文在网络中传递时，需要经过各种各样的业务节点，才能保证网络能够按照设计要求，提供给用户安全、快速、稳定的网络服务。这些业务节点（service node），典型的有防火墙、负载均衡、入侵检测等。通常，网络流量需要按照业务逻辑所要求的既定顺序，穿过这些业务点，这就是所谓的服务链。为
了实现各种业务逻辑，服务链需要可编程实现灵活组合。而随着SDN以及NFV的不断推进，服务链变得更加重要。传统的网络用专业硬件承载单独功能，再将其
部署在物理网络中，作为一种固化的网络拓扑。随着业务编排和服务链的引入，网络可以被抽象。运营商可以面向业务流定义所需要的网络功能以及业务流处理方
式。

通过SDN控制器，把多个NFV软件化的业务功能模块链接在一起运作，实现业务的灵活调度，服务链是多业务整合的关键，也为个性化应用的平台开发打
下基础。服务链中的各角色：业务节点（service function）、流分类节点（classification）、控制平面（control
plane）、代理节点（proxy node）协同完成业务定义。

4 基于SDN与NFV技术的云数据中心应用场景

随着技术的逐步走向成熟，越来越多的运营商、互联网公司和企业在SDN/NFV相关领域开展实验网络部署、测试和验证活动，在SDN/NFV的需求
场景识别、产品验证和商业准备等关键环节均取得了明显进展。AT&T在2013年启动的Domain2.0计划，旨在通过SDN/NFV技术将网
络基础设施从以硬件为中心向以软件为中心转变，实现基于云架构的开放网络。
与传统电信运营商的SDN网络商业诉求不同，互联网公司作为技术的先行者，在SDN商业化进展相对领先。如Google公司宣布通过部署SDN能够将数据
中心之间的链路利用率提升至90%以上，并于2014年4月宣布推出基于SDN和NFV技术的Andromeda虚拟化平台。

4.1 试验进展与结论

中国电信股份有限公司江苏分公司（以下简称江苏电信）从2014年开始积极探索SDN/NFV技术在云数据中心等领域的应用，重点关注机房资源碎片化、非
核心区域机房闲置率较高、网络资源无法按需分配、网络架构难以灵活调整、网络配置过于复杂等多方面问题，通过在省内不同城市的云资源池中试点部署部分厂商
的解决方案，实现了跨数据中心大二层网络架构，总结并提出了基于SDN/NFV技术的云数据中心组网方案，试验环境拓扑如图3、图4所示。

图3 基于SDN/NFV技术的云数据中心网络架构（厂商A）

图4 基于SDN/NFV技术的云数据中心网络架构（厂商B）

在SDN领域，试点工作主要围绕基于SDN+VxLAN技术的跨数据中心大二层组网展开，分别对跨机房东西向、南北向互通以及虚拟机在线迁移等多个
功能场景进行了验证，虽然各厂商提供的方案略有差异，但从试验结果来看，均能达到预期效果，各类基础功能场景及价值结论见表1。

表1 SDN+VxLAN技术基础功能场景及价值总结

SDN+VxLAN技术基础功能场景	技术价值
跨机房相同网段东西向互通场景（服务器A与服务器B位于不同机房）	可以把运营商分散在多个数据中心的零散服务器集中管理（如同部署在同一个数据中心），便于提高资源利用率
跨机房不同网段东西向互通场景（服务器A与服务器B位于不同机房）	可以将两个部署在不同数据中心的业务系统通过私网IP地址实现互通，有效节约公网IP地址资源
同机房南北向互通场景（服务器与出口设备位于相同机房）、跨机房南北向互通场景（服务器与出口设备位于不同机房）	可以实现多个数据中心托管服务器出口集中控制（网关）和按需部署增值业务（业务链、负载均衡等），避免各个数据中心重复投资
虚拟机跨机房在线迁移场景	可以实现业务系统双活、主备等容灾备份需求，提升系统可靠性

同时，充分利用同城两个云资源池（位于不同机房）间已具备的光纤直连环境，与多厂商提供的SDN+VxLAN解决方案开展性能对比测试工作，分别对网站、FTP、视频、数据库等4类应用系统业务场景进行了模拟，测试结果见表2。

表2 光纤直连与各厂商大二层互联方案性能测试结果

解决方案	网站类	FTP类	视频类	数据库类
	访问时长/s	上传/下载速率/（MB/s）	分组丢失率	TPM/TPS/个
光纤直连（20公里以内）	0.71	581.1/244.3	<3%	6 829/115
厂商A	0.56	90.4/82.7	<3%	5 866/99
厂商B	0.51	90.9/108.2	<3%	7 113/120
厂商C	0.58	51.6/13.5	<3%	6 754/114

在NFV领域，以江苏电信业务云为试验环境，试点部署了业界较为成熟的VMware
NSX解决方案，并率先提出了基于NFV架构的网络自助式云化流程，现阶段已依托相关IT支撑系统对NSX部分功能进行了二次开发，目前已完成虚拟防火
墙、虚拟负载均衡器、虚拟DHCP等3类虚拟网元功能开发，相关配置界面如图5、图6所示。

图5 虚拟防火墙自助式配置界面

图6 虚拟负载均衡器自助式配置界面

4.2 VDC应用产品展望

在开展上述技术验证工作的同时，计划以云计算和传统数据中心资源整合为切入点，结合IDC产品特性，面向政企用户推出一类基于SDN/NFV技术的创新产
品——VDC（virtual data
center，虚拟数据中心）。VDC是用物理设备构建的专属虚拟化资源池，是将云计算概念运用于IDC的一种新型的数据中心形态。VDC组网是基于
VxLAN的大二层技术实现多个IDC机房的互联，提供IDC机房间东西向与底层无关的二层互通能力，整合零散的IDC资源，进而通过应用SDN、
NFV、自动化部署等技术，建设统一创新型VDC运营管理系统，构建可伸缩的虚拟化基础架构，面向用户提供灵活、安全的私有云服务，允许客户在自己定义的
虚拟网络中配置和使用云资源。用户可以完全掌控自己的虚拟网络环境，包括选择自有的 IP
地址范围、创建子网以及配置路由表、网关，甚至包括复杂的4~7层应用交付服务。在此基础上，还可以根据用户的需求，提供各种应用环境配置、安全管理、代
维等增值业务。VDC逻辑模型如图7所示。

图7 VDC逻辑模型

VDC业务场景需求描述见表3。

表3 VDC业务场景需求描述

序号	需求名称	需求场景	需求解析及具体技术指标	业务归属
1	多机房提供云业务	场景1：异地组建VDC，为用户提供虚机服务，满足云业务场景2：同城组建VDC，为用户提供虚机服务，满足云业务场景3：VDC内虚机迁移、资源迁移、动态资源部署（分钟级）等需求	跨机房传输时延应低于5ms； VDC分组丢失率应低于0.1%； VDC内应实现用户IP、隧道标识（例如：VNI）、全局MAC地址的管理，可动态发现、可重叠； VDC应与云资源池互通，有接口支持资源的协同； VDC应支持一键部署，VDC本身架构的配置应与用户业务参数（如IP、MAC）尽量分开	云业务
2	多机房IDC资源整合	现有机房不能够满足客户在本机房的机架需求，需要选择同城的另一个机房的机架进行扩容，并实现两个机房之间的二层互通	对现有数据中心机房的资源进行整合管理；系统应能够实时、灵活收集并利用各机房的零散机架资源；向用户提供统一的资源视图。使用户的可以感知资源的使用情况	IDC业务
3	用户业务的自动冗余与备份	客户应用系统对数据备份和容灾的需求场景主要有：数据容灾（异地高端存储、低成本云存储）；应用容灾（非实时）；对于有数据、应用容灾需求的客户主要为银行、证券等对价格不敏感的客户	异地的实时数据备份、实时应用备份近期需求不明显；高端客户个性化需求较多，一般通过项目满足；数据备份期间需要保障传输通道、IP链路的稳定带宽	IDC业务、云业务
4	混合云需求	场景1：用户租用电信的公有云，并与自有私有云二层互联，共享应用层业务资源场景2：在用户私有云与其他私有云或者电信公有云连接时，对连接的链路有质量要求（SLA）场景3：增值业务平台的集约化部署（例如：单点部署DDoS清洗系统通过引流为全DC服务等）	用户私有云与公有云二层互通的需求。用户自规划IP地址，建立三层连接；需要组网可以提供对云间连接的保障；有对用户业务7层引流的需求	IDC业务
5	客户租用带宽按需快速调整	场景1：东西向流量带宽调整同一客户的应用系统A、B（或同一应用的A部分、B部分）部署在不同IDC机房或云资源池，A、B之间有内部流量互通；A/B部署场景主要有以下几种情况：物理服务器——物理服务器；云主机——云主机；物理服务器——云主机；物理服务器分布式部署在以上场景下需要实现客户A、B系统/部分之间链路（传输、IP）带宽的快速增减。场景2：南北向流量带宽调整客户租用的IDC出口带宽，需要在（10）分钟颗粒度内实现出口带宽的快速增减场景3：多机房共享互联网出口用户租用多个机房资源后，只在某一个机房租用互联网出口，其他机房共享这一南北向出口。同时，用户南北向流量和机房之间的流量有QoS保障需求	支持用户租用东西向流量带宽（传输、IP）的快速调度、开通，并保障链路的QoS；云计算用户和托管租赁用户有调度南北向互联网出口带宽的需求，VDC需要具备快速调度机制；多机房共享资源，需要与资源系统结合，并支持在多租户场景下的调度，防止调度冲突	IDC业务、云业务
6	自动化运维需求	用户使用虚拟数据中心之后由于虚机或者物理主机位置难于提前确定，完全由系统实时分配（分钟级），因此有使用电信提供代维服务的需求	用户缺少云计算虚机、网络设备的维护手段，需要云管理平台提供相应的运维方法；用户缺少托管主机及其网络设备的维护手段，需要VDC本身与资源系统、DC管理系统结合提供新的运维手段	IDC业务、云业务

5 结束语

传统网络设备支撑了过去几十年网络的发展和应用，随着云计算与移动互联网的兴起，用户的业务需求呈现出多样化、灵活化、不确定性等特点，目前封闭的
网络体系架构已经不能满足实际应用的需求，面临着越来越多的问题和挑战。SDN/NFV作为一种革命性的新技术必将对未来网络的演进带来举足轻重的影响。
云网融合已经成为一种趋势，无论对运营商还是互联网企业而言，谁能率先实现云计算与网络基础设施的深度融合，谁就能够在“互联网+”时代赢得先机，取得领
导地位。

参考文献：

1 赵慧玲, 雷葆华, 王峰, 等. SDN核心技术剖析和实战指南[M]. 北京：电子工业出版社, 2013: 12~13.

2 NADEAU T D, GRAY K. 软件定义网络: SDN与OpenFlow解析[M]. 毕军, 单业, 张绍宇, 等译. 北京: 人民邮电出版社, 2014: 66~67.

3 SDx Central. 2015年网络功能虚拟化（NFV）报告[R/OL]. [2015-04-16]. http://www.sdnlab.com/10593.html.

4 李祥敬. 云数据中心引入网络功能虚拟化NFV[EB/OL ]. [2015-03-22]. http://server.yesky.com/datacenter/161/53732661.shtml.

5 SDN产业联盟. SDN产业发展白皮书（2014年）[EB/OL ]. [2015-04-23]. http://www.sdnlab.com/10752.html .

作者简介：

赵辉（1984年），男，中国电信股份有限公司江苏分公司操作维护中心工程师、平台维护技术支撑工程师，中国通信学会个人会员，主要研究方向为云计算平台维护优化、SDN/NFV技术预研、产品开发等。

丁鸣（1977年），男，中国电信股份有限公司江苏分公司操作维护中心工程师、平台维护部主任，主要研究方向为平台维护管理等。

程青松（1975年），男，中国电信股份有限公司江苏分公司操作维护中心工程师、平台维护部副主任，主要研究方向为平台维护管理等工作。

卢凌（1980年），男，中国电信股份有限公司江苏分公司操作维护中心工程师、平台维护技术支撑工程师，主要研究方向为云计算平台架构规划和新技术研究工作。

孔晨晟（1984年），男，中国电信股份有限公司江苏分公司操作维护中心工程师、平台维护技术支撑工程师，主要研究方向为云计算平台维护优化、SDN/混合云预研等工作。

本文转自： SDNLAB