CloudFabric云数据中心网解决方案-运营维护设计指南（专业完整版）

1、目录CloudFabric云数据中心网解决方案 设计指南（运营维护） TOC o 1-5 h z 1数据中心网络运维概述1 HYPERLINK l bookmark0 o Current Document h 1.1数据中心网络智能运维背景与挑战1 HYPERLINK l bookmark6 o Current Document h 1.2数据中心SDN网络运维需求与目标3 HYPERLINK l bookmark8 o Current Document h SDN数据中心Underlay网络可靠性4 HYPERLINK l bookmark10 o Current Document h 1.

2、2.2服务器批量上线效率5 HYPERLINK l bookmark12 o Current Document h 1.2.3业务变更网络布放效果预测5 HYPERLINK l bookmark14 o Current Document h 1.2.4既有业务网络可达性校验5 HYPERLINK l bookmark16 o Current Document h 1.2.5故障快速发现定位及恢复5 HYPERLINK l bookmark18 o Current Document h 1.3数据中心网络运维设计原则6DAY-0规格化设计-SDN数据中心Underlay网络设计7 HYPERLI

3、NK l bookmark24 o Current Document h 2.1整体拓扑设计7 HYPERLINK l bookmark30 o Current Document h 2.2路由协议设计10 HYPERLINK l bookmark38 o Current Document h 2.3扩展性设计14 HYPERLINK l bookmark44 o Current Document h 2.4可靠性设计15 HYPERLINK l bookmark46 o Current Document h 2.4.1可靠性设计一般原则15Border Leaf 节点可靠性16Spine 节

4、点可靠性16Leaf节点可靠性18NGFW 节点可靠性24vSwitch 节点可靠性（受限商用）28 HYPERLINK l bookmark74 o Current Document h DAY-0网络初始化-ZTP开局31 HYPERLINK l bookmark76 o Current Document h DAY-0意图验证-Underlay网络校验32 HYPERLINK l bookmark88 o Current Document h DAY-1业务方案&变更-SDN网络业务发放前校验方案36 HYPERLINK l bookmark92 o Current Document h

5、 5.1网络业务编排（设计态）37 HYPERLINK l bookmark94 o Current Document h 5.2网络资源仿真校验38 HYPERLINK l bookmark96 o Current Document h 5.3网络连通性校验385.4设备配置变更内容预览39DAY-2.例行维护40 HYPERLINK l bookmark98 o Current Document h 6.1单路径探测40 HYPERLINK l bookmark136 o Current Document h 6.2多路径探测51 HYPERLINK l bookmark170 o Cur

6、rent Document h DAY-2 CloudFabric 智能运维59 HYPERLINK l bookmark172 o Current Document h CloudFabric 智能运维方案总体架构59 HYPERLINK l bookmark174 o Current Document h iMaster NCE-Fabric 控制器架构60 HYPERLINK l bookmark220 o Current Document h iMaster NCE-Fabriclnsight 架构63 HYPERLINK l bookmark178 o Current Documen

7、t h SDN数据中心网络故障智能运维方案及功能介绍65 HYPERLINK l bookmark180 o Current Document h 7.2.1网络故障智能运维能力全景65 HYPERLINK l bookmark182 o Current Document h 7.2.2网关故障智能运维处理流程介绍74 HYPERLINK l bookmark192 o Current Document h 7.2.3网络故障智能运维之网络监控能力80 HYPERLINK l bookmark194 o Current Document h 7.2.4网络故障智能运维之故障发现82 HYPER

8、LINK l bookmark196 o Current Document h 7.2.5网络故障智能运维之问题定位定界83 HYPERLINK l bookmark202 o Current Document h 7.2.6网络故障智能运维之故障恢复/隔离86 HYPERLINK l bookmark208 o Current Document h 7.2.7数据中心典型故障智能运维case示例87 HYPERLINK l bookmark210 o Current Document h Casel：交换机FIB表项跳变导致会话异常87 HYPERLINK l bookmark212 o C

9、urrent Document h Case2：光模块故障导致链路频繁闪断88 HYPERLINK l bookmark214 o Current Document h Case3： ARP 攻击89 HYPERLINK l bookmark216 o Current Document h 使用 Fabriclnsight进行网络例行巡检89 HYPERLINK l bookmark218 o Current Document h 7.4数据中心iMaster NCE-Fabriclnsight智能运维网络部署90iMaster NCE-Fabriclnsight 和控制器的资源要求90 HY

10、PERLINK l bookmark222 o Current Document h 7.6方案约束（本节对外发布时不展示）91 HYPERLINK l bookmark224 o Current Document h 7.6.1设备的能力约束92DAY-2配置回滚93&全网回滚93 HYPERLINK l bookmark232 o Current Document h 8.2租户回滚95 HYPERLINK l bookmark238 o Current Document h DAY-N网络扩容-SDN数据中心服务器自动化批量上线98 HYPERLINK l bookmark252 o C

