NSX干货分享·Edge传输节点和路由
笔者最近持续跟进了一个客户的NSX-T数据中心实施项目。对于用户来说,这个项目最难的地方就是实现业务网络从传统拓扑“渐进式”过渡到NSX逻辑网络。我们知道,VMware NSX-T是一款纯软件方式实现SDN架构的产品,其带给用户网络的灵活性体现在能够满足在网络拓扑中同时存在SDN拓扑和传统拓扑的需求。

 

对于新建数据中心这类项目来说,是否采用SDN架构是一个“TO BE or NOT TO BE”的简单问题。但对于一些对现网进行改造的项目来说,尽最大可能地减少对生产系统的影响,进而实现业务网络的“平滑迁移”就显得弥足珍贵了
如上图所示,目前用户的虚拟机流量完全由分布式虚拟机端口组或者NSX-T VLAN传输区域的分段来承载。管理员创建一个Overlay传输区域,以“传输节点配置文件”的方式关联vCenter上的某一个群集应用生效。在完成了包括Tier0网关、Tier1网关、Overlay分段、南北向路由等一系列配置后,就为业务从传统网络平滑过渡到NSX-T的逻辑网络创造了全部的先决条件。注意:上述所有组件的创建和生效并不会对现网产生任何的影响,自然也不会造成虚拟机的任何网络中断或者影响生产。这之后的工作,就和我之前公众号的一篇分享所描述的那样(NSX逻辑桥接不仅仅是一个L2组件),按部就班循序渐进即可。
不过,今天的主题并不是想要“炒冷饭”。而是在这个项目中,一线工程师因为【采用虚拟机版本的Edge传输节点和启用了HSRP的上游设备】遇到了一些“小小的阻力”。所以想利用公众号这个平台,和各位关注VMware NSX的朋友一同分享经验和教训。
 
✨0x01.Edge虚拟机的上联网络(端口组)配置
对于Edge传输节点(后文简称Edge)来说,至少存在三种不同的网络流量:
➀ Edge与NSX Manager之间的管理流量;
➁ Edge与其他传输节点之间的Underlay流量,该流量通过GENEVE协议封装,属于Overlay传输区域的流量;
➂ Edge与物理网络设备之间的南北向流量,属于VLAN传输区域的流量。
如果Edge采用裸金属方式部署,一般情况下它的连接方式如下图所示:

由于是物理设备之间的跳线,管理员可以非常“直观”地连接Edge与ToR交换机或者核心设备。对于虚拟机Edge来说,Edge与物理设备之间,还夹着一层ESXi上的虚拟交换机,情况就有点复杂了。对于Edge中运行的Tier0网关来说,业务虚拟机的北向流量最终会通过Tier0网关的上联接口传输到物理网络。从路径上看,这个流量至少经过了Underlay网络-Edge实例中的Tier0上联-虚拟交换机的端口组-ESXi的VMNIC适配器-物理设备这些节点。中间任何一个环节配置出现了纰漏,必然会造成南北向通信的不可达。那么,面对由ESXi承载的虚拟机Edge,管理员应该如何来进行基本的上联网络配置呢?

首先各位要清楚一点:Edge虚拟机默认情况下一共有4块vNIC虚拟网络适配器用于承载管理、Overlay传输区域和VLAN传输区域的流量。

➀ 管理流量:管理员在虚拟交换机上配置一个虚拟机端口组vPG-VLAN1001,将Edge虚拟机的第一块vNIC连接到这个端口组,就可以实现通信。(毫无难度,基本操作)

➁ Overlay流量:管理员同样可以在虚拟交换机上配置一个虚拟机端口组vPG-VLAN100,然后将Edge虚拟机的第二块vNIC连接到这个端口组。(毫无难度,基本操作)

可对于VLAN流量而言,那就有点复杂了!

很多人会说,这有什么复杂的!每一台Edge虚拟机不是2块vNIC么?每一块vNIC连接到对应的一个端口组不就好了,就像下图所示的这样。

表面上看,这种设计没有任何的漏洞。但对于Edge01这台Edge的VLAN102的流量,真的会经过vNIC3转发么?同理,对于Edge02而言,VLAN104的流量,真的会经过它的vNIC3转发么?

答案是否定的!因为在NSX-T的体系中,有一个概念叫做“传输区域(后文称TZ)”。管理员在置备或者交付Edge传输节点的时候,其实都会配置“传输区域”和“主机交换机”。

如上图所示,以Edge01举例来说,VLAN TZ的主机交换机在关联Edge虚拟机vNIC的时候,其实只关联了vNIC2。vNIC3处于“未被使用”的状态。因此,无论是VLAN101还是VLAN102的流量,都只会经过vNIC2的虚拟网卡转发到ESXi的虚拟交换机。此时,虚拟交换机的端口组就要满足同时放行VLAN101和VLAN102的流量。所以管理员应该配置一个Trunk类型的虚拟机端口组提供给Edge虚拟机的vNIC2上联。

