大规模SDN云计算数据中心组网的架构设计

本文首先分析了在大规模SDN数据中心组网中遇到的问题。一方面Underlay底层组网规模受限于设备实际的转发能力和端口密度,单一Spine-leaf的Fabric架构无法满足大规模组网的需求;另一方面在SDN技术实现方案上,Openstack和SDN控制器分别有管理控制能力上的限制。

本文分别从多POD大规模数据中心的Underlay组网及路由规划,和跨POD互联互通SDN技术实现方案两方面,深入到技术细节,结合网络业务流量模型的实现,阐述了大规模SDN数据中心组网架构。
1.大规模SDN数据中心组网需解决问题分析

大规模的SDN数据中心组网需实现几万台服务器作为一个资源池来承载和编排调度。综合考虑Underlay组网以及SDN解决方案的实现,主要有以下三个方面的问题需要解决。

(一)在数据中心Underlay组网层面。虽然随着芯片不断的升级换代,数据中心交换机处理转发能力极大提升,但是基于目前的数据中心交换机端口能力,同时考虑到每个机房实际机柜的数目,以及机房间跨机房布线的难易程度,单一的Spine-leaf两层架构组网不能满足上万服务器的承载需求。

例如在一个数据中心组网中,选用目前业界主流厂商成熟的16槽的核心交换机设备为Spine,100G板卡端口密度是20个/板卡,40G板卡端口密度是30个/板卡;选用配置48个万兆6个40G的接入交换机为Leaf。Leaf到Spine全互联,Spine核心数量满配6台,核心交换机各配置2块100G板卡用于连接外部防火墙、专网或专线路由设备等。在满足带宽1:1收敛比的情况下,经计算单一Spine-Leaf架构最多能支持服务器的数量为5760台,不能满足几万台服务器的承载需求。

(二)SDN控制器的管理规模和管理范围。SDN控制器管理VSW或者硬件交换机会启用TCP长连接,从占用CPU内存资源,数量过多的被纳管设备将极大地消耗SDN控制器的资源,进而降低控制器的性能,这是SDN控制器管理规模主要限制因素。SDN控制器的管理范围主要受控制器和被纳管设备间的网络时延限制,因此SDN控制器建议本地部署而不建议长距离异地远程管理。目前主流设备厂家在SDN控制器3机集群的情况下,可以管理2000个VSW或者1000个硬件SDN交换机。

(三)云操作系统Openstack的管理能力。Openstack是集中式消息处理机制,所有交互操作会到指令层面进行拆分,而指令并发处理能力低,主要以单进程队列方式进行。比如资源池内同时对100台虚拟机进行操作的场景,交互操作进行指令拆分处理时,因指令并发处理能力差,拆解出的大量指令不得不排队等待执行,Openstack系统此时的交互操作响应效率和及时性都会恶化,影响用户的实际感知。

Cell技术可以极大地提升Openstack平台的消息处理效率,Nova可以扩展为多个Nova处理节点,每个节点有独立的数据库,采用数据库同步的方式,实现多个nova节点的协同和分布式工作。但是,Openstack系统性能是和企业的实际研发能力密切相关的,目前基于开源Openstack研发的主流厂家产品,管理能力为500台虚拟化Host(5000个VM)或者3000台裸金属服务器。

2.大规模SDN数据中心的多POD组网架构

由于单一Spine-Leaf结构的Underaly网络接入承载能力,Openstack平台的管理能力以及SDN控制器的控制范围、控制规模的限制,因此在大规模SDN数据中心组网时,需要分解成多个单独的Spine-Leaf模块进行部署。模块间通过统一的应用层借助于SDN-DCI技术进行协同,实现整个数据中心资源池的统一管理和编排。每个单独的Spine-leaf模块为一个单独的Fabric,也称为一个POD(Point of Delivery)。

POD内组网采用标准SDN数据中心架构,每个POD单独的Openstack云操作系统和SDN控制器。根据主流厂家的Openstack云操作系统产品性能指标,限定POD内的裸金属服务器场景下支持服务器数量3000台,虚拟化服务器场景下支持服务器Host主机数量500台。同时根据主流厂商的SDN控制器性能,限定POD内的硬件交换机数量不大于1000台,VSW数量不大于2000台。

多POD的大规模SDN数据中心组网,POD内Underlay组网是标准的Spine-Leaf架构。POD内SDN-GW可以和Spine合设也可以旁挂Spine部署,防火墙、负载均衡设备旁挂SDN-GW部署。

目前SDN-GW主要是两台堆叠部署,以便于SDN控制器的统一管理,因此如果POD规模较大,需要两台以上Spine时,不建议SDN-GW和Spine合设,SDN-GW应单独旁挂部署。

