本篇我们继续来闲谈VMware出品的“变形金刚”。
最近在和关注公众号的朋友交流过程中，发现不少朋友都有一些疑惑：
- ▪想要学习NSX DC，有什么推荐的参考书么？
- ▪想要学习NSX-T，是否一定要有NSX-V的基础？
- ▪想要自己动手搞一搞NSX，服务器需要多少资源？
我觉得这些问题都很实在，也是我在刚接触NSX DC的时候，自己困惑过的几个疑问。首先，NSX-T或者说NSX DC是VMware的产品，VMware的官网上有非常详细的手册(中英文版本)提供大家作为标准技术参考，而市场上的参考书大多站在SDN的高度来对主流的产品进行评述，各位可以根据自己的需要适当选择。其次，我觉得学习NSX-T不一定要NSX-V的基础；其实NSX DC的两个产品在概念、架构、原理上是相互独立，但又相互联系的。我举个简单的例子，NSX-V的Overlay采用的是普遍的VXLAN技术；而NSX-T采用的是Geneve(Generic Network Virtualization Encapsulation)；两者的协议类型虽然不同，但是在应用场景上是相同的，都是用以承载NSX逻辑交换网络Overlay流量的协议。只能说，如果有NSX-V的基础来学习NSX-T，会有一种得心应手+触类旁通的感觉，这一点我是深有体会的。最后来谈谈如何去动手，VMware的Hands on Lab(后文简称Hol)是一个非常好的云实验环境；在VMware官网申请账号后，就可以随时随地的使用Hol进行学习、测试和演示；在准备VCAP-NV以及VCAP-DCV的考试期间，Hol就是我平时熟悉和练习的平台，我极力推荐给各位想要接触NSX DC的朋友。当然，如果有一套自己的“迷你私有云”，能将每天的学习成果保留下来，那就更好了。至于服务器的资源，我觉得根据自己的需求吧，就拿上一篇“一步步实现SDDC”系列来说，里面有vSphere、NSX、vSAN，加起来也就32GB内存的负载。
说了这么多，也是想回应下一些朋友的疑问。接下来，我们来谈谈今天的主要分享内容。
如果一个管理员想要借助NSX DC中的NSX-V实现网络与安全，他需要做哪些准备及就绪部署呢？
▪完成vCenter环境的部署，关键点：VC、集群、分布式交换机和MTU1600
VC是NSX-V架构中，与NSXMGR同属于管理平面的组件，并且NSXMGR必须与VC做1:1的集成，才能实现对NSX环境的集中管理。
▪完成NSXMGR虚拟机的部署，关键点：NTP时间同步、与VC的注册集成
▪完成NSX Controllers(后文简称NSXCTRL)集群的部署，关键点：NSXCTRL建议部署3台控制器；在学习、测试或者演示环境中，可以选择只部署1台控制器
▪以集群为单位，借助于VC的ESXi Agent Management(后文简称EAM)，在每一台相关的ESXi内核中安装esx-nsxv.vib，关键点：VTEP地址池、分布式交换机；
▪依次完成VNI定义、传输区域定义，完成主机准备的“最后一公里”，关键点：传输区域与主机准备集群的不匹配，会导致逻辑网络通信出现问题。
如果想要查看详细的部署流程，可以参看我之前的一篇分享：一步步实现SDDC-NSX MGR安装和主机准备
在NSX-V环境中，由于VXLAN的传输区域是与集群关联，没有和分布式交换机形成一种捆绑的关系；逻辑交换机从本质上来说呢，又是分布式交换机上的虚拟机端口组；因此在传输区域与分布式交换机出现不对称覆盖的时候，业务会受到影响：
▪如下图所示，这是一个正确的配置模型：
传输区域覆盖了所有可能出现Overlay承载的集群，包括计算集群1、计算集群2和管理与边界集群
- 下图是一个错误的配置：
传输区域并没有覆盖计算集群2；虽然该集群的主机都连接到了dvs-compute，换言之，均可以看到管理员创建的用于虚拟机的网络流量承载的逻辑交换机，也都在主机准备中创建了用于VXLAN通信的VTEP，但是由于不在传输区域VXLAN Transport Zone中，计算集群2上承载的虚拟机，无法与计算集群1上承载的虚拟机，实现逻辑交换与逻辑路由的互通
- 下图是一个有风险的配置示例：
有人会疑问，下图的配置示例与上图乍看之下似乎并没有区别啊，都是传输区域覆盖不匹配啊。是的，在下图的配置模型下，计算集群和边界集群均被正确覆盖，因此业务虚拟机通过VXLAN实现互通是没有任何问题的。但是由于逻辑交换机是分布式交换机上的一个虚拟机端口组，因此在没有进行过主机准备，不具备VXLAN通信的管理集群主机上，同样能看到逻辑交换机的虚拟机端口组；虽然理论上管理集群上的虚拟机定然不会使用到这些虚拟机网络，但是管理员的疏忽或者误操作，将某一台计算或者边界集群的虚拟机迁移到了这个集群，就会出现业务的中断，是一个需要注意的风险点。
上文所提的注意事项，是在NSX-V主机准备过程中，非常容易被管理员忽视，但同时可能会对业务产生比较大影响的配置失误。那么在NSX-T的“主机准备”过程中，是否也会产生这样的问题呢？
0x02-01：NSXMGR&NSXCTRL的部署与初始化
--------------------------------------------------------
在NSX-T的环境中，NSXMGR的部署依旧通过OVA部署，只不过多了一些新的设置需要定义，如新增加的“审计管理员”角色等。
- 通过OVA模板，完成NSXMGR的上传与部署
- 打开NSXMGR操作系统电源，等到服务器正常启动
- 如果在OVA部署节点，设置了允许SSH访问，管理员可以通过admin账号，以SSH协议访问NSXMGR底层，查看网络设置和服务运行情况：
- # get interface eth0；用以检查基本网络设置
- # get services；用以检查服务是否正常启动并运行
- 等待各服务正常运行后，管理员可以访问https://nsxmgr，对整个NSX-T环境进行统一的管理；这一点与原来NSX-V环境大相径庭，由于NSX-T与VC没有直接的注册关系，因此，包括逻辑交换、边界服务、安全微分段等功能的配置，全部通过NSXMGR的UI或者RestAPI实现；所以说在NSX-T的架构中，VC已经从管理平面中被移除，即使是面对独立的vSphere主机或者其他异构的Hypervisor，NSX-T都可以提供集中式的管理和一致的网络与安全体验
- 对NSX-T比较陌生的管理员，也不用担心出现配置无从下手的情况；NSX-T的欢迎界面会弹出提示，指导管理员完成包括NSX节点扩容、配置文件的创建以及传输节点配置工作等流程
据说，在NSX-T的某一个内部版本中(可能就是大黄蜂吧)，研发人员曾经想要将管理平面与控制平面合二为一；不过直到NSX-T2.4，这个想法才得以成为现实。
如果要用一句话来形容NSX-V以及NSX-T2.3版本以前的组件，就是管控隔离1+3；意思是管理平面NSXMGR与控制平面NSXCTRL是相互独立的，一个环境中只有一台NSXMGR(NSX cross VC架构中，Primary NSXMGR也只有一台)；同时为了满足控制平面的高可用，会采用最多3台NSXCTRL来组成一个控制器集群。
由于NSXCTRL集群一般是由3台控制器组成，并且可以启用控制器断连操作(CDO)实现在控制器集群全部停止服务情况下，生产业务不发生严重的中断；所以NSXCTRL很少会成为NSX DC架构中的单点故障。而NSXMGR虽然是一个管理平面的组件，当它停止服务的时候，数据平面并不会受到影响，可依旧是NSX环境中，一个系统单点故障的风险隐患。
在NSX-T2.4的架构中，除了管理平面与控制平面合二为一之外，NSXMGR也支持类似VCHA的三节点高可用集群部署。
- 点击系统-架构层-概览页面下管理群集的“添加节点”
- 系统会运行节点添加向导，管理员可以选择在某一台VC管理的vSphere集群上，再添加最多2台NSXMGR，实现三节点高可用
- 同时，为了更好地实现高可用，NSXMGR需要定义一个虚拟IP；在多节点群集的环境下，管理员可以通过该虚拟IP来访问NSXMGR。多节点群集也让NSXMGR的管理平面避免了以往单点故障的风险；现在的架构简单来说就是管控合一3+3；即三台NSXMGR自身既是管理器也是控制器。
注意，由于我的环境资源有限，我在完成NSXMGR节点添加操作后，就将该节点删除了；因此后续在演示传输节点与NSXMGR通信的时候，各位实际只能看到和一台NSXMGR的连接。
0x02-02：传输区域、主机交换机和传输节点配置文件
--------------------------------------------------------
在上文，我提到了NSX-V环境下，由于管理员的疏忽，可能会造成传输区域覆盖不合规，导致业务受到影响或者出现风险的两种情况。那么，在NSX-T的环境下，这种情况能否避免呢？
在讨论这个问题之前，我们首先要来思考一个问题：管理员部署NSX-T，逻辑交换机还是分布式交换机上的一个虚拟机端口组么？其实这个问题的答案很简单：一定不是！因为NSX-T除了支持vSphere之外，包支持包括KVM、容器、裸机等异构对象。拿KVM来说，它是没有vSphere独有的分布式交换机的。那么NSX-T的逻辑交换机会承载在哪种类型的交换机上呢？
NSX-T的架构中，VMware引入了一个新的概念，叫主机交换机或者叫N-VDS。在完成传输节点的准备操作(配置NSX)后，主机交换机的模块就会在Hypervisor内核中运行；这一点，我会在下一篇分享中说明；现在，我们先引入这个概念。
- 管理员进入系统-结构层-传输区域，点击添加
- 在NSX-T的环境下，VLAN流量和Geneve流量都需要定义对应的传输区域
- 如下图所示，我先定义了一个Global-Overlay-Only-TZ，只用于Geneve Overlay流量的承载；又定义了一个Global-VLAN-Only-TZ，只用于VLAN流量的承载。
- 但无论是Overlay还是VLAN流量的传输区域，都需要定义个主机交换机的名称，如Production-Overlay-Only-N-VDS
可以看到，在配置传输区域的过程中，管理员除了定义了该传输区域承载的网络流量类型(VLAN或者Geneve)之外，也指定了主机交换机的名称，实现了传输区域与主机交换机的强制对应关系；在这种模式下，不会再出现传输区域覆盖与原来分布式交换机关联集群不匹配的情况。
在完成传输区域添加操作后，管理员还需要添加传输节点配置文件，该配置文件最终可以实现传输节点与传输区域的关联。
- 在系统-配置文件下，添加新的传输节点配置文件
- 添加一个Global-Overlay-Only-TZ-Profile，设置关联的传输区域是Global-Overlay-Only-TZ
- N-VDS的名称无法更改，只能选择之前定义的Production-Overlay-Only-N-VDS；与NSX-V主机准备相类似，管理员依旧需要定义和关联VTEP IP地址池；但是不同的是，由于主机交换机并不受到VC的管理，无法像分布式交换机一样，通过添加和管理主机实现对主机交换机承载VMNIC的定义，因此需要在传输配置文件中，定义承载关联的主机交换机上联的物理网卡，如vmnic2和vmnic3；包括NIOC等其他配置文件均采用默认即可。
- 同样地，完成Global-VLAN-Only-TZ-Profile传输节点配置文件的定义，与Geneve类型不同的是，VLAN类型的主机交换机不需要定义VTEP IP池
- 至此，我一共创建了两个传输节点配置文件，其中一个只用于VLAN流量，另一个只用于Geneve流量
注意：下图中的另一个同时承载VLAN和Geneve流量的传输节点配置文件请暂时忽略，我会在下一篇中解释用法
0x02-03：主机节点就绪
--------------------------------------------------------
接下来，我将演示如何就绪主机节点；在NSX-T的概念中，包括ESXi、KVM等Hypervisor均称为主机节点，承载逻辑路由器角色的叫做Edge节点，它们又统称为传输节点。
虽然在NSX-T的架构中，VC不再作为管理平面组件，但是对于vSphere环境，VC依旧是虚拟化的核心组件，用来管理vSphere环境的集群、主机、虚拟机和模板；因此，NSXMGR可以将VC添加作为计算管理器，来实现对VC下属vSphere环境的统一管理。此外，在NSX-T架构中，NSXMGR不再与VC具有1:1的注册关系，一台NSXMGR最多可以添加五台VC作为计算管理器。
- 在系统-结构层，添加计算管理器
- 填写VC相关信息
- 接受VC指纹
- 完成计算管理器sa-vcsa-01.vclass.local的添加
我实在想不出什么有意思的域名了，正好最近在复习以前的教材准备再考一门VCAP，干脆就用了vclass.local
- 进入到系统-架构层-节点，首先为计算管理器sa-vcsa-01.vclass.local下的计算集群进行“配置NSX”的操作
- 由于计算集群虚拟机均通过Geneve封装实现逻辑网络互连，因此选择部署的传输节点文件为Global-Overlay-Only-TZ-Profile
- 等待计算集群的两台ESXi服务器均正常“配置NSX”，可以看到配置状态和节点状态均为绿色健康
对于KVM或者其他类型的Hypervisor，由于无法通过计算管理器sa-vcsa-01.vclass.local实现统一的纳管，因此必须以独立主机的形式进行“NSX配置”操作
- 点击添加独立节点，选择Ubuntu KVM，输入主机名、IP地址和管理员凭据等操作系统信息
- 接受服务器指纹信息
- 对于独立的Ubuntu KVM主机，在被添加作为主机节点的时候，管理员可以对传输节点配置文件定义的内容进行部分更新，如同样是选择Global-Overlay-Only-TZ-Profile，但是对于KVM主机，物理网卡命名为eth1和eth2，并非ESXi主机的vmnic2和vmnic3
- 依次完成其他独立主机的添加操作
至此，包括两台ESXi主机和两台KVM主机，一共四台主机传输节点的就绪工作已经完成。总结一下NSX-T环境下的主机传输节点就绪步骤：
- ▪完成异构Hypervisor的部署，在上一篇我以ESXi和Ubuntu KVM作为本系列的主要Hypervisor
- ▪完成NSXMGR的部署，在NSX-T2.4版本，NSXMGR同时承载着管理平面和控制平面角色，并且支持最多3台NSXMGR实现群集化
- ▪完成传输区域、主机交换机和传输节点配置文件的创建和关联，其中传输区域流量类型分为VLAN和Geneve Overlay流量，每个传输区域都与一个主机交换机相关联，将来逻辑交换机端口以及VLAN端口均生成在主机交换机上。
- ▪对于vSphere环境可以添加VC作为计算管理器，其他异构主机以独立主机方式接受NSXMGR的统一管理，通过“配置NSX”操作，关联节点传输配置文件，完成就绪步骤。
比较与NSX-V的主机准备工作，除了不需要将NSXMGR与VC注册集成外，管理员似乎也不需要再手动指定Geneve的VNI Numbers。
最后，再强调一句，MTU1600！
今天分享主要是向各位演示如何进行NSX-T的“主机准备”工作，并没有仔细讲解在这个过程中，NSXMGR与Hypervisor之间进行了哪些交互，又有什么状态或者现场可以用来帮助我们分析这个过程。此外，相信各位也会有以下若干疑问：
- ▪为什么不再对管理和边界集群进行“配置NSX”的“主机准备”工作？
- ▪NSX-T的VNI Numbers能否手动指定？
- ▪是否可以选择由一个主机交换机同时承载VLAN和Geneve两种流量类型？
- ▪除了NSXMGR与VC，之前NSX-V架构中的vsfwd、netcpad是否依旧保留在NSX-T的架构中？
在下一篇分享中，我会依次为各位解答上述问题。同时，因为晓冬也是在今年年初刚结束NSX-T，在分享的内容上难免会有一些纰漏和谬误的地方。在这里，也恳请各位关注NSX-T的朋友，能批评指正；并希望能和各位多多进行交流互动，谢谢。