就这个情况来说,也会有朋友提出疑问:能不能创建两个VLAN TZ,这样不就可以用上vNIC3了么?的确如此。在许多采用裸金属Edge的项目中,为了实现多上行链路冗余,的确可以采用配置两个VLAN TZ,关联Edge的两块物理网络适配器来提高利用率、提高带宽(A-A模式,开启ECMP)、实现冗余。但是在虚拟机Edge的场景下,本身的多链路冗余是通过ESXi的多上行链路实现的,因此不太需要考虑这个问题。当然,虚拟机Edge可能存在一些别的问题,这点我们后面再谈。

 

✨0x02.一种可借鉴的路由配置参考

“世上没有两片完全相同的树叶”,莱布尼茨的话放到NSX-T的项目中同样适用。不同的用户、不同的环境、不同的架构自然会有不同的配置。区别于传统网络设备的“刷配置”,包括路由在内的NSX-T的配置只是简单地点击鼠标、输入文字而已。但反过来说,很多项目的经验又是值得归纳、总结和分享的,所以晓冬想借这个机会,结合之前亲身经历的几个项目,给出一个典型的路由配置示例,为工程师提供一些建议和参考。

路由拓扑:
一个典型的NSX南北向互联拓扑通常包括Tier0网关、物理设备和路由协议。

通常情况下,出于高可用性、高利用率、高吞吐性能等考量,项目中都会采用Active-Active方式部署Tier0网关。Edge群集中的多台Edge内核中都会创建并运行Tier0网关的服务路由器(后问称SR)角色。如上图所示,两台Tier0SR将通过BGP协议与上游物理设备建立邻居关系,实现路由互通。每一台Tier0SR都会有两根上行链路,分别与上游物理设备互联。所有有状态的服务,都将由Tier1SR承载。
传输区域设计:
基于Tier0有多条上行链路,对应“Edge的不同接口与物理设备接口”的互联线路。因此至少应该配置两个VLAN传输区域,才能满足同一个Tier0SR的每一根上行链路的流量分别由两块物理网络适配器承载的要求。

每一台Edge实例,都需要配置两个主机交换机,分别关联不同的VLAN传输区域,并且使用不同的物理网络适配器来承载流量。

VLAN分段与接口配置:

因为Tier0网关合计有四根不同的网络上联,所以管理员需要配置四个分段,并且两两关联到对应的VLAN传输区域。

在完成VLAN分段的配置后,紧接着完成Tier0网关的配置。建议配置环回口用于标识RouterID和为路由故障排查提供方便。

当然,四根不同的上行链路会由两台Edge承载。换句话说,每台Edge中运行的Tier0SR实例都会有两根上行链路到不同的两台上游物理设备。

在Edge实例的命令行,管理员可以通过命令验证配置是否生效。比如下图所示的Edge01中运行的Tier0SR实例的概况:

路由协议配置:

NSX的路由配置是相当直观与便捷的。BGP的声明一般分为几个步骤:邻居关系的声明、本地源接口的声明、需要重分发的分段声明。

通常情况下,包括Tier1直连分段、负载均衡器的VIP地址、NAT的转换IP都会重分发到BGP。

而且,为了实现链路的快速收敛,需要在Tier0网关和上游物理设备配置BFD协议。

通过命令行进入到Tier0SR实例之后,可以直观地了解到每一台Tier0SR通过eBGP学习到的路由条目以及BFD会话的状态。

但是这样真的够了么?

在某一个项目中,晓冬遇到了一个紧急故障:因为用户的不规范操作触发了BUG,导致Edge群集中正常运行的所有Tier0SR全部移除了BGP邻居。这无疑会造成所有南北向流量的中断,影响到所有业务的正常运行。因此为了避免出现BUG或者人为因素造成的上述情况,管理员可以酌情增加若干静态路由。

比如Tier0SR可以增加一条默认静态路由,将去往非直连或者服务网段的流量转发到上游物理设备。同时,为了避免对通过eBGP学习到的“全零”路由产生影响,需要将管理距离调高一点,比如180(高于eBGP,低于Inter-SR iBGP)

这样,在正常情况下,Tier0SR会根据eBGP学习到的路由条目执行转发。当所有的eBGP邻居全部中断的情况下,默认静态路由就会出现在路由表中,确保南北向业务的正常互访。当然,对于上游物理设备来说,同样需要有南向的汇总静态路由。其实,在许多项目中,由于网络规模不是很大,用户会直接选择静态路由的方式来实现NSX网络与外部网络的互通。

说到这里,各位看官认为我们的路由协议的配置“完满”了么?

答案依旧是否定的。静态路由虽然简单,但是它无法像动态路由一样侦测链路状态。如果简单地使用静态路由而不考虑故障的情况,可能会造成路由黑洞。因此,对于静态路由而言,同样需要配置BFD。

