🔮2x16 分布式交换机其实可以这么玩！ - 《🚀 VMware》

最近晓冬参加了一次客户交流，在谈起对vCenter日常运维的建议时，说了说自己的看法。我们聊到虽然在VMware虚拟化的世界里，vCenter一直扮演【管理平面组件】的角色，它的故障不会造成业务虚拟机的中断。管理员依旧可以使用vSphere Client访问ESXi服务器来实现对虚拟机的基本管理。但不可否认的一点是，在vCenter出现故障后，如果只是简单地重建VC，必然会出现包括证书问题、分布式交换机管理问题、SSO域用户权限问题等。其中最令管理员“头疼”的是分布式交换机的管理问题，也正因如此，许多管理员宁愿不用分布式交换机，而改用标准交换机。
在晓冬看来，这是一种并不推荐的“因噎废食”的做法。vCenter的高可用性和可恢复性完全可以通过vCenter HA+vSphere HA+有计划的自动备份来实现。我们知道，分布式交换机的管理，包括创建、关联主机、创建端口组等都是在vCenter界面完成的。在vCenter出现故障后，连接到分布式交换机上虚拟机端口组的虚拟机网络通信并不会受到影响，毕竟真正的【数据平面组件】是ESXi服务器的内核。在通过各类手段恢复vCenter后，自然也就恢复了分布式交换机，且毕竟有很多实用的功能，是标准虚拟交换机所不具备的。因此，我一只建议管理员依旧采用分布式交换机来承载业务流量。今天也趁这个机会，就来和各位简单说说分布式交换机一些常用且实在的功能。
👓0x01.分布式交换机和端口组是可以集中创建并管理的
这是一个显而易见的好处，试想如果一个vSphere群集内包含16台主机，并且需要配置除了管理VMkerneal端口以外的其他16个虚拟机端口组，那么一共需要配置16x16=256次，这是一个相当大的工作量了。即使管理员愿意投入这样的工作量，但是也不排除期间由于误操作（比如VLAN漏配了），导致虚拟机在连接到对应的端口组之后，出现无法正常通信的情况。(这种看似低级的配置纰漏，其实在日常运维中经常发生。)
">
在使用vDS的情况下，管理员只需要在vCenter上配置一个分布式交换机和16个分布式虚拟机端口组，再关联到所有群集内的主机（也支持跨群集关联），就实现了所有主机的网络配置，在大大减少工作量的同时，也避免了人为误操作造成配置有误，造成业务中断的情况发生。
">
有人说，“即使使用vDS，也可能出现人为的配置漏洞啊！”的确，为了避免这种情况的发生，vDS提供了“端口健康状态检查”功能，提醒可能出现纰漏的配置情况。
">
👓0x02.支持端口镜像
我们知道，在日常运维过程中，管理员经常会通过交换机的“端口镜像”来帮助进行排障或业务梳理等。对于虚拟化场景来说，一台服务器上可能承载了几十台甚至更多的虚拟机，如果在服务器的上联端口配置“端口镜像”，虽然可以抓到需要的“数据包”，但是也会有许多其他虚拟机的“无关的数据包”。更何况在两台虚拟机位于同一台ESXi主机的情况下，使用物理交换机进行“端口镜像”无法抓取到这种不出ESXi主机流量的情况。
对于采用vDS承载虚拟网络流量的场景来说，利用vDS的“端口镜像功能”就可以轻松解决上述两种痛点。来看个简单的实验：
将Web01和Web02迁移到同一台ESXi上，并进行持续的PING。
">
这种不经过ESXi的上联VMNIC，也就是不经由物理交换机进行转发的流量，无法用传统的端口镜像方式进行抓包分析。那么就需要使用vDS的端口镜像功能了。
">
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-CFFD9157-FC17-440D-BDB4-E16FD447A1BA.html">vDS支持多种端口镜像的模式，我们使用最常用的“分布式端口镜像”即可。有兴趣的朋友，可以自行阅读VMware官方的材料：https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-CFFD9157-FC17-440D-BDB4-E16FD447A1BA.html
">
设置端口镜像的源是Web01虚拟机。
">
设置端口镜像的目的是另一台与它们位于同一个L2网络的无关虚拟机。
">
接下来，我们在目标虚拟机上通过抓包工具或者命令进行分析，可以清晰地看到ICMP的数据包已经被镜像到目的虚拟机。
">
可见使用vDS的端口镜像，可以帮助管理员轻松实现抓包和排障的需求。
👓0x03.网络IO控制
这是晓冬最喜欢在项目中使用分布式交换机的最重要原因，因为它具有“网络IO控制功能”，也叫NIOC。其实在很多项目中，出于成本和跳线等因素的考虑，一台服务器可能只配备了一块双口的万兆网络适配器来承载ESXi的所有网络流量。那么此时摆在管理员面前的选项有几个：
选项A：采用标准交换机，无非就是累一点。
选项B：一个网口用来走管理，标准交换机；另一个走业务，分布式交换机；但是缺少了冗余性，对业务而言也少了50%的可用带宽。
选项C：采用分布式交换机承载系统（管理和迁移）、业务流量、以及其他的如vSAN、备份等流量，通过NIOC来保障业务的稳定运行。
在满足许可合规性的前提下，选项C理所当然地会成为用户管理员的首选。管理员可以配置多块VMNIC承载vDS的上联，通过合理的“负载均衡策略”来实现冗余和最大化带宽利用率。
">
通过定义预留策略，来为虚拟机流量“划盘子”。分布式交换机最多可以预留可用带宽的75%提供给虚拟机（或者其他多种类型流量总和）使用。比如下图：我的分布式交换机每块上联VMNIC都是普通的千兆网卡。因此最多可以预留750Mbps带宽提供给各类流量使用(注意，NIOC的预留、共享、限制都是针对单独的物理网络适配器生效的)。
由于我的分布式交换机也同时承载了ESXi管理、vMotion、NFS数据存储这样的系统流量，我必须进行合理的NIOC来满足业务的稳定性和性能：
现在，首先预留100Mbps提供给ESXi管理使用；100Mbps提供给vMotion使用；100Mbps提供给NFS使用；200Mbps提供给虚拟机使用。
同时，将为虚拟机流量配置600Mbps的限制。
在完成上述配置后，如果ESXi的物理网络适配器吞吐并没有达到饱和，自然不需要做网络IO控制，包括虚拟机、ESXi管理、迁移等类型在内的各种流量甚至可以占满整个带宽（虚拟机会有600Mbps的峰值限制），毕竟NIOC是在资源竞争场景下为了满足特定功能对象的网络性能而存在的。但是如果网络流量非常大，各种流量出现竞争的时候，NIOC的作用就明显了。比如：系统管理员正在通过Web Client上传一个庞大的系统补丁到ESXi本地盘；ESXi根据DRS策略，正在进行虚拟机工作负载的再平衡，所有的虚拟机都运行在后端的NFS共享存储上；App01和App02虚拟机之间正在进行正常地相互通信……各种类型的流量都会尝试争用带宽，都想独占1Gbps的“蛋糕”。
">
可事实上，当启用了NIOC后，系统管理员上传系统补丁的带宽将至少满足100Mbps的要求，vMotion将至少满足100Mbps的要求，满足迁移任务可以并发稳定地进行；ESXi和后端NFS存储将满足至少100Mbps的要求，确保虚拟机稳定健康地运行……虚拟机之间的相互通信将满足至少200Mbps的带宽，但是为了避免过度抢占资源，会被限制到600Mbps一下……有人说，那么剩下的500Mbps尚未被“预留”的带宽，会如何分配呢？
">
如上图所示，其实每一种流量除了预留和限制之外，还有一个“共享”的权值。如果各种流量最终会完全占用1Gbps的带宽，那么对于虚拟机流量而言，它可用的最大带宽：
最大带宽=200+100/(100+50+50+50)*500=200(预留)+200(争用)=400Mbps
同理，NFS可用的最大带宽=100+50/(100+50+50+50)*500=100+100=200Mbps
由此可见，合理运用NIOC既能满足某种流量最小的带宽需求，又能避免它完全占用带宽，影响其他的系统或者业务流量。
做个简单的测试吧：
使用vMotion，将App01和App02运行在不同的ESXi主机上。可以看到，在没有任何策略限制的前提下，Web01和Web02之间的可以占用超过800Mbps的带宽（TCP测试）
">
晓冬现在将总带宽限制到600Mbps，再次进行测试。
">
这次Web01和Web02之间的带宽被限制到了600Mbps以下。
">
这是一种类似“总体规划”的NIOC策略，在实际的项目中，管理员会进一步定义各类不同的“网络资源池”。用以应对出现资源竞争时，不同优先级虚拟机占比网络带宽的要求。
记得在晓冬考VCAP-DCV-Deploy认证的时候，有一道实验题大意上是这样描述的：
用户的生产和测试用户都运行在同一个群集上，要求考生通过网络策略，为总体业务流量预留500Mbps的带宽，当出现资源竞争的时候，生产业务可以保证有50%的可用带宽，测试业务有20%的可用带宽…….
">配置的方法也很简单。对于这个vDS来说，由于各台服务器合计有10个网络适配器上联，因此总预留带宽是200Mbps10=2Gbps。既然要预留50%的可用带宽，那么就需要预留1Gbps提供给High优先级的端口组使用（即生产业务流量）。同样地，预留2Gbps10%=200Mbps给Medium优先级的端口组使用（即测试业务流量）。
完成资源池的划分后，接下来需要将对应的分布式交换机端口组DvPG关联到这些网络资源池，就可以实现更为精确的网络IO控制。比如下图所示的端口组：
">
当各类流量出现竞争的时候，NIOC会根据策略的定义，来满足特定虚拟机的流量有充足的带宽保障。但是这里不得不提一句，想要真正发挥NIOC的优势，需要为群集开启分布式资源调度DRS功能。
如下图所示，当有一台新的虚拟机VM3将要被开启电源时，由于ESXi1主机的上行链路已经趋于饱和，没有足够的带宽资源分配给VM3；在配置了DRS的情况下，VM3将会在其他带宽充分的主机，如ESXi2上被开启。
">
同样的道理，如下图所示，当ESXi1的其中一根上行链路出现故障，已经无法同时满足VM1和VM2的带宽预留要求的时候，DRS会将两台虚拟机中带宽占比高的一台虚拟机迁移到其他带宽充裕的ESXi主机上，从而实现NIOC配置文件预留的要求。
">
这些常用且实在的功能，都是标准虚拟交换机所不具备的。当然，分布式交换机还支持LCAP和NetFlow(与vRealize Network Insight集成，实现对应用拓扑自动描绘、防火墙策略、网络可见性等高级功能)。
">
相信各位通过今天的分享能够了解到分布式交换机的优势和实用。其实很多时候，管理员觉得某个产品或者功能不好用，往往是对这款产品存在一定的误解或者未按照最佳实践的建议来配置。这一点晓冬也是深有体会，所谓“技术”的提升，依赖于日常的积累，其中包括了原理的深入和实践的推进。今天我们从vCenter聊到了分布式交换机。下次我们看看是否来聊一聊别的一些“最佳实践”，敬请各位持续关注。

