《私有云计算整合、虚拟化和面向服务的基础设施》一2.5Layer-2演化

简介: 本节书摘来自华章出版社《私有云计算整合、虚拟化和面向服务的基础设施》一 书中的第2章,第2.5节,作者:(美)Stephen R.Smoot Nam K.Tan,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.5Layer-2演化

深入研究光纤模块之前,让我们想一下目前的优化技术已经克服了以往哪些DC技术缺陷,而当前DC技术还存在哪些可被优化的地方,显然后者比前者更重要,因为它将带来更好的技术效率和改善性能。有一个需要注意的问题是,冗余L2设计方案时生成树协议(Spanning Tree Protocol,STP)的副作用。尽管对STP(可以回溯到1985年)已经做了某些优化,但是这些优化仍然未能解决两个基本的L2设计问题:
STP不支持特定VLAN下的L2多路径,同样每VLAN负载平衡允许使用接入层交换机的两条上行链路,但要求用户自己配置。之所以没有其他好的替换方案,是因为数据平面的STP要求必须这样做以防止产生回路。
为了形成生成树拓扑使得数据平面对STP产生依赖,将导致收敛时延,并带来诸如网络泛洪、链路饱和等潜在危险。
说明:STP的优化措施包括快速生成树协议(Rapid Spanning Tree Protocol,RSTP)、每VLAN生成树(Per-VLAN Spanning Tree,PVST)、快速每VLAN生成树改进(shengRapid Per-VLAN Spanning Tree Plus,Rapid PVST+)以及多生成树协议(Multiple Spanning Tree Protocol)等。
围绕这些问题的解决方法之一是部署无回路L2接入拓扑,经典的L2回路拓扑中每个接入层交换机拥有一个上行链路。其他都是冗余链路或处在断开状态的链路。与经典L2回路拓扑相比,无回路拓扑没有生成树断开端口。图2-12展示了一个无回路L2接入设计方案,也称为无回U型以及无回反U型拓扑,两种方案在L2/L3分界之处有细微差别。
无回路U型拓扑设计方案提供了一条主上行链路,通过接入层交换机之间的内部交换机链路实现冗余,在每个接入层交换机,接入层交换机与相应的802.1Q上行链路间,802.1Q内部交换机链路上都配置了VLAN,但是汇聚层交换机没有配置VLAN以避免产生回路拓扑。由于系统中不存在回路,因此生成树不会阻塞端口。该方案主要不利之处为无法在接入对之外扩展VLAN,某些故障也有可能会产生黑洞。而如果采用在接入对之外扩展VLAN的方案,将形成一个通过汇聚层的回路,启动STP后,就会回到带阻塞链路的四点回路拓扑上。

screenshot

在无回路反U型拓扑中,在每个接入层交换机以及相应的802.1Q上行链路上都配置了VLAN,此外还扩展到汇聚层交换机之间。此时,为了防止回路,VLAN不会扩展到接入层交换机间。无回路反U型拓扑允许所有上行链路都作为主链路,为VLAN与汇聚层交换机连接提供支持,也支持VLAN扩展经过接入层,这种拓扑的不利之处在于当汇聚层交换机或者接入层交换机上行链路出现故障时,系统没有提供备用路径,因而可能形成黑洞或者是不可访问的服务器。
尽管在两种拓扑结构中都采用了无回路设计,为了确保安全,仍然需要运行STP以防止在发生线缆或配置错误时产生回路降低整个网络的性能。
虽然“U”型方案听起来比较新鲜,但该方案的影响以及局限性将使我们重新考虑传统的解决途径—L2回路接入拓扑。如图2-13所示,回路接入拓扑由一个三角形(也即V型)和一个正方形组成。

screenshot

