分布式虚拟交换宕了

故障缘起

笔者一直以来都对虚拟化环境中的“暗流量”抱有兴趣，很想真切观察同一个VLAN内虚机之间通信是否真的不被送到uplink网卡的物理交换机，也很想看看管理流量的规律，以及vMotion流量的峰值。带着这些好奇，笔者配置了ntopng，计划使用VDS（Virtual Distribution Switch）所自带的端口镜像功能将流量转发到ntopng进行观察。

故障现象

配置过程并不顺利，不管是单个或多个端口流量镜像到ntopng网卡，还是VLAN流量镜像到ntopng网卡，在ntopng上都不能观察到流量的明显增加，同时ntopng主机上监控网卡流量也未能看到明显的变化，让我分不清到底是ntopng收不到流量还是VDS未转发流量。

在不断的反复调试中，我见端口和VLAN都不能抓取流量，可被镜像的对象还有vmk0可选择，于是，未经缜密的思考，就将集群中8个ESXi的vmk0全都镜像到了ntopng的网卡上，在点击确定的一瞬间，ntopng及其主机马上观察到了明显的流量，心中顿时一喜，然而接下去的几秒钟中里，不安感立即超过了欣喜，因为流量大得惊人，从第一眼看到的100多Mbps，到短短5秒内，流量超过900Mbps，脑海里还想着整个群集的流量不可能这么大的同时，虚机也随之失去了响应，迷茫了几秒钟后，vCenter的连接也丢失了，我忽然意识到，这下犯了大错误了，整个虚拟化环境都受到影响了。

理清处置思路

vCenter的忽然中断从来就不是好事。在当前情况下，下意识间去做的，就是检查运行在虚拟化集群中重要服务的状态，结果是一部分服务打不开了，另一部分能打开的速度也非常慢，可谓是喜忧参半。喜的是虚机自身的状态可以确定都还是保持开机的，也就是并未造成所有虚机集体重启，那么只要恢复了网络就能快速恢复受影响的业务；忧的是vCenter的网络也已经不可连接，8个ESXi中有7个都无法连接，加之集群所用的VDS配置并未事先备份，网络受损的程度及恢复时间仍难以估量。

根据对当前情况的初步判定，首先确定处置的第一原则，要在保持所有虚机不异常重启的状态下去尝试恢复网络，因为只要不强制关闭或重启任一虚机，一旦网络可用，业务就能最短时间内恢复，且不会造成虚机内文件损坏或服务非正常停止等异常，若造成虚机内的异常，可能会比分布式虚拟网络的恢复更麻烦。

恢复虚机网络的尝试

登录还存活的惟一一个ESXi，查看其状态没有明显的异常，其上虚机的响应速度也正常，除此之外也找不到其他线索来定位网络问题所在。

从无法登录的7个ESXi中随机挑选一个ESXi，在服务器控制台登录SHELL，使用命令vim-cmd vmsvc/getallvms查看虚机清单列表，然而却得到“503 service unavailable”的提示。使用命令uptime查看平均负载，可以看到load average非常高，比平时虚机高峰负载观察到的平均负载还要高出数倍。又挑选了另2个ESXi进行同样的观察也是相同的现象。基于此分析，出问题的7个ESXi一定都跟超大的镜像流量是有关系的，镜像的vmk0除了处理自身的业务流量，还会不断叠加这些流量，从而可以印证ntopng接收到的流量是几何倍数快速增加，故而vmk0无论多强大，都无法处理不断叠加的镜像包，CPU资源也会被快速叠加的流量消耗完，于是有的虚机网络非常慢，有的甚至完全中断。

那么，是否重启ESXi的网络就会恢复呢？带着疑问，挑选了一个ESXi在SHELL下执行了/sbin/services.sh restart命令，等待许久却是个执行失败的回复。回到ESXi Console，在图形界面下重启Management Agents，提示成功，立即用vsphere client登录该ESXi，以非常慢的速度登录成功，不过又很快失去了连接。利用重启管理网络的方法尝试了另几个ESXi，要么很快失去了连接，要么还是网络不通，惟一的收获，是定位到了vCenter所在ESXi节点。

基于上述判断再次梳理思路，当前的VMkernel其实没有别的错误，问题应在vmk0保持了流量镜像指令的执行而无法正常响应，如果有命令能停止vmk0的流量镜像，网络应该是马上可以得到恢复的。不过，经过一番搜索努力，一方面没能找到相关的资料，另一方面网络的恢复也不能无限制地等待下去，需要果断采取一些措施。

