vSphere虚拟机网络时断时续

■ 唐山工业职业技术学院 黄骁 孙达明 徐世英

编者按： 笔者某客户在部署教育资源公共服务平台迁移到新服务器时，总是出现无法访问的现象，对此，笔者进行了一系列故障分析和排查，本文正是对此次故障排查进行的总结，其中部分内容进行了简化和模糊处理，希望能对读者有所帮助。

某单位新上了一组服务器，服务器虚拟化使用的软件是VMware vSphere是6.7，该单位将笔者为其部署的教育资源公共服务平台迁移到了新服务器后，该平台总出现无法访问的现象，于是该单位平台运维人员找到笔者，让笔者帮忙解决这个问题。

为了增加同时在线用户数量，该单位的教育资源公共服务平台使用了34台虚拟机，虚拟机上安装的服务器操作系统既有Windows系统，也有Linux系统，34台虚拟机独立组网，这些虚拟机使用的vShere网络没有使用默认的 “VM Network”网络，而是单独添加的“InfoPM” 网络，其网络拓扑如图1所示。

故障现象及排查经历

笔者到达现场后，逐台检查了虚拟机的网络配置，没有发现问题。

图1 网络拓扑图

图2 网络故障说明示意图

用ping命令检查虚拟机之间网络是否畅通，发现虚拟机之间的网络有的能ping通，有的不能ping通。比较奇怪的是，有的虚拟机和其他虚拟机都不能ping通，有的虚拟机和部分虚拟机能ping通，和部分虚拟机不能ping通。

为了更直观地描述故障现象，笔者画出如图2所示示意图，用来描述这个奇怪的网络故障。

假设有 A、B、C、D、E五台虚拟机，在A上不能ping通其他四台虚拟机；在E上能 ping通 C、D，但不能ping通A、B；本次遇到的故障奇怪的地方就是，B、E之间不能通信，但 E、D 之间、B、D之间却能通信。

除此之外，还有更离奇的现象，在E上不能ping通B，在B上却能ping通E。在B上ping通E以后，反过来，在E上重新ping B，此时可以ping通B。

面对如此复杂、奇怪的网络故障，笔者就从和其他虚拟机都不能通信的虚拟机A着手。按照惯例，笔者首先怀疑虚拟机A可能和其他计算机存在IP地址冲突，于是笔者为其更换了IP地址，在用ping命令做通信测试，故障依旧，仍不能和其他虚拟机通信。

难道是计算机名重复引起的网络故障？为虚拟机A更换计算机名后，在用Ping命令做通信测试，测试结果是，它能和虚拟机E、D、C通信，不能和B通信。

虚拟机A能和其他部分虚拟机通信，是虚拟机A和其他虚拟机MAC地址重复了？还是克隆虚拟机或从模板部署虚拟机时，新虚拟机仍用了原来的MAC地址?笔者检查了各虚拟机的MAC地址，没有发现MAC地址冲突。尽管如此，笔者还是想更换故障虚拟机的MAC地址。为了方便修改虚拟机MAC地址，笔者决定用VMware Workstation连接到vCenter Server。具体操作如下：

1.打开VMware Workstation后，依次单击“文件”菜单→“连接服务器”。

2.出现“连接服务器”对话框后，在“服务器名称”文本框输入vCenter Server的名称或IP地址，在用户名和密码文本框中输入登录vCenter Server所需的用户名和密码。

图3 单击“高级”按钮进行配置

3.用VMware Workstation登录到vCenter Server后，找到故障虚拟机，右击故障虚拟机，在右键菜单中选择“设置”。

4.出现“虚拟机设置”对话框后，在“硬件”清单中选择“网络适配器”，在对话框右侧单击“高级”按钮（如图 3）。

5.出现“网络适配器高级设置”对话框后，单击“生成”按钮即可为故障虚拟机生成一个新的MAC地址（如图 4）。

更换虚拟机A的MAC地址后，用ping命令做通信测试，发现这个方法很有效，基本上可以ping通其他虚拟机了。

以此类推，笔者将凡有网络故障的虚拟机都重新生成了一个新MAC地址，经过一段时间努力，终于让该单位的教育资源公共服务平台下所有虚拟机之间都能互相通信了，该单位的教育资源公共服务平台也能正常访问了。

图4 为故障虚拟机生成新的MAC地址

可是好景不长，不到一天，客户单位的这名运维人员又找到笔者，该单位的教育资源公共服务平台又不能访问了。笔者再次检查了虚拟机网络，发现虚拟机之间确实有不能通信的现象，问题出现在哪里呢？原来平台能正常运行，现在只是将平台迁移到新服务器上，难道是ESXi主机网络问题。

笔者检查了新服务器所连接的网络，通过检查发现，该单位为实现网络冗余和负载平衡，在物理交换机上启用了链路聚合。而vSphere标准交换机和vSphere Distributed Switch上的默认负载平衡策略是“基于源虚拟端口的路由”，看来问题就出现在这里。

链路聚合和vSphere负载平衡