L2回路接入拓扑与L2设计方案在STP上拥有一样的问题—网络越大,收敛时间越长,同时缺乏L2多路径支持。使用端口通道可以保留数据平面的逻辑生成树,同时也不会使冗余性及负载平衡受到影响,尽管这一方法能够克服STP的局限性,但是仅有链路汇聚也无法建成一个完全冗余的DC,因为它无法处理单个交换机故障。Cisco公司的虚拟交换系统(Virtual Switching System,VSS)和虚拟端口通道(Virtual Port Channel,VPC)通过创建一个能够在两个不同物理交换机上分布的L2端口通道接口解决了上述问题。端口通道的优化特性也足够让整个DC摆脱对STP的依赖。本书只讨论了vPC,由于VSS及vPC技术差不多,更多有关vPC的详细内容,请参考2.5.1节。
借助在L2层对帧路由、多链接半透明互联(Transparent Interconnection of Lots of Link,TRILL[21])是能够完全突破经典基于生成树帧转发的领导性技术之一。IETF希望通过TRILL与中间系统到中间系统(Intermediate System to Intermediate System,IS-IS[22])的网络路由协议一起能够替代STP,从L2角度,实现一种更灵活、可扩展性更好的未来DC设计方案。借助TRILL,所有处于像IS-IS转发状态的链路都能计算转发表,去除STP后,系统中再也不存在被阻塞的端口,有助于L2多路径(L2 MultiPath,L2MP)转发,增加了系统等分带宽[23],使得负载偏低的路径能够转发对延迟敏感的帧。
由于IS-IS属于链路状态路由协议,因此其收敛时间远小于STP,借助内部域(级别1)与外部域(级别2)路由变量的概念,网络泛洪的可能性也大大降低。此外,也更容易发现性价比最高的路径来转发帧,到达目的地的中间跳的次数也减少了,从而缩短了整体时延。TRILL提供了一种获得“STP-less”DC的途径,而vPC则提供了一条到TRILL的转换路径。目前,TRILL依然还处于研究阶段,更多有关TRILL的讨论则已经超出了本书的范围。

2.5.1虚拟端口通道:STP的改造者

借助vPC可以使物理连接两个不同交换机之间的链路,在第三方下行设备看起来就像一个单一设备一样,并使其成为一个端口通道的一部分。第三方设备可以是交换机、服务器或任意其他支持802.3ad端口通道的网络设备。只是这里概念与VSS中稍有不同,此时两个交换机仍然是相互独立的,拥有不同的控制及转发平面。本节讨论的vPC均在Cisco Nexus 7000(NX7K)以及Cisco Nexus 5000(NX5K)系列交换机上实现。
简而言之,vPC有助于对汇聚/核心层交换机进行整合/虚拟化,使它们成为一个单一逻辑实体。更多有关vPC的配置样例请参考9.6节的相关内容。
vPC要点
vPC设置包括以下部分:
vPC域:一个vPC域组合了两个vPC对等交换机,每一个vPC拥有一个唯一的域ID。
vPC对等交换机:vPC对等交换机是两个作为对等设备通过对等链路互相连接在一起的交换机,它们为vPC建立了一个单一逻辑终端,尽管只有两个交换机能够参与到对等连接中,但是这一简单特性已经足够克服经典STP的局限。
vPC对等链路:vPC对等链路是vPC交换机之间的链路,通常称作多机箱以太通道(Multichassis EtherChannel,MEC)链路,该链路属于标准的IEEE 802.3ad端口通道,带有一个被修改的STP权重。对等链路的功能包括同步对等交换机之间的MAC地址,为组播传输提供必要的支持,并负责孤立端口间的通信。
vPC成员端口:vPC成员端口是vPC中对等交换机的物理端口,一个运行中的vPC实例要求每个对等交换机上的vPC成员端口至少拥有一个端口通道。
孤立端口:vPC拓扑将非vPC节点上的端口连接设备称为孤立端口。
vPC对等心跳链路:对等心跳链路是一个运行在带外管理网络(不使用对等链路)上的逻辑链路,它提供了一个L3通信路径,用于辅助检测,确定远程peer工作是否正常。通过vPC对等心跳链路发送的帧(心跳消息),可以探测源交换机工作是否已经启动,vPC是否开始运行。数据或同步信息不会通过vPC对等心跳链路传送。系统使用对等心跳链路来处理双活故障(即vPC peer之间的peer 链路发生故障)。
Cisco光纤服务(Cisco Fabric Service,CFS)协议:CFS协议协议是为支持快速状态配置消息传送及同步而设计的一种可靠消息协议,vPC借助CFS来传递系统配置副本,完成MAC和两个vPC对等交换机之间的Internet管理协议(Internet Group Management Protocol,IGMP)状态信息的对比及同步处理。CFS协议同时还能够验证vPC成员端口的兼容性以建立端口通道,并监测vPC成员端口的状态。
如图2-14所示,SW01和SW02是两个vPC对等交换机(可以为NX7K或NX5K交换机),由它们组建了一个vPC域,通过普通的端口通道配置,将接入层交换机SW03和SW04以及服务器H2均连接到vPC对等交换机处在vPC拓扑中,负责连接非vPC节点中的设备到vPC拓扑的端口被称为孤立端口,连接到孤立端口的服务器被称为单宿主服务器,图2-14中的服务器H1和H3都属于单宿主服务器类型。H2、SW03、SW04均连接到vPC成员端口上。
说明:推荐所有接入层交换机均采用双重连接模式与vPC peer连接,如果不这样,那么那些只与一个vPC peer连接的交换机或主机将会占用对等链路宝贵的带宽资源,而在对等链路或vPC peer发生故障时,也会使得这些交换机或主机成为与网络隔离的孤立点。
STP不说再见
尽管vPC克服了STP的缺点,但并不能完全代替STP,vPC对运行在对等交换机上的生成树主要做了如下两方面改进:
vPC确保了对等链路不会间断转发行为,而备份vPC对等交换机也会将对等链路看成至主vPC对等交换机的根端口。
vPC确保了只有主vPC对等交换机才会转发vPC上的桥接协议数据单元(Bridge Protocol Data Unit,BPDU),使得从生成树角度出发,在其他连接到vPC系统或拓扑中的接入层交换机看来,两台对等交换机如同一个单一实体。这样的改变只适合vPC成员端口,当vPC成员端口上的备份vPC对等交换机接收到BPDU后,它们将通过把数据对等链路转发给主vPC对等交换机处理。

