《云数据中心网络架构与技术》第四章数据中心网络总体架构与技术演进(上)

数据中心网络的物理架构

传统的三层网络架构

这个模型包含以下三层。

· 汇聚层(Aggregation Layer):汇接交换机连接接入交换机,同时提供其他服务,例如安全、QoS、网络分析等,在传统的三层架构中,汇接交换机往往会承担网关的作用,负责收集PoD(Point of Delivery,分发点)内的路由。

· 接入层(Access Layer):主要负责物理机和虚拟机的接入、VLAN(Virtual Local Area Network,虚拟局域网)的标记,以及流量的二层转发。

· 核心层(Core Layer):核心交换机主要负责对进出数据中心的流量进行高速转发,同时为多个汇聚层提供连接性。

通常情况下,汇接交换机是二层(L2)和三层(L3)网络的分界点,汇接交换机以下的是二层网络,以上是三层网络。每组汇接交换机管理一个PoD,每个PoD内都是独立的VLAN。服务器在PoD内迁移不必修改IP地址和默认网关,因为一个PoD对应一个二层广播域。

缺点一:无法支撑大二层网络构

是在云计算背景下,计算资源被资源池化,根据计算资源虚拟化的要求,VM需要在任意地点创建、迁移,而不需要对IP地址或者默认网关进行修改,这从根本上改变了数据中心的网络架构。

为了满足计算资源虚拟化的要求,必须构建一个大二层网络来满足VM的迁移诉求,如图4-2所示。针对传统的三层网络架构,必须将二三层网络的分界点设置在核心交换机,核心交换机以下均为二层网络,这样一来,汇聚层就不再起网关作用了,网络架构逐渐向没有汇聚层的二层架构演进。

缺点二:.无法支持流量(尤其是东西向流量)的无阻塞转发

数据中心的流量可以分为以下几种。

· 南北向流量:数据中心之外的客户端与数据中心内部服务器之间的流量,或者数据中心内部服务器访问外部网络的流量。

· 东西向流量:数据中心内部服务器之间的流量。

· 跨数据中心流量:不同数据中心之间的流量。

东西向流量的大幅增加使得东西向流量取代了南北向流量,成为数据中心网络中占比最高的流量类型,占比可超90%。而保证东西向流量的无阻塞转发成为云数据中心网络的关键需求。

Spine-Leaf架构

Spine-Leaf架构相对于传统的三层网络架构的优势如下。

第一,支持无阻塞转发。Spine-Leaf架构对东西向和南北向流量的处理模式是完全一致的,在设计合理的情况下,可以实现流量的无阻塞转发。无论何种类型的流量,都只需要经过Leaf---Spine---Leaf(3个节点)即可完成转发。

第二,弹性和可扩展性好。Spine-Leaf拥有很好的横向扩展能力,只需要保证Spine和Leaf在一个比例范围内,不需要重新设计,将原有的结构复制一份即可。一般来说,基于3级Clos的Spine-Leaf架构可以满足当前大部分数据中心网络的带宽诉求。针对超大型的数据中心,可采用5级的Spine-Leaf架构,即每个PoD部署一个3级Clos的Spine-Leaf网络,不同PoD之间再增加一层核心交换机进行互联,跨PoD流量可以经过Leaf---Spine---Core---Spine---Leaf,5跳可达。Spine和Core之间进行full mesh连接。另外,网络设计可以非常灵活,在数据中心运行初期网络流量较少时,可以适当减少Spine交换机的数量,后续流量增长后再灵活地增加Spine交换机。

第三,网络可靠性高。传统三层网络架构中,尽管汇聚层和核心层都做了高可用设计,但是汇聚层的高可用是基于STP(Spanning TreeProtocol,生成树协议)的,不能充分利用多个交换机的性能,如果所有的(一般是两个)汇接交换机都出现故障,那么整个汇聚层PoD网络就会瘫痪。但是在Spine-Leaf架构中,跨PoD的两个服务器之间有多条通道,不考虑极端情况时,该架构的可靠性比传统三层网络架构高。