要解决前面所描述的网络故障，首先应了解链路聚合和vSphere负载平衡。

链路聚合是将多个物理端口汇聚在一起，形成一个逻辑端口，各端口分担出/入口流量，当交换机检测到其中一个成员端口的链路发生故障时，就停止在此端口上发送封包，并根据负荷分担策略在剩下的链路中重新计算报文的发送端口，故障端口恢复后再次担任收发端口。

可见，链路聚合既可以达到负载平衡的目的，还可以实现链路冗余。链路聚合的应用场景一般是一个IP到多个IP连接，或者是多个IP到多个IP的连接。

vShere提供的负载平衡策略主要有“基于IP哈希的路由”“基于源MAC哈希的路由”“基于源虚拟端口的路由”“使用明确故障切换顺序”等四种策略。

基于IP哈希的路由：虚拟交换机可根据每个数据包的源和目标IP地址选择虚拟机的上行链路。在基于IP哈希的路由策略中，任何虚拟机都可以根据源和目标IP地址，使用网卡组中的任何一条上行链路。如果虚拟机在包含大量独立虚拟机的环境中运行，则IP哈希算法可在组中的网卡之间均匀地分布流量。当虚拟机与多个目标IP地址通信时，虚拟交换机可为每个目标IP生成不同的哈希。因此，数据包可以使用虚拟交换机上的不同上行链路，从而实现更高的吞吐量。如果环境中包含的IP地址较少，则虚拟交换机可能会始终通过组中的一条上行链路传递流量。

基于源MAC哈希的路由：虚拟交换机可以基于虚拟机MAC地址选择虚拟机的上行链路。在基于源MAC哈希的路由负载平衡策略中，虚拟交换机使用虚拟机MAC地址和网卡组中的上行链路数目来计算虚拟机的上行链路。

基于源虚拟端口的路由：ESXi主机上运行的每个虚拟机在虚拟交换机上都有一个关联的虚拟端口ID。基于源虚拟端口的路由策略中，虚拟交换机使用虚拟机端口ID和网卡组中的上行链路数目来计算虚拟机的上行链路，虚拟交换机为虚拟机选择上行链路后，只要该虚拟机在相同的端口上运行，就会始终通过此虚拟机的同一上行链路转发流量。

故障分析

前面所描述的网络故障就是因为在物理交换机上做了链路聚合，而链路聚合的应用场景应该是一个IP到多个IP连接，或者是多个IP到多个IP的连接。

在此场景下，应该选择vShere提供的“基于 IP 哈希的路由”负载平衡策略，而不是vShere默认的“基于源虚拟端口的路由”负载平衡策略。因“基于源虚拟端口的路由”负载平衡策略和物理交换机上所做的链路聚合不匹配，在此种情况下，链路选择很容易失败，虚拟机网络也就会出现时断时续故障，其实，在图2所描述的奇怪的网络故障，就是因为网络时断时续引起。

排除故障

为降低发生网络连接中断的可能性，需要正确配置ESXi主机的vShere负载平衡策略。在本例中，客户单位连接ESXi主机的物理交换机启用了链路聚合，就应该将虚拟机所连接的网络“负载平衡”设置为“基于IP 哈希的路由”，具体方法如下：

登 录vCenter Server后，选择一台主机，在页面右侧选择“配置”选项卡，在设备清单中选择“网络”→“交换机”，在虚拟交换机下拉列表中选择虚拟机网络所连交换机，在本例中，虚拟机网络所连交换机为“标准交换机：vSwitch0”。

如果所选虚拟交换机下面有多个网络，此时应选择故障虚拟机所在网络，在本例中，该单位的教育资源公共服务平台所在网络是默认的“VM Network”,单击“VM Network”网络右侧的“…”按钮，在弹出菜单中选择“编辑设置”（如图5）。

出现“VM Network编辑设置”对话框后，单击左侧“绑定和故障切换”，勾选“负载平衡”右侧的“替代”复选框，在其右侧的下拉列表框中选择“基于IP哈希的路由”（如图6）。

图5 选择“编辑设置”

图6 选择“基于IP哈希的路由”

需要说明的是，前面尽管通过配置ESXi主机网络“绑定和故障切换”，将负载平衡策略设置为“基于IP哈希的路由”。但这个配置不会传播到管理网络端口组。因此还需要按同样的方法配置管理网络“Management Network”，将管理网络的负载平衡策略也设置为“基于IP哈希的路由”。

以此类推，笔者将新部署的几台主机ESXi主机的“绑定和故障切换”策略都从默认的“基于源虚拟端口的路由”更改为“基于IP哈希的路由”后，该单位教育资源公共服务平台下虚拟机相互之间全都能通信了，平台也能访问了。

经过一段时间运行，没有出现前面所描述的虚拟机网络时断时续故障，说明故障已彻底排除。

案例说明

本案例是真实案例，故障排查过程也是真实过程，为了维护客户单位信息网络安全，笔者对上述文字和图片做了技术处理，如有雷同，纯属巧合。