为实现POD之间的流量互通,设置东西向流量汇聚核心交换机Core-Spine用于承载跨POD的东西向流量;为实现POD内到外网的互访,设置南北向流量汇聚核心交换机Out-Spine用于承载南北向流量。东西向流量汇聚核心交换机和南北向汇聚核心交换机的数量可以根据实际的POD规模、POD数量和网络收敛比要求灵活计算。POD内Spine到POD间汇聚核心交换机一般是跨机房互联,为提高链路利用率,应采用100G光模块互联。

如果POD间东西向流量规划很大,建议POD内Spine直接上连东西向汇聚交换机。此时的流量模型为,POD间互通流量从POD内Spine去到SDN-GW,SDN-GW解开原有VXLAN封装,再将互通流量导入不同的互联VNI后发回给Spine,最后由Spine发送到东西汇聚交换机。此流量模型下相同业务流量会穿越POD内Spine两次,因此如果流量规划完全在SDN-GW交换机设备的承受范围内,建议由SDN-GW上连东西向汇聚交换机,这样可以减少POD内Spine上的来回穿透流量。

大规模SDN数据中心多POD组网架构

POD内的SDN数据中心转发控制技术实现方案,可以是Openflow+Netconf也可以是E×××+Netconf。虚拟机场景推荐使用表项更大更灵活的VSW作为VTEP,从而采用Openflow+Netconf方案。裸金属服务器场景采用硬件SDN接入交换机作为VTEP,可以根据具体网络设备能力情况灵活选择E×××+Netconf的方案或者Openflow+Netconf的方案。

在Openflow+Netconf和E×××+Netconf混合部署的场景,需要在SDN控制器上进行两种控制技术方案的翻译和打通。SDN控制器和SDN-GW建立E×××邻居,将E×××控制面的信息翻译成Openflow发送给VSW,将VSW的相关Openflow信息翻译成E×××控制信息发送给硬件SDN交换机。从而控制实现在VSW和硬件SDN交换机之间建立VXLAN隧道和转发数据。

POD间互联的方案将完全借鉴SDN-DCI的相关技术,采用E×××+VXLAN的技术。POD内的SDN-GW将同时作为DCI-GW,与不同POD的SDN-GW间建立E×××邻居,在统一的协同层的控制下实现跨POD流量的互通。

共享分布式块存储、分布式文件存储、分布式对象存储可以单独规划组成存储POD。访问存储POD的流量在SDN-GW解开VXLAN封装以后走Underaly网络路由转发达到存储POD。在POD内配置单独的VRF用于隔离访问存储的流量和其他业务流量。存储POD有访问外网需求的,存储汇聚交换机规划上连南北汇聚交换机。FC SAN存储建议直接部署在各POD内。

存储POD网络规划图

3.大规模SDN数据中心Underlay组网及路由规划

多POD的大规模数据中心的Underlay组网,网络内网络设备数量众多,按每POD内500台网络设备数量计算,10个POD组网网络设备将超过5000台,因此如何规划好Underlay层面的路由配置,对大规模数据中心网络的高性能转发非常重要。

普通数据中心场景IGP路由主要是以OSPF路由为主,OSPF路由技术成熟,网络建设运维人员使用经验丰富。使用OSPF作为大规模数据中心组网的IGP路由协议,各POD应划分为不同的Area区域,东西汇聚交换机作为骨干区域Area0,以减少LSA的传播区域和传播数量。各POD内SDN-GW作为OSPF区域边界网络设备,将不同接口划入不同的区域,上连东西汇聚交换机接口划入Area0,下连POD内Spine接口划入各POD单独Area。南北汇聚交换机一般工作在二层透传模式,三层终结在外网防火墙,因此南北汇聚交换机可不运行路由协议。


大规模数据中心组网OSPF路由规划

相比较OSPF,ISIS 支持ISPF(Incremental SPF),对大规模网络的支持能力和收敛性能更好。ISIS支持灵活的TLV编码方式,协议扩展性更好。ISIS因其收敛速度快、结构清晰、适用于较大规模网络,一直比较多应用于城域网场景或者IP专网场景作为IGP路由协议。随着数据中心规模越来越大、设备数量越来越多,ISIS也更多的应用于数据中心场景。ISIS的区域边界在链路,每台网络设备只能属于一个ISIS区域。为减少LSP的传播区域和传播数量,在大规模数据中心场景ISIS分层次进行规划,骨干区域包括POD间东西汇聚交换机和每个POD内的SDN-GW。POD间东西汇聚交换机运行ISIS level2,POD内的SDN-GW运行ISIS的level-1-2。每个POD内Spine和Leaf运行ISIS level1。

大规模数据中心组网ISIS路由规划

