熟悉NSX的朋友一定知道，NSX的流量可分为东西向和南北向。简单来说，东西向流量是同一个应用或者同一个租户的工作负载对象之间的流量；南北向流量通常是NSX逻辑网络与数据中心物理网络之间通信的流量。因此，今天笔者分享的Federation架构下跨数据中心L3网络就一定会涉及到相关流量类型。
01.采用两层网关架构的建议
无论是Federation架构还是Multisite架构，亦或是Standalone的NSX路由，都离不开Tier1网关和Tier0网关。
对于NSX逻辑网络而言，一定会包括Tier0网关。
在只有Tier0网关的设计架构下，它承载了以下工作：
-
通过静态路由或者动态路由协议与物理网络实现南北向的交互；
-
借助NSX的VDRB模块实现工作负载的东西向流量的转发。
如上图所示：
虚拟机连接到Overlay传输区域的某一个分段，这个分段本身连接到Tier0网关并且被定义了网关地址。此时Tier0网关就承载了这台虚拟机及其所属分段与其他Overlay传输区域分段和虚拟机之间的东西向流量转发的功能。
我们知道，Tier0网关是由服务路由器（Service Router，简称SR）以及分布式路由器（Distributed Router，简称DR）两种角色组成的，承载东西向流量转发的是DR角色。在只有Tier0网关的简单架构场景下，Tier0DR实例除了会在Edge传输节点内出现外，也会出现在ESXi的主机传输节点上，这一点可以通过命令行确认：
# nsxcli
> get logical-routers
通过上文的显示结果不难看出，在笔者环境的ESXi主机传输节点内核中，运行了一个UUID（尾号fbc5）的DR实例（VDR UUID）。但无法明确标注这个DR实例究竟是Tier1网关还是Tier0网关。如果管理员想明确知道这个实例究竟是Tier0还是Tier1网关，需要使用相同的命令在Edge节点上进行查看。
回到今天分享的主题本身，其实在笔者为用户设计NSX逻辑网络的时候，更多地会倾向于设计Tier1+Tier0两层架构来实现更为灵活的虚拟云网络搭建和交付，原因有三：
❆ 两层架构更适用于多租户环境
每一个租户都是一个独立的Tier1网络（所有分段连接到对应租户的Tier1网关），Tier1网关和Tier1网关之间的网络可以受到NSX的管控，允许IP地址重叠（通过SNAT、负载均衡实现出向和入向访问），从整体架构上更加具有可管理性和安全性。
❆ 两层架构更灵活，兼顾有状态服务和等价多路径需求
Tier1和Tier0网关都可以承载诸如NAT、负载均衡这类常用的“有状态的服务”，这些功能都是由对应网关的SR角色来实现的。但Tier1和Tier0的SR也有一个巨大的不同之处：Tier0网关实例（其实就是T0SR角色实例）是支持Active-Active以及Active-Standby两种模式的，而Tier1SR角色实例仅支持Active-Standby一种模式。对于想要激活有状态服务的场景，无论是将其运行在Tier1还是Tier0SR实例上，均要求该实例必须是AS模式，这是有状态服务的需求。对于用户来说，无论是虚拟机还是裸金属的Edge传输节点，都至少会部署2台以上。一方面是因为设计必须满足高可用性，另一方面也希望利用等价多路径ECMP来提高吞吐（多台Edge传输节点的Tier0SR实例同时承载南北向的出入流量），而ECMP仅被AA模式支持。既然如此，Tier0网关采用AA模式以满足ECMP的需求，Tier1网关采用AS模式以满足有状态服务的需求，这种两层架构可以很好地适应这种普遍存在的场景。
❆ 两层架构更贴近云的自动化场景
笔者之前分享过一篇VMware vRealize Automation的随笔【一起来描绘vRealize Automation的复合蓝图】。一直以来，笔者始终认为想要真正最大化发挥虚拟云网络为用户带来的便捷，一定需要结合诸如vRA这样的云自动化解决方案。对于类似NSX+CMP的场景来说，编排器Orchestrator会为提交申请的用户自动创建NSX网络提供工作负载连接。因此采用两层架构能更好地明确服务边界：
对于IT管理员来说，他们更像是运营商，只需要负责Tier0网关的交付和运维（包括南北向路由、租户间网络策略以及边界防火墙）；
对于租户来说，编排器为他们创建Tier1网络并连接到Tier0网关，实现内部东西向互通外，也实现了与外部网络的南北向互通。因为是相互独立的Tier1网络，自然可以实现上文讲到的其他两点设计考量。
因此笔者为大家分享的Federation架构会采用Tier1+Tier0两层实现L3互通，这是真正开始动手“实现分布式路由”的重要前提。
02.分布式路由的实现
经过了重重铺垫，接下来笔者就给出Federation架构下使用Tier1网关实现跨数据中心L3网络互通的配置步骤。
根据VMware官方文档的建议，在创建Tier1网关之前应该优先创建Tier0网关以确定“跨度”，所谓的跨度其实就是指Tier0网关延伸所覆盖的Location位置，在笔者的环境中这个跨度包含Primary DataCenter和Secondary DataCenter。
⚝ 访问Global Manager，创建Tier0网关：
最先需要定义的是Tier0网关的名称，笔者通常习惯采用易于管理和识别的命名方式，比如“t0-gw-aa-global”，意味着这是一个全局环境使用（Federation架构）下的AA模式的Tier0网关。
默认的模式是活动-活动，也就是A/A模式；在双活模式下，流量在所有位置的Edge节点之间进行负载均衡。在主备模式下，选举出的 Edge 节点处理每个位置的流量。如果活动节点发生故障，备用节点将变为活动状态。
为了实现ECMP和Local Egress，选择A/A作为HA模式，同时勾选“将所有位置标记为主站点”。
接下来需要为Tier0网关定义延伸的跨度。在本示例中，依次选择Primary DataCenter和Secondary DataCenter；随后在弹出的Edge集群下拉菜单中选择已经做好RTEP等定义的Edge集群（本示例中依次为edgecl-primary和edgecl-secondary）,因为已经勾选了“将所有位置标记为主站点，”因此模式固定为“主”和“主”。
⚝ 确认上述设置无误后，点击保存完成Tier0网关的创建工作。
⚝ 访问Global Manager，继续创建Tier1网关（其实这一步在之前跨数据中心延伸分段被创建的时候就已经做过了）。
为Tier1网关定义一个便于管理和辨识的命名，如t1-gw-as-global；
可以看到Tier1网关的HA模式仅限于活动-备用；
Edge池分配大小选择【路由】；关于其他选项的说明会在后续的连载中给出。
⚝ 确认上述设置无误后，点击保存完成Tier1网关的创建工作。
接下来，我们将创建三个全局Overlay传输区域的分段，并将其连接到刚刚创建的Tier1网关之上。这三个分段分别是：
❆ gseg-web-10.10.1.0
❆ gseg-app-10.10.2.0
❆ gseg-db-10.10.3.0
不难看出，这是为了呈现一个典型的3-Tier-Application而定义的三个分段，也是VMware VCAP-NV最喜欢用的经典模型。
随后将预先在两个数据中心vCenter上创建的5台虚拟机连接到对应的分段之上。
为了便于后面的演示，笔者将之前创建的gseg-photon-10.10.0.0分段暂时先删除了。
五台用于演示用例的虚拟机分布在两个数据中心，并且同一个数据中心内的虚拟机不会运行在同一台ESXi传输节点之上。
❆ 现在进行同一个数据中心内的分布式路由测试：
web-21虚拟机尝试通过ssh访问app-21虚拟机以及db-21虚拟机，结合上一篇分享不难知道这些流量会在ESXi主机传输节点之间进行封装和传输。
可以看到在同一个数据中心内，借助于NSX Tier1网关的分布式路由功能，不同分段之间已经实现了L3可达。
❆ 现在进行跨数据中心的分布式路由测试：
web-11/web-12虚拟机尝试通过ssh访问app-21虚拟机以及db-21虚拟机。
以web-11访问db-21为例：这些流量会经过Tier1分布式路由器首先路由到gseg-db-10.10.3.0分段的网关10.10.3.254，这个IP存在于每一台ESXi传输节点内核中运行的T1网关之上。随后的ESXi传输节点-本地首选Edge传输节点-远端首选Edge传输节点-目标ESXi传输节点的流量均隶属于gseg-db-10.10.3.0分段，这就是NSX经典的“先路由-后交换”原则。
通过NSX自带的TraceFlow工具可以清楚地看到这个过程：
测试的结果也表示：跨数据中心的分布式路由也已经实现了。
至此，当前演示用例的Federation逻辑网络和工作负载部署拓扑如下所示：
现在我们一起用命令来查看已经创建的Tier1网关和Tier0网关在数据中心之间的延伸情况。这里依旧使用上文所提到的两个命令：
# nsxcli
> get logical-routers
首先是Primary DataCenter的esxi-11传输节点：
发现已经存在2个分布式路由器，虽然看不到具体的命名，但是不难推测出UUID尾号为222d的实例应该是Tier0网关的DR，另一个UUID尾号为fbc5的肯定是Tier1网关的DR。
相信在其他传输节点上，分布式路由器实例的分布也不会有差异。
Secondary DataCenter的esxi-23传输节点：
在Primary DataCenter的edge-11传输节点：
edge-12传输节点：
在Secondary DataCenter的edge-21传输节点：
edge-22传输节点：
通过对比不难看出，虽然不同数据中心的Tier1DR实例和Tier0DR实例其LR-ID可能不同，但本质上是同一个DR实例在数据中心之间实现了延伸，因为其UUID是一致的。
实际上，基于当前的Tier0和Tier1网关配置，其对应实例的分布情况如下图所示：
同理，即便Tier0网关下再多几个Tier1网关，其总体架构拓扑不会发生根本性的变化。在当前的配置下，Tier1网关和Tier0网关已经实现了跨数据中心延伸。
05.如果Tier1启用有状态服务呢？
在创建Tier1网关的时候，笔者并没有为Tier1网关指定Edge集群。可就像上文笔者所说的那样，其实很多很多时候Tier1网关会承载很多有状态的服务，诸如负载均衡、NAT这些。因此我们也需要讨论Tier1网关承载有状态服务的情况。
让我们回到Tier1网关的配置界面：
⚝ 修改Tier1网关的配置，激活【为服务或自定义跨度启用 Edge 集群】
此时Tier1网关的配置界面又多了几个选项：
故障切换可以选择【主动】或者【被动】；所谓的主动就是指如果首选节点发生故障并恢复，它将抢占其对等节点并成为活动节点。对等方将其状态更改为备用。与之相对应的被动就是如果首选节点发生故障并恢复，它将检查其对等节点是否为活动节点。如果是这样，首选节点将不会抢占其对等节点并将成为备用节点。
⚝ 本示例中，定义故障切换为【主动】。
可以看到因为Tier1网关已经连接到了Tier0网关，换言之，其延伸的数据中心“跨度”已经被Tier0网关所定义，因此在位置选项栏已经定义了包含Primary DataCenter和Secondary DataCenter。
⚝ 随后为不同的数据中心“跨度”选择已经完成包括RTEP就绪在内的Edge集群，即edgecl-primary以及edgecl-secondary。
在Edge选项可以选择【自动分配】或者手动【设置】。
如果开启【启用备用切换】，那么管理员必须选择【自动分配】；想要手动指定Edge传输节点的主备关系，需要关闭【启用备用切换】。
⚝ 本示例中，关闭【启用备用切换】；
⚝ 定义Primary DataCenter为Tier1有状态服务的【主】模式。
在完成上述配置后，我们再去传输节点用命令行检查Tier0网关和Tier1网关的实例情况。
在Primary DataCenter的ESXi主机传输节点esxi-11上，只剩下Tier1网关的DR实例。
无独有偶，在Secondary DataCenter的ESXi主机传输节点esxi-23上，也只剩下Tier1网关的DR实例。
那么在Edge传输节点上，又会发生什么变化呢？其实看过笔者之前公众号分享的朋友一定猜到了，因为Tier1网关出现了SR实例，且没有任何分段连接到Tier0网关之上，因此ESXi传输节点内部不会有任何除了Tier1网关DR之外的实例，Tier0网关的DR实例只会出现在Edge传输节点上。
在Primary DataCenter的edge-11传输节点上，出现了Tier1网关的DR、SR实例以及Tier0网关的DR实例。
同样地，在Primary DataCenter的edge-12传输节点上，也出现Tier1网关的DR、SR实例以及Tier0网关的DR实例。
那么，在Secondary DataCenter的Edge传输节点情况又是如何呢？没错，在这个【备】数据中心的Edge传输节点内部，同样出现了Tier1网关的DR、SR实例以及Tier0网关的DR实例。
有人会说，如果是这样的话，不就和之前没有创建Tier1网关SR实例的情况一样了嘛！
是否真的一样，需要等待Tier0网关与物理上联构建起南北向路由后再来分析。这些内容将在下一篇连载中向大家分享。