screenshot

如果某个端口通道成员发生了故障,vPC方法会采用用端口通道恢复机制而非STP,这一做法在很大程度上减少了整体收敛时间。
说明:非vPC端口或孤立端口(通常为单宿主而非双宿主)的操作与普通端口一样,采用标准STP协议,包括MSTP及快速PVST+等。vPC专有功能仅适用于vPC成员端口。

2.5.2vPC设计概要

本节从设计角度简要讨论如下vPC概念及组件:
vPC角色及权限
vPC对等链路
vPC对等心跳
vPC初始化
vPC及HSRP
vPC角色及权限
必须调用“feature vpc”命令,才能在系统中使用vPC功能,配置vPC时,首先要确定域的ID(1~1000)及主从交换机角色,角色优先级为16位整数,默认值为32 767。在vPC系统中,只有一台vPC对等交换机被确定为主交换机,另外一台交换机将会根据优先级被定义成从交换机。主对等交换机的值比从交换机的值低,因为较低的值优先级更高。代码清单2.4展示了一个vPC域及优先级配置模板。
screenshot

说明:构建vPC系统的两个对等交换机其域ID必须匹配。
vPC对等链路
对等链路为连接对等交换机的端口通道,负责所有用户自定义接入VLAN。同时,对等链路还负责传送诸如BPDU、热备份路由协议(Hot Standby Router Protocol,HSRP[24])的hello消息以及对等交换机间MAC地址同步等控制信息。如果需要实现高可用性HA,必须将对等链路配置成冗余模式。NX7K交换机中,该端口通道必须被配置成特定的能跨越两个独立10千兆以太网线卡的10千兆以太网接口模式。代码清单2.5给出了一个vPC对等链路配置模板。
screenshot

说明:连接vPC peer的端口通道(对等链路)只负责支持vPC成员端口需要的VLAN传输,如果孤立端口使用的VLAN也运行在同一链路上,一旦对等链路发生故障,孤立端口之间的通信就受到破坏。为了避免这一问题,推荐采用双重连接的服务器,一条端口通道为vPC成员端口服务,另一条端口通道连接到单个对等交换机上。
vPC对等心跳
vPC管理系统借助心跳消息来确定对等链路及远程对等交换机是否发生了故障。如果远程交换机工作状态正常(即双活模式下,即使对等链路发生故障,依然可以通过带外对等心跳链路响应心跳消息),vPC备份对等交换机将关闭其vPC成员端口,如果收不到对等心跳消息,系统会认为远程对等交换机出现了故障,此时,心跳消息的发起者将假定只有自己这方的对等交换机状态正常并负责数据转发。当对等链路或远程交换机故障解除后,系统会对在故障中获得的MAC地址重新进行同步处理并按正常状况转发。
不建议在与对等链路相关的VLAN上传递心跳消息,推荐通过路由基础设施(L3云)发送心跳信息。心跳信息包括目标IP地址(远程)、源IP地址(本地)以及负责对等链路传输的VRF[25]。代码清单2.6给出了一个vPC对等心跳链路的配置模板。
screenshot