RFC7938提出了将EBGP路由协议应用于大规模数据中心的建议,而且目前也有少量将EBGP应用于数据中心内作为底层路由协议的实例。有别于OSPF、ISIS等链路状态协议,BGP是一种距离矢量路由协议,因此BGP的扩展性更好。在中小型的数据中心组网时,使用BGP和使用ISIS、OSPF等链路状态协议性能区别不大,但是在超大型数据中心的网络中,应用BGP的性能会更优。OSPF、ISIS等链路状态协议需要在网络内传递大量的LSA,路由信息生成过程是先完成LSA信息同步,再计算生成路由信息。在网络部分节点发生变动或者网络割接升级时,会引起大量LSA的传递。而距离矢量路由协议BGP不存在这样的问题,BGP节点间直接通告路由,在网络扩展和割接升级时的网络稳定性更好。

目前关于OSPF和ISIS路由协议的LSA优化在IETF已经有相应的draft,目的都是为了减少LSA的传播数量和传播范围,已使OSPF和ISIS在超大规模数据中心组网中的性能更优,但是目前并没有非常有效的并被实际应用的方案。虽然目前将EBGP应用于数据中心应用并不广泛,但是未来超大规模数据中心的底层路由协议选择,距离矢量路由协议BGP很可能会得到更广泛的应用。

EBGP路由的规划和配置相对于OSPF和ISIS会复杂一些。POD内的多台Spine设备规划为同一AS号,多台东西汇聚交换机规划为同一AS号,每组堆叠Leaf规划一个单独 AS号。虽然每个POD内Leaf只和本POD内Spine建立EBGP邻居,Leaf间不建立EBGP邻居,但是Spine上仍然需要配置大量的Leaf邻居信息。规划配置复杂,是限制EBGP在数据中心内应用的因素之一。

在使用EBGP作为底层路由协议的大规模数据中心,如果POD内同时以E×××+Netconf为转发控制方案,POD内E×××需以IBGP为基础建立,因此需要一台网络设备同时配置EBGP+IBGP两个不同AS号的BGP进程。目前已经有主流厂家网络设备支持不同AS号的BGP双进程。

常规BGP报文AS号为16比特长度,取值范围为0-65535,其中私有AS号范围64512到65534,因此可用于数据中心内组网规划的私有AS号数量为1023个。按照每组堆叠Leaf一个AS号的原则,显然无法满足多POD大规模数据中心组网的AS号分配需求。RFC6793建议将BGP的AS号扩展到32比特长度,扩展后AS号数量满足大规模数据中心组网已经完全没有问题,且目前业界主流设备已具备32比特AS号长度的支持能力。


大规模数据中心组网EBGP路由规划

SDN数据中心的管理网除了满足传统的设备带外管理功能,还要部署Openstack云管理平台和SDN控制器,因此相比传统数据中心的管理网更加重要。随着数据中心规模的增大,管理网的规模也必然同时增大,因此大规模数据中心的管理网也需要分POD部署。POD内管理网核心交换机配置各网段网关,管理网接入交换机工作在二层VLAN透传模式。管理网POD间设置管理汇聚交换机,POD内管理网核心和POD间汇聚交换机三层互联,可以运行ISIS或者OSPF路由协议。为了减小POD内管理网广播域使管理网更加稳定,也可以将管理网段的网关配置在管理接入交换机上,规划三层到边缘的管理网络,但是这样做同时带来的弊端是需要更详细的管理地址规划,过于细分的管理地址规划会在一定程度上浪费地址资源,因此三层到边缘的管理网规划并不常见。

4.大规模SDN数据中心POD间互联互通

大规模SDN数据中心需要将不同POD内资源统一管理和调度,构造大规模数据中心统一资源池。大规模SDN数据中心采用SDN-DCI技术实现POD间互联互通。

SDN-DCI技术通过E×××+VXLAN建立跨POD互联通路,管理面采用E×××协议,数据面采用VXLAN隧道承载。POD内的SDN-GW将同时作为DCI-GW,各POD的SDN-GW之间配置运行Full mesh的EBGP协议。基于EBGP协议,各POD的SDN-GW之间建立E×××邻居关系,通过E×××建立互联互通的控制面,传递租户VPC内(Virtual Private Cloud)的MAC、ARP和IP网段路由信息。

大规模数据中心部署统一云管理平台,协同编排各POD内SDN控制器实现跨POD网络业务流量互通。考虑到实际网络部署时,POD间很可能为异厂家设备,因此云管理平台需要对接不同厂家SDN控制器,为此需定义标准的SDN控制器到云管平台的北向API开放接口,异厂家SDN控制器据此标准接口接收云管平台指令并控制本POD内转发设备完成指令的执行。


跨POD互通E×××+VXLAN技术方案示意图

通过分析大规模数据中心跨POD业务互联互通需求,可以得出以下流量模型:同业务域同租户跨POD互通,不过内网防火墙;同业务域不同租户跨POD互通,过内网防火墙;不同业务域同租户跨POD互通,过内网防火墙;不同业务域不同租户跨POD互通,过内网防火墙。

将以上网络流量模型总结分析,可以归纳简化为两种互通流量模型,即跨POD过防火墙互通和跨POD不过防火墙互通。在云管平台跨POD互通业务接口指令模板中,增加防火墙状态使能开关来决定是否过防火墙。另外考虑到流量模型的对称,在过墙的场景下要求双侧POD内均过墙。