11、urrent Document h DAY-N网络扩容-交换机扩容102 HYPERLINK l bookmark254 o Current Document h DAY-N设备更换-替换交换机105 HYPERLINK l bookmark256 o Current Document h 11.1替换设备（非ZTP设备）105 HYPERLINK l bookmark288 o Current Document h 11.2替换设备（ZTP设备）116 HYPERLINK l bookmark310 o Current Document h DAY-N设备更换-替换端口124 HYPERLI

12、NK l bookmark318 o Current Document h A参考图片1271数据中心网络运维概述1数据中心网络运维概述数据中心作为信息与信息系统的物理载体，主要用于与IT相关的主机、网络、存储等 设备和资源的存放、运营及管理，只有运维好一个数据中心，才能发挥数据中心的作 用，使之能更好的为业务部门提供强大的支撑能力。本文档主要针对数据中心的网络运维进行了阐述，其出发点在于使用户能对SDN时代 的数据中心网络实现精确管控维护，使SDN网络的管理水平和服务质量得到持续提 升，此外对传统数据中心网络的建设有具有参考价值。1.1数据中心网络智能运维背景与挑战1.2数据中心SDN网络运

13、维需求与目标1.3数据中心网络运维设计原则1.1数据中心网络智能运维背景与挑战本节主要介绍数据中心业务连续性及容灾标准。近来年，无论是金融、电信、互联网等行业的大型企业，还是全国各个科技园区、各 级政府都在如火如荼地进行数据中心建立，数据中心的稳定运行关系着国家信息安全 和社会稳定，为了防范灾难和风险，保障业务连续性，国内外监管部门颁布了一系列 业务连续性及容灾的标准。国内外数据中心规范对业务连续性要求ANSI/TIA-942-B 2017数据中心电信基础设施标准主要是根据数据中心基础设施 的“可用性(Availability ) ”、稳定性(Stability )” 和安全性(Securit

14、y )”分 为四个等级：Tier I, Tier II, Tier III, Tier IV。该标准所说的数据中心可以是政府或企 业自有产权的自有数据中心，也可以是运营商用于租赁服务的公用数据中心。该标准 描述了各类数据中心或计算机房中，对通信基础设施的起码的、最低的要求。ANSI/TIA -942-B 标 准定义可信要求可用性指标/每年允许宕机时 间TierlBasic基本系统没有冗余的基本的数据中心可用性99.671%、年平均故 障时间28.8小时Tier IIRedundant Component 冗余系统组件级冗余基础设施可用性99.741%、年平均故 障时间22.7小时Tier II

15、IConcurrentlyMaintainable并行维护可并行维护级机房基础设施，电 源等主用1+备用1,多上行可用性99.982%、年平均故 障时间1.6小时Tier IVFault Tolerant 容错 系统容错级机房基础设施，所有设施 支持容错（上行链路、存储、制 冷、电源等1+1主用）可用性99.995%、年平均故 障时间0.4小时ANSI/TIA-942-B突出对数据中心可用性/故障中断时间提出了要求：其中，Tier III可 用性99.982%、年平均故障时间1.6小时;Tier IV可用性99.995%、年平均故障时间 0.4小时。国内标准数据中心设计规范（GB50174）在

16、满足中国数据中心行业发展的前提 下，吸取国外数据中心设计的优点，结合中国数据中心行业的具体情况，增加补充具 有数据中心行业特点的相关条文规定。主要围绕数据中心的可靠性、可用性、安全、 节能环保等方面提出进一步明确要求。数据中心设计规范根据数据中心的使用性 质、数据丢失或网络中断在经济或社会上造成的损失或影响程度确定所属级别，将数 据中心划分为分为A （容错型）、B （冗余型）、C （基本型）三个级别。GB50174级别可信要求可用 性行业遵从与 TIA-942-B 级 别对应关系A级容错 系统应在一次意外事故后或单系统设备维 护或检修时仍能保证电子信息系统正 常运行当两个或两个以上地处不同区域

17、、同 城或者异地同时数据中心建设，要求 互为备份，主要适用于云计算数据中 心、互联网数据中心等最高 等级金融行业、军 事部门、交 通、电信、国 家信息中心Tier IVTier IIIB级冗余 系统基础设施在冗余能力范围内，不应因设 备故障而导致电子信息系统运行中断居中科研院所、高 校、政府办公 楼Tier IIC级基本 系统在基础设施正常运行情况下，应保证电 子信息系统运行最低-Tierl行业数据中心规范对业务连续性要求 金融行业金融数据中心一般都有本地的数据冗余保护或容灾建设，最主流的灾备技术是两 地三中心建设，确保业务可靠可用性高，遵从数据中心设计规范A级标准。中国银监会发布商业银行业务

18、连续性监管指引【2011】（104号），标志着国家 和行业监管部门对业务连续性的重视程度已经提升到了一个新的高度。表1-1商业银行业务连续性监管指引对运营中断事件等级定义事故等级定级定级标准监管处置I级事故特别重大运营中断 事件单机构单省中断6小时单机构多省中断3小时多机构多省中断3小时上报国务院II级事故重大运营中断事件单机构单省中断3小时单机构多省中断半小时多机构多省中断半小时上报银监会III级事 故较大运营中断事件单机构单省中断半小时上报银监会电信行业运营商遵从数据中心设计规范A级标准，业务可用性99.995% （年平均故障 时间0.4小时），处于国际标准Tier4范围。互联网行业YD/