最近晓冬参加了一次客户交流，在谈起对vCenter日常运维的建议时，说了说自己的看法。我们聊到虽然在VMware虚拟化的世界里，vCenter一直扮演【管理平面组件】的角色，它的故障不会造成业务虚拟机的中断。管理员依旧可以使用vSphere Client访问ESXi服务器来实现对虚拟机的基本管理。但不可否认的一点是，在vCenter出现故障后，如果只是简单地重建VC，必然会出现包括证书问题、分布式交换机管理问题、SSO域用户权限问题等。其中最令管理员“头疼”的是分布式交换机的管理问题，也正因如此，许多管理员宁愿不用分布式交换机，而改用标准交换机。

在晓冬看来，这是一种并不推荐的“因噎废食”的做法。vCenter的高可用性和可恢复性完全可以通过vCenter HA+vSphere HA+有计划的自动备份来实现。我们知道，分布式交换机的管理，包括创建、关联主机、创建端口组等都是在vCenter界面完成的。在vCenter出现故障后，连接到分布式交换机上虚拟机端口组的虚拟机网络通信并不会受到影响，毕竟真正的【数据平面组件】是ESXi服务器的内核。在通过各类手段恢复vCenter后，自然也就恢复了分布式交换机，且毕竟有很多实用的功能，是标准虚拟交换机所不具备的。因此，我一只建议管理员依旧采用分布式交换机来承载业务流量。今天也趁这个机会，就来和各位简单说说分布式交换机一些常用且实在的功能。

