摘要：在今年9月份的一个虚拟化项目中，项目前期一切正常。在为服务器添加、更换内存之后，出现ESXi主机存储断开、虚拟机系统慢、ESXi主机启动慢的故障，经过多方检查，终于排查了故障。最终故障的原因很简单：ESXi主机与存储的连接光纤出现问题导致了故障的产生。但整个项目过程中涉及到了更换内存、更换主板、升级固件等一系列事件，所以前期故障分析中没有正确的定位故障点，导致事情越来越复杂。下面我把整个过程还原一次，希望此事对其他经常做项目的朋友有所帮助。
这个项目比较简单：2台联想3650 M5的主机（每主机配置1个CPU、128GB内存、单口8GB FC HBA接口卡）、1台IBM V3500存储，每台主机安装了VMware ESXi 6.0.0 U2的版本，有6个业务虚拟机、1个vCenter Server虚拟机用于管理。拓扑如图1所示。
图1 某单位虚拟化拓扑图
在项目的初期，安装配置ESXi主机、划分IBM V3500存储、创建虚拟机后，各个业务虚拟机对外提供服务，系统一切正常。在全部业务虚拟机正常运行两天后，观察到主机内存使用率超过60%接近70%时，我对客户建议将每台服务器的内存扩充到256GB，甲方技术主管在汇报领导后，同意了扩充内存的要求，但是就是在这个扩充内存，引起了后续一系列的故障。
说明：使用vSphere Client登录vCenter Server，在左侧导航器中选中群集，在右侧“主机”选项卡中，可以看每个主机配置的内存、已经使用内存的百分比。图2是每台主机配置到256GB之后的截图，当时128GB截图没有保存。这是项目正常之后的截图，从图中可以看出，系统中所有虚拟机使用内存大约170GB，在每台主机只有128GB的情况下，使用内存是66%，在每台主机扩充到256GB后，使用内存33%。
图2 主机内存、CPU使用率
联想3650 M5服务器，支持2个CPU，每个CPU有12个内存插槽，每个内存插槽最大支持单条64GB内存。故每个CPU最大支持64×12＝768GB内存。
在这个项目中，每台联想3650 M5配置了8条16GB的内存，只剩余4个插槽（当前主机只配置了一个CPU），如果要扩充到256GB内存，可以再购买4条32GB或2条64GB内存，进行“混插”。但这样客户后期将不能继续进行内存扩充，这样不是好的升级方案。我给出的方案是，建议为每台服务器配置4条64GB的内存，拆下的内存折旧或内存置换。联系了长期为我们提供内存的公司，对方答应可以4条16GB换成1条64GB的内存，这样对三方有利。
8条64GB的内存到位之后，为每台服务器更换内存。内存更换过程中，可以将所有虚拟机暂时迁移到另一台主机，这样业务不会中断。
服务器安装内存是有“讲究”的，必须按照指定的位置进行安装。每台服务器的盖板上都有内存的安装顺序，例如联想3650 M5内存安装顺序如图3所示。
图3 联想3650 M5内存安装顺序
即：单个CPU的内存安装顺序是1，4，9，12，2，5，8，11，3，6，7，10；双CPU的安装顺序依次是1，13，4，16，9，21，12，24，2，14，5，17，8，20，11，23，3，15，6，18，7，19，10，22。例如当前主机安装了8条16GB内存，则需要安装在1，4，9，12，2，5，8，11位置。安装之后，在开机之前可以在IMM中看到安装的内存信息、内存是否正常，如图4所示。
图4 当前安装了8条16GB内存截图
但是，将4条64GB的内存插上之后，服务器开机无显示，在IMM中也没有检测到内存，如图5、图6所示。
图5 没有检测到内存
图6 内存详细信息、无内存
后来一条一条内存安装，服务器也是检测不到内存。没有办法，将原来的8条16GB内存插回主机。
联系内存经销商之后，更换了镁光的单条64GB的内存，安装成功（内存往返又是三、五天的时间），如图7所示。说明，此次不能用的单条64GB内存，我在DELL R720XD主机上使用是没有问题的。
图7 检测到4条64GB的主机
但是，关键问题是这个“但是”。在为第1台主机顺利的安装更换了内存之后，为第2台主机安装内存的时候出了大问题。在插上这4条64GB内存之后，主机无法开机，在IMM检测，提示系统出现严重故障（System Critical），如图8所示。
图8 System故障
经过联系联想的售后，工程师说主板坏了，这下我们就“晕”了，这服务器也太不“结实”了吧？没办法，只能等售后工程师上门更换主板了。
所幸我们离北京较近，售后第2天上门更换新的主板之后，故障依旧。这时大家都有点“糟”了。但是，还是工程师有经验。工程师换上原来的16GB内存之后，服务器可以开机，一切正常。但换上这4条内存之后还是出现图8的故障。之后工程师，采用一条一条安装64GB内存，检测到其中的一条有问题，后来安装了3条64GB内存，如图9所示。
图9 当前安装3条内存
这样我们就更郁闷了，一条内存故障就能让服务器开不了机，以后如果内存万一坏了一条是不是也会出同样的故障呢？这些问题我们就先不考虑了。之后又等了几天，厂商发来了新内存，插上之后4条内存全部认到。
本来以为项目进行到这就完成了（当时是9月30号），但是（该死的“但是”又来了）上班之后问题又来了……
10月5号该单位第一天上班，客户反映虚拟机ERP系统慢。
我当时不在现场（更换内存时我不在现场，是公司其他工程师实施的）。我远程登录，在检查的过程中，发现其中一台ESXi12主机（IP地址172.16.6.12）的存储连接断开，在“清单”中有一个虚拟机变灰，如图10所示，但此时使用远程桌面是可以登录这个虚拟机的。
图10 没有检测到共享存储
此时在左侧选中172.16.6.12这台主机（ESXi12），“配置→存储”中共享存储已经变灰不可访问，如图11所示。
图11 在第2台主机存储变灰
但另一个主机ESXi11（IP地址为172.16.6.11）存储正常，但fc-data02显示的可用容量为0，如图12所示。
图12 第1台主机存储正常
登录IBM V3500存储，在存储中检查到一切正常，如图13所示。
图13 存储中检测到正常
在重新扫描存储没有反应之后，我重新启动故障主机。正常情况下，主机在5～8分钟之后会上线，但等了有30分钟，这台重新启动的主机也没有上线，PING这台主机的IP地址也不通，这时候我就有点着急了，坏了，这台没出现问题的服务器也出问题了（换主板的是另一台服务器）。
这时我还在家，我马上联系公司的人、联系客户，说服务器出了问题，需要马上赶过去。
一路无话，下午赶到现场之后，发现我远程重新启动、出问题的那台那台服务器已经“正常”了。但感觉虚拟机系统还是有点慢。之后我重新启动这台主机，终于发现了问题，就是这台服务器启动特别慢。BIOS自检到系统启动这一环节还算正常，但从出现ESXi的界面之后到进入系统，时间非常的长。
在进入ESXi界面之后，分别在“nfs41client loaded successfully”（如图14所示）、“Running sfcbd-watchdog start”（如图15所示）各停留大约30多分钟。
图14 在此停留半小时
图15 在此停留半小时
因为另一台主机更换过主板与内存，这台主机只更换过内存。而在换内存之前系统正常。初步判断可能是更换单条64GB内存引起的，但网络中另一台服务器也是安装了4条64GB的内存，这台主机正常，忘记说了，另一台正常的主机更换过主板。检查这两个主机，发现正常运行的主机的固件比较新（ESXi11的主机），因为这台主机换了一块新主板。之后我为出故障的主机（ESXi12）刷新固件到同版本，系统启动变快了一点，但仍然没有解决问题（还是在图14、图15停留很长时间）。这时已经是晚上8点多了，先暂时不解决了，回去换个思路。
第二天一早来到客户现场，我参考联想工程师的方法，一条一条的“试”内存。在一条一条“试”内存的过程中，插上每条内存启动速度都很快，从出现图14、图15所示的ESXi的启动界面，几分钟就进入系统出现ESXi的控制台页面（出现IP地址等信息），但试过内存没问题之后，将所有内存都插上，系统启动就又变慢了。
之后，换上原来拆下来的单条16GB的内存（当时内存还没有发回厂家），ESXi启动时间变为半小时，但ESXi主机反应仍然较慢。
这样时间就又过去了2个多小时，问题还没有解决，能想的都想过了，能尝试的都尝试过了，那么问题出在那呢？
我思考，为什么插上单条64GB内存很快，内存全部插上就变慢呢？这时我注意到了一个“细节”，在插单条64GB内存的时候，为了加快测试速度，我没有插网线和存储光纤（每次关机拔内存都要断电，要把服务器从机柜中拉出来，后面的网线、光纤也是拔下的）。然后我思考，网络问题不会引起ESXi启动慢，那么问题就可能出在服务器与存储的连接光纤上！因为每台服务器只配了一块单口的FC-HBA接口卡，服务器与存储只有一条光纤连接，没有冗余。将出问题的这台服务器更换光纤之后，重新启动服务器，启动速度正常（大约不到5分钟就进入了ESXi的控制台界面），至此问题解决。
总结
事后分析，因为前几天反复更换内存、为服务器更换主板，反复为服务器加电、断开、从机柜中拉出服务器，可能碰到了ESXi12这台服务器的光纤，导致光纤出故障，但光纤又没有完全断，可能处于“时通时断”的状况，这样服务器在连接到存储时，会反复尝试，或者有错误的数据包需要纠错。如果光纤完全断开，服务器检测不到就会跳过连接存储，反而是这种“时通时断”的连接，导致服务器反复尝试，增加了服务器的启动时间。
更多虚拟化课程及视频，请单击“VMware系统集成工程师”专题。
http://edu.51cto.com/topic/1308.html
原文地址：http://blog.51cto.com/wangchunhai/2102841