数据中心网络的技术演进

xSTP

用于对广播域环路进行破除。xSTP的标准是IEEE 802.1D,它通过创建一个树状拓扑结构进行环路的破除,从而避免报文在环路网络中无限循环。

。关于xSTP的内容和具体原理,读者可以自行查阅相关资料,这里仅说明一下为什么xSTP不再适用于当前的数据中心网络。

· 收敛速度慢:在xSTP网络中,当链路或交换机出现故障时,生成树需要重新进行计算,MAC表需要重新生成,如果是根节点出现故障,还需要重新选举根节点。这些都导致xSTP的收敛速度在亚秒级甚至秒级。在以前百兆、千兆(吉比特)接入的网络中,这个收敛速度尚可接受,但是在现在动辄10Gbit/s、40Gbit/s甚至100Gbit/s的网络中,秒级的收敛会导致大量的业务掉线,这是不可接受的。所以收敛速度慢是xSTP网络的主要缺点之一。

· 链路利用率低:如上所述,xSTP将网络构建为一个树状结构,以确保由此产生的网络拓扑没有环路。具体实现方法是通过阻塞一些网络链路来进行树状结构的构建,这些被阻塞的链路是网络的一部分,只是被置于不可用的状态,只有在正常转发的链路出现故障时,才会使用这些被阻塞的链路。这就导致了xSTP不能充分利用网络资源。

· 次优转发路径问题:xSTP网络是树状结构,网络中任意两台交换机之间只有一条转发路径。这时,如果两个非根交换机之间有一条更短的路径,但是更短的路径由于xSTP计算的原因被阻塞了,那么流量就不得不沿着更长的路径进行转发。

· 不支持ECMP技术:在三层网络中,路由协议通过ECMP机制可以实现两点之间有多条等价路径进行转发,实现了路径冗余并提高了转发效率。xSTP技术没有类似的机制。

· 广播风暴问题:尽管xSTP通过构建树状结构防止了环路的发生,但是在一些故障场景下,环路还是有可能产生的,而xSTP对这种场景完全无能为力。在三层网络,IP报文头里有TTL(Time to Live,存活时间)字段,每经过一台路由器时,该字段都会减去一个设置好的值,当TTL字段值变成0后,该报文就会被丢弃,从而防止报文在网络中无休止循环。但是以太报文头中并没有类似的值,所以一旦形成了广播风暴,会导致所有涉及的设备的负载大幅上升,这就极大地限制了xSTP网络的规模。在一些经典的网络设计资料中,xSTP网络的直径被限制在7以及7以内。这对动辄数万甚至数十万终端的数据中心网络来说简直是杯水车薪。

· 缺乏双归接入机制:由于xSTP网络是树状结构,当服务器双归接入两台基于xSTP的交换机时,必然会产生网络环路(除非这两台交换机属于两个局域网,那么服务器可能需要两个不同网段的IP),所以,即使服务器上行链路是通过双归接入的,也会被xSTP堵塞端口,从而导致双归变为单归。

· 网络规模:除了上述所说的广播风暴问题限制了xSTP网络的规模外,xSTP网络支持的租户数量也限制了网络规模。xSTP通过VLAN ID来标识租户,VLAN ID仅有12bit,在IEEE 802.1Q设计之初,设计者可能认为4000个租户的数量已经足够多了,但是在云计算时代,远不止4000个租户。

以上问题导致xSTP技术慢慢地在数据中心网络中被淘汰。在网络后续的发展中,为了解决上述问题,一些新的技术陆续出现。

虚拟机框类技术

首先要介绍的是虚拟机框类技术,这种技术能够将多台设备中的控制面整合,形成一台统一的逻辑设备,这台逻辑设备不但具有统一的管理IP,而且在各种二层和三层协议中也表现为一个整体。因此,经整合后,xSTP所看到的拓扑是无环的,这就间接规避了xSTP的种种问题。

