XXX SDN数据中心网络解决方案(模板)

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.3XX SDN解决方案 (6)
3XXX项目SDN网络解决方案 (6)
3.1方案设计原则 (6)
3.2整体建设方案 (8)
3.2.1整体组网设计 (9)
3.2.2单Fabric组网设计 (10)
3.2.3方案主要功能 (11)
3.3XX SDN服务支持 (20)
3.3.1SDN部署服务 (20)
3.3.2SDN软件技术支持服务 (20)
3.3.3SDN开发者技术支持服务 (20)
3.3.4SDN解决方案规划咨询服务 (20)
3.3.5SDN APP定制开发服务 (21)
3.4XX SDN下一代数据中心优势 (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)
1 XXX项目建设背景
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.1XX SDN解决方案
做为国内领先的网络设备供应厂商，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转发在同一台设备上。

XX SDN数
据中心解决方案，能够充分利用分布式控制的优势，根据全局网络拓扑，基于流进行路径规划，将网络流量分散到不同路径上去，在避免环路的同时实现了链路之间的负载均衡，和链路故障冗余切换，从而提高链路的利用率。

3.2.1整体组网设计
加入方案整体网络设计，如下参考：
按照数据中心业务分区，构建四张Fabric网络，分别为生产云DMZ、服务保障区DMZ、生产云内网、服务保障区内网，每个Fabric网络部署一套SDN控制器集群，一套Openstack云平台，SDN控制器和Openstack 平台通过Neutron 实现对接，形成四朵云。

同时，从稳定性、高效运维、弹性扩展方面考虑，四个Fabric采用相同的组网架构，根据业务规模控制器网络的规模，实现投入产出的最大化。

3.2.2单Fabric组网设计
1）整网架构采用Spine+Leaf两层结构设计,Leaf分为Border Leaf（出口），Server Leaf（TOR服务器接入）、Service Leaf（安全资源池接入），将
支持MP-BGP EVPN功能的交换机作为数据中心架构中的Spine交换设
备；
2）TOR接入区分为计算资源接入和安全资源池接入。

3）控制平面采用MP-BGP EVPN协议，数据平面采用VXLAN。

4）Underlay采用OSPF路由协议，Spine为iBGP RR角色；
5）Overlay VXLAN L3/L2网关部署在LEAF节点，LEAF采用40G上行接入SPINE节点。

同时LEAF可以为服务器提供1G/10G/25G服务器接入能
力。

6）东西向安全，利用安全资源池为逻辑区域间访问提供安全控制和LB 服务。

7）运维管理区部署VCF Director（VCFD）、SDN控制器（VCFC）、云平台等。

VCFD实现对数据中心基础设施自动化部署及Overlay网络运行
维护监控，VCFC控制器实现对Overlay网络的调度管理，通过带外管
理方式管理业务区，其中SDN控制器可以与原生标准OpenStack云平
台对接，对于其他非Openstack云平台或非原生Openstack云平台（经
过二次开发），可以通过控制器Restful Api方式进行对接，需要评估
开发工作量。

3.2.3 方案设备选型
方案拟采用如下设备选型：（按照下面维度列举，说明选型建议和考虑因素.直接附配置清单）
Spine:
Leaf：
Border：
ED：
3.2.4方案主要功能
✓SDN、EVPN、VXLAN：通过SDN、EVPN和VXLAN技术，支持业务应用系统运行自虚拟网络环境中，使得业务网络不再受限于物理网络设备位置
限制，实现业务网络按需自动化部署。

✓服务链：当通过服务链，用户可以依据自身业务需求，自定义业务的安全访问路径。

这样使得用户可以对业务应用系统灵活的实施安全防护策
略。

✓VPC租户：在云平台为租户提供私有云环境，这样使得租户间从逻辑上完全隔离。

从而保证租户间业务应用系统相互没有任何影响。

例如，租
户间业务应用IP地址重叠了，也不会互相影响。

✓第三方安全设备东西向引流，可纳管第三方安全设备，目前实施项目中已经对接过的厂商有F5、山石、迪普等，对于在Openstack社区中提供
安全设备插件接口的其他厂家，同样可以纳管。

✓支持多层级端口绑定特性，突破4K VXLAN限制特性，可对接Openstack VLAN组网和Openstack VXLAN组网。

✓Underlay自动化支持路由协议包含OSPF、ISIS。

✓Overlay自动化支持配置按需下发。

2.3.1.1Underlay自动化
Underlay自动化功能，由Fabric Director软件和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.2 Overlay自动化–对接OpenStack
Underlay自动化完成后，用户可以从云平台界面按需配置虚拟网络模型，或者直接在SDN控制器的界面完成同样的工作，两种情况下，均由SDN控制器将虚拟网络模型转换为Overlay配置下发到设备。

当用户通过云平台进行配置时，在创建接入主机的虚拟L2网络时可以选择
VLAN网络、VxLAN网络等类型。