19、T 2441-2013互联网数据中心技术及分级分类标准规定了互联网数据中心 IDC在可靠性、绿色节能和安全性等三个方面的分级分类的技术要求，明确定义 T IDC可靠性方面的等级为R1R3,其中R1为最低等级，R3为最高等级：R3 业务可用性299.95%, R2业务可用性299.9%, R1业务可用性299.5%。OTT可用性要求：OTT业务可用性基本要求99.95%（年平均故障时间4.38小 时），可靠性为R3级别，介于国际标准Tier II和Tierlll之间。BAT可用性要求：百度业务可用性要求99.99% （年平均故障时间0.88小时）， 阿里99.99% （年平均故障时间0.88小时

20、），可靠性为R3级别，介于国际标准 Tier3和Tier4之间；腾讯99.9% （年平均故障时间8.76小时），可靠性为R2级 别，介于国际标准Tier2和Tier3之间。1.2数据中心SDN网络运维需求与目标在数据中心云化背景下，为了提示数据中心业务上线效率，数据中心网络业务发放也 趋于采用SDN解决方案，随之而来的对网络运维效率也要求向智能化、自动化方向转 变，以适应数据中心业务高效、复杂多变的业务需求。在此背景及目标的驱动下，华为CloudFabric为数据中心SDN网络提供了智能化的运 维解决方案。华为CloudFabric运维解决方案的愿景：建设自动化、可视化、智能化的数据中心，并

21、最终实现无人值守。图1-1 CloudFabric运维解决方案的愿景AS-IS：传统运维TO-BE:赵值守网络健康监控系统(U ndertay&Overtay)网络KPI信息主动上报 业务质*分析Q Q统一南向采集接口修复隔离策略基于AI的故障走位引擎基于AI的故障修复引擎根据国内外数据中心设计标准业务可用性要求，结合客户对业务SLA等级越来越高的 要求，华为CloudFabric运维解决方案制定了 SDN场景下的运维目标：1分钟故障发 现，3分钟故障定位，5分钟故障恢复。版本如下：V100R019C10：支持75+故障场景，实现1分钟自动发现、3分钟故障定位、5分 钟故障修复。V100R02

22、0C00：管控析融合统一 3个入口：业务发放入口、统一监控入口、故障 处理入口。业务发放入口：包括Underlay/Overlay业务自动化部署、意图验证引擎实现配 置变更无人值守。统一监控入口：包括物理网络、逻辑网络、应用网络资源分布情况、健康度 状态。故障处理入口：以故障快速恢复为主线，对故障处理生命周期全过程实现连 贯性处理。1.2.1 SDN数据中心Underlay网络可靠性随着数据中心业务云化的开展，用户对数据中心网络的可靠性等有了更高的要求，业 务云化也带来了资源池化的需求，相应的要求网络能够满足在更大范围上的资源池化 部署，同时，在互联网+的大形势下用户要求能够实现业务的快速部署

23、，从传统的周、 月部署周期，提升到天、小时级的部署周期，甚至让业务实现分钟级上线，但这些高 效提升的前提是要求数据中心Underlay网络能够适应SDN业务的发放特点，提供稳定 可靠的网络保障性，因此在进行SDN网络设计时，针对Underlay网络的可靠性需要从 网络的接入侧、网络侧、转发设备、VAS设备、网络出口等多个层面来综合考虑、全 面设计，打造端到端的数据中心可靠网络。1.2.2服务器批量上线效率在数据中心的日常维护中，服务器扩容是一个经常性且关键的工作，通常情况下管理 员需要事先规划好服务器网卡与交换机的连接关系，包括管理网、存储网、业务网等 多个网络平面。传统的运维模式下通过人工按

24、规划设计对交换机进行配置，完成服务 器的接入上线。但在云化数据中心场景下，对业务的上线效率要求越来越高，采用人 工配置完成大批量服务器上线的速度越来越跟不上业务节奏的要求。尤其是在SDN组 网场景下，也需要考虑采用自动化、智能化的方案实现服务器的批量快速上线。1.2.3业务变更网络布放效果预测在SDN组网场景下，业务的逻辑网络是由管理员在0层编排完成的，但下发到网络设 备上的具体配置是由SDN控制器自动转换后下发的，相对于传统的网络配置方法，采 用SDN后管理员对于SDN控制器下发的何种具体配置将无从知晓。但在某些场景 下，女口：管理员正在经历传统手工配置向SDN自动发放过度，或者某些重要业务