虚拟机框类技术实现了设备的"多虚一",不同的物理设备分享同一个控制面,实际上就相当于给物理网络设备做了个集群,也有选主和倒换的过程。业界各厂家都有虚拟机框类技术,比如Cisco的VSS、H3C的IRF2。下面简单介绍一下华为的虚拟机框类技术CSS/iStack(ClusterSwitch System/Intelligent Stack),也称堆叠。

虚拟机框类技术------CSS/iStack

虚拟机框类技术的优势和劣势

虚拟机框类技术通过控制面,将多台设备虚拟成一台逻辑设备(即多虚一),通过链路聚合使此逻辑设备与每个接入层物理或逻辑节点设备均只通过一条逻辑链路连接,将整个网络逻辑拓扑变成一个无环的树状连接结构,从而满足无环与多路径转发的需求。如图4-13所示,在设备经过堆叠后,从逻辑上说,整个网络就成为一个天然的树状结构,整网甚至不需要通过xSTP进行环路破除。

但是,虚拟机框类技术本身也存在以下一些问题。

· 扩展性受限:由于控制面合一,整个虚拟机框系统控制面的重担全部压在了主交换机身上,控制面的处理能力最多不超过系统中单台设备的处理能力。

· 可靠性问题:控制面合一带来的另一大问题是可靠性问题,由于控制面完全集中在主交换机上,一旦主交换机出现故障,可能会导致较长时间的丢包或者整个系统停止运行。

· 升级丢包问题:控制面合一还会导致虚拟机框系统升级较为困难,一般的重启升级必然会导致控制面的中断,从而导致较长时间的丢包。对于一些对丢包敏感的业务,虚拟机框系统升级可能会导致的秒级甚至分钟级的丢包是完全不可接受的。虽然各个厂家都推出了一些无损升级的方案,如ISSU(In Service Software Upgrade,在线业务软件升级)(注:这类技术一般通过控制面多进程实现无损升级,主进程重启时,备进程正常工作,主进程重启完成后,进行进程主备倒换,具体过程不再赘述,读者可以自行查阅资料),但是这些方案普遍非常复杂,操作难度极高,对网络也有要求,所以在实际应用中效果并不好。

· 带宽浪费问题:虚拟机框系统中需要设备提供专门的链路用于设备之间的状态交互及数据转发,通常这个专门的链路可能需要占用设备10%~15%的总带宽。

L2MP类技术

L2MP类技术的基本思想是将三层网络路由技术的机制引入二层网络中。

传统的以太网交换机通常是透明传输的,本身不维护网络的链路状态,也不需要显式寻址的机制。而链路状态路由协议通常要求网络中的每个节点都是可寻址的,每个节点通过链路状态协议计算出网络的拓扑,再通过这个拓扑计算出交换机的转发数据库。所以L2MP类技术需要给网络中的每台设备添加一个可寻址的标识,类似于IP网络中的IP地址。

TRILL协议

TRILL(Transparent Interconnection of Lots of Link),即多链接透明互联协议。它的基本思想是,二层环有问题,三层环没有问题,那就把三层的路由能力模拟在二层实现。运行 TRILL 协议的交换机称为 RBridge,是具有路由转发特性的网桥设备,只不过这个路由是根据 MAC 地址来的,不是根据 IP 来的。Rbridage 之间通过链路状态协议运作。记得这个路由协议吗?通过它可以学习整个大二层的拓扑,知道访问哪个 MAC 应该从哪个网桥走;还可以计算最短的路径,也可以通过等价的路由进行负载均衡和高可用性。

TRILL 协议在原来的 MAC 头外面加上自己的头,以及外层的 MAC 头。TRILL 头里面的 Ingress RBridge,有点像 IP 头里面的源 IP 地址,Egress RBridge 是目标 IP 地址,这两个地址是端到端的,在中间路由的时候,不会发生改变。而外层的 MAC,可以有下一跳的 Bridge,就像路由的下一跳,也是通过 MAC 地址来呈现的一样。