挑选一个ESXi主机，进入控制台界面，选择Restore vDS菜单，勾选所有uplinks接口和Restore to default blocked setting，将该ESXi的VDS进行初始化，随即测试该ESXi上的业务访问已经恢复正常，这一结果让原本焦躁的心情得以稍稍平静，查看uptime负载，也下降到正常时极低的数值，于是又连续初始化了3个ESXi的VDS。此时，忽然想起vCenter上ESXi的状态到底如何，查看之下，这4个初始化了VDS的ESXi在vCenter上都是警告状态，网络配置里也找不到初始化之后的分布式虚拟交换机，尤其是物理网卡在vSphere Client上怎么都找不到了，也就无法划分物理网卡到虚拟交换机了，心中顿时凉了一半，难道这样处置仍存在未考虑周全的地方？

为避免恢复过程造成次生破坏，同时验证分析的网络问题和实际是否相一致，决定对剩下的3个ESXi初始化为标准虚拟交换机。根据已有的知识积累，初始化为标准的vswitch会清理该ESXi上所有网络的配置，初始化结束后需要登录到ESXi上重新配置ESXi的管理和业务VLAN，并将虚机划分到新建的VLAN中才能恢复网络，同时也需要在vCenter的清单中先删除这3个ESXi，待管理网络配置后再重新添加到vCenter，步骤相对麻烦许多，但这样恢复后是可以完全查看和管控虚拟网络配置的。此时，在vCenter中可看到集群的状态仍在警告，仅初始化VDS的ESXi也提示：“与主机上的代理交换机对应的vSphere Distributed Switch在vCenter Server中不存在或不包含此主机”。

由此分析，仅初始化VDS应该是系统生成了新的VDS和vmk0取代了原有故障，但这个新的VDS并未注册到vCenter，故而在vCenter中不可查看和管理物理网卡及虚拟网络，在当前所有虚机网络都已恢复的情况下，可以松一口气，但完全恢复健康的VDS状态仍需小心谨慎。

恢复分布式虚拟网络

基于前面的努力，当前环境中实际存在两个VDS，一个是旧的，另一个则是系统生成但却不可见，这两个VDS已都不可恢复到正常健康的状态，因此需要新建一个VDS来取代现有的两个。

创建VDS，创建VLAN的端口组，迁移物理网卡到VDS的uplink，初始化为vSwitch的网络都顺利迁移成功，但初始化为VDS的ESXi仍无法找到物理网卡，在此情况下，4个ESXi逐一创建vSwitch仍会存在找不到物理网卡的情况，能想到的惟一解决办法只有继续初始化到vSwitch，这样一来，这4个ESXi上虚机仍会面临短时的断网，所能做的只是如何缩短中断的时间。

由于每个ESXi都有4个物理网卡作为uplink，重置到标准虚拟交换机后，先划分2个物理网卡给VDS，保留2个网卡在vmk0上，这样就可以马上批量迁移虚机的端口组到新的VDS上，并且能够连通业务网络，只要动作熟练，每个ESXi上虚机断网时间可以控制在3-5分钟内，待确保虚机网络畅通后，再来迁移剩下的2个物理网卡和vmk0到VDS，既不影响在vCenter上的操作，也缩短了处理过程的断网时间。

如此处理完后，每个ESXi逐一检查网络的配置和状态，确定每个虚机都正常，逐一重启每个ESXi，确保重启后运行正常，且在vCenter上没有报错信息，然后重启一次vCenter并确认不再有报错信息，分布式虚拟网络和集群都恢复正常，最后再删除旧的VDS和恢复过程产生的vSwitch。此时距离故障发生，已过去6小时。

经验总结

虽然每次都是这样被自己“手贱”搞出事情，但也不得不承认在这样的经历中进步得更快，对知识的理解和运用更为深刻。

首先，除了上述的主要问题，次生了两个问题。一是vCenter里配置的虚机管理权限存在部分丢失情况，需要重新给相应的用户配置虚机管理的授权；二是vcops的vapp发生了解体，当然这个直接把虚机拖回到vapp里即可。

其次，之所以在ntopng里没看到期望的流量，原因不在VDS，而是ntopng没有安装收费的流量分析插件，仅安装了免费的ntopng程序仅能查看本机网卡上的流量，而不能过滤转发过来的镜像流量，这也就导致了我因看不到流量而不断调整镜像端口引发了本次故障。

最后，对于vmk0应引起足够的重视，它不仅是虚拟网络运行的内核，也是物理网络与虚拟网络的处理核心，同时它也是软件。本次故障的根源还是在片面的知道vmk0会拥有所有的虚机流量，简单的把它当作了uplink，却忘记了转发层也是它自身。