3.2.1.2.1支持OpenStack VLAN网络
当租户使用VLAN网络时，需要提前进行的准备工作如下：
在VCFC上为该VLAN网络配置VxLAN-VLAN映射关系
如果配置下发方式为预下发，配置完成后会立刻下发到指定的设备所有端口或指定端口；如果配置下发方式为按需下发，在VM上线后再下发到VM上线端口。

准备完成后，租户申请VM的整个处理流程如下：
1.租户在云平台界面创建VM
1)云平台租户根据业务需求，创建VM，并接入指定VLAN Network，分配
到对应VLAN ID及IP地址
2)Neutron组件为该VM分配接入VLAN网络的vPort
3)Nova组件将VM创建请求下发到选定计算节点
2.计算节点创建VM成功
1)计算节点为VM分配云平台指定的计算资源配额（CPU、内存、磁盘空
间等），VM创建成功
2)计算节点上运行的Nova Agent通知Nova组件VM创建成功，Nova相关
处理完成
3)计算节点上运行的Neutron Agent向Neutron Server请求该VM分配到的
VLAN ID，并配置在vSwitch上，保证VM启动后发出的报文经由vSwitch
上送到交换机时携带该VLAN ID
3.Neutron将相关信息下发到VCFC
VM创建成功，Neutron Server将分配给该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层次化端口绑定
云平台租户使用OpenStack VLAN网络类型时，受限于4K VLAN限制，最多只能创建不超过4K的L2虚拟网络。

如果使用OpenStack VxLAN网络类型，在云平台上没有4K VLAN限制；当云平台将虚拟网络模型下发到VCF Fabric时，就形成了如下图示的分层网络：
⏹Spine-Leaf、Leaf-Leaf是VxLAN网络，其Segment ID（L2广播域标识符）
为VxLAN ID，通过VxLAN ID区分不同的L2虚拟网络
⏹Leaf到计算节点间是VLAN网络，其Segment ID（L2广播域标识符）为
VLAN ID，通过VLAN ID区分不同的L2虚拟网络
⏹不同层级的网络，由Neutron组件中对应的Mechanism Driver对接管理
对于分层网络，为了保证VM可以接入并正常使用端到端的L2虚拟网络，必须解决以下2个问题：
⏹问题1：对同一VM（vPort），不同层级网络的Segment ID如何形成映射
关系
⏹问题2：如果Segment ID间是静态1:1映射关系，且下层网络为VLAN网
络，则端到端的二层广播域数量将受到VLAN 4K限制
为了解决上述问题，OpenStack从Liberty版本开始，正式引入层次化端口绑定特性。

⏹解决问题1：通过不同Mechanism Driver配合，为同一主机在各层网络
分配对应的Segment ID
⏹解决问题2：下层网络（VLAN网络）使用动态分配的Segment ID
1)在下层网络对应的Mechanism Driver中，为每个计算节点建立独立的
Segment ID范围
2)当接入某vPort的VM需要分配Segment ID时，上层网络（VxLAN网络）
分配静态ID，下层网络（VLAN网络）从主机所在计算节点的Segment ID
范围中分配动态ID
3)当VM（vPort）迁移到新的计算节点，上层网络的静态ID保持不变，下
层网络从新计算节点的Segment ID范围中再次分配新的动态ID
4)按上述实现，单个计算节点上的VM所接入的虚拟网络不能超过4K，整
网无此限制
3.2.1.2.3支持OpenStack VxLAN网络
租户使用VxLAN网络时，需要提前进行的准备工作如下：
⏹在Neutron组件配置文件中，为每个计算节点配置独立的VLAN范围，
不同节点的VLAN范围可以重叠
⏹承载VM的物理服务器需要启用LLDP协议，向Leaf设备定期发送LLDP
报文（Leaf设备的LLDP协议已经在Underlay自动化时开启）准备完成后，租户申请VM的整个处理流程如下：
1.租户在云平台界面创建VM
1)云平台租户根据业务需求，创建VM，并接入指定VxLAN Network，分配
到对应VxLAN ID及IP地址
2)Nova组件将VM创建请求下发到选定计算节点
3)Neutron组件为该VM分配接入VxLAN网络的vPort，同时从选定计算节
点的VLAN范围中，为该VxLAN ID分配对应VLAN ID
2.计算节点创建VM成功
1)计算节点为VM分配云平台指定的计算资源配额（CPU、内存、磁盘空
间等），VM创建成功
2)计算节点上运行的Nova Agent通知Nova组件VM创建成功，Nova相关
处理完成
3)计算节点上运行的Neutron Agent向Neutron Server请求该VM分配到的
VLAN ID，并配置在vSwitch上，保证VM启动后发出的报文经由vSwitch
上送到交换机时携带该VLAN ID
3.Neutron将相关信息下发到VCFC
VM创建成功，Neutron组件的VCFC Mechanism Driver将分配给该VM的vPort 信息、IP地址下发到SDN控制器VCFC。