TRILL的数据报文如图

TRILL的数据报文由4个部分组成,由里往外分别是:数据、内层以太帧头、TRILL帧头、外层以太帧头。

L2MP类技术的优势和问题

L2MP类技术的优势在前文中已经说明:通过在二层网络引入路由的机制解决了环路问题,同时也解决了网络扩展性和链路利用率的问题。这里主要说明一下L2MP类技术的问题。

L2MP类技术的问题主要有以下几点。

租户数量问题:和xSTP类似,TRILL也通过VLAN ID来标识租户,VLANID仅有12bit,仅支持4000户左右的租户规模。

· 部署成本问题:L2MP类技术或引入了新的转发标识,或增加了新的转发流程,不可避免地需要对设备的转发芯片进行升级换代。所以存量网络使用旧版芯片的设备是无法使用L2MP类技术的,这就增加了客户的部署成本。

· 机制问题:TRILL的OAM(Operation,Administration andMaintenance,运行、管理与维护)机制和组播机制一直未能形成正式的标准,影响了协议的演进。

跨设备链路聚合技术

跨设备链路聚合技术本质上还是控制面虚拟化技术,但由于控制面耦合程度低,理论上的可靠性比虚拟机框类技术高。此外,两台设备可以进行独立升级,业务中断时间较短。

和虚拟机框类技术类似,采用跨设备链路聚合技术的设备之间信息的同步机制均为内部实现,所以业界各厂家均有跨设备链路聚合技术的私有协议。比如Cisco的VPC(Virtual Port Channel,虚拟端口通道)、Juniper的MC-LAG。这里以华为CloudEngine系列交换机上实现的跨设备链路聚合技术M-LAG(Multi-Chassis Link Aggregation Group,跨设备链路聚合组)为例,说明跨设备链路聚合类技术的运行原理。

M-LAG的基本概念

· M-LAG:跨设备链路聚合组,是一种实现跨设备链路聚合的机制,能够实现多台设备间的链路聚合,从而把链路的可靠性从单板级提高到设备级,组成双活系统。

· M-LAG主/备设备:和CSS/iStack类似,M-LAG也会选举主/备设备,但是正常情况下,主/备设备转发行为没有区别,仅在双活系统分裂场景下,备设备会抑制自身转发行为,而主设备正常转发。

· Dfs-group:动态交换服务组(协议)。M-LAG双归设备之间的接口状态、表项等信息同步需要依赖Dfs-group协议进行同步。

· peer-link:部署M-LAG的两台设备之间必须存在的一条直连链路,该链路必须为链路聚合且配置为peer-link。peer-link链路是一条二层链路,用于协商报文的交互及部分流量的传输。接口配置为peer-link口后,该接口上不能再配置其他业务。

· keepalive链路:心跳链路,承载心跳数据报文,主要作用是进行双主检测。需要注意的是,keepalive链路和peer-link是不同的两条链路,其作用也不一样。正常情况下,keepalive链路不会参与M-LAG的任何转发行为,只在故障场景下,用于检查是否出现双主的情况。keepalive链路可以通过外网承载(比如,如果M-LAG上行接入IP网络,两台双归设备通过IP网络可以互通,那么互通的链路就可以作为keepalive链路)。也可以单独配置一条三层可达的链路来作为keepalive链路(比如通过管理口)。

· M-LAG成员口:双归接入的接口,两个M-LAG成员口的状态需要进行同步。

· 单归设备:单归设备仅连接到M-LAG双归设备中的一台。如果部署M-LAG,单归设备是极不推荐的。

M-LAG工作机制

· M-LAG两端的设备配置完成后,进行配对。两边设备会在peer-link上定期发送Hello报文,Hello报文中携带了自己的Dfs-group ID、协议版本号、系统MAC等信息。

· 收到对端的Hello报文后,会判断Dfs-group ID是否相同,如果相同,则配对成功。