说明:当使用冗余监测器时,NX7K交换机每一时刻对给定vPC peer上只有一个活动管理接口,因此在两个NX7K对等交换机的管理接口之间不要采用直接背靠背连接,因为很难确定在某个给定时刻哪个监测器是活动的。对于带外连接,推荐通过槽5上的监测器及槽6上的监测器的mgmt0接口,将每个NX7K对等交换机连接到管理网络(L3云)上。
vPC初始化
在对等交换机上,如果调用“vpc”命令,vPC将被配置成普通端口通道,对等交换机上的成员端口(转发端口)也会与vPC关联,vPC对等交换机之间可以交换vpc序号,两个单独的本地端口通道配置也将被vPC对等交换机绑定到分布式vPC虚拟端口上。
如果vPC及对等链路能够实现静态链路汇聚,推荐使用链路汇聚控制协议(Link Aggregation Control Protocol,LACP)以避免发生配置错误,也能提供更精确的故障恢复控制。有了LACP,因配置错误而产生的不匹配端口之间将无法建立端口通道,此时,这些端口将被归到单个(Individual,I)状态,运行常规生成树。
LACP是由IEEE 802.3ad引入到基于标准的机制,通过LACP两个交换机之间能够协商建立端口通道。使用“channel-group”命令可以完成LACP配置,接口配置参数为“active”或“passive”。为了启动通道协商,至少有一方的端口通道连接必须设置成主动模式。代码清单2.7给出了vPC及vPC成员端口的配置模板。
screenshot

说明:vPC序号不一定要与端口通道序号一致,不过为了便于管理,推荐将它们设置成一样的值。
vPC和HSRP
NX7K上的HSRP具有一个值得一提的独特功能,假定两端的对等交换机均为NX7K,将其中一个配置成主HSRP peer,另外一个配置成从HSRP peer。优化后,主HSRP peer以及从HSRP peer的转发引擎都能进行本地L3转发,这样一来不需要对现有HSRP配置做任何更改,就能在实际上得到主/主HSRP配置。HSRP控制协议依然按照主/从对模式工作,只有一个主HSRP peer响应地址解析协议(Address Resolution Protocol,ARP)请求。如果来自服务器的(双重连接模式,一个端口通道连接到vPC成员端口,另一个连接到对等交换机)某个ARP到达从HSRP peer,将通过对等链路转发给主HSRP peer。相关对等交换机上的两个HSRP接口(主/从)都可以转发可路由网络传输。如果从HSRP peer接收到了源自同一服务器的网络流,将直接转发给下一跳(假设下一跳为合法地址)设备,不需要再通过对等链路将该网络流转发给主HSRP。
说明:推荐保留vPC主peer上的默认网关,为此,需要将该vPC主peer配置成所有VLAN的主HSRP peer。

2.5.3vPC和Nexus 1000V

在大多数NX1KV设计方案中,要求端口通道能跨越多个接入层交换机,为了方便在交换机之间的跨越,NX1KV交换机提供了两种配置方式,这两种方法都不要求在上行交换机中配置端口通道:
vPC主机模式(vPC HM)
MAC绑定
vPC主机模式
在Vpc-HM模式中,NX1KV交换机上配置的端口通道被分成子群(更小的逻辑端口通道),每一个子群代表一条或多条连接一个上行物理交换机的上行链路(Eth接口),系统采用轮叫机制将VEM上的每个vEth接口(更多细节请参考2.3.3节的“VEM 交换机端口分类”中的内容)映射到一个或两个子群上。相应地,所有来自vEth接口的网络传输都通过给定子群完成,如果某个给定子群发生故障,剩下的子群也不能再使用该vEth接口,但如果最初的指定子群恢复工作,网络传输将重新转移到该子群上。
图2-15展示了两个vPC-HM样例,图的左边为两个NIC共用一条端口通道。其中两个NIC都是端口通道1的一部分,配置成vPC-HM模式,分别连接到两个上行交换机,两个NIC共用一个上行链路配置文件,通过源MAC地址散列算法,将VM的负载平衡分布到两条上行链路中。

screenshot