比如现在Tier0SR的其中一条上行链路因为Edge的物理网络适配器出现故障而造成了中断。在配置了静态路由,但未配置BFD的情况下,上游物理设备依旧会转发到这条互联链路上,进而触发路由黑洞,造成部分南北向流量的中断。因此,动态路由/静态路由+BFD在NSX的路由协议配置中是绝对要遵循的原则之一。

最后,大家不要忘记一点。就是在同一个Tier0SR实例有多条上联的时候,一定要开启Inter-SR iBGP功能,这同样也是避免出现路由黑洞情况而做的配置。详细的说明,可以参考晓冬之前的一篇分享-NSX干货分享·一些有趣且实用的Tips。

✨0x03.虚拟机Edge环境下Tier0网关路由配置Tips

上文的路由设计与配置示例是针对裸金属Edge的,那么在面对Edge是虚拟机的场景下,是否依然适用呢?首先可以确定的是,路由设计与配置的整体思路肯定是相同的。实际上,VMware有专门的VVD文档来指导管理员进行设计与配置。比如:VLAN传输区域的流量不要配置HSRP了吧(此处应该有一张滑稽脸

)

但并不是所有用户都有客观条件去按照VVD的描述落地NSX的。实际上,晓冬参与的这个项目正式因为Edge虚拟机+上游网络设备配置了HSRP才遇到了一些问题。

我们知道,通常情况下,虚拟交换机至少会使用两块网络适配器作为上联,连接到VLAN或者Underlay网络。虚拟机Edge用于VLAN传输区域的vNIC2和vNIC3连接到虚拟交换机上的端口组。如上图所示,红色的链路表示Tier0SR的某一个实例用于和某一台上游网络设备互联的线路。当Edge是裸金属的情况下,其实Tier0SR的上行链路与裸金属Edge的物理网络适配器是可以通过主机交换机实现Mapping的。但对于虚拟机Edge来说,红色的流量到达虚拟交换机之后,由于Edge和ESXi的物理网络适配器没有任何的对应关系,可能会有50%的流量到达另一台物理网络设备。这是裸金属Edge场景下不会遇到的问题。

当然,解决问题的办法还是多种多样的。比如手动指定特定的端口组,只使用固定的某一块网络适配器。

如此,流量就只会转发到与对应物理设备互联的网络适配器上。同时单个特殊端口组的配置并不会影响虚拟交换机和其他端口组。但这种方式仅适用于物理服务器(ESXi)直连网络核心的情况,如果中间有服务器区域的接入交换机或者服务器是刀片式服务器(真正连接网络设备的是刀箱,刀片和刀箱上联中间存在“看不见的”背板交换机),那就无能为力了。

在这个项目中,用户就遇到了这样的情况。无论是ESXi还是NSX,都无法控制虚拟机Edge的VLAN TZ上行流量走向。好在办法总比困难多!基于用户的上游网络设备配置了HSRP,因此Tier0网关可以相对应地做出一些改变来实现南北向流量的互通。

对于Tier0网关来说,其实只需要配置两根上行链路。由于该用户采用静态路由的方式来实现南北向互通。那么对于10.0.0.4/29这个接口而言,路由条目的下一跳地址设置为10.0.0.1;同样地,对于10.0.0.12/29这个接口而言,路由条目的下一跳地址设置为10.0.0.9。这样,无论红色的流量究竟被转发到哪一台上游物理设备,都可以“找到”10.0.0.1这个地址;反之无论去往NSX的流量被转发到哪一台上游物理设备,都可以找到10.0.0.4这个地址。只是这种做法可能不太符合最佳实践罢了。

在说明Tier0网关路由配置的0x02章节,晓冬提到无论是动态路由还是静态路由,为了实现链路的快速故障切换,都应该配置BFD。但对于上述这个用户而言,虽然静态路由的下一跳地址写成了HSRP的VIP地址,解决了VLAN TZ流量的转发问题。但VIP地址如果作为BFD的对端地址,BFD会话是无法建立的,最终会导致包括全零路由在内的静态路由条目的丢失,同样会造成南北向业务的中断。在查阅了文档之后,通过在NSX的Tier0网关配置静态路由+BFD,同时在上游思科的网络设配配置IP SLA之后完美解决了这个问题。

 

✨0x04.说点什么

在经历了多个NSX的项目之后,越来越觉得NSX数据中心是一款既需要了解原理更需要实践和积累的产品。比如在涉及分段和虚拟交换机的时候,需要熟悉MAC表、ARP表和VTEP表的更新和工作流程,才能在项目中遇到问题情况下,运用原理知识去针对现象提供思路帮助排障。相比之vSphere的“下里巴人”或者vRealize Suite的“阳春白雪”,NSX更像是一曲永不休止的乐章,充满着吸引人不断深入评鉴的魅力。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