跨POD互通不过防火墙流量,租户流量在本地接入VTEP封装进本地VXLAN隧道,到达POD内SDN-GW解开本地VXLAN封装,并重新封装进互联VXLAN后发往对端POD内SDN-GW。流量达到对端POD内SDN-GW后解开互联VXLAN封装,再封装进相应租户本地VXLAN隧道。不同业务的跨POD互通流量应予以隔离,需要为每组业务互通流量规划一个单独的VNI和VRF,并将VNI和VRF绑定。

跨POD不过防火墙流量模型

跨POD互通过防火墙流量模型,租户流量到达POD内SDN-GW解开本地VXLAN封装后通过VLAN二层转发送往防火墙,防火墙处理完毕后送回SDN-GW,SDN-GW重新封装进互联VXLAN后发往对端POD内SDN-GW。流量达到对端POD内SDN-GW后解开互联VXLAN封装,通过VLAN二层转发送往本POD内防火墙,防火墙处理完毕后送回SDN-GW,SDN-GW再将流量封装进相应租户本地VXLAN隧道。

跨POD不过防火墙流量模型

不同业务的跨POD互通流量应予以隔离,需要为每组业务互通流量规划一个单独的VNI和VRF,并将VNI和VRF绑定。对于部分需要经过负载均衡设备处理的业务流量,可以由云管平台统一编排流量经过相应的负载均衡。

5.大规模SDN数据中心南北向流量简述

大规模SDN数据中心对南北向流量的处理,在引入多POD组网后,增加了南北汇聚交换机。由南北汇聚交换机分别上连互联网防火墙、IP专网和专线路由器。南北汇聚交换机在互联网南北业务流量的处理上工作在二层透传模式,三层分别终结在SDN-GW和外网防火墙。在进出IP专网和专线的南北流量处理上可以视具体情况工作在二层透传或者三层模式,工作在三层模式需要配置VRF进行不同业务流量的隔离。
创作:http://www.ie-lab.cn/
本文首先分析了在大规模SDN数据中心组网中遇到的问题。一方面Underlay底层组网规模受限于设备实际的转发能力和端口密度,单一Spine-leaf的Fabric架构无法满足大规模组网的需求;另一方面在SDN技术实现方案上,Openstack和SDN控制器分别有管理控制能力上的限制。

本文分别从多POD大规模数据中心的Underlay组网及路由规划,和跨POD互联互通SDN技术实现方案两方面,深入到技术细节,结合网络业务流量模型的实现,阐述了大规模SDN数据中心组网架构。
1.大规模SDN数据中心组网需解决问题分析

大规模的SDN数据中心组网需实现几万台服务器作为一个资源池来承载和编排调度。综合考虑Underlay组网以及SDN解决方案的实现,主要有以下三个方面的问题需要解决。

(一)在数据中心Underlay组网层面。虽然随着芯片不断的升级换代,数据中心交换机处理转发能力极大提升,但是基于目前的数据中心交换机端口能力,同时考虑到每个机房实际机柜的数目,以及机房间跨机房布线的难易程度,单一的Spine-leaf两层架构组网不能满足上万服务器的承载需求。

例如在一个数据中心组网中,选用目前业界主流厂商成熟的16槽的核心交换机设备为Spine,100G板卡端口密度是20个/板卡,40G板卡端口密度是30个/板卡;选用配置48个万兆6个40G的接入交换机为Leaf。Leaf到Spine全互联,Spine核心数量满配6台,核心交换机各配置2块100G板卡用于连接外部防火墙、专网或专线路由设备等。在满足带宽1:1收敛比的情况下,经计算单一Spine-Leaf架构最多能支持服务器的数量为5760台,不能满足几万台服务器的承载需求。

(二)SDN控制器的管理规模和管理范围。SDN控制器管理VSW或者硬件交换机会启用TCP长连接,从占用CPU内存资源,数量过多的被纳管设备将极大地消耗SDN控制器的资源,进而降低控制器的性能,这是SDN控制器管理规模主要限制因素。SDN控制器的管理范围主要受控制器和被纳管设备间的网络时延限制,因此SDN控制器建议本地部署而不建议长距离异地远程管理。目前主流设备厂家在SDN控制器3机集群的情况下,可以管理2000个VSW或者1000个硬件SDN交换机。

(三)云操作系统Openstack的管理能力。Openstack是集中式消息处理机制,所有交互操作会到指令层面进行拆分,而指令并发处理能力低,主要以单进程队列方式进行。比如资源池内同时对100台虚拟机进行操作的场景,交互操作进行指令拆分处理时,因指令并发处理能力差,拆解出的大量指令不得不排队等待执行,Openstack系统此时的交互操作响应效率和及时性都会恶化,影响用户的实际感知。

