在创建传输区域和配置传输节点配置文件的时候，管理员需要对Overlay流量和VLAN流量分别创建对应的传输区域和主机交换机；如下图所示：
由于传输区域与主机交换机有绑定关系，一般来说，Overlay流量的主机交换机和VLAN流量的主机交换机是区分开的。在配置Edge传输节点的时候，管理员需要将Edge传输节点同时关联到Overlay传输区域和VLAN传输区域，以实现逻辑网络与数据中心物理网络的互通。由于两个传输区域分别有自己独立的主机交换机，Edge节点至少会有三种不同的流量：
- ▪Overlay流量，逻辑网络
- ▪VLAN流量，物理网络
- ▪管理流量，物理网络
我们先不考虑以ESXi承载虚拟机版本Edge节点那种方式，假定用户采用一台物理机作为Edge节点，需要多少网络适配器，才能在满足业务需求的基础上，提供冗余高可用呢？
- ▪Edge节点本身用于和NSXMGR通信的管理网络，由于不涉及业务生产，考虑用1块千兆网络适配器承载；
- ▪承载Overlay流量和VLAN流量业务的主机交换机共有2台，考虑冗余，至少需要4块vmnic，并且基于业务带宽的需要，至少万兆以上。
综上所示，理想情况下，至少需要2块双口万兆网络适配器+1块千兆网络适配器才能同时满足业务的性能要求与高可用标准。
在实际项目中，如果用户出于预算的考量或者利旧服务器，只能满足1块双口万兆网络适配器的时候，这台服务器还能满足Edge节点的业务需求么？
有人说，当然可以！既然是双口万兆网络适配器，其中一个万兆口用于承载VLAN主机交换机的流量，另一个万兆口用于承载Overlay主机交换机的流量不就解决问题了么？
不可否认，这是一种可行的方案，代价是Overlay或者VLAN都存在单点故障的风险。而且，由于Edge节点的角色特征，导致了无论是Overlay还是VLAN流量出现中断，总体的业务都会受到严重的影响。
因此，上面的方案可以用于PoC或者项目演示，但无法满足生产业务的需求。我们需要一个B方案：用1台主机交换机，同时承载Overlay和VLAN流量，这样可以同时保证2个传输区域的高可用。
0x03：公用主机交换机的传输节点配置文件创建
===============================
- ▪访问NSXMGR，在系统-结构层-传输区域页面，添加新的传输区域
- ▪添加一个Overlay传输区域，命名为Global-Overlay-TZ，N-VDS命名为Production-Overlay-N-VDS，流量类型为覆盖网络
注：Global-Overlay-TZ与Global-VLAN-TZ将共用一个N-VDS
- ▪添加一个VLAN传输区域，命名为Global-VLAN-TZ，N-VDS命名同样为Production-Overlay-N-VDS，流量类型为VLAN
在上一篇，我提到了传输区域会与主机交换机有绑定关系，但并没说明这种关系具有1:1的强制绑定
- ▪进入传输节点配置文件，添加新的配置文件
- ▪命名配置文件为Global-Overlay_VLAN-TZ-Profile，同时关联两个传输区域
- ▪定义一个新的IP地址池，命名为Global-VTEP-Pool
地址为172.18.11.51/24-172.18.11.56/24
- ▪为传输节点配置文件关联N-VDS，设置双网卡上联
可以看到，虽然只有一个主机交换机Production-Overlay-N-VDS，但是可以承载包括Global-Overlay-TZ和Global-VLAN-TZ两个不同的传输区域流量
- ▪等待传输区域文件添加完成
这种配置方式不仅适用于Edge节点，对于主机传输节点，如果网络适配器的数量不足以满足“物理隔离Overlay流量和VLAN流量的同时，提供高可用冗余”，可以选择用一台公用的主机交换机同时承载两个传输区域的流量负载。（这种情况往往用于承载虚拟机版本的Edge主机场景）
话到这里，请各位思考一个问题，如果所有的ESXi和KVM主机都是部署在一台ESXi服务器上的虚拟机，现在需要在虚拟机版本的ESXi上再部署若干虚拟机版本的Edge节点，网络环境又需要如何准备？这个答案我会在Edge节点准备和逻辑路由章节揭晓。
在我之前的几篇分享“NSX分布式防火墙是如何工作的？”“NSX控制平面和静态路由更新流程1”“NSX控制平面和静态路由更新流程2”中，我介绍了NSX-V的三层架构。那么在NSX-T环境中，三层架构具体又有哪些变化呢？
首先，NSX-T的架构中，vCenter已经从必要的组件成为只针对vSphere环境的计算管理器，不再作为管理平面组件出现；这一点在上一篇分享中已经有比较详细的演示了。在NSX-V环境中，NSXMGR借助于VC的EAM，会在ESXi内核中安装VIB，并运行包括vsip、vdl2和vdrb等模块。在NSX-T环境中，NSXMGR同样会在传输节点内核中安装若干模块，请看下文我的演示：
- ▪对于没有进行过“配置NSX”的普通ESXi主机，内核中不会运行NSX相关的模块
- ▪对于进行过“配置NSX”的主机节点，内核中运行了NSX相关的诸多模块；可以看到，在数量上要远远大于NSX-V环境中的ESXi主机
- ▪NSX会在主机传输节点内核中安装各类NSX VIB，而不是NSX-V环境中的一个
- ▪与NSX-V相同，在NSX-T传输节点的用户空间，运行着消息总线代理MPA，它依旧作为管理平面的组件存在，但是功能更趋向于传输节点运行状态的收集；与NSX-V的MPA(vswfd)相同，它与NSXMGR保持着TCP5671的长连接；
- ▪不过笔者并没有充足的物理环境支撑部署3台NSXMGR，以群集模式验证传输节点与NSXMGR的长连接状态：
究竟是主机节点同时与所有三台NSXMGR建立TCP5671连接；还是单独与其中的某一台NSXMGR建立连接？不知道是否有大拿做过类似的验证，晓冬恳请分享。
- ▪由于NSXMGR和NSXCTRL合二为一，可以看到传输节点除了与NSXMGR的TCP5671保持长连接，也与TCP1235保持长连接
- ▪这里面有两个变化，在NSX-V的环境中，ESXi用户空间运行的控制平面组件netcpad与所有NSXCTRL的TCP1234保持着长连接，在NSX-T中，这个端口变更成了TCP1235；同时由于NSXCTRL的角色合并到NSXMGR，在传输节点上只能看到与NSXMGR的两条长连接信息
一般来说，在NSX-T的架构中，称呼在传输节点用户空间运行的控制平面组件为LCP，在NSXMGR上运行的控制平面组件为CCP。
在NSX-T2.3版本以前，由于NSXMGR和NSXCTRL是独立的组件，因此架构简图如下：
而到了NSX-T2.4版本，由于管理平面与控制平面的合二为一，架构发生了比较大的变化：
在完成了主机传输节点的就绪工作后，管理员可以创建逻辑交换机实现跨Hypervisor的虚拟机二层通信。在下篇的分享中，我将演示如何创建逻辑交换网络，实现ESXi主机与KVM主机上运行的虚拟机二层互通；并且将演示在配置KVM环境中需要注意的若干事项。
