XXX SDN数据中心网络解决方案模板.docx
- 文档编号:28573054
- 上传时间:2023-07-19
- 格式:DOCX
- 页数:25
- 大小:358.41KB
XXX SDN数据中心网络解决方案模板.docx
《XXX SDN数据中心网络解决方案模板.docx》由会员分享,可在线阅读,更多相关《XXX SDN数据中心网络解决方案模板.docx(25页珍藏版)》请在冰豆网上搜索。
XXXSDN数据中心网络解决方案模板
XXX项目SDN数据中心网络
解决方案(模板)
XX集团
XXX.XXX.XXX
1XXX项目建设背景4
1.1项目背景4
1.2项目目标4
1.3项目需求4
2XXSDN技术发展及产品现状4
2.1XXSDN技术发展现状4
2.2XXSDN市场地位5
2.3XXSDN解决方案6
3XXX项目SDN网络解决方案6
3.1方案设计原则6
3.2整体建设方案8
3.2.1整体组网设计9
3.2.2单Fabric组网设计10
3.2.3方案主要功能11
3.3XXSDN服务支持20
3.3.1SDN部署服务20
3.3.2SDN软件技术支持服务20
3.3.3SDN开发者技术支持服务20
3.3.4SDN解决方案规划咨询服务20
3.3.5SDNAPP定制开发服务21
3.4XXSDN下一代数据中心优势21
3.4.1整网设计架构开放、标准、兼容22
3.4.2可靠性设计22
3.4.3安全融合,符合等保建设要求23
3.4.4架构弹性设计23
3.4.5端到端全流程自动化25
3.4.6可视化运维管理便捷25
1XXX项目建设背景
1.1项目背景
XXX
1.2项目目标
基于以上项目背景和需求,本次XXXX网络建设设计需要满足未来较长一段时期的基础设施部署需求,并借助本次XXXX网络部署的独立性,运用VXLAN、SDN主流技术对当前数据中心网络结构进行优化,以适应未来网络架构的发展需求。
本项目的具体目标如下:
1.建设XXXX机房网络基础设施。
2.数据中心网络至少需要支持未来的生产系统、业务系统部署需求。
业务上线时间由原先的平均30天,缩短到分钟级别。
3.结合xx公司IT总体的规划,对XXXX的网络结构进行必要的优化,以适应新时期的业务部署、安全运行、提高IT管理水平的需求,网络方案要保持一定的先进性。
4.采用先进的数据中心设计理念,能够支持新一代应用架构,适用于未来5-7年的IT技术发展,可以最大程度的保护数据和业务连续性。
1.3项目需求
在XXXX建设过程中,主要有以下几方面需求。
1.1.1业务需求
如何更加快速地部署业务应用,为企业业务系统提供更及时、更便利的网络服务,提升企业的运行效率与竞争实力,也是当前企业数据中心使用中面临的挑战之一。
因此,当前数据中心的建设必须考虑如何实现快速上线业务、快速响应需求、提高部署效率。
1.1.2网络需求
服务器虚拟化使高效利用IT资源,降低企业运营成本成为可能。
服务器内多虚拟机之间的交互流量,传统网络设备无法感知,也不能进行流量监控和必要的策略控制。
虚拟机的灵活部署和动态迁移需要网络接入侧做相应的调整,在迁移时保持业务不中断。
虚拟机迁移的物理范围不应过小,否则无法充分利用空闲的服务器资源。
迁移后虚拟机的IP地址不改变,以保持业务不中断,因此对数据中心网络提出了大二层的需求。
1.1.3安全需求
数据中心对网络安全性的需求是最基本的需求。
安全性设计包括物理空间的安全控制及网络的安全控制。
系统设计从整体方案上需要考虑端对端的安全,保证安全、绿色的使用资源。
1.1.4运维需求
高效的运维是数据中心运营成功的基础。
数据中心网络设备和IT资源呈现数量大、厂商多、运行配置复杂的特点,如何简化企业数据中心的运维管理、降低人工运维成本,是当前企业数据中心发展面临的重要挑战。
在采用虚拟化技术后,数据中心网络延伸到服务器内部,如何对包括虚拟设备在内的多类设备进行统一管理、实现网络流量的精细化管理和网络故障的快速定位,都是对云计算时代数据中心运维的基本需求。
在数据中心业务场景中,面向应用的运维管理目前正变得越来越迫切,如应用间/内的交互数据统计,带宽占用情况,数据转发路径链路质量,会话连接故障分析等精细化运维管理正成为用户广泛的诉求,上述运维手段的实现将对减轻人工运维压力,快速故障响应,提升用户业务体验等方面都将获得显著效果。
2XXX项目SDN网络解决方案
2.1XXSDN解决方案
做为国内领先的网络设备供应厂商,XX在SDN领域同样有着深厚的积累,能够提供从SDN设备、SDN控制器(Controller)、SDN业务编排、SDN应用与SDN管理等全套SDN解决方案的厂商。
与传统网络设备与解决方案不同,XX的SDN设备、SDN控制器与整个SDN解决方案都提供了丰富、标准与开放的可编程接口(API),使得用户能够针对自己网络的特点使用这些可编程接口来开发网络应用,并通过网络应用对网络进行智能掌控,从而实现网络与用户业务及应用的无缝集成。
2.2方案设计原则
XXX项目从业务实际需求出发,充分利用信息技术优势,从大处着眼,小处着手,与用户共同建设一个目标明确、管理清晰、执行顺利、平稳运行的项目,在系统的建设和管理过程中,我们将遵循以下原则:
1、注重顶层设计、统筹规划,分步实施原则
在项目的整体规划和总体设计阶段做好统一设计、统一标准、统一规范,然后分层、分阶段、逐步建设,关注每个阶段的产出和成果,在统一的目标下逐步完成整个项目的策略、需求、分析、设计、研发、测试、部署、试运行、培训、运维等工作。
同时充分发挥各类项目相关人的知识能动性,为XXX提供信息化建设的咨询指导。
2、强化应用建设,突出应用,关注实用原则
XXX建设项目的建设效果和建设思路直接体现了XXX建设项目最直接的产出。
因此,我们在建设项目过程中,将重点突出项目的应用目的,关注实用价值,以应用和需求为主导,并在建设的过程中基于XXX业务服务的要求、IT技术的发展,边建设、边开发、边应用、边完善,让应用的实际效果作为项目直接驱动要素。
3、追求架构先进、技术成熟,扩展性强原则
项目建设中所采用的技术架构,在一定程度上影响着项目的稳定性,也影响到项目未来的发展。
因此在实施过程中我们将放眼长远,在保证可靠的基础上,尽量采用先进的网络技术、应用平台和开发工具,使XXX系统建设项目具有较长的生命周期。
4、经济实用、节约成本原则
无论在产品的选型、技术的选择中,我们都要考虑成本的约束,其中不仅考虑当前采购的经济性,还要考虑系统长期运维的经济性,即系统的总拥有成本,尽力选择既经济可行又长期保障的产品和技术。
5、确保安全、保护隐私原则
在系统建设中要充分考虑到系统安全性以及敏感信息的隐私性,避免数据出现在共享信息里,从网络系统、硬件子系统、软件子系统的设计都要充分考虑安全保密,采用安全可靠的技术,保证建成的系统稳定运行。
6、重视资源、强调成长原则
在项目建设的过程中,注重信息资源和人力资源的管理,在数据资源方面,注重网络资源共享的效率性,实现网络互连、信息互通、资源共享,应用交互与协同的网络环境,同时注重各级人力资源配置的合理性,做好培训工作,与甲方的工作人员共同成长,充分发挥资源效能。
7、保护投资、充分利旧原则
在本项目建设过程中,充分利用现有资源,防止新铺摊子和重复建设,所有建设内容都依托现有条件和队伍进行建设,充分利用现有的资源、成果、设备,不搞重复建设。
8、先进性和成熟性
遵守先进性、可行性、成熟性,以保证系统的互操作性、兼容性、可维护性、可扩展性,并对前期投资有较好的保护。
9、一致性和复用性
本项目建设应充分考虑业务需求,要最大限度利用已有的资源,以减少重复投资,提高投资收益率。
10、实施有序性
统筹协调,建立相关管理制度,加强管理和指导,确保协调推进,有序实施,保证项目能够顺利、按时完成。
2.3整体建设方案
由于数据中心云计算流量类型和流量突发的复杂性,希望全网实现clos架构,如何避免环路,充分利用带宽链路且实现负载均衡是网络非常关心的问题。
之前的stp会导致链路block,导致链路带宽浪费,其他的TRILL/SPB实现复杂,支持设备较少,且无法实现L2隧道终结和L3转发在同一台设备上。
XXSDN数据中心解决方案,能够充分利用分布式控制的优势,根据全局网络拓扑,基于流进行路径规划,将网络流量分散到不同路径上去,在避免环路的同时实现了链路之间的负载均衡,和链路故障冗余切换,从而提高链路的利用率。
3.2.1整体组网设计
加入方案整体网络设计,如下参考:
按照数据中心业务分区,构建四张Fabric网络,分别为生产云DMZ、服务保障区DMZ、生产云内网、服务保障区内网,每个Fabric网络部署一套SDN控制器集群,一套Openstack云平台,SDN控制器和Openstack平台通过Neutron实现对接,形成四朵云。
同时,从稳定性、高效运维、弹性扩展方面考虑,四个Fabric采用相同的组网架构,根据业务规模控制器网络的规模,实现投入产出的最大化。
3.2.2单Fabric组网设计
1)整网架构采用Spine+Leaf两层结构设计,Leaf分为BorderLeaf(出口),ServerLeaf(TOR服务器接入)、ServiceLeaf(安全资源池接入),将支持MP-BGPEVPN功能的交换机作为数据中心架构中的Spine交换设备;
2)TOR接入区分为计算资源接入和安全资源池接入。
3)控制平面采用MP-BGPEVPN协议,数据平面采用VXLAN。
4)Underlay采用OSPF路由协议,Spine为iBGPRR角色;
5)OverlayVXLANL3/L2网关部署在LEAF节点,LEAF采用40G上行接入SPINE节点。
同时LEAF可以为服务器提供1G/10G/25G服务器接入能力。
6)东西向安全,利用安全资源池为逻辑区域间访问提供安全控制和LB服务。
7)运维管理区部署VCFDirector(VCFD)、SDN控制器(VCFC)、云平台等。
VCFD实现对数据中心基础设施自动化部署及Overlay网络运行维护监控,VCFC控制器实现对Overlay网络的调度管理,通过带外管理方式管理业务区,其中SDN控制器可以与原生标准OpenStack云平台对接,对于其他非Openstack云平台或非原生Openstack云平台(经过二次开发),可以通过控制器RestfulApi方式进行对接,需要评估开发工作量。
3.2.3方案设备选型
方案拟采用如下设备选型:
(按照下面维度列举,说明选型建议和考虑因素.直接附配置清单)
Spine:
Leaf:
Border:
ED:
3.2.4方案主要功能
✓SDN、EVPN、VXLAN:
通过SDN、EVPN和VXLAN技术,支持业务应用系统运行自虚拟网络环境中,使得业务网络不再受限于物理网络设备位置限制,实现业务网络按需自动化部署。
✓服务链:
当通过服务链,用户可以依据自身业务需求,自定义业务的安全访问路径。
这样使得用户可以对业务应用系统灵活的实施安全防护策略。
✓VPC租户:
在云平台为租户提供私有云环境,这样使得租户间从逻辑上完全隔离。
从而保证租户间业务应用系统相互没有任何影响。
例如,租户间业务应用IP地址重叠了,也不会互相影响。
✓第三方安全设备东西向引流,可纳管第三方安全设备,目前实施项目中已经对接过的厂商有F5、山石、迪普等,对于在Openstack社区中提供安全设备插件接口的其他厂家,同样可以纳管。
✓支持多层级端口绑定特性,突破4KVXLAN限制特性,可对接OpenstackVLAN组网和OpenstackVXLAN组网。
✓Underlay自动化支持路由协议包含OSPF、ISIS。
✓Overlay自动化支持配置按需下发。
2.3.1.1Underlay自动化
Underlay自动化功能,由FabricDirector软件和Spine-Leaf网络设备配合完成。
2.3.1.1.1Fabric规划
开始自动化部署之前,需要先根据用户需求完成准备工作,包括以下步骤:
1.物理设备连线,安装Director软件,通过带外管理交换机将Director和物理设备管理口接入三层可达的管理网络。
2.根据用户需求完成Underlay网络规划,包括IP地址、可靠性、路由部署规划等,规划完成后,自动生成Spine-Leaf规划拓扑。
3.通过Director完成Underlay自动化预配置
1)通过Director完成DHCP服务器、TFTP服务器的部署和参数设置
2)基于Spine/Leaf角色,通过Director完成设备软件版本和配置模板文件的准备
3)指定Fabric的RR、Border角色,支持指定多个Spine/Leaf作为Border
3.2.1.1.2自动配置
Underlay网络自动配置的目的是为Overlay自动化提供一个IP路由可达的三层网络,包括以下步骤:
1.设备上电,基于Spine/Leaf角色,自动获取管理IP、版本文件、配置模板
2.根据拓扑动态生成配置
3.自动配置IRF
4.自动配置Underlay路由协议,可选OSPF、ISIS
3.2.1.1.3可视化部署
Director根据IP地址段扫描已经上线的设备,生成Underlay自动化过程中的动态拓扑,并在该拓扑上实时呈现自动化状态和进度:
1.自动化开始
设备根据角色加载版本,并获取配置文件模板,开始自动化配置过程,进入设备自动化开始状态。
2.查看实时IRF状态
设备加入IRF时,支持上报设备IRF开始;设备加入IFR完成后,支持上报设备IRF结束;设备出现故障等导致IRF分裂,支持上报设备离开IRF。
3.查看实时拓扑状态
支持上报设备互连接口UP、DOWN状态;设备互连接口获取IP,路由收敛后,支持上报设备间Spine和Leaf链路三层连通性状态;设备互连接口获取IP,路由收敛后,支持上报链路连通状态的整网检测结果。
4.自动化结束
支持Fabric自动化过程结束状态上报。
3.2.1.1.3资源纳管
Underlay网络自动化完成后,所有参与自动化的物理网络设备自动被Director纳管。
3.2.3.2Overlay自动化–对接OpenStack
Underlay自动化完成后,用户可以从云平台界面按需配置虚拟网络模型,或者直接在SDN控制器的界面完成同样的工作,两种情况下,均由SDN控制器将虚拟网络模型转换为Overlay配置下发到设备。
当用户通过云平台进行配置时,在创建接入主机的虚拟L2网络时可以选择VLAN网络、VxLAN网络等类型。
3.2.1.2.1支持OpenStackVLAN网络
当租户使用VLAN网络时,需要提前进行的准备工作如下:
⏹在VCFC上为该VLAN网络配置VxLAN-VLAN映射关系
如果配置下发方式为预下发,配置完成后会立刻下发到指定的设备所有端口或指定端口;如果配置下发方式为按需下发,在VM上线后再下发到VM上线端口。
准备完成后,租户申请VM的整个处理流程如下:
1.租户在云平台界面创建VM
1)云平台租户根据业务需求,创建VM,并接入指定VLANNetwork,分配到对应VLANID及IP地址
2)Neutron组件为该VM分配接入VLAN网络的vPort
3)Nova组件将VM创建请求下发到选定计算节点
2.计算节点创建VM成功
1)计算节点为VM分配云平台指定的计算资源配额(CPU、内存、磁盘空间等),VM创建成功
2)计算节点上运行的NovaAgent通知Nova组件VM创建成功,Nova相关处理完成
3)计算节点上运行的NeutronAgent向NeutronServer请求该VM分配到的VLANID,并配置在vSwitch上,保证VM启动后发出的报文经由vSwitch上送到交换机时携带该VLANID
3.Neutron将相关信息下发到VCFC
VM创建成功,NeutronServer将分配给该VM的vPort信息、IP地址下发到SDN控制器VCFC。
VM创建成功后,用户启动VM,开始正常使用,整个流程如下:
4.VM启动并上线
用户启动VM,VM上线,发送DHCP请求(广播报文)。
5.VCFC处理DHCP代答及VM上线
1)如果部署了独立DHCP服务器,不需要VCFC进行DHCP代答,则跳过此步骤
2)如果需要VCFC进行DHCP代答,Leaf通过Openflow通道将DHCP请求上送到VCFC,VCFC使用VM创建成功时Neutron下发的IP地址构造DHCP应答报文,经由Leaf发送给VM
3)VCFC将VM对应的vPort状态标记为上线,如果配置下发方式是按需下发,此时会将提前在VCFC界面配置的VxLAN-VLAN映射关系下发到Leaf接入该VM的端口上
6.VM发送首个报文
VM在发送首个业务报文前,先发送针对其目的IP的ARP请求,获取其目的IP对应的MAC地址。
7.Leaf进行ARP处理
1)Leaf复制ARP请求上送控制器
2)Leaf根据当前配置,进行ARP代理/代答应答处理
8.VCFC进行ARP处理
如果部署了独立DHCP服务器,VCFC未进行DHCP代答,此时该VM对应的vPort在VCFC处并未上线;VCFC收到Leaf上送的ARP请求后,将VM对应的vPort状态标记为上线,如果配置下发方式是按需下发,此时会将提前在VCFC界面配置的VxLAN-VLAN映射关系下发到Leaf接入该VM的端口上。
经过上述流程处理,租户VM创建及上线均已完成,可以基于虚拟VLAN网络进行正常通信。
3.2.1.2.2层次化端口绑定
云平台租户使用OpenStackVLAN网络类型时,受限于4KVLAN限制,最多只能创建不超过4K的L2虚拟网络。
如果使用OpenStackVxLAN网络类型,在云平台上没有4KVLAN限制;当云平台将虚拟网络模型下发到VCFFabric时,就形成了如下图示的分层网络:
⏹Spine-Leaf、Leaf-Leaf是VxLAN网络,其SegmentID(L2广播域标识符)为VxLANID,通过VxLANID区分不同的L2虚拟网络
⏹Leaf到计算节点间是VLAN网络,其SegmentID(L2广播域标识符)为VLANID,通过VLANID区分不同的L2虚拟网络
⏹不同层级的网络,由Neutron组件中对应的MechanismDriver对接管理
对于分层网络,为了保证VM可以接入并正常使用端到端的L2虚拟网络,必须解决以下2个问题:
⏹问题1:
对同一VM(vPort),不同层级网络的SegmentID如何形成映射关系
⏹问题2:
如果SegmentID间是静态1:
1映射关系,且下层网络为VLAN网络,则端到端的二层广播域数量将受到VLAN4K限制
为了解决上述问题,OpenStack从Liberty版本开始,正式引入层次化端口绑定特性。
⏹解决问题1:
通过不同MechanismDriver配合,为同一主机在各层网络分配对应的SegmentID
⏹解决问题2:
下层网络(VLAN网络)使用动态分配的SegmentID
1)在下层网络对应的MechanismDriver中,为每个计算节点建立独立的SegmentID范围
2)当接入某vPort的VM需要分配SegmentID时,上层网络(VxLAN网络)分配静态ID,下层网络(VLAN网络)从主机所在计算节点的SegmentID范围中分配动态ID
3)当VM(vPort)迁移到新的计算节点,上层网络的静态ID保持不变,下层网络从新计算节点的SegmentID范围中再次分配新的动态ID
4)按上述实现,单个计算节点上的VM所接入的虚拟网络不能超过4K,整网无此限制
3.2.1.2.3支持OpenStackVxLAN网络
租户使用VxLAN网络时,需要提前进行的准备工作如下:
⏹在Neutron组件配置文件中,为每个计算节点配置独立的VLAN范围,不同节点的VLAN范围可以重叠
⏹承载VM的物理服务器需要启用LLDP协议,向Leaf设备定期发送LLDP报文(Leaf设备的LLDP协议已经在Underlay自动化时开启)
准备完成后,租户申请VM的整个处理流程如下:
1.租户在云平台界面创建VM
1)云平台租户根据业务需求,创建VM,并接入指定VxLANNetwork,分配到对应VxLANID及IP地址
2)Nova组件将VM创建请求下发到选定计算节点
3)Neutron组件为该VM分配接入VxLAN网络的vPort,同时从选定计算节点的VLAN范围中,为该VxLANID分配对应VLANID
2.计算节点创建VM成功
1)计算节点为VM分配云平台指定的计算资源配额(CPU、内存、磁盘空间等),VM创建成功
2)计算节点上运行的NovaAgent通知Nova组件VM创建成功,Nova相关处理完成
3)计算节点上运行的NeutronAgent向NeutronServer请求该VM分配到的VLANID,并配置在vSwitch上,保证VM启动后发出的报文经由vSwitch上送到交换机时携带该VLANID
3.Neutron将相关信息下发到VCFC
VM创建成功,Neutron组件的VCFCMechanismDriver将分配给该VM的vPort信息、IP地址下发到SDN控制器VCFC。
4.VCFC处理LLDP报文
1)Leaf收到计算节点定期发送的LLDP报文,将其通过Openflow通道上送给VCFC
2)VCFC收到Leaf上送的计算节点LLDP报文后,从中解析得到该计算节点当前接入的端口信息,填写到该计算节点上当前已创建VM的vPort信息中,形成完整的VxLAN-VLAN映射关系(VxLANID、VLANID、计算节点接入端口);如果配置下发方式为预下发,立刻下发到该端口;如果配置下发方式为按需下发,在VM上线后再下发到该端口
VM创建成功后,用户启动VM,开始正常使用,整个流程如下:
5.VM启动并上线
用户启动VM,VM上线,发送DHCP请求(广播报文)。
6.VCFC处理DHCP代答及VM上线
1)如果部署了独立DHCP服务器,不需要VCFC进行DHCP代答,则跳过此步骤
2)如果需要VCFC进行DHCP代答,Leaf通过Openflow通道将DHCP请求上送到VCFC,VCFC使用VM创建成功时Neutron下发的IP地址构造DHCP应答报文,经由Leaf发送给VM
3)VCFC将VM对应的vPort状态标记为上线,如果配置下发方式是按需下发,此时会将该vPort的VxLAN-VLAN映射关系下发到Leaf接入该VM的端口上
7.VM发送首个报文
VM在发送首个业务报文前,先发送针对其目的IP的ARP请求,获取其目的IP对应的MAC地址。
8.Leaf进行ARP处理
1)Leaf复制ARP请求上送控制器
2)Leaf根据当前配置,进行ARP代理/代答应答处理
9.VCFC进行ARP处理
如果部署了独立DHCP服务器,VCFC未进行DHCP代答,此时该VM对应的vPort在VCFC处并未上线;VCFC收到Leaf上送的ARP请求后,将VM对应的vPort状态标记为上线,如果配置下发方式是按需下发,此时会将提前在VCFC界面配置的VxLAN-VLAN映射关系下发到Leaf接入该VM的端口上。
经过上述流程处理,租户VM创建及上线均已完成,可以基于虚拟VxLAN网络进行正常通信。
3.2.3.3Overlay自动化–独立Fabric场景
3.2.3.3.1软件定义网络模型
XXSDN控制器VCFC支持OpenStackNeutron标准网络模型,用户可以选择通过云平台或VCFC界面配置
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- XXX SDN数据中心网络解决方案模板 SDN 数据中心 网络 解决方案 模板