Cell技术可以极大地提升Openstack平台的消息处理效率,Nova可以扩展为多个Nova处理节点,每个节点有独立的数据库,采用数据库同步的方式,实现多个nova节点的协同和分布式工作。但是,Openstack系统性能是和企业的实际研发能力密切相关的,目前基于开源Openstack研发的主流厂家产品,管理能力为500台虚拟化Host(5000个VM)或者3000台裸金属服务器。

2.大规模SDN数据中心的多POD组网架构

由于单一Spine-Leaf结构的Underaly网络接入承载能力,Openstack平台的管理能力以及SDN控制器的控制范围、控制规模的限制,因此在大规模SDN数据中心组网时,需要分解成多个单独的Spine-Leaf模块进行部署。模块间通过统一的应用层借助于SDN-DCI技术进行协同,实现整个数据中心资源池的统一管理和编排。每个单独的Spine-leaf模块为一个单独的Fabric,也称为一个POD(Point of Delivery)。

POD内组网采用标准SDN数据中心架构,每个POD单独的Openstack云操作系统和SDN控制器。根据主流厂家的Openstack云操作系统产品性能指标,限定POD内的裸金属服务器场景下支持服务器数量3000台,虚拟化服务器场景下支持服务器Host主机数量500台。同时根据主流厂商的SDN控制器性能,限定POD内的硬件交换机数量不大于1000台,VSW数量不大于2000台。

多POD的大规模SDN数据中心组网,POD内Underlay组网是标准的Spine-Leaf架构。POD内SDN-GW可以和Spine合设也可以旁挂Spine部署,防火墙、负载均衡设备旁挂SDN-GW部署。

目前SDN-GW主要是两台堆叠部署,以便于SDN控制器的统一管理,因此如果POD规模较大,需要两台以上Spine时,不建议SDN-GW和Spine合设,SDN-GW应单独旁挂部署。

为实现POD之间的流量互通,设置东西向流量汇聚核心交换机Core-Spine用于承载跨POD的东西向流量;为实现POD内到外网的互访,设置南北向流量汇聚核心交换机Out-Spine用于承载南北向流量。东西向流量汇聚核心交换机和南北向汇聚核心交换机的数量可以根据实际的POD规模、POD数量和网络收敛比要求灵活计算。POD内Spine到POD间汇聚核心交换机一般是跨机房互联,为提高链路利用率,应采用100G光模块互联。

如果POD间东西向流量规划很大,建议POD内Spine直接上连东西向汇聚交换机。此时的流量模型为,POD间互通流量从POD内Spine去到SDN-GW,SDN-GW解开原有VXLAN封装,再将互通流量导入不同的互联VNI后发回给Spine,最后由Spine发送到东西汇聚交换机。此流量模型下相同业务流量会穿越POD内Spine两次,因此如果流量规划完全在SDN-GW交换机设备的承受范围内,建议由SDN-GW上连东西向汇聚交换机,这样可以减少POD内Spine上的来回穿透流量。

大规模SDN数据中心多POD组网架构

POD内的SDN数据中心转发控制技术实现方案,可以是Openflow+Netconf也可以是E×××+Netconf。虚拟机场景推荐使用表项更大更灵活的VSW作为VTEP,从而采用Openflow+Netconf方案。裸金属服务器场景采用硬件SDN接入交换机作为VTEP,可以根据具体网络设备能力情况灵活选择E×××+Netconf的方案或者Openflow+Netconf的方案。

在Openflow+Netconf和E×××+Netconf混合部署的场景,需要在SDN控制器上进行两种控制技术方案的翻译和打通。SDN控制器和SDN-GW建立E×××邻居,将E×××控制面的信息翻译成Openflow发送给VSW,将VSW的相关Openflow信息翻译成E×××控制信息发送给硬件SDN交换机。从而控制实现在VSW和硬件SDN交换机之间建立VXLAN隧道和转发数据。

POD间互联的方案将完全借鉴SDN-DCI的相关技术,采用E×××+VXLAN的技术。POD内的SDN-GW将同时作为DCI-GW,与不同POD的SDN-GW间建立E×××邻居,在统一的协同层的控制下实现跨POD流量的互通。

共享分布式块存储、分布式文件存储、分布式对象存储可以单独规划组成存储POD。访问存储POD的流量在SDN-GW解开VXLAN封装以后走Underaly网络路由转发达到存储POD。在POD内配置单独的VRF用于隔离访问存储的流量和其他业务流量。存储POD有访问外网需求的,存储汇聚交换机规划上连南北汇聚交换机。FC SAN存储建议直接部署在各POD内。

存储POD网络规划图

3.大规模SDN数据中心Underlay组网及路由规划

多POD的大规模数据中心的Underlay组网,网络内网络设备数量众多,按每POD内500台网络设备数量计算,10个POD组网网络设备将超过5000台,因此如何规划好Underlay层面的路由配置,对大规模数据中心网络的高性能转发非常重要。