👓0x01.分布式交换机和端口组是可以集中创建并管理的

这是一个显而易见的好处，试想如果一个vSphere群集内包含16台主机，并且需要配置除了管理VMkerneal端口以外的其他16个虚拟机端口组，那么一共需要配置16x16=256次，这是一个相当大的工作量了。即使管理员愿意投入这样的工作量，但是也不排除期间由于误操作（比如VLAN漏配了），导致虚拟机在连接到对应的端口组之后，出现无法正常通信的情况。(这种看似低级的配置纰漏，其实在日常运维中经常发生。)

在使用vDS的情况下，管理员只需要在vCenter上配置一个分布式交换机和16个分布式虚拟机端口组，再关联到所有群集内的主机（也支持跨群集关联），就实现了所有主机的网络配置，在大大减少工作量的同时，也避免了人为误操作造成配置有误，造成业务中断的情况发生。

有人说，“即使使用vDS，也可能出现人为的配置漏洞啊！”的确，为了避免这种情况的发生，vDS提供了“端口健康状态检查”功能，提醒可能出现纰漏的配置情况。

👓0x02.支持端口镜像

我们知道，在日常运维过程中，管理员经常会通过交换机的“端口镜像”来帮助进行排障或业务梳理等。对于虚拟化场景来说，一台服务器上可能承载了几十台甚至更多的虚拟机，如果在服务器的上联端口配置“端口镜像”，虽然可以抓到需要的“数据包”，但是也会有许多其他虚拟机的“无关的数据包”。更何况在两台虚拟机位于同一台ESXi主机的情况下，使用物理交换机进行“端口镜像”无法抓取到这种不出ESXi主机流量的情况。

