本文首先分析了在大规模 SDN 数据中心组网中遇到的问题. 一方面 Underlay 底层组网规模受限于设备实际的转发能力和端口密度, 单一 Spine-leaf 的 Fabric 架构无法满足大规模组网的需求; 另一方面在 SDN 技术实现方案上, Openstack 和 SDN 控制器分别有管理控制能力上的限制. https://www.sdnlab.com/23041.html
本文分别从多 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 上的来回穿透流量.
图 1. 大规模 SDN 数据中心多 POD 组网架构
POD 内的 SDN 数据中心转发控制技术实现方案, 可以是 Openflow+Netconf 也可以是 EVPN+Netconf. 虚拟机场景推荐使用表项更大更灵活的 VSW 作为 VTEP, 从而采用 Openflow+Netconf 方案. 裸金属服务器场景采用硬件 SDN 接入交换机作为 VTEP, 可以根据具体网络设备能力情况灵活选择 EVPN+Netconf 的方案或者 Openflow+Netconf 的方案.
在 Openflow+Netconf 和 EVPN+Netconf 混合部署的场景, 需要在 SDN 控制器上进行两种控制技术方案的翻译和打通. SDN 控制器和 SDN-GW 建立 EVPN 邻居, 将 EVPN 控制面的信息翻译成 Openflow 发送给 VSW, 将 VSW 的相关 Openflow 信息翻译成 EVPN 控制信息发送给硬件 SDN 交换机. 从而控制实现在 VSW 和硬件 SDN 交换机之间建立 VXLAN 隧道和转发数据.
POD 间互联的方案将完全借鉴 SDN-DCI 的相关技术, 采用 EVPN+VXLAN 的技术. POD 内的 SDN-GW 将同时作为 DCI-GW, 与不同 POD 的 SDN-GW 间建立 EVPN 邻居, 在统一的协同层的控制下实现跨 POD 流量的互通.
共享分布式块存储, 分布式文件存储, 分布式对象存储可以单独规划组成存储 POD. 访问存储 POD 的流量在 SDN-GW 解开 VXLAN 封装以后走 Underaly 网络路由转发达到存储 POD. 在 POD 内配置单独的 VRF 用于隔离访问存储的流量和其他业务流量. 存储 POD 有访问外网需求的, 存储汇聚交换机规划上连南北汇聚交换机. FC SAN 存储建议直接部署在各 POD 内.
图 2. 存储 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. 南北汇聚交换机一般工作在二层透传模式, 三层终结在外网防火墙, 因此南北汇聚交换机可不运行路由协议.
图 3. 大规模数据中心组网 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.
图 4. 大规模数据中心组网 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 内同时以 EVPN+Netconf 为转发控制方案, POD 内 EVPN 需以 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 号长度的支持能力.
图 5. 大规模数据中心组网 EBGP 路由规划
SDN 数据中心的管理网除了满足传统的设备带外管理功能, 还要部署 Openstack 云管理平台和 SDN 控制器, 因此相比传统数据中心的管理网更加重要. 随着数据中心规模的增大, 管理网的规模也必然同时增大, 因此大规模数据中心的管理网也需要分 POD 部署. POD 内管理网核心交换机配置各网段网关, 管理网接入交换机工作在二层 VLAN 透传模式. 管理网 POD 间设置管理汇聚交换机, POD 内管理网核心和 POD 间汇聚交换机三层互联, 可以运行 ISIS 或者 OSPF 路由协议. 为了减小 POD 内管理网广播域使管理网更加稳定, 也可以将管理网段的网关配置在管理接入交换机上, 规划三层到边缘的管理网络, 但是这样做同时带来的弊端是需要更详细的管理地址规划, 过于细分的管理地址规划会在一定程度上浪费地址资源, 因此三层到边缘的管理网规划并不常见.
4. 大规模 SDN 数据中心 POD 间互联互通
大规模 SDN 数据中心需要将不同 POD 内资源统一管理和调度, 构造大规模数据中心统一资源池. 大规模 SDN 数据中心采用 SDN-DCI 技术实现 POD 间互联互通.
SDN-DCI 技术通过 EVPN+VXLAN 建立跨 POD 互联通路, 管理面采用 EVPN 协议, 数据面采用 VXLAN 隧道承载. POD 内的 SDN-GW 将同时作为 DCI-GW, 各 POD 的 SDN-GW 之间配置运行 Full mesh 的 EBGP 协议. 基于 EBGP 协议, 各 POD 的 SDN-GW 之间建立 EVPN 邻居关系, 通过 EVPN 建立互联互通的控制面, 传递租户 VPC 内 (Virtual Private Cloud) 的 Mac,ARP 和 IP 网段路由信息.
大规模数据中心部署统一云管理平台, 协同编排各 POD 内 SDN 控制器实现跨 POD 网络业务流量互通. 考虑到实际网络部署时, POD 间很可能为异厂家设备, 因此云管理平台需要对接不同厂家 SDN 控制器, 为此需定义标准的 SDN 控制器到云管平台的北向 API 开放接口, 异厂家 SDN 控制器据此标准接口接收云管平台指令并控制本 POD 内转发设备完成指令的执行.
图 6. 跨 POD 互通 EVPN+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 绑定.
图 7. 跨 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 隧道.
图 8. 跨 POD 不过防火墙流量模型
不同业务的跨 POD 互通流量应予以隔离, 需要为每组业务互通流量规划一个单独的 VNI 和 VRF, 并将 VNI 和 VRF 绑定. 对于部分需要经过负载均衡设备处理的业务流量, 可以由云管平台统一编排流量经过相应的负载均衡.
5. 大规模 SDN 数据中心南北向流量简述
大规模 SDN 数据中心对南北向流量的处理, 在引入多 POD 组网后, 增加了南北汇聚交换机. 由南北汇聚交换机分别上连互联网防火墙, IP 专网和专线路由器. 南北汇聚交换机在互联网南北业务流量的处理上工作在二层透传模式, 三层分别终结在 SDN-GW 和外网防火墙. 在进出 IP 专网和专线的南北流量处理上可以视具体情况工作在二层透传或者三层模式, 工作在三层模式需要配置 VRF 进行不同业务流量的隔离.
来源: https://www.cnblogs.com/sdnlab1509/p/11170588.html