普通数据中心场景IGP路由主要是以OSPF路由为主,OSPF路由技术成熟,网络建设运维人员使用经验丰富。使用OSPF作为大规模数据中心组网的IGP路由协议,各POD应划分为不同的Area区域,东西汇聚交换机作为骨干区域Area0,以减少LSA的传播区域和传播数量。各POD内SDN-GW作为OSPF区域边界网络设备,将不同接口划入不同的区域,上连东西汇聚交换机接口划入Area0,下连POD内Spine接口划入各POD单独Area。南北汇聚交换机一般工作在二层透传模式,三层终结在外网防火墙,因此南北汇聚交换机可不运行路由协议。

大规模数据中心组网OSPF路由规划

相比较OSPF,ISIS 支持ISPF(Incremental SPF),对大规模网络的支持能力和收敛性能更好。ISIS支持灵活的TLV编码方式,协议扩展性更好。ISIS因其收敛速度快、结构清晰、适用于较大规模网络,一直比较多应用于城域网场景或者IP专网场景作为IGP路由协议。随着数据中心规模越来越大、设备数量越来越多,ISIS也更多的应用于数据中心场景。ISIS的区域边界在链路,每台网络设备只能属于一个ISIS区域。为减少LSP的传播区域和传播数量,在大规模数据中心场景ISIS分层次进行规划,骨干区域包括POD间东西汇聚交换机和每个POD内的SDN-GW。POD间东西汇聚交换机运行ISIS level2,POD内的SDN-GW运行ISIS的level-1-2。每个POD内Spine和Leaf运行ISIS level1。

大规模数据中心组网ISIS路由规划

RFC7938提出了将EBGP路由协议应用于大规模数据中心的建议,而且目前也有少量将EBGP应用于数据中心内作为底层路由协议的实例。有别于OSPF、ISIS等链路状态协议,BGP是一种距离矢量路由协议,因此BGP的扩展性更好。在中小型的数据中心组网时,使用BGP和使用ISIS、OSPF等链路状态协议性能区别不大,但是在超大型数据中心的网络中,应用BGP的性能会更优。OSPF、ISIS等链路状态协议需要在网络内传递大量的LSA,路由信息生成过程是先完成LSA信息同步,再计算生成路由信息。在网络部分节点发生变动或者网络割接升级时,会引起大量LSA的传递。而距离矢量路由协议BGP不存在这样的问题,BGP节点间直接通告路由,在网络扩展和割接升级时的网络稳定性更好。

目前关于OSPF和ISIS路由协议的LSA优化在IETF已经有相应的draft,目的都是为了减少LSA的传播数量和传播范围,已使OSPF和ISIS在超大规模数据中心组网中的性能更优,但是目前并没有非常有效的并被实际应用的方案。虽然目前将EBGP应用于数据中心应用并不广泛,但是未来超大规模数据中心的底层路由协议选择,距离矢量路由协议BGP很可能会得到更广泛的应用。

EBGP路由的规划和配置相对于OSPF和ISIS会复杂一些。POD内的多台Spine设备规划为同一AS号,多台东西汇聚交换机规划为同一AS号,每组堆叠Leaf规划一个单独 AS号。虽然每个POD内Leaf只和本POD内Spine建立EBGP邻居,Leaf间不建立EBGP邻居,但是Spine上仍然需要配置大量的Leaf邻居信息。规划配置复杂,是限制EBGP在数据中心内应用的因素之一。

在使用EBGP作为底层路由协议的大规模数据中心,如果POD内同时以E×××+Netconf为转发控制方案,POD内E×××需以IBGP为基础建立,因此需要一台网络设备同时配置EBGP+IBGP两个不同AS号的BGP进程。目前已经有主流厂家网络设备支持不同AS号的BGP双进程。

常规BGP报文AS号为16比特长度,取值范围为0-65535,其中私有AS号范围64512到65534,因此可用于数据中心内组网规划的私有AS号数量为1023个。按照每组堆叠Leaf一个AS号的原则,显然无法满足多POD大规模数据中心组网的AS号分配需求。RFC6793建议将BGP的AS号扩展到32比特长度,扩展后AS号数量满足大规模数据中心组网已经完全没有问题,且目前业界主流设备已具备32比特AS号长度的支持能力。

大规模数据中心组网EBGP路由规划

SDN数据中心的管理网除了满足传统的设备带外管理功能,还要部署Openstack云管理平台和SDN控制器,因此相比传统数据中心的管理网更加重要。随着数据中心规模的增大,管理网的规模也必然同时增大,因此大规模数据中心的管理网也需要分POD部署。POD内管理网核心交换机配置各网段网关,管理网接入交换机工作在二层VLAN透传模式。管理网POD间设置管理汇聚交换机,POD内管理网核心和POD间汇聚交换机三层互联,可以运行ISIS或者OSPF路由协议。为了减小POD内管理网广播域使管理网更加稳定,也可以将管理网段的网关配置在管理接入交换机上,规划三层到边缘的管理网络,但是这样做同时带来的弊端是需要更详细的管理地址规划,过于细分的管理地址规划会在一定程度上浪费地址资源,因此三层到边缘的管理网规划并不常见。