· 配对成功后,会选举主/备设备,根据优先级选举,优先级高为主设备。如果优先级一样,则比较系统MAC,系统MAC小的则为主设备。默认情况下,优先级为100,可以通过手动配置修改。

· 配对成功之后,设备间会发送同步报文进行信息同步,需要同步的信息包括设备名、系统MAC、软件版本、M-LAG状态、STP BPDU(BridgeProtocol Data Unit,网桥协议数据单元)信息、MAC表项、ARP表项、IGMP(Internet Group Management Protocol,互联网组管理协议)表项等。

设备配对成功后,会通过keepalive链路发送心跳。心跳主要是用于在peer-link发生故障时,双主检测使用。

NVo3类技术

,NVo3类技术是一项以IT厂商为推动主体的、旨在摆脱对传统物理网络架构依赖的叠加网络技术。

叠加网络是指在物理网络之上构建一层虚拟网络拓扑。每个虚拟网络实例都是由叠加来实现的,原始帧在NVE(Network VirtualizationEdge,网络虚拟化边缘)设备上进行封装。该封装标识了解封装的设备,在将帧发送到终端之前,该设备将对该帧进行解封装,得到原始报文。中间网络设备基于封装的外层帧头来转发帧,不关心内部携带的原始报文。虚拟网络的边缘节点可以是传统的交换机、路由器,或者是Hypervisor内的虚拟交换机。此外,终端可以是VM或者是一个物理服务器。VNI(VXLAN Network Identifier,VXLAN网络标识符)可以封装到叠加头中,用来标识数据帧所属的虚拟网络。因为虚拟数据中心既支持路由,又支持桥接,叠加报文头内部的原始帧可以是完整的带有MAC地址的以太帧,或者仅仅是IP报文。NVo3类技术模型如图

图4-37中的发送方表示终端设备,可能是VM或者是物理服务器等。NVE表示网络虚拟化边缘,可能是一台物理交换机或者是Hypervisor上的虚拟交换机。发送方可以直接和NVE相连,或者通过一个交换网络和NVE相连。NVE之间通过隧道(Tunnel)相连。隧道的含义是将一种协议封装到另一种协议中。在隧道入口处,将被封装的协议报文封装入封装协议中,在隧道出口处再将被封装的协议报文取出。在整个隧道的传输过程中,被封装协议作为封装协议的负载(payload)。NVE上执行网络虚拟化功能,对报文进行封装/解封装等操作,这样三层网络中的节点只需要根据外层帧头进行转发,不需要感知租户的相关信息。

NVo3类技术的代表有VXLAN、NVGRE(Network Virtualizationusing Generic Routing Encapsulation,基于通用路由封装的网络虚拟化)、STT(Stateless Transport Tunneling,无状态传输通道)等,其中翘楚无疑是当前最为火热的VXLAN技术。

相关推荐
子兮曰5 小时前
后端字段又改了?我撸了一个 BFF 数据适配器,从此再也不怕接口“屎山”!
前端·javascript·架构
卓卓不是桌桌7 小时前
如何优雅地处理 iframe 跨域通信?这是我的开源方案
javascript·架构
Qlly7 小时前
DDD 架构为什么适合 MCP Server 开发?
人工智能·后端·架构
用户881586910911 天前
AI Agent 协作系统架构设计与实践
架构
鹏北海1 天前
Qiankun 微前端实战踩坑历程
前端·架构
货拉拉技术1 天前
货拉拉海豚平台-大模型推理加速工程化实践
人工智能·后端·架构
RoyLin1 天前
libkrun 深度解析:架构设计、模块实现与 Windows WHPX 后端
架构
CoovallyAIHub2 天前
实时视觉AI智能体框架来了!Vision Agents 狂揽7K Star,延迟低至30ms,YOLO+Gemini实时联动!
算法·架构·github
RoyLin2 天前
领域驱动设计:回归本质的工程实践
架构
CoovallyAIHub2 天前
OpenClaw:从“19万星标”到“行业封杀”,这只“赛博龙虾”究竟触动了谁的神经?
算法·架构·github