4.VCFC处理LLDP报文
1)Leaf收到计算节点定期发送的LLDP报文，将其通过Openflow通道上送
给VCFC
2)VCFC收到Leaf上送的计算节点LLDP报文后，从中解析得到该计算节点
当前接入的端口信息，填写到该计算节点上当前已创建VM的vPort信息
中，形成完整的VxLAN-VLAN映射关系（VxLAN ID、VLAN ID、计算节点
接入端口）；如果配置下发方式为预下发，立刻下发到该端口；如果配置
下发方式为按需下发，在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支持OpenStack Neutron标准网络模型，用户可以选择通过云平台或VCFC界面配置虚拟网络模型，实现相同的功能。

3.2.3.3.2Overlay配置下发到设备
VCFC将虚拟网络模型转换为具体配置后，向纳管网元下发，配置类型有：
⏹VPN实例配置
⏹L3VNI配置
⏹VSI接口配置
⏹VSI配置
⏹AC配置（含VxLAN-VLAN映射关系）
VCFC下发配置的方式，按下发配置的时机，分为以下两种：
⏹配置预先下发
在VCFC上配置完成后，立刻下发到网元，此时通常主机还未上线，并不需
要使用相关配置，属于配置预先下发。

⏹配置按需下发（部分）
AC配置在主机上线时下发，其他配置预先下发。

3.2.3.3.3Fabric接入
如果将VCF Fabric整体看成一台虚拟网络设备，数据中心的所有软硬件资源，包括计算及存储资源、数据中心出口的外部网络，都必须接入到Fabric的某个端口，才能正常使用。

该方案可支持接入的资源包括：
⏹支持VM接入：VM通过ARP/DHCP报文上线、VM迁移时支持配置及策
略随迁
⏹支持外部网络接入：通过配置Border vRouter（无安全纳管）或服务网关
组（安全纳管）实现
⏹支持第三方防火墙接入：通过控制器下发引流策略
3.3XX SDN下一代数据中心优势
XX AD-DC方案采用云网安融合的建设思路，Overlay技术为支撑，为客户带来以下价值：
（1）兼容第三方设备的全网络虚拟化能力，构建“一网一设备”的交换矩阵。

基于IP网络构建Fabric。

无特殊拓扑限制，IP可达即可；承载网络和业务网络分离；对现有网络改动较小，保护用户现有投资。

（2）丰富的云特性，业界最佳的将“计算、存储、网络和安全资源”统一灵活部署的多租户方案。

（3）基于SDN架构的高度自动化运维能力。

（4）支持VMware、Microsoft Hyper-V、XX CAS、KVM和XEN等主流虚拟化平台。

（5）原生的灾备建设能力。

（6）网络配置一次成型，业务扩容与变更无需改动网络，大幅度减少网络运维工作量。

网络简化、安全。

虚拟网络支持L2、L3等，无需运行LAN协议，骨干网络无需大量VLAN Trunk。

（7）简化网络IP地址的规划，用于设备互连的IP网段和用于业务通信的IP网段互相不重叠。

（8）加快应用部署速度，应用可以在任意位置部署，配置好自己的IP地址即可实现通信，无需变更网络，应用部署速度从以周计缩短为以天计。

（9）转发优化和表项容量增大。

消除了MAC表项学习泛滥，ARP等泛洪流量可达范围可控，且东西向流量无需经过网关。

3.4.1 整网设计架构开放、标准、兼容
XX AD-DC方案已开放为基础，采用SDN理念，设计场景化的方案。

1、L4-L7层开放兼容，可以纳管第三方安全品牌的设备、F5的设备，对于第三方安全设备纳管采用openstack标准的FWaas/LBaas等安全云插件形式，提升异构厂商组网的开放能力和标准化程度;
2、北向接口开放，不同于传统SDN控制器只提供Rest API，XX VCF Controller可以同时提供Rest API和JAVA API，给用户更多灵活的选择。

理论上可以对接任何品牌的云平台、客户自身的应用APP，但实际部署中主要考虑基于Openstack平台的商用产品，有标准的插件进行对接；
3、南向接口开放，有利于基础设施层设备纳管，不会被绑定，即使需要管理第三方品牌的交换机，也可以考虑定制化；
4、Overlay网络的控制层面采用标准RFC定义的EVPN协议，不掺杂私有协议；
5、可视化采集使用SNMP、NETCONF等标准协议，不掺杂厂商私有协议，可以有效的监控数据中心除网络设备、SDN控制器之外的，服务器、存储等运行状态。

3.4.2可靠性设计
新型数据中心承载者用户80%以上的核心业务，对于企业的重要程度不言而喻。

其可靠性需要全方位保证，XX AD-DC方案提供从设备级到方案级的各层次。