4.大规模SDN数据中心POD间互联互通

大规模SDN数据中心需要将不同POD内资源统一管理和调度,构造大规模数据中心统一资源池。大规模SDN数据中心采用SDN-DCI技术实现POD间互联互通。

SDN-DCI技术通过E×××+VXLAN建立跨POD互联通路,管理面采用E×××协议,数据面采用VXLAN隧道承载。POD内的SDN-GW将同时作为DCI-GW,各POD的SDN-GW之间配置运行Full mesh的EBGP协议。基于EBGP协议,各POD的SDN-GW之间建立E×××邻居关系,通过E×××建立互联互通的控制面,传递租户VPC内(Virtual Private Cloud)的MAC、ARP和IP网段路由信息。

大规模数据中心部署统一云管理平台,协同编排各POD内SDN控制器实现跨POD网络业务流量互通。考虑到实际网络部署时,POD间很可能为异厂家设备,因此云管理平台需要对接不同厂家SDN控制器,为此需定义标准的SDN控制器到云管平台的北向API开放接口,异厂家SDN控制器据此标准接口接收云管平台指令并控制本POD内转发设备完成指令的执行。

跨POD互通E×××+VXLAN技术方案示意图

通过分析大规模数据中心跨POD业务互联互通需求,可以得出以下流量模型:同业务域同租户跨POD互通,不过内网防火墙;同业务域不同租户跨POD互通,过内网防火墙;不同业务域同租户跨POD互通,过内网防火墙;不同业务域不同租户跨POD互通,过内网防火墙。

将以上网络流量模型总结分析,可以归纳简化为两种互通流量模型,即跨POD过防火墙互通和跨POD不过防火墙互通。在云管平台跨POD互通业务接口指令模板中,增加防火墙状态使能开关来决定是否过防火墙。另外考虑到流量模型的对称,在过墙的场景下要求双侧POD内均过墙。

跨POD互通不过防火墙流量,租户流量在本地接入VTEP封装进本地VXLAN隧道,到达POD内SDN-GW解开本地VXLAN封装,并重新封装进互联VXLAN后发往对端POD内SDN-GW。流量达到对端POD内SDN-GW后解开互联VXLAN封装,再封装进相应租户本地VXLAN隧道。不同业务的跨POD互通流量应予以隔离,需要为每组业务互通流量规划一个单独的VNI和VRF,并将VNI和VRF绑定。

跨POD不过防火墙流量模型

跨POD互通过防火墙流量模型,租户流量到达POD内SDN-GW解开本地VXLAN封装后通过VLAN二层转发送往防火墙,防火墙处理完毕后送回SDN-GW,SDN-GW重新封装进互联VXLAN后发往对端POD内SDN-GW。流量达到对端POD内SDN-GW后解开互联VXLAN封装,通过VLAN二层转发送往本POD内防火墙,防火墙处理完毕后送回SDN-GW,SDN-GW再将流量封装进相应租户本地VXLAN隧道。

跨POD不过防火墙流量模型

不同业务的跨POD互通流量应予以隔离,需要为每组业务互通流量规划一个单独的VNI和VRF,并将VNI和VRF绑定。对于部分需要经过负载均衡设备处理的业务流量,可以由云管平台统一编排流量经过相应的负载均衡。

5.大规模SDN数据中心南北向流量简述

大规模SDN数据中心对南北向流量的处理,在引入多POD组网后,增加了南北汇聚交换机。由南北汇聚交换机分别上连互联网防火墙、IP专网和专线路由器。南北汇聚交换机在互联网南北业务流量的处理上工作在二层透传模式,三层分别终结在SDN-GW和外网防火墙。在进出IP专网和专线的南北流量处理上可以视具体情况工作在二层透传或者三层模式,工作在三层模式需要配置VRF进行不同业务流量的隔离。
创作:http://www.ie-lab.cn/

原文地址:https://blog.51cto.com/14248289/2373764

时间: 2024-11-10 02:31:05

大规模SDN云计算数据中心组网的架构设计的相关文章

云计算数据中心安全体系架构浅析

建立数据中心的目的是为了更好地利用数据.挖掘数据,向数据要效益.在数据中心中应用云计算技术则是一个必然的趋势.而从数据中心获得效益就必须有一个相对安全稳定的环境作为支撑,因此研究云计算数据中心的信息安全体系架构具有重要意义. 在建设云计算数据中心时,由于资源整合程度和共享程度很高,不论是数据安全.应用安全还是虚拟化安全,都以服务的方式交付给数据中心用户.在这种建设思路的指引下,云计算数据中心的信息安全体系和传统数据中心的安全防护体系差别很大,像小鸟云数据中心都是基于业务驱动的分布式云数据中心架构