25、管理 员希望能在业务网络布放前校验SDN下发的配置是否正确，这就要求SDN方案能具 备业务网络布放前提供预先校验的能力，包括配置校验、资源校验、业务可达性校验 等多个方面效果预测。1.2.4既有业务网络可达性校验Underlay网络初始化部署完成后，为了能验证网络设备上线后的连通性及路由转发实 现是否符合预期，用户一般会用ping, trace等常规测试方法进行验证，但这种验证手 段效率较低，且验证效果并不全面，所以就需要一种更高效的方案来替代传统方式， SDN组网场景下用户也希望能采用一种自动化方式来达到此种目的。1.2.5故障快速发现定位及恢复在数据中心网络的日常维护中，非常重要的一项工作

26、就是网络中故障的快速发现定位 并能及时排除，按照传统维护经验，网络中的故障发现主要通过两种途径：网管系统收集的告警、日志及设备上报的统计数据等通过网管系统告警进行故障发现有几个显而易见的问题：1是时效性比较差，网管收集设备数据本身有一定的时延，管理员在网管系统上发 现告警等故障数据又会有一定的周期，甚至有些故障初期显现的苗头数据不一定 会得到管理员的关注和处理；2是复杂故障的发现需要依靠管理员的经验，通过对多种网管数据、指标的综合分 析才能最终断定。3是由于设备算法或底层芯片故障导致的流转发类异常的，管理员目前并有效的发 现和定位手段，往往需要厂商技术支持人员现场排查才能准确判断；业务报障有很

27、多网络中产生的故障，通过网管系统收集的日志或统计数据是无法及时发现 的，比如设备上的配置错误、转发表项异常抑或是业务遭受了攻击导致的异常等 等，在传统数据中心网络运维模式下，这些网络问题往往业务上报故障时间会早 于网络管理员主动发现问题的时间。而且这类问题的排除定位通常也会费时费 力。在SDN组网场景下，为了能跟上业务发放、变更的高效节奏，网络故障也需要具备快 速发现、定位以及恢复的能力。这就需要网管运维系统除了收集传统的日志告警类信 息外，还需要收集更多的指标类、资源类、表项类甚至是会话交互数据，同时还要具 备海量数据的分析处理能力，并能从中找出故障间的关联线索实现快速准确的故障定 位，对于

28、其中可以通过配置实现故障恢复或隔离的，还要具备恢复预案的自动生成能 力，必要时这些预案可实现一键式下发从而实现对故障的快速恢复或隔离。1.3数据中心网络运维设计原则华为CloudFabric V1R19C10提供了数据中心SDN网络DAYO-DAYn全生命周期的设计 指导原则及方案实现指南，本篇文章针对数据中心网络在生命周期每个阶段的重点运 维设计工作将进行展开介绍。DAY-0规格化设计-SDN数据中心Underlay网络设计在华为CloudFabric解决方案中,Underlay网络从Fabric骨干组网结构、Server Leaf接 入、Border Leaf接入、网络出口以及Underl

29、ay网络路由等多个方面进行了全新的考量 和设计，力求满足数据中心云化场景要求，提升SDN Overlay场景下的网络可靠性， 灵活性及可弹性扩缩等方面的能力。2.1整体拓扑设计2.2路由协议设计2.3扩展性设计2.4可靠性设计2.1整体拓扑设计物理网络架构概览根据华为CloudFabric解决方案对数据中心组网的先进设计理念，一个典型的数据中心 内部的物理组网架构，应遵循Spine-Leaf架构。华为推荐的物理组网如下图所示。图2-1推荐的物理组网方式其中对上图CloudFabric解决方案的物理组网中各类角色的定义参见下表。表2-1物理组网中各类角色的功能说明物理组网角色含义和功能说明Fab

30、ric一个SDN控制器管理的网络故障域，可以包含一个或多个Spine- Leaf网络结构。Spine骨干节点，VXLAN Fabric网络核心节点，提供高速IP转发功能， 通过高速接口连接各个功能Leaf节点。Leaf叶子节点，VXLANFabric网络功能接入节点，提供各种网络设备 接入VXLAN网络功能。Service LeafLeaf功能节点,提供Firewall和LoadBalance等L4L7增值服务接 入VXLAN Fabric网络的功能。Server LeafLeaf功能节点，提供虚拟化服务器、非虚拟化服务器等计算资源接 入VXLAN Fabric网络的功能。Border Lea

31、fLeaf功能节点，提供数据中心外部流量接入数据中心VXLAN Fabric网络的功能，用于连接外部路由器或者传输设备。DCI Leaf (FabricLeaf功能节点，提供跨Fabric三段式转发时，VXLAN Mapping的 网络功能，具体使用情况见MultiFabric设计指南。物理组网角色含义和功能说明Gateway)华为CloudFabric解决方案，要求一个典型的数据中心组网中Fabric网络结构具有以下 几个特点：包含了一个或多个Spine-Leaf结构；具有高带宽、大容量能力；接入节点间无差异性；采用扁平结构，由于当前数据中心内部东西流量较大，因此采用扁平化设计可使 流量路径