说明:NX1KV交换机支持17种散列算法来平衡经过端口通道物理接口的负载。这些算法分成两类:基于源的散列和基于流的散列。基于源的散列算法确保不管端口通道中有多少条链路,一个MAC地址只会向下沿着其中一条链路进行传送。
图2-15的右边为4个NIC共用两条端口通道,每一个端口通道都拥有一个链路连接到上行交换机。此时,每一个vPC-HM子群都拥有一条单独的链路,因此不需要在上行交换机对端口通道进行配置,在该样例中,负载平衡处理依然采用了源MAC地址散列算法。
如果上行交换机支持CDP消息,则可以通过上行交换机返回到CDP消息,将端口通道中连接到同一上行交换机的Eth接口自动绑定在同一子群内。如果上行交换机不支持CDP消息,或者系统需要覆盖CDP消息,也可以通过接口级配置,人为地把接口分配到特定子群中。
当多个上行链路都汇聚在NX1K交换机中的同一子群时,上行链路需要一个端口通道被配置成能够将所有这些链路绑定在一起,该端口必须要选用“mode on”命令参数。图2-16展示了另一个vPC-HM样例,这一次是4个NIC带1个端口通道,这个单独的基于vPC-HM的端口通道部署形式为将VM的负载分布到尽可能多的NIC上。此设计方案的主要优势在于VM数据传输可以利用所有4个NIC,并且能够灵活地支持基于流的散列算法。如果使用了基于流的散列,每一个上行交换机就必须配置一个端口通道,不过如果使用基于源的散列算法,就不要求采用这种配置。

screenshot

说明:基于流的散列可以使来自单个MAC地址的网络流同时分布到端口通道内多个链路上,提供了一种更精确的负载平衡方法。增加了VM可得带宽,提高了端口通道中上行链路的利用效率。
MAC绑定
MAC绑定将所有来自服务器的上行链路(Eth接口)都当做单独的链路处理,并以轮询方式为这些链路分配来自不同Eth接口的MAC地址。如图2-17左边所示,MAC绑定方法能够确保上行交换机的多个接口均看不见VM的MAC地址。如果某个上行链路发生故障,NX1KV交换机将发送一个免费ARP[26]消息来通知上行交换机,告知它从之前Eth接口所获得的vEth接口MAC地址将会被重新绑定到另外一个Eth接口上。该过程的说明如图2-17的右边部分所示。有了MAC绑定,VEM(或Eth接口)在连接上行交换机时可以不必再配置上行信息。

screenshot

相关文章
|
Java Linux 数据安全/隐私保护
华为云计算FusionCompute虚拟化平台的安装与设置
华为云计算FusionCompute虚拟化平台的安装与设置
763 0
华为云计算FusionCompute虚拟化平台的安装与设置
|
5月前
|
存储 弹性计算 调度
云计算——计算虚拟化
云计算——计算虚拟化
99 0
|
虚拟化
开源的虚拟化私有云及云管平台
免费开源的私有云及云管平台来了,除虚拟化外,还支持纳管主流的 9 大公有云及私有云平台,欢迎大家安装体验!
|
存储 缓存 前端开发
重点!!!计算虚拟化技术(HCIE云方向)(二)
重点!!!计算虚拟化技术(HCIE云方向)(二)
385 0
|
存储 监控 容灾
重点!!!计算虚拟化技术(HCIE云方向)(一)
重点!!!计算虚拟化技术(HCIE云方向)(一)
687 0
|
存储 监控 安全
带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.3弹性裸金属服务器和神龙虚拟化(一)
《弹性计算—无处不在的算力》第三章:计算产品和技术3.3弹性裸金属服务器和神龙虚拟化
525 0
带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.3弹性裸金属服务器和神龙虚拟化(一)
|
存储 弹性计算 运维
带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.3弹性裸金属服务器和神龙虚拟化(二)
《弹性计算—无处不在的算力》第三章:计算产品和技术3.3弹性裸金属服务器和神龙虚拟化(二)
271 0
带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.3弹性裸金属服务器和神龙虚拟化(二)
|
机器学习/深度学习 vr&ar 虚拟化
阿里云VGN5i虚拟化GPU服务器价格更低的GPU计算服务
阿里云推出虚拟化GPU VGN5i实例,适用于云游戏、VR/AR、AI推理和DL教学等轻量级GPU计算场景,更细粒度的GPU计算服务,阿里云百科网分享: 什么是虚拟化GPU服务? 虚拟化GPU服务是一种弹性GPU计算服务,用户可以根据业务需求选择比一颗物理GPU更小的计算资源来部署自己的业务。
1928 0