话接上回，笔者已经依次完成了Federation架构下Global Manager、Local Manager以及Edge传输节点和集群的部署，只要再对主机进行NSX配置，就完成了所有的“准备工作”。今天分享的主题将围绕分段Segment展开，说说Federation架构下跨数据中心的全局分段相比普通的分段，其配置和实现原理有何异同点。
01
—
主机传输节点就绪
在Federation架构下，主机传输节点的就绪并没有需要特别注意的地方，这里就简单给几张配置图示，提供参考。
根据ESXi宿主机物理硬件以及vTEP网段规划的实际情况，定义上行链路配置文件。
这里需要注意，如下图所示：Primary DataCenter宿主机的上行链路配置文件是由Primary DataCenter的Local Manager来定义，而另一个Secondary DataCenter宿主机的上行链路配置文件是需要另一个数据中心的Local Manager来定义。这一点是区别于Multi-Site架构下的定义方式的。
完成上行链路配置文件的定义后，分别完成两个数据中心的ESXi传输节点配置文件的定义。
本步骤需要注意的是，传输节点中关联的传输区域一定是Global Overlay传输区域。至于vTEP的IP分配采用静态方式、地址池还是DHCP不影响Federation的实现，各位朋友完全可以根据自己环境的实际情况来定义。
如下图所示，笔者的环境采用地址池的方式来分配TEP使用的IP地址。
别忘记分别在两台vCenter上设置分布式交换机的MTU，这一点很重要但却很容易被管理员所忽略。
最后，分别在两个数据中心的Local Manager界面以vSphere群集为单位，完成NSX的配置工作。
至此，前期的准备和预配置暂时告一段落，可以创建全局分段了。
02
—
创建一个全局分段？
不！创建一个T1/T0网关
在刚开始接触Federation的时候，天真的笔者真的以为现阶段已是“万事俱备只欠东风”，应该没有什么可以阻挡笔者创建全局分段了。可事实告诉我，有！既然要创建一个全局分段，那么管理员进行配置的界面自然是Global Manager角色。这一点相信所有看官都能理解和认同。
可当管理员信心满满准备创建全局分段的时候就会发现【在默认情况下，无法创建全局Overlay传输区域的分段】。原因其实也是显而易见的：既然“连接的网关”是必选项，那么就需要管理员提前完成至少一个网关的创建和定义。为了能更好地呈现Federation网络架构，笔者将创建一个Tier1网关。在Global Manager创建一个T1网关，并且在两个不同的数据中心之间延伸。这里需要说明几个参数的定义，理由后续的分享中会详细展开：
- Edge池分配大小：路由，确保不会有Tier1网关的角色路由器被创建；
- 暂时不创建Tier0网关；
- Tier1网关的位置会包含Primary DataCenter和Secondary DataCenter，Edge集群分别选上，其中定义Primary DataCenter和关联集群为“主模式”。
现在是真的可以创建全局Overlay传输区域的分段了，不会再有意外了。
03
—
创建一个全局分段
为了更好地呈现分段跨数据中心延伸的效果，笔者预先在两个数据中心创建了3台VMware PhotonOS的虚拟机：
由于两个数据中心之间是三层互通，因此在没有实现Federation的情况下，无法满足三台虚拟机之间的二层互通。
创建一个全局Overlay传输区域的分段。
注意，当管理员选择分段上联的网关后，流量类型默认就会从VLAN网络更改为Overlay网络（覆盖网络）。
随后，在两个数据中心vCenter对应的分布式交换机上，都可以看到出现了新的一个NSX分段“gseg-photon-10.10.0.0”。
其中还有一个叫做“inter-site-bp-uuid”的分段，是系统自己创建的。不妨先“望文生义”一下：应该是用来实现跨站点分段延伸而自动创建的。
来验证一下吧：
1. 将Primary DataCenter虚拟机分别连接到对应的分布式交换机相关分段上
注意photon-11和photon-12是由不同的ESXi主机所承载的，这就表示Overlay流量必然会经过Underlay的传输。
同数据中心L2网络连通性：Photon-11与Photon-12之间L2互访正常。
2.默认情况下，跨数据中心的访问是失败的。
3.将Photon-21连接到Secondary DataCenter下分布式交换机对应的分段之上。
4.位于Primary DataCenter的Photon-11与位于Secondary DataCenter的Photon-21实现了跨数据中心的网络L2互通。
至此，我们完成了在Federation架构下，不同数据中心之间的全局Overlay传输区域的延伸，在该区域下的分段能够实现网络的跨数据中心L2可达，为业务多活、容灾和跨数据中心迁移提供了最重要的网络一致性基础。
04
—
来探索探索实现原理
虽然我们已经实现了基于全局分段的网络跨数据中心L2延伸，但笔者还是想深入探究一下其实现原理。因为如果工程师无法对基本的实现原理有所了解，一旦遇到故障排查的场景，就会手足无措一筹莫展。因此笔者尝试借助NSX自己的TraceFlow，来探索一下实现原理。
第一步，温故而知新。
对于NSX的标准分段来说，跨主机传输节点的Overlay传输区域的流量传输会涉及TEP封装。以下图为例：
当photon-11想要与photon-12通信的时候，从宿主机esxi-12和esxi-13的角度来说，他们之间的对话应该是这样的。
当然这中间涉及到ARP表、MAC表和TEP表的更新和同步，具体的原理和流程可以参加VMware官方的NSX ICM课程来进一步了解。
随后，如上图所示：photon-11的数据包经过NSX的vdl2模块到达TEP，经过封装后通过Underlay(VLAN81)网络转发到目标宿主机的TEP，目标宿主机接收到这个数据包后进行TEP的解封转，再经过vdl2模块转发到目标虚拟机photon-12，完成了这一次通信的过程。归纳来说，不同宿主机之间的Overlay流量传输必然经过了TEP的封装/解封转。
通过NSX自己的TraceFlow工具，也能清晰地看到这个过程：
由于屏幕显示的限制，笔者只能截取最关键的TEP封装和Underlay转发部分。
看到这里，我们是否可以温故而知新：跨数据中心之间的Overlay流量也是直接通过ESXi主机之间的TEP实现封装与解封装，然后经过Underlay网络来转发的！
这是一个合情合理的猜想，其流量转发如下图所示：
可事实真的如何么？
第二步，实践出真知。
在NSX上通过TraceFlow工具进行验证：
看来结果并非如此。实际上跨数据中心的L2通信，是通过Edge传输节点的Remote TEP来实现的。在下图中，大家可以清楚地看到这个步骤。
实际上，这个跨数据中心的数据包一共经过了三段Underlay传输：第一段：源虚拟机所在的ESXi-----本地Edge群集的首选Edge传输节点；第二段：本地Edge传输节点-------远端Edge群集的首选Edge传输节点；
第三段：远端Edge传输节点-------目的虚拟机所在的ESXi。如下图所示，TraceFlow中显示的Edge传输节点是该Edge集群中被选举为活动状态的传输节点，比如Secondary DataCenter中的edge-22传输节点。
仔细观察TEP地址，也不难发现这三段Underlay传输涉及到Edge传输节点的两个不同的TEP地址。以Primary DataCenter的edge-11传输节点为例：第一段Underlay传输是ESXi主机传输节点->Edge传输节点，MTU是上行链路配置定义的数值，至少1600，本例中笔者环境定义的数值是MTU9000。第二段Underlay传输在Edge传输节点Remote TEP与远端Edge传输节点的Remote TEP之间进行，这个MTU数值是在Global Manager单独定义的，此处笔者定义的MTU是1700。
这里需要做个特别说明：
在笔者的分享联盟时代II.管理与控制服务器部署中，笔者曾望文生义，认为RTEP网络必须满足MTU1700的要求。后来VMware的黄Sir私聊笔者，指出了MTU1700只是建议值，最小值其实1500就可以满足。这里也非常感谢黄Sir的指正，笔者也非常欢迎各位看官能随时指正和交流。
写在最后
—
本来笔者想通过ESXi自带的pktcap-uw来抓取TEP流量，但是无论是用默认的参数还是添加了kernelside均失败了。虽然使用NSX自带的TraceFlow已经可以清晰地说明跨数据中心的Overlay延伸分段的转发路径，但还是有点遗憾，毕竟眼见为实嘛。NSX的迭代更新真的很快，4.0的发布意味着又有很多新的特性需要去实践和探索，对于工程师来说或许真的就是学无止境吧，技术的魅力也正在于此。下一篇想聊一聊跨数据中心延伸Tier1和Tier0网关，感谢持续关注。