32、尽可能短，转发效率高；灵活组网、弹性扩缩：当服务器数量增加时，可相应增加Leaf数量；当Spine转 发带宽不足时，可相应增加Spine节点个数，扩容灵活。对于Spine-Leaf架构的组网，推荐以下组网形态：推荐采用由CE大容量物理交换机组网；推荐米用L3网络、部署IGP路由协议：Leaf和Spine之间米用三层互联；推荐采用ECMP实现等价多路径负载均衡和链路备份：从Leaf通过多条等价路径 转发数据流量到Spine,在保证可靠性的同时也能提升网络的带宽。Fabric提供的服务原则上要求网络接入节点间可提供无差异互访能力。物理网络设计基本原则一个数据中心网络内部推荐采用由CE系列交换机组成

33、的Spine-Leaf结构，并根据网络 规模来灵活配置Spine和Leaf的节点数量。图2-2 Fabric中ECMP示意图 L3 interfaceSpine设计在Spine-Leaf网络架构中，Spine的数量由Leaf到Spine的收敛比（Leaf的下行总 带宽和Leaf的上行总带宽的比值，不同的行业及不同的客户有各自的要求）来决 定。Spine节点与Leaf节点之间使用以太网口互联，并且配置成三层路由接口模式， 从而构建全IP Fabric网络。Leaf设计Leaf可使用多种灵活组网方式，如M-LAG （推荐）和堆叠。每一个Leaf节点与所有Spine节点相连，构建全连接拓扑形态。Le

34、af节点的TOR设备数量较多，建议通过ZTP的方式来部署TOR设备，降 低部署复杂度。匚口说明ZTP - Zero Touch Provisioning是指新出厂或空配置设备上电启动时采用的一种自动加载版本文 件，包括系统软件、配置文件、补丁文件的功能。转发设计Underlay路由建议选择OSPF动态路由协议，Spine-Leaf间可以形成IPECMP 等价路径。Leaf设备到Spine设备的流量形成ECMP负载分担，无阻塞转发，故障快速 收敛。ECMP链路须选择基于L4 Port的负载分担算法，由于VXLAN使用的是UDP 封装，因此VXLAN报文的目的端口号是4789不变，而VXLAN报文

35、头部的 源端口号可变，基于此来进行负载分担。2.2路由协议设计Underlay层面的路由协议，建议选用OSPF （推荐）或EBGP。Underlay路由选用OSPF当TOR规模小于100台时，推荐Underlay路由选用OSPF,此时路由规划如下：单Fabric内部，Spine和Leaf节点的物理交换机上全部部署OSPF,并都在AreaO 中，使用三层路由口地址建立OSPF邻居，打通Underlay路由，network类型建议 为P2P,如图2-3所示。多Fabric之间互联设备部署在OSPF AreaO,打通Underlay路由，如图2-4所示。 单Fabric内部OSPF路由规划推荐图2-

36、3单Fabric部署OSPF路由规划推荐图2-3单Fabric部署OSPF路由规划推荐P2PP2PP2PP2PP2POSPF1 Area 0C)叠）c)Sc)Spine2Leafl Leaf2Leaf3 Leaf4Leaf5Leaf6图2-4多Fabric部署OSPF路由规划推荐当Underlay的路由选用OSPF时的优缺点对比参见下表。表2-2 Umierby路由为OSPF时的优缺点对比说明项目说明优点OSPF路由协议部署简单OSPF路由收敛速度快Underlay中的OSPF路由协议报文与Overlay中的BGP协议报文不同队 列，VRF和路由表项都相互隔离，从而实现underlay和ove

37、rlay路由协议 故障上互相隔离项目说明缺点 OSPF路由域规模受限故障域较大Underlay路由选用EBGP当TOR规模大于200台时，推荐Underlay路由选用EBGP,该场景路由规划如下：单Fabric内部，Spine节点划分一个AS,每个Leaf节点分别划分一个AS, Leaf 节点和所有Spine节点之间部署EBGP邻居（IPv4地址族），如图2-5所示。多Fabric之间通过互联设备部署EBGP邻居，打通Underlay路由，如图2-6所zj O图2-5单Fabric内部EBGP路由规划推荐AS 63500Spine2AS 65501(&)Leafl Leaf2Leaf3 Lea

38、f4Leaf5 Leaf6图2-6多Fabric之间EBGP路由规划推荐图2-6多Fabric之间EBGP路由规划推荐POD2SpineSpineLEAF倉）（） AS 65501、AS 65522 ；1 AS 655021_5_521Super SpinePOD1LEAFAS 61500当Underlay的路由选用EBGP时的优缺点对比参见下表。表2-3 UiKterlay路由为EBGP时的优缺点对比说明项目说明优点每个分区路由域独立，故障域可控路由控制灵活，可灵活扩展规模适合大规模组网缺点配置复杂Underlay路由协议选择对比不同的Underlay路由协议之间的对比参见下表。表2-4不同

39、的Underlay路由协议之间的对比说明项 目优点缺点适用场景OSPFOSPF路由协议部署简单OSPF路由收敛快速Underlay中的OSPF路由协议报文与 Overlay中的BGP协议报文不同队 OSPF路由域规模受限故障域较大中小型网络单Area,大型网络 三层架构多Area；建议邻居数200项 目优点缺点适用场景列，VRF和路由表项都相互隔离， 实现故障的隔离建议多POD规划，避免单 POD邻居数100,避免路由域 过大影响网络性能EBGP每个分区路由域独立，故障域可控路由控制灵活，可灵活扩展规模适合大规模组网配置复杂中大型网络建议邻居数500建议多POD规划，避免单POD邻居数100,

