概述
本文记录针对NSX-T传输节点配置文件中的主机上行链路进行测试比对，一种是基于常规双上行链路，一种是基于交换机做了Lacp或M-lag，使用Lag组成员，另外一种则是直接复用Lag组作为上行链路。
环境概述
嵌套虚拟化安装vSphere ESXi 7.0U3版本，并安装VCSA和NSX-T。
角色分配
| 角色 | IP地址 |
|---|---|
| VMware ESXi 7.0 | 192.168.111.101 |
| VMware VCSA 7.0 | 192.168.111.100 |
| NSX Manager 4.1.2.1 | 192.168.111.111 |
网卡分配
| 网卡 | 业务 |
|---|---|
| vmnic0 | Web Client管理 |
| vmnic1 | NSX uplink01 / lag1 |
| vmnic2 | NSX uplink02 / lag1 |
计划测试三两种场景
- 基于物理链路的上行
- 将上行链路组成lag，指定lag组成员做未上行
- 将上行链路组成lag，复用聚合组作为上行
主备上行链路
按照计划，将上行链路uplink-1、uplink-2分别对应vmnic1、vmnic2，逻辑图如下所示
配置传输节点
集群配置NSX，等待完成。
耐心等待一会儿后NSX配置就好了。
创建了一个Segment01，用于后续使用。
VCSA上也同步了该Segment，类型为N-vDS。
通过命令行查看
esxcli network nic list
nsxdp-cli vswitch instance list可以看到vdrPort的传输节点是使用的vmnic1网卡，vmnic2网卡就处于被动状态。
需要注意的是vdr-vdrPort的MAC地址在所有传输节点上都是相同的，默认为 02:50:56:56:44:52，即使环境中未使用T0、T1网关。
现模拟故障：将vmnic1 shutdown 掉，看会是什么情况。
esxcli network nic down -n vmnic1根据实际操作可见，vdr-vdrPort的传输节点切换到了vmnic2网卡上了。
业务冗余验证①
创建2个虚拟机，并将网络指定到该segment01上。
使用长ping虚拟机IP地址，并up/down物理网卡，和预期一样，在整个过程中虚拟机并无中断网络。
NSX Manager 触发上行链中断告警，但并未对业务造成影响。
聚合上行链路
同样，按照计划，将上行链路1、上行链路2分别对应lag1-0、lag1-1在此之前需要先把VCSA上面的Lag配置好。
将Lag1配置好后，管理主机网络，并调整上行链路分别指向lag1-0、lag1-1 。
Lag1为一个聚合组，它包含了lag1-0、lag1-1成员，该聚合组对应了2个物理链路vmnic1和vmnic2。所以该聚合组内的任意一个物理链路发生up/down的时候也是不会影响到业务的，逻辑图如下图所示。
所以此时创建配置文件活动上行链路和备用上行链路输入lag1-0 和 lag1-1。
新建传输节点配置文件，选择刚才创建好的上行链路配置文件Lag1，并指定上行链路1、上行链路2
同样也将集群配置NSX，等待完成。
耐心等待一会儿后NSX配置就好了。
同样创建了一个Segment，用于后续使用。
先看下当前的网卡状态
通过命令行查看
esxcli network nic list
nsxdp-cli vswitch instance list看到vdr-vdrPort的传输节点Uplink默认是void，无效的，因为我是嵌套的环境，没有使用交换机做LACP，正常情况下这里应该是显示lag1-0或者lag1-1。
同样，现模拟故障：将vmnic1 物理网卡shutdown 掉，看会是什么情况。
esxcli network nic down -n vmnic1可见状态并没有变化
虽然NSX Manager 提示LAG 成员关闭，但并未对业务造成影响。
业务冗余验证②
由于是嵌套环境，不能对虚拟交换机做LACP所以这里无法记录该过程，今后有机会了再补充。
验证方式如上。
复用聚合链路
将NSX传输节点直接复用lag1组，逻辑图如下所示：
传输节点配置文件中绑定上行选择lag1组。
同样创建了一个Segment03，用于后续使用
VCSA上也同步了该Segment，类型为N-vDS。
通过命令行查看
nsxdp-cli vswitch instance list可以看到vdrPort的传输节点是使用的lag1聚合组。
现模拟故障：将vmnic1 shutdown 掉，看会是什么情况。
esxcli network nic down -n vmnic1根据实际操作可见，vdr-vdrPort的传输节点并无变化。
业务冗余验证③
创建2个虚拟机，并将网络指定到该Segment上。
使用长ping虚拟机IP地址，并up/down物理网卡，和预期一样，在整个过程中虚拟机并无中断网络。
NSX Manager 触发上行链中断告警，但并未对业务造成影响。
总结
此次验证了三种上行链路方式均可满足业务冗余链路需求，在部署NSX-T的时候，需结合实际情况选择最佳方案。
0