一张图看明白云计算数据中心总体分层架构

释放价值,分享知识和经验,解读IT前沿和技术.帮助他人,提升自己.更多交流请关注微信公众号itboxes(IT智囊).

[转]漫谈数据中心CLOS网络架构

http://djt.qq.com/article/view/238 1.数据中心网络架构挑战 随着技术的发展,数据中心的规模越来越大,一个数据中心的服务器容量从几年前的几千台服务器发展到今天的几万甚至几十万台.为了降低网络建设和运维成本,数据中心网络的设计者们也竭力将一个网络模块的规模尽可能扩大.同时,数据中心网络内部东西向流量也日益增加,在一些集群业务的需求驱动下,数据中心网络设计者们甚至开始讨论一个网络模块内10000台千兆线速服务器的可能性. 常见的数据中心网络模块的典型架构是双核心交换

国庆遐想:漫步云计算数据中心

回顾历史,云计算的概念起源于2006年(亚马逊.谷歌首创),但是,微软是后起之秀,2008年起步,现在,在纳徳拉的领导下,成为全球云计算的领头人. 你去过云计算数据中心吗?一般而言,考虑到安全因素,一般人是不允许进入云计算数据中心的.大约在2008年的夏天,我曾当面向李开复提出要求参观谷歌云计算数据中心,结果,李开复以商业机密为由,我被婉言相拒. 记得,在2000年的初秋,我得以进入深圳云计算数据中心,只见机柜林立,整齐排列,阵势吓人,...... 言归正传.大家都见过智能手机,体积很小,硬件的

云计算数据中心系列 【服务器篇】

课程目录:1-1.课程简介2-1.服务器基础2-2.服务器基准测试体系.TPC.SPEC2-3.服务器分类2-4.超融合服务器2-5.服务器分类2(指令集)2-6.Scale.up.-.Scale.out.-Scale.in2-7.服务器硬件架构2-8.服务器核心组件介绍3-1.RAID技术基础3-2.常见RAID技术(RAID.0.1.3.5.10.50等)3-3.RAID.2.0技术4-1.IBM大型机4-2.IBM小型机4-3.分享:.你不知道的杨振宁4-4.浪潮华为小型机4-5.华为通用

云计算数据中心运维管理要点

在数据中心生命周期中,数据中心运维管理是数据中心生命周期中最后一个.也是历时最长的一个阶段.数据中心运维管理就是:为提供符合要求的信息系统服务,而对与该信息系统服务有关的数据中心各项管理对象进行系统的计划.组织.协调与控制,是信息系统服务有关各项管理工作的总称.数据中心运维管理主要肩负起以下重要目标:合规性.可用性.经济性.服务性等四大目标. 由于云计算的要求弹性.灵活快速扩展.降低运维成本.自动化资源监控.多租户环境等特性除基于ITIL的常规数据中心运维管理理念之外,以下运维管理方面的内容,也

推进云计算数据中心发展:小鸟云华东数据中心投入使用!

据小鸟云官网消息,小鸟云华东数据中心日前宣布建成,并将在今日内正式开放使用!这个占地25,000平米,总机柜数量4000架的数据中心落户江苏南京,为华东地区云计算.大数据和移动互联网等业务打造了坚实的互联网基础设施平台. 该中心投资5亿元人民币,建筑面积25,000平米,按国际T4标准.国内A级.电信行业五星级标准建设,拥有4000个标准服务器机柜.电信.联通.移动.广电.教育网五网接入,是华东地区极为稀缺的多线BGP机房,可提供99.995%可靠率的高品质服务. 小鸟云:不忘初心,质量为王 小

【大数据干货】基于Hadoop的大数据平台实施——整体架构设计

大数据的热度在持续的升温,继云计算之后大数据成为又一大众所追捧的新星.我们暂不去讨论大数据到底是否适用于您的公司或组织,至少在互联网上已经被吹嘘成无所不能的超级战舰.大数据的热度在持续的升温,继云计算之后大数据成为又一大众所追捧的新星.我们暂不去讨论大数据到底是否适用于您的公司或组织,至少在互联网上已经被吹嘘成无所不能的超级战舰.好像一夜之间我们就从互联网时代跳跃进了大数据时代!关于到底什么是大数据,说真的,到目前为止就和云计算一样,让我总觉得像是在看电影<云图>--云里雾里的感觉.或许那些正

TWaver可视化编辑器的前世今生(四)电力 云计算 数据中心

插播一则广告(长期有效) TWaver需要在武汉招JavaScript工程师若干 要求:对前端技术(JavasScript.HTML.CSS),对可视化技术(Canvas.WebGL)有浓厚的兴趣基础不好的可培养,基础好的可共谋大事感兴趣的给我发邮件:[email protected] --------------------------------------------------------------------------------正文的分割线--------------------