40、避免路由域 过大影响网络性能2.3扩展性设计数据中心内Fabric网络的扩展模型主要有两种类型：小POD模式和大POD模式。小POD模式扩展在原先Fabric基础上进行扩展，小POD模式是指扩展成的新Fabric实际上是将原 Fabric复制成多份后组成，它们之间使用高速的传统网络互连起来，如下图所示。图2-7小POD模式扩展示意图Fabric 1小POD模式扩展的特点是：按需扩容，模块化扩展适用于大规模数据中心POD接入规模超过2000台服务器时推荐此方式典型场景：金融行业数据中心大POD模式扩展当原网络中业务需要扩容时，增加Fabric网络中Leaf的数量来达到扩容目的。在增加 Serve

41、r Leaf的同时也可以增加Border Leaf,如下图所示。图2-8大POD模式扩展示意图Fabric 1Fabric 1大POD模式扩展的特点是：按需扩容，扩展Leaf节点适用于中小规模数据中心POD接入规模不超过2000台服务器推荐典型场景：企业数据中心2.4可靠性设计2.4.1可靠性设计一般原则以三层架构组网为例，通过设备冗余备份来提升网络的可靠性。服务器链路故障：服务器双归接入，网卡负载分担/主备，当服务器一条链路故障 时，业务倒换到冗余/备份链路。Server Leaf/Border Leaf 设备故障：Server Leaf/Border Leaf 配置 M-LAG 工作组，

42、当一台 Server Leaf/Border Leaf 故障时,业务倒换到另外一台 Server Leaf/Border Leaf上继续转发。Leaf上行链路故障：Leaf和Spine间通过多条链路实现ECMP,当一条上行链路 故障后，业务哈希到其他链路继续转发。Spine设备故障：一台Spine故障后，流量从另外一台Spine设备转发。FW故障：FW配置主备镜像，配置和会话表实时同步，当主FW故障后，流量切 换到备份FW设备。Peer-link故障：当M-LAG组中互联的Peer-link故障时,通过双主检测，触发状 态为备的设备上除管理网口、Peer-link接口以外的接口处于Error-

43、Down状态，避 免网络出现双主，提高可靠性。PE与Border Leaf之间链路故障：当某一台Border Leaf设备与外部网络连接故障 时，通过路由收敛后，自动启用到外部网络的备份路径继续转发，SDN控制平面 不感知故障。当使用框式设备组网时，框式设备的上下行链路以及堆叠、Peer-link链路建议跨 板连接，实现单板级可靠性。Border Leaf节点可靠性两个Border Leaf组成双活网关（部分部署组播的场景需要开启M-Lag特性）。这两台 Border Leaf需配置唯一的虚拟VTEP IP和Server Leaf建立VxLAN隧道。Border Leaf和PE之间交叉或口字型

44、组网。Border Leaf和PE通过E-trunk对接。FW可旁挂或直挂组网，一般是旁挂。两台FW主备备份。单台FW通过trunk接口双 归到两个 Border Leaf。Border Leaf 通过 E-trunk 口和 FW 连接。Border Leaf与外部PE 口字型组网可靠性正常情况下，两台Border Leaf设备分别将指向外部网络的静态或动态私网路 由引入三层逃生链路并发布，以便Border Leaf建立到外部网络的备份路径。当某一台Border Leaf设备与外部网络连接故障时，通过路由收敛后，自动启 用到外部网络的备份路径继续转发，SDN控制平面不感知故障，支持链路失 效告

45、警。网络侧内部链路故障时，路由收敛依赖于IGP动态路由的能力，SDN控制平 面不感知故障，支持链路失效告警。当某一台Border Leaf设备故障时，网络通过路由收敛完成转发路径切换， SDN控制平面不感知故障，支持设备失效告警。Border Leaf与外部PE交叉型组网可靠性正常情况下，两台Border leaf使用4个L3接口与PE对接，物理组网交叉连 线，分别建立私网eBGP会话或者静态路由传递路由信息。两台Border leaf在交叉组网下可以不需要部署L3逃生路径。只有当Border Leaf与PE间的物理链路都故障时才会走到逃生路径。当某一台Border Leaf设备与外部网络连接

46、故障时，通过路由收敛后，自动启 用到外部网络的备份路径继续转发，SDN控制平面不感知故障，支持链路失 效告警。网络侧内部链路故障时，路由收敛依赖于IGP动态路由的能力，SDN控制平 面不感知故障，支持链路失效告警。当某一台Border Leaf设备故障时，网络通过路由收敛完成转发路径切换， SDN控制平面不感知故障，支持设备失效告警。243 Spine节点可靠性数据中心网络Spine-Leaf架构下，单纯的Spine设备角色本身彼此无需物理连线连接， 各设备独立运行在Underlay路由网络。Spine上连Border Leaf设备，下连ServerLeaf 设备，均使用三层路由口互联。某台S

