🐾 环境描述
在上期的分享中，笔者通过演示用例说明了Federation架构下想要实现“本地输出”的需求是需要满足一定条件的：
- 。延伸的Tier0网关必须以Active-Active的方式在多个数据中心（位置）部署；
- 。不能使用Tier1网关来承载诸如负载均衡、网络地址转换等有状态的服务；
- 。所有全局Overlay传输区域下的全局分段可以连接在延伸的Tier1网关或者Tier0网关之上。
但不满足上述条件的其他一些网络拓扑虽然也能享受Federation带来的优势和便捷，但无法实现本地输出。鉴于这两种截然不同的南北向流量模型，接下来的分享将以此两种不同的场景作为对象分别进行阐述。今天的分享将只针对“本地输出场景”进行分析。下面给出笔者环境的简单拓扑：
本次用例涉及四台Federation网络环境中的虚拟机，分别是：位于同一个位置的web-11、web-12、db-11；以及另一个位置的web-21；其中web虚拟机全部连接在同一个全局Overlay分段上，db虚拟机连接在另一个全局Overlay分段上，所有分段的网关全部位于同一个延伸的Tier1网关之上。
🐾 本地输出场景-Tier0上联中断
在笔者的环境中，两个数据中心（位置）的延伸Tier0网关分别有2根上行链路连接到不同的物理核心（VYOS模拟）。换言之，每一个数据中心的Tier0网关与上游物理核心之间的可用连接数分别是2+2=4根。接下来笔者将陆续中断Tier0上联，来验证东西向和南北向流量是否会出现走向变化。
🐾 中断1根Tier0上联
第一个测试：中断10.255.1.0/30这一根链路，模拟以下几种场景：
1. Edge-11裸金属Edge传输节点网口、网线故障；
2. 物理核心与Edge-11裸金属Edge传输节点的网口、网线故障。
通过上图不难发现，这种故障场景下的云网络连通性不会有“灾难”式的影响。在Underlay网络没有故障点的情况下，本站点之内与远端站点之间的Overlay通信不会受到Tier0上联中断的影响。而所有到达tier0SR in Edge-11的北向流量依旧可以通过10.255.1.8/30这根上行链路继续北向转发；反之亦然，所有到达10.255.1.1/30所在上游物理核心的南向流量依旧可以通过10.255.1.12/30这根下行链路继续南向转发。
从tier0SR in Edge-11的路由表上观察默认路由就能得出上述结论。
可以看到与下方正常状态下的路由表对比，有一条默认路由消失了；对应的上行链路就是10.255.1.1。
🐾 中断2根Tier0上联
中断2根Tier0上联有两种情况，第一种情况同时中断10.255.1.0/30和10.255.1.12/30两根链路，这是模拟以下几种场景：
1. Tier0SR所在Edge传输节点的网口、网线故障；
2. 上游物理核心设备整机故障。
当上游物理核心整机故障的时候，在配置了BGP+BFD的笔者环境中，路由会快速收敛，不会有南北向流量被转发到这台物理核心上；如果只是对应的网口、网线故障，那么对于Tier0网关来说，由于路由表中指向这台物理核心的路由会全部“消失”，所以自然不会有北向流量被转发到这台核心；而由于10.255.1.16/30这根iBGP链路的存在，所有转发到这台核心的南向路由都会经过这根链路被转发到对应的10.255.1.18/30这台核心后，再南向转发到Tier0网关。综上所述，第一种情况下的各类流量并不会发生“中断”。第二种情况同时中断10.255.1.0/30和10.255.1.8/30两根链路，这是模拟以下几种场景：1. Tier0SR所在Edge传输节点的网口、网线故障；2. Edge-11传输节点整机故障。如果只是对应的网口、网线故障，那么在tier0SR in Edge-12正常运行的情况下，总体流量不会发生中断的情况。
上图是当前故障场景下的tier0SR in Edge-11的路由表，可以看到当有北向转发的流量到达这台已经中断2根上行链路的Tier0网关时，会通过Inter-SR iBGP链路被转发到相同数据中心的另一台可用的tier0SR in Edge-12。
但如果是Edge-11整机故障，事情就会变得不太一样。我们知道Edge-11除了承载tier0SR in Edge-11的南北向流量外，还会承载跨数据中心的全局Overlay分段流量。如下图所示，当web-11尝试与web-21通信的时候，会经过Edge-11的RTEP进行封装和传输；因此Edge-11的整机故障可能会影响跨数据中心Overlay流量。
当笔者关闭Edge-11传输节点的电源模拟整机故障后，可以看到Primary DataCenter（后文简称PDC）的南北向流量并没有影响；而且由于Edge-11的整机故障，PDC的延伸Tier1网关实例只会将北向流量转发到tier0SR in Edge-12，通过在web-11虚拟机使用traceroute命令可以清楚地看到这个变化。
而对于跨数据中心的Overlay流量来说，因为Edge-12也可以承载这类流量，因此总体的网络连通性也不会受到影响。
在PDC的Local Manager Edge传输节点状态上可以清楚地看到这个状态。
综上所述，当存在2根上行链路中断的场景下，无论是东西向还是南北向的流量均不会有影响。
🐾 中断3根Tier0上联
第三个测试，同时中断3根Tier0上联，这是模拟以下几种情况：1. Tier0SR所在Edge传输节点的网口、网线故障；2. Edge-11和上游网络核心设备位于同一台机柜，机柜出现了电源中断。
通过对前两个测试的分析，相信各位看官不难得出“在这种场景下，所有流量均不会受到影响”的结论吧。
🐾 中断4根Tier0上联
其实真正严格意义上涉及到“Federation灾难切换和冗余”命题的，是第四个测试。
出现这种场景的可能性是多种多样的，如果笔者说“巧了，就Edge-11和Edge-12对应的那四个口出现了故障或者网线物理中断”，各位看官大概也不会相信吧，虽然这种可能性是存在的。客观来说，这类故障通常会是以下三种情况：
1. 上游物理设备故障
2. Edge传输节点故障
3. 站点整体故障
接下来，笔者就逐条来分析故障场景下的网络流走向变化情况。
首先，笔者关闭上游物理设备电源（两台VYOS虚拟机）。在Tier0SR的路由表上可以看到原先的南北向路由发生了变化。
可以看到，所有原先指向上行网络核心的路由（包括默认路由）全部指向远端数据中心Secondary DataCenter（后文称SDC）的Tier0SR实例；这是否意味着所有本地数据中心NSX网络承载的虚拟机北向流量依旧可以通过远端数据中心继续转发？
笔者在web-11上通过traceroute命令验证了这个猜想：
可以看到访问互联网3.3.3.3的流量即使到达了tier0SR in Edge11或者tier0SR in Edge12，也会经过inter-SR iBGP链路被转发到tier0SR in Edge21或者tier0SR in Edge22，再继续北向转发，如下图所示：
而跨数据中心的Overlay流量因为Edge-11以及Edge-12依旧正常运行，RTEP的封装和解封装并不会受到影响，因此此类流量不会发生中断。
不过对于经过上游物理核心南向转发的流量来说，这些流量到达上游物理核心后，没有其他备用的路由继续南向转发，因此此类流量就会发生中断。
接着，笔者开启上游物理核心，再关闭Edge-11和Edge-12两台边界传输节点的电源。
显而易见的故障是跨数据中心Overlay流量一定发生了中断：
因为实现了“本地输出”的关系，SDC的南北向流量并不会受到影响。
那么PDC的虚拟机南北向流量是否受到了影响呢？
要知道对于源是SDC目的是PDC虚拟机的流量来说，虽然可以经过SDC的Tier0网关被转发到NSX网络，但是因为Edge-11和Edge-12都出现了故障，最后的跨数据中心Overlay流量无法被转发，所以必然会受到影响。（笔者没测试RTEP单独由额外的Edge集群承载的情况，因为环境的资源基本消耗光了，得过一段时间再看看能不能腾出点资源部署台Edge测试一下）基于上述逻辑，不难得出在Edge-11和Edge-12均出现故障的情况下，所有可能的备选路由因为都需要经过RTEP封装和解封装，因此所有南北向流量均会影响。
那么在这种情况下，如何快速恢复业务呢？
最直接的方法就是尽快通过替换-重装，或者其他方式完成Edge-11和Edge-12的恢复。
最笨重的方法就是临时将Federation架构改成Multi-Site架构，新建一个全新的非延伸的Tier1网关；不过这完全是以跨数据中心Underlay链路MTU不低于1600且L3连通性并没有发生故障为前提的。
当然还有一个轻松的方法，就是利用管理的L3链路，将PDC的虚拟机迁移到SDC的vCenter，从而继续享受“本地输出”带来的便捷。
最后的一种场景，是PDC整体发生了故障，那么结果是显而易见的......
🐾 本地输出场景-跨数据中心L3网络中断
对于跨数据中心L3网络中断来说，可以分为三类情况：
1. 管理网络L3中断；
2. 承载跨数据中心Overlay流量的L3 Underlay网络中断；
3. 数据中心之间的其他网络链路中断。
🐾 管理网络L3中断
我们知道，在Federation架构下的跨数据中心的管理/系统流量包含以下几种类型：
vCenter实例之间的流量，当跨数据中心之间的L3网络中断之后，管理员访问一台vCenter Web UI将会看到与另一台vCenter实例之间的连接中断这类提示。但这本身不会影响整体平台的运行，除非有应用与之强关联；比如两个数据中心之间启用了SRM容灾解决方案；与此同时，跨数据中心的vMotion也会失败，这也是管理网络L3中断的一些影响。
Global Manager（后文简称GM）主备集群之间的流量，GM和Local Manager（后文简称LM）集群之间的流量；这类属于管理平面与控制平面的流量，同样不会对业务产生影响。对于每一个站点来说，只要能确保自己的LM与传输节点之间的网络可达不受到影响，就不会出现业务中断的情况。
综上所述，管理网络L3的中断不会对业务产生显著的影响。
🐾 跨数据中心Underlay网络中断
这类网络中断对于Federation架构来说，算是一种近乎致命的影响了。在之前分析“Edge-11和Edge-12同时故障的场景”中，笔者已经提到过，因为跨数据中心Underlay网络承载的是经过Edge传输节点RTEP封装和解封装的流量，因此这类网络中断肯定会造成NSX网络连通性的巨大问题。在笔者的环境中，此时位于SDC的web-21虚拟机将无法访问PDC的db-11虚拟机。对于SDC站点来说，web-21与db-11共同对外提供的业务将出现“数据库不可达”的情况，业务因之出现了停摆。不过好在web-11和web-12能继续对外提供业务访问，在使用NSX Advanced Loadbalancer或者其他ADC作为全局负载均衡的条件下，总体的业务不会受到影响。同时，如果管理员能够数据库只读等方式，通过同步机制在SDC的主机传输节点上部署一台db-21，那么依旧可以实现业务的冗余性。因此，跨数据中心Underlay网络中断虽然会造成东西向严重的网络不可达，但可以通过其他形式进行弥补。
🐾 跨数据中心其他网络链路中断
通过之前对tier0sr in Edge路由表的分析，各位不难发现：所有另一个数据中心站点学习到的路由条目，对于本数据中心来说都会经过inter SR iGBP链路进行转发。以下图为例：
在tier0SR in Edge21以及tier0SR in Edge22两个延伸Tier0网关的路由表上，都会学习到2.2.2.2/32这个路由，这是上游网络设备通过eBGP宣告给Tier0网关的。
那么对于tier0SR in Edge11和tier0SR in Edge21来说，2.2.2.2/32的路由就会被inter SR iBGP链路转发到远端的Tier0SR实例，下方的tier0SR in Edge11的路由表印证了这个说法。
因此通常情况下，除了管理网络、跨数据中心Underlay网络故障外，其他的网络故障不会对Federation业务产生不利的影响。
🐾 本地输出场景-小结
总结来看，在满足“本地输出”前提下，出现以下几种情况时，NSX云网络的东西向以及南北向流量可能会受到影响。某一个站点Tier0网关上游所有的网络设备全部出现故障，此时无论是站点内还是站点间的东西向流量无影响，故障站点的北向流量会经过inter-SR iBGP链路到达另一个站点的Tier0网关后向北转发。故障站点的Tier0网关不会收到任何南向流量。其他站点访问故障站点NSX云网络的流量均会通过跨站点的Underlay网络转发（前提是这个网络不在上游网络设备上）。
某一个站点用于跨站点RTEP封装的Edge传输节点全部出现了故障，如果该Edge传输节点本身不承载Tier0网关，那么各自站点的南北向流量不会受到影响；反之南北向流量中断。而同站点内的东西向流量不会受到影响（因为本地输出没有Tier1SR实例）；但跨站点的东西向流量中断。某一个站点全部出现故障的时候，毫无疑问所有东西向、南北向流量均会受到影响。
🐾 写在最后
经过本次分享，相信各位对满足“本地输出”的Federation故障切换应该有了充分的认识了。其实Federation架构的故障场景基本上与普通NSX架构的故障场景产生的结果相类似。南北向的可用性取决于Edge传输节点（Edge集群）的稳定性，因此在设计部署Edge传输节点的时候，管理员应该尽量选择满足兼容性的硬件选型，并且充分考虑吞吐合理规划Edge（虚拟机）规模。同时，笔者还是“盲目”相信Tier0SR与上游物理设备的|X|型连接能提供最高的可用性，只要有一根链路是正常的情况下，本地的总体南北向网络可达不会中断，只是吞吐会受到一些影响。普通NSX架构的Tier0网关上游设备出现故障的时候，所有的南北向流量均会中断，而Federation很好地弥补了这个缺陷。不过当RTEP所在的Edge集群出现问题的时候，NSX网络的跨数据中心L2互访同样会出现问题，这是MultiSite架构不会遇到的情况。
未来的几篇公众号分享，笔者计划一来是把有Tier1SR实例的故障切换情况与各位看官做个阐述；二来自己已经搭建好NSX Advanced Loadbalancer和Opencart开源电商网站演示用例，想好好学习并实践一下AVI的全局负载均衡和弹性伸缩功能。不过，笔者估计需要不少时间才能吃透自己并不擅长的东西，期待下次的见面吧~