对于采用vDS承载虚拟网络流量的场景来说，利用vDS的“端口镜像功能”就可以轻松解决上述两种痛点。来看个简单的实验：

将Web01和Web02迁移到同一台ESXi上，并进行持续的PING。

这种不经过ESXi的上联VMNIC，也就是不经由物理交换机进行转发的流量，无法用传统的端口镜像方式进行抓包分析。那么就需要使用vDS的端口镜像功能了。

vDS支持多种端口镜像的模式，我们使用最常用的“分布式端口镜像”即可。有兴趣的朋友，可以自行阅读VMware官方的材料：https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-CFFD9157-FC17-440D-BDB4-E16FD447A1BA.html

设置端口镜像的源是Web01虚拟机。

设置端口镜像的目的是另一台与它们位于同一个L2网络的无关虚拟机。

接下来，我们在目标虚拟机上通过抓包工具或者命令进行分析，可以清晰地看到ICMP的数据包已经被镜像到目的虚拟机。

可见使用vDS的端口镜像，可以帮助管理员轻松实现抓包和排障的需求。

👓0x03.网络IO控制

这是晓冬最喜欢在项目中使用分布式交换机的最重要原因，因为它具有“网络IO控制功能”，也叫NIOC。其实在很多项目中，出于成本和跳线等因素的考虑，一台服务器可能只配备了一块双口的万兆网络适配器来承载ESXi的所有网络流量。那么此时摆在管理员面前的选项有几个：

选项A：采用标准交换机，无非就是累一点。

选项B：一个网口用来走管理，标准交换机；另一个走业务，分布式交换机；但是缺少了冗余性，对业务而言也少了50%的可用带宽。

选项C：采用分布式交换机承载系统（管理和迁移）、业务流量、以及其他的如vSAN、备份等流量，通过NIOC来保障业务的稳定运行。

在满足许可合规性的前提下，选项C理所当然地会成为用户管理员的首选。管理员可以配置多块VMNIC承载vDS的上联，通过合理的“负载均衡策略”来实现冗余和最大化带宽利用率。

通过定义预留策略，来为虚拟机流量“划盘子”。分布式交换机最多可以预留可用带宽的75%提供给虚拟机（或者其他多种类型流量总和）使用。比如下图：我的分布式交换机每块上联VMNIC都是普通的千兆网卡。因此最多可以预留750Mbps带宽提供给各类流量使用(注意，NIOC的预留、共享、限制都是针对单独的物理网络适配器生效的)。

由于我的分布式交换机也同时承载了ESXi管理、vMotion、NFS数据存储这样的系统流量，我必须进行合理的NIOC来满足业务的稳定性和性能：

现在，首先预留100Mbps提供给ESXi管理使用；100Mbps提供给vMotion使用；100Mbps提供给NFS使用；200Mbps提供给虚拟机使用。

同时，将为虚拟机流量配置600Mbps的限制。

在完成上述配置后，如果ESXi的物理网络适配器吞吐并没有达到饱和，自然不需要做网络IO控制，包括虚拟机、ESXi管理、迁移等类型在内的各种流量甚至可以占满整个带宽（虚拟机会有600Mbps的峰值限制），毕竟NIOC是在资源竞争场景下为了满足特定功能对象的网络性能而存在的。但是如果网络流量非常大，各种流量出现竞争的时候，NIOC的作用就明显了。比如：系统管理员正在通过Web Client上传一个庞大的系统补丁到ESXi本地盘；ESXi根据DRS策略，正在进行虚拟机工作负载的再平衡，所有的虚拟机都运行在后端的NFS共享存储上；App01和App02虚拟机之间正在进行正常地相互通信……各种类型的流量都会尝试争用带宽，都想独占1Gbps的“蛋糕”。