47、pine设备的链路或者整机故障时，上下层设备通过动态路由协议，例如OSPF或者EBGP,收敛Underlay路由，将流量引导到正常的 Spine链路或者设备承载。由于Spine间可靠性耦合较小，因此Spine设备自身的可靠性是主要的考虑因素，在 CloudFabric基线中，建议使用框式设念作为Spine节点：CE12800系列、CE12800S系列或者12800E系列（海外不体现）框式交换机CE16800系列框式交换机CE16800系列框式交换机CE16800系列框式设备采用多种冗余技术提高设备的可靠性，如图2-9所示，包括主 控单元的冗余备份，监控单元冗余备份，交换单元的冗余备份，电源模块

48、的冗余备 份，风扇冗余备份等。并且当上述冗余的模块发生故障时，可以通过热插拔方式替 换，保证整机持续处于高可靠状态。另外，接口板也可以通过配置多块单板，多链路跨板接入方式保证链路侧可靠性，接 口板同样支持热插拔替换。图2-9 CE16800系列框式交换机可靠性示意图电源N+M热备份监控1+1热备份系统级 热备份PEM输入N+N备份交换网N+M热备份 风扇框/风扇热备份主控1十1热备份CE12800系列框式交换机CE12800系列框式设备采用多种冗余技术提高设备的可靠性，如图2-10所示，包括主 控单元的冗余备份，监控单元冗余备份，交换单元的冗余备份，电源模块的冗余备 份，风扇冗余备份等。并且当

49、上述冗余的模块发生故障时，可以通过热插拔方式替 换，保证整机持续处于高可靠状态。另外，接口板也可以通过配置多块单板，多链路跨板接入方式保证链路侧可靠性，接 口板同样支持热插拔替换。图2-11服务器接入VXLAN的两种方案图2-10 CE12800系列框式交换机可靠性示意图监控W热备份一*主控1十1热备份-电源N十M热备份热备份交换网N+M热备份风扇框内双风扇 W热备份-1+1风扇框级热备份系统内热备份电源era e31主用备用1雌雌Sx 网板外设.3s im ri阿i両i网板n双CAN监控总线双GE管理总线多LINK高速数据总线CE12800系列的可靠性还包括设备本身对故障的检测、分析和预警处

50、理能力。这些技 术包括设备CPU防攻击能力、完善故障监控和全面的告警功能。CE12800系列交换机 采用控制平面和管理平面分离的同时，还增加监控平面。这三个平面完全独立，保证 整个系统的可靠性以及业务连续性。匚口说明监控单元是一个完全独立的带外管理单元，遵循数据中心DCMI1.0管理规范和IPMI2.0管理规 范。监控单元可以实现远程单板的上电、固件升级、资产管理、故障诊断和温度、电压、功率的 监控等功能，从而实现设备的远程管理和远程维护。2.4.4 Leaf节点可靠性服务器接入方式简介服务器接入Server Leaf的方式推荐为M-LAG,如图2-11所示。（推荐）服务器Eth-Tnmk接入

51、Leaf M-LAG I作组，如下图中“1”所示。服务器主备接入Leaf单机，如下图中“2”所示。上述几种部署方式的比较参见下表。表2-5两种服务器接入方式的对比部署方式特点管理复 杂度可靠性接入成本（推荐）服务 器 Eth-Trunk 接入LeafM- LAG工作组两台Leaf设备通过peer-link互联并建立DFS Group,对外表现为一台逻辑设备，但又各自有独 立的控制面，服务器以负载分担方式接入两台 Leaf设备升级维护简单，运行可靠性高。下行口 配置M-LAG特性双归接入服务器，服务器双网卡 运行在主备/负载分担模式。因设备有独立控制 面，故部署配置相对复杂。高高中服务器主备接

52、入Leaf单机Leaf独立部署，服务器双网卡绑定以主备模式接 入两台Leaf设备，同一时间只有一个网卡收发报 文，带宽利用率低。主备网卡切换时接收流量的 VTEP IP变化，依赖于发生切换的服务器发送免 费ARP报文重新引流。中高中综上所述，推荐M-LAG来组建Leaf工作组。当两台设备之间配置了 DFS Group和Peerl-link后，两台设备通过Peer-link链路进行 DFS Group配对，并协商设备的主、备状态和M-LAG成员口的主备。正常工作后，两 台设备之间会通过Peer-link链路发送M-LAG同步报文实时同步对端的信息，M-LAG 同步报文中包括MAC表项、ARP表项

53、以及STP、VRRP协议报文信息等，并发送M- LAG成员端口的状态，这样任意一台设备故障都不会影响流量的转发，保证正常的业 务不会中断。M-LAG上行链路故障时的可靠性保证如下图所示，M-LAG I作组的双主检测链路通过连接到Spine的业务网络互通。配置 Monitor-Link,将一台设备的所有上行链路加入Uplink,对应服务器的下行链路加入 Downlinko当这台设备的所有上行链路故障时，联动下行链路down,触发服务器侧流 量只通过另一条上行链路转发。此时场景变为单归接入。M-LAG下行链路故障时的可靠性保证如下图所示，当下行M-LAG成员口故障时，DFS Group主备状态不会

