🐾 上期分享遗留问题的测试结果
在上期的分享中，笔者“天真”地想当然：如果承载延伸Tier0和Tier1网关的Edge集群与承载RTEP跨数据中心Overlay传输的Edge集群是不同的集群，那么就能将南北向业务和跨数据中心的东西向业务进行“合理的拆分”。当笔者信心满满地完成了edge-13边界传输节点的创建以及Edge集群的配置，准备验证想法的时候，被现实无情的打脸：
看来似乎无法对这两个业务进行拆分，这是上期遗留问题的测试结果。
🐾 测试前的准备工作
言归正题，在上期分享中笔者聊完了满足本地输出的几种情况，今天再来说说有Tier1SR的场景，并以此可以推断出Active-Standby模式的延伸Tier0网关下的灾难容错和切换情况。
首先，对于有Tier1SR的场景来说，流量默认会经过其中一个数据中心的Edge传输节点后再继续转发。因此，在这种场景下讨论Standby站点的Edge传输节点故障似乎“没有什么意义”；当然Edge节点故障一定会造成跨数据中心Overlay流量的中断，这点毋庸置疑；再者，对于Standby站点的Tier0网关来说，只会有南向从外部访问NSX网络的流量，不会有本站点北向访问外部流量的经过Standby站点的Tier0网关转发，因此讨论Tier0上联中断对于Standby站点来说似乎也“没有什么意义”。最后，我们还是要用实践来验证我们的猜想。
今天的分享依然基于下图所示的拓扑：
位于Secondary DataCenter（后文简称SDC）的web-21虚拟机在当前场景下尝试访问3.3.3.3这个互联网地址的时候，一定会经过自己SDC的出口，这是“本地输出”的典型南北向网络走向。
现在通过配置更新将Primary DataCenter（后文称呼PDC）切换为“主站点”，更新的方式很简单：为延伸的Tier1网关分配Edge集群，如下图所示：
更进一步，就edgecl-primary这个Edge集群来说，edge-11被定义为首选，edge-12被定义为次选；同样地，对于edgecl-secondary这个Edge集群来说，edge-21被定义为首选，edge-22为次选。
在完成上述配置后，再次访问web-21命令行，使用traceroute命令验证南北向数据流走向：
可以看到，web-21所有的南北向流量全部经过了PDC的网络设备进行转发；而位于PDC的web-11、web-12以及db-11的南北向流量保持之前由本地的网络设备转发不变；因此当前的环境已经不再是“本地输出”的架构，而是全部由PDC的Tier0网关承载所有与物理网络互联的南北向流量。
🐾 中断SDC所有Tier0网关上行链路
毫无疑问，这是一次“没有意义的测试”。因为位于SDC Edge集群的延伸Tier0网关SR实例全部的VLAN传输区域的上行链路不会承载SDC的NSX网络与外部网络的南北向流量。证明的方式也很简单，有兴趣的朋友可以自己去尝试一下：
- 使用web-21长ping目标地址3.3.3.3，因为Tier1SR实例存在的关系，流量一定是从PDC的Tier0网关向上转发；
- 然后中断SDC的Edge传输节点所有的VLAN传输区域上行链路。
如果中断SDC的Tier0网关上行链路会对南北向流量产生影响（无论是切换还是中断），那么长ping的数据包一定会有丢包。如果没有任何的丢包或者异常的高延迟ICMP回包，那说明根本没有受到影响。
🐾 SDC所有Edge传输节点故障
这个测试和之前“本地输出”场景下PDC传输节点故障的结果相同，跨数据中心的东西向流量会受到影响，从而导致整体的SDC南北向流量同样发生中断；在本次分享中，同样不多做赘述。
🐾 中断PDCTier0网关上行链路
接下来正式进入“有参考意义的测试”，如果PDC站点出现了NSX相关组件的故障，那么根据故障的情况不同，可能会对NSX Federation网络产生一些影响（无论是切换还是业务中断）。
最常见的就是PDC站点Tier0网关的上行链路出现了中断。如下图所示，这是正常情况下PDC和SDC的Tier0网关上行链路情况：绿色实线表示“活动”的链路，蓝色虚线表示“连接正常但备用”的链路。
毋庸置疑的是，以下几种情况不会造成任何的南北向网络中断：
- 中断任意一根上行链路，模拟硬件设备网络接口故障或者线路物理中断；
- 中断任意两根上行链路，模拟一台Edge传输节点整机故障或者一台上游物理核心整机故障或者“该巧不巧”同时出现了两个设备的网络接口故障等；
- 中断任意三根上行链路，模拟机柜电源故障后导致同一个机柜中的一台上游物理核心设备以及Edge传输节点双双整机故障。
这其实并不涉及Federation特有的知识点，而是普通NSX网络冗余特征。但是当出现4根上行链路同时故障的时候，情况可能就不一样了。
🐾 同时中断所有的PDC Tier0网关上行链路
首先来看看如果PDC所有上游物理核心出现故障的场景，如下图所示：
PDC所有的南北向出口“全部封死”，但是tier0SR in Edge-11以及tier0SR in Edge-12依旧是正常运行的，所有的inter-SR iBGP链路也没有受到影响。
如下图所示，笔者关闭了模拟上游网络核心的VYOS虚拟机电源。
在Edge-11传输节点的命令行，笔者查看了tier0SR in Edge-11的路由表：
还记得169.254.32.6以及169.254.32.7么？这是tier0SR in Edge-21以及tier0SR in Edge-22的inter-SR iBGP链路的接口地址。看样子到达PDC Edge传输节点内运行的延伸Tier0SR实例的流量，应该会被转发到SDC后继续下一跳的路由。也就是说，南北向流量应该不会中断。
但现实又给了笔者“一记响亮的耳光”......（等等，为什么说又？）
无论是位于PDC的web-11和SDC的web-21均无法访问外部网络；但是NSX内部网络的互通不受到影响。
笔者在web-21虚拟机使用traceroute命令查看网络的走向，如下图所示：
数据包经过Tier1网关与Tier0网关之间的inter-Tier链路后如同“石沉大海”，杳无音信。
而在web-11虚拟机使用traceroute命令查看网络的走向，可以更明显地看到数据包被转发到了tier0SR in Edge-21以及tier0SR in Edge-22。
接下来，笔者做了一组PING和TRACEROUTE测试，发现“故障点”在Tier0SR与上游物理网络设备之间，如下图所示：
根据Traceroute命令的反馈结果，笔者在当前拓扑上描绘了数据包北上的路程：
10.10.1.211访问10.255.2.1（tier0SR in Edge-21的物理上联设备）
1> ESXi内核中的Tier1DR网关地址10.10.1.254
2> Tier1DR下一跳Tier1SR in Edge-11
3> Tier1SR in Edge-11下一跳Tier0DR in Edge-11
Tier0DR in Edge-11下一跳Tier0SR in Edge-11
4> Tier0SR in Edge-11通过interSR iBGP链路到下一跳Tier0SR in Edge-21
5> ？？？（应该是到达了上游核心设备10.255.2.1接口）
那么在10.255.2.1这台设备上尝试ping虚拟机web-21又是如何的情况呢？
结果如上图所示，由于上游路由设备并没有通过eBGP学习到NSX Federation的路由，因此对于目的地址为10.10.1.0/24的数据包将命中默认路由条目继续北向转发，这造成了PDC所有Tier0SR上行链路中断后，最终引起NSX网络所有南北向流量中断结果的直接原因。
那么接下来摆在管理员面前需要讨论的问题有两个：
第一个问题，为什么上游设备没有学习到NSX网络的路由？
首先可以排除是eBGP本身的配置问题。因为在满足“本地输出”的场景中，SDC的路由是完全没问题的。且通过Global Manager（后文简称GM）同样可以验证这个说法。
因此造成无法学习到的原因还是因为“活动的”Edge没有切换到Edge-21以及Edge-22上，毕竟目前Edge-11和Edge-12还是正常的。
第二个问题，能不能通过一些方式来解决问题？
笔者于是简单尝试了一下，比如专门给非主站点的其他站点上游网络设备添加静态路由。
接着，分别在web-11和web-21尝试进行PING包测试，结果如下：
可以看到在添加了静态路由后两个数据中心的web-11和web-21都可以正常访问外部网络了。
现在笔者将PDC的上游设备重新恢复开机状态。
如下图所示，所有的流量全部恢复到经过PDC的Tier0SR进行南北向转发。
总结来说，如果位于PDC的物理核心出现了故障，默认情况下南北向网络会出现中断。管理员可以通过在其他站点（如SDC）添加静态路由来避免中断情况的发生。
再来看看如果PDC所有Edge网络出现故障的情况。
毫无疑问，如果Edge集群的所有节点都出现故障，那么跨数据中心的Overlay网络一定会出现中断。对于PDC站点来说，包括跨数据中心的东西向和南北向流量在内的几乎所有网络可达性都会出现“灾难”。
🐾 中断活动Edge传输节点
我们知道对于有Tier1SR实例的场景而言，真正的Active实例只会存在一个Edge传输节点中。在笔者的环境里，这台“天选之节点”被笔者设置为Edge-11，接下来笔者将关闭Edge-11的电源。
经过测试可以确认两个数据中心虚拟机的南北向流量总体并没有受到影响。
虽然从TraceRoute的路径上看不出任何切换的变化（因为所有Tier1SR的Downlink地址是同一个），但可以确信的是，目前Tier1SR实例已经由Edge-12来承载。
在PDC的Local Manager（后文简称LM）管理界面上可以看到目前的活动节点已经是Edge-12。
由此可见，处于活动状态的Edge节点出现故障的时候，Federation会根据预先定义的顺序自动完成Tier1SR实例的切换，这并不会影响业务。
🐾 计划内的停机维护
上述所有的情况以及上期分享的“故障场景”均为计划外的停机维护。可以看到除了Edge集群全部故障外，其他计划外的停机维护都能通过Federation自身的冗余机制或者人为介入的方式实现自动的快速切换。在本篇的最后，我们来谈谈计划内的停机维护。所谓计划内的“停机”维护，可以理解为因为主客观的原因，管理员需要将当前活动的站点（如本示例中的PDC）切换到备用站点，而将备用站点中的某一个（如本示例中的SDC）切换到活动站点。在开始最后一次测试之前，笔者首先恢复Edge传输节点Edge-11。
如下图所示，因为笔者设置了故障切换模式为“主动”，因此当Edge-11开启电源并正常启动后，原先激活在Edge-12传输节点上的Tier1SR实例将重新回到Edge-11传输节点。
在PDC的LM界面，可以看到Tier0SR实例已经切换回Edge-11传输节点。
接下来，笔者将手动执行切换操作，以测试“计划内的停机维护”。操作方法非常简单，将Tier1SR实例的活动站点从PDC的Edge集群切换到SDC的Edge集群；系统会提示切换操作会造成网络中断。
在笔者完成切换后，长ping的两台虚拟机web-11和web-21均发生了短暂的网络中断（丢包）；但中断都仅限于南北向流量，跨数据中心的东西向流量并没有发生中断。这说明Tier1SR实例已经完成了切换，现在活动的实例运行在SDC的Edge-21传输节点中。
在两台虚拟机的命令行使用traceroute命令验证南北向流量走向。其中位于SDC的web-21虚拟机将变成“本地输出”。
而位于PDC的web-11虚拟机会通过跨数据中心的Overlay链路，从tier0SR in Edge-21或者tier0SR in Edge-22实现自身南北向流量的路由与转发。
上述就是“计划内的停机维护”场景下NSX网络流量的变化情况。
至此，所有的测试项全部完成。
写在最后
总结来说利用NSX网络本身的冗余性已经可以覆盖大部分故障场景下继续满足可用性的要求。对于满足“本地输出”的场景来说，因为所有站点的Tier0SR与上游网络设备之间在配置了动态路由协议的情况下，默认就能学习到路由；当出现站点级物理网络核心故障的时候，Federation会自动进行切换，确保南北向流量的连续性。而对于其他不满足“本地输出”的场景来说，默认情况下除了主站点外的其他站点上游物理核心无法通过动态路由协议学习到NSX网络，因此当Edge集群本身正常的情况下，就会出现南北向流量的中断；但这完全可以通过添加静态路由+BFD的方式相对完美地解决问题。