可事实上，当启用了NIOC后，系统管理员上传系统补丁的带宽将至少满足100Mbps的要求，vMotion将至少满足100Mbps的要求，满足迁移任务可以并发稳定地进行；ESXi和后端NFS存储将满足至少100Mbps的要求，确保虚拟机稳定健康地运行……虚拟机之间的相互通信将满足至少200Mbps的带宽，但是为了避免过度抢占资源，会被限制到600Mbps一下……有人说，那么剩下的500Mbps尚未被“预留”的带宽，会如何分配呢？

如上图所示，其实每一种流量除了预留和限制之外，还有一个“共享”的权值。如果各种流量最终会完全占用1Gbps的带宽，那么对于虚拟机流量而言，它可用的最大带宽：

最大带宽=200+100/(100+50+50+50)*500=200(预留)+200(争用)=400Mbps

同理，NFS可用的最大带宽=100+50/(100+50+50+50)*500=100+100=200Mbps

由此可见，合理运用NIOC既能满足某种流量最小的带宽需求，又能避免它完全占用带宽，影响其他的系统或者业务流量。

做个简单的测试吧：

使用vMotion，将App01和App02运行在不同的ESXi主机上。可以看到，在没有任何策略限制的前提下，Web01和Web02之间的可以占用超过800Mbps的带宽（TCP测试）

晓冬现在将总带宽限制到600Mbps，再次进行测试。

这次Web01和Web02之间的带宽被限制到了600Mbps以下。

这是一种类似“总体规划”的NIOC策略，在实际的项目中，管理员会进一步定义各类不同的“网络资源池”。用以应对出现资源竞争时，不同优先级虚拟机占比网络带宽的要求。

记得在晓冬考VCAP-DCV-Deploy认证的时候，有一道实验题大意上是这样描述的：

用户的生产和测试用户都运行在同一个群集上，要求考生通过网络策略，为总体业务流量预留500Mbps的带宽，当出现资源竞争的时候，生产业务可以保证有50%的可用带宽，测试业务有20%的可用带宽…….

配置的方法也很简单。对于这个vDS来说，由于各台服务器合计有10个网络适配器上联，因此总预留带宽是200Mbps10=2Gbps。既然要预留50%的可用带宽，那么就需要预留1Gbps提供给High优先级的端口组使用（即生产业务流量）。同样地，预留2Gbps10%=200Mbps给Medium优先级的端口组使用（即测试业务流量）。

完成资源池的划分后，接下来需要将对应的分布式交换机端口组DvPG关联到这些网络资源池，就可以实现更为精确的网络IO控制。比如下图所示的端口组：

当各类流量出现竞争的时候，NIOC会根据策略的定义，来满足特定虚拟机的流量有充足的带宽保障。但是这里不得不提一句，想要真正发挥NIOC的优势，需要为群集开启分布式资源调度DRS功能。

如下图所示，当有一台新的虚拟机VM3将要被开启电源时，由于ESXi1主机的上行链路已经趋于饱和，没有足够的带宽资源分配给VM3；在配置了DRS的情况下，VM3将会在其他带宽充分的主机，如ESXi2上被开启。

同样的道理，如下图所示，当ESXi1的其中一根上行链路出现故障，已经无法同时满足VM1和VM2的带宽预留要求的时候，DRS会将两台虚拟机中带宽占比高的一台虚拟机迁移到其他带宽充裕的ESXi主机上，从而实现NIOC配置文件预留的要求。

这些常用且实在的功能，都是标准虚拟交换机所不具备的。当然，分布式交换机还支持LCAP和NetFlow(与vRealize Network Insight集成，实现对应用拓扑自动描绘、防火墙策略、网络可见性等高级功能)。

相信各位通过今天的分享能够了解到分布式交换机的优势和实用。其实很多时候，管理员觉得某个产品或者功能不好用，往往是对这款产品存在一定的误解或者未按照最佳实践的建议来配置。这一点晓冬也是深有体会，所谓“技术”的提升，依赖于日常的积累，其中包括了原理的深入和实践的推进。今天我们从vCenter聊到了分布式交换机。下次我们看看是否来聊一聊别的一些“最佳实践”，敬请各位持续关注。