54、变化，但如果故 障M-LAG成员口状态为主，则备M-LAG成员口状态由备升主，流量切换到该链路上 进行转发。发生故障的M-LAG成员口所在的链路状态变为Down,双归场景变为单归 场景。故障M-LAG成员口的MAC地址指向peer-link接口。在故障M-LAG成员口恢 复后，M-LAG成员口状态不再回切，由备升主的M-LAG成员口状态仍为主，原主M- LAG成员口在故障恢复后状态为备。可以执行display dfs-group dfs-group-id node node-idm-lag命令来查看成员接口当前状态。图2-13下行链路故障时可靠性示意图图2-14 M-LAG主设备故障时可靠性示

55、意图图2-14 M-LAG主设备故障时可靠性示意图NetworkNetworkDAD linkBackupDAD linkPeer-linkPeer-link:kup下行链路故障对于组播源在网络侧，组播成员在接入侧的组播流量，当M-LAG主设备的M-LAG成 员口故障时，通过M-LAG同步报文通知对端设备进行组播表项刷新，M-LAG主备设 备不再按照组播地址奇偶进行负载分担，而是所有组播流量都由端口状态Up的M- LAG备设备进行转发，反之亦然。M-LAG主设备故障时的可靠性保证如下图所示，当M-LAG主设备故障，则M-LAG备设备将升级为主，其设备侧Eth- Trunk链路状态仍为Up,流量

56、转发状态不变，继续转发流量。M-LAG主设备侧Eth- Trunk链路状态变为Down,双归场景变为单归场景。如果是M-LAG备设备发生故障，M-LAG的主备状态不会发生变化，M-LAG备设备 侧Eth-Trunk链路状态变为Down。M-LAG主设备侧Eth-Trunk链路状态仍为Up,流 量转发状态不变，继续转发流量，双归场景变为单归场景。M-LAG主设备 故障DAD link BackupNetworlDAD linkasterPeer4inkifi*BAckupM-LAG的Peer-Link链路故障时的可靠性保证如下图所示，当M-LAG应用于普通以太网络、VXLAN网络或IP网络的双归

57、接入 时，peer-link故障但双主检测心跳状态正常会触发备设备上除管理网口、peer-link接口 和堆叠口以外的接口处于Error-Down状态。一旦peer-link故障恢复，处于ERROR DOWN状态的M-LAG接口默认将在2分钟后自动恢复为Up状态，处于ERROR DOWN状态的其它接口将立即自动恢复为Up状态。图2-15 M-LAG的Peer-Link链路故障时可靠性示意图图2-15 M-LAG的Peer-Link链路故障时可靠性示意图Peer-UnkJJf 障BickupPeer-link /ckupDAD linkMasti fX y Peer-link1x故障链路Erro

58、r-Down 接口但在实际组网应用中，当某些上行端口运行路由协议或者是双主检测心跳口时是不希 望被Error-Down的。此时，可以根据实际情况选择配置下列功能。在peer-link故障但 双主检测正常时，配置下列功能，设备接口 Error-Down情况参见下表。表2-6设备在peer-link故障但双主检测正常时接口 Error-Down情况设备配置情况M-LAG接入普通以太网络、VXLAN网络或IP网络设备缺省情况除管理网口、peer-link接口和堆叠口以外的接口处于 ERROR DOWN 状态。设备仅配置suspend功能仅M-LAG成员口以及配置该功能的接口处于ERROR DOWN状

59、态。设备仅配置reserved功能除配置该功能的接口、管理网口、peer-link接口和堆叠 口以外的接口处于ERROR DOWN状态。设备同时配置suspend功 能和reserved功能仅M-LAG成员口以及配置suspend功能的接口处于 ERROR DOWN 状态。部署注意事项 关于VTEP IP的规划计算节点通常双归接入到M-LAG工作组中的两台不同的TOR设备，且这两台 TOR需配置相同的、全网唯一的VTEPIP地址和相同的NVE1的MAC地址。使 用M-LAG技术可以在两台物理TOR上配置相同的VTEPIP,但两台设备依然彼 此独立，可独立升级部署，进一步提高接入可靠性。 关于P

60、eer-Link链路带宽的选择如下图所示：网络正常时，流量不经过Peer-link链路横穿，无论上行流量经过哪个DFS成 员设备，下行流量Hash到其他成员时，其他成员具备本地优先转发能力。当DFS1的全部上行链路中断时，服务器发出的流量要通过Peer-link链路横 穿到其他DFS成员设备进行转发，如下图中绿色虚线所示。因此Peer-link链 路带宽应不小于DFS单设备上行带宽。当DFS1的全部下行链路中断时，网络侧下行的流量要通过Peer-link链路横 穿到其他DFS成员设备进行转发，如下图中红色虚线所示。因此Peer-link链 路带宽应不小于DFS单设备上行带宽。图2-16成员设备