vSAN一次人肉工程师踩过的坑

vSAN一次人肉工程师踩过的坑

原创 李严省 虚实之路 2017-04-16

         大家星期天好，这几天阳光不错，是个带家人或者女朋友出去转转的好时候。可惜这二天一夜做了VMwarevSAN人肉工程师，这二天一夜如何当好人肉工程师，慢慢为大家好好说说。

 

客户环境

      客户使用VMware vSAN虚拟化存储，具体情况如下所示：

       1.VMware vSphere虚拟化版本为6.0

       2.VMware vSAN为4个节点

       3.每个VMware vSphere节点的硬件配置如下：

• • • Dell R730xd服务器

    • 256G内存

    • 7块6T SATA磁盘、1块800G SSD和2块300G SAS 10K磁盘

    • 配置2个10G以太网口

    • 2台Dell 10G网络交换机

    • Raid型号为H730 mini（1G缓存）

       4.VMware vSAN配置如下：

• • • 2块300G SAS组成为raid1，安装ESXi操作系统

    • 7块6T SATA和1块800G SSD组成磁盘组，用于vSAN

    • H730 Mini配置成为Raid模式，即8块HDD和SSD配置成为raid0，即一块磁盘为一个raid0

    • 每个esxi主机创建1个vmkernel端口，关联两个10G 以太网口，且两个10G网口全为Active模式，没有区分主备。

    • 2台Dell 10G网络交换机相互独立，没有做级联或堆叠，专用于vsan网络。

       5.VMware vCenter部署模式为VMware VCSA虚拟机

       6.有1个虚拟机的虚拟磁盘大小为3T

 

问题原因

 

以上是本客户VMware vSAN真实环境，现在在说一下本次人肉工程师的起因：

 

       前几天下午客户发现有两个esxi主机（简称为esxi01和esxi02）的磁盘出现掉盘的现象，即这二个主机都同时出现一块磁盘不可见。而刚好虚拟磁盘大小为3T的虚拟机的同一组件的两个副本刚好存放在这二个磁盘上，因此这个虚拟机死机，即表现为不可访问，而该虚拟机对客户非常重要，该虚拟机用于每天晚上业务清算，对业务影响非常严重。

 

问题临时解决

       当天晚上到达客户现场，查看服务器的硬盘指示灯为绿色，大概判断二个主机上的2块硬盘硬件上应没有问题，所以建议客户做一次esxi服务器重启动作。开始临时修复故障。首先把esxi01服务器上其它的虚拟机迁移到其它主机，然后进入维护模式（确保数据可访问性），等待几十分钟后，esxi01进入维护模式完成。重启esxi01服务器，丢失的硬盘恢复可见，esxi01主机的磁盘组恢复正常。重复如上步骤也重启esxi02主机，esxi02主机丢失的硬盘也恢复可见，因此4个节点的VMware vSAN恢复正常，3TB大小的虚拟机恢复正常，业务恢复，没有数据丢失。

       根据客户反应，2月份也出现过类似的问题，但当时只有1台esxi主机出现硬盘丢失的现象（硬盘没有亮黄灯），不对虚拟机业务产生影响。然后向dell进行硬件故障报修，更换新的硬盘，然后恢复VMware vSAN。

 

提出建议

       查看客户VMware vSAN环境和客户交流，得知VMware vSAN实现情况，如文章开头客户环境所述。然后查看VMware官方VMware vSAN硬件兼容性例表，建议客户把H730miniraid卡配置为Paas-Through模式，即直通模式，同时听取厂商意见升级VMware vSAN到6.5环境。

VMware vSAN升级改造过程

 

3月14日（星期五）下午

       到达客户现场，迁移esxi01主机上的虚拟机到其它esxi主机，然后进入维护模式（完全数据迁移模式），经过3个小时的等待，完成进入维护模式，即主机上的磁盘不再存储虚拟机数据。然后把该主机从VMwarevSAN集群移走，同时也从VMware vCenter移除。

       由于VMware官网上没有Dell OEM ESXi6.5a镜像，从Dell官网下载Dell OEM ESXi 6.5 GA镜像（Dell官网最新版本），制作成USB启动盘。服务器安装两个8G Dell原厂SD卡到服务器，BIOS设置两个SD卡为镜像。设置H730Mini为直通模式，两块300G SAS磁盘仍旧放在服务器上。然后设置服务器从U盘引导，服务器进入ESXi安装欢迎界面后，立即报错，如下图所示

 

       然后dell 400电话询问关于双SD BIOS设置，再网上google查询各种资料，根据400和网上建议，把SD卡格式化写零，然后安装1片SD卡，再重新安装ESXi6.5系统，仍旧出错，出错信息一样。和客户商量解决办法中，突然脑中一想，会不会是由于原先的2块300G SAS磁盘做成raid1安装esxi操作系统引起的问题？即往SD卡安装esxi的时候，esxi系统不但只检查服务器磁盘硬件信息，也会检测其上的文件系统。然后把两块300G SAS磁盘从服务器上取下，重新从U盘引导安装esxi，esxi安装成功。从开始准备安装esxi到安装完成，总共花去2个小时。

       完成esxi01的vmware esxi 6.5安装后，配置管理IP地址。开始升级VCSA6.0到VCSA6.5a，把VCSA 6.5a ISO镜像上传到Windows 2008 R2虚拟机，使用虚拟光驱挂载vcsaiso文件，无法打开installer.exe

       关闭防火墙后，再尝试，仍旧打不开installer.exe程序。建议客户重新克隆一个干净的windows2008 R2虚拟机，installer.exe总算能打开了，然后开始升级（配图为mac下截图，现场客户为内网，且不能使用个人电脑，不能往外传数据）

 

       升级处于第一个阶段的时候，出现问题了，一直无法向esxi01主机(新装的esxi 6.5)上传VCSA虚拟机，一直处于0%，最后esxi01显示上传ovf超时失败，如下图所示

       然后又建议客户重新克隆一个windows 7虚拟机，且和esxi01主机管理地址同一网段。然后再尝试升级VCSA6.0到VCSA6.5a，最后还是已失败告终。正在准备放弃升级，直接重新安装一个新的vcsa6.5a的时候，脑中突然一想，要不使用我的Mac直接接到他们的内网，使用我的Mac来做升级VCSA，客户一看我的电脑是Mac，不怕中毒，然后同意这么处理。我把Mac接到内网，配置和esxi01同一网段地址，然后开始升级vcsa，果不其然，居然正常升级了，等待40多分钟，完成vcsa6.0到vcsa6.5a的升级。

       完成vCenter升级后，重新使用vc接管esxi01(ESXi6.0)，重新配置vSAN网络，把esxi01(ESXi6.0)重新加入到vSAN集群。

 

然后等待客户11点多开始更换交换机，即把千兆交换机换为万兆交换机。等到1点多，完成交换机切换，检查VMware上的虚拟机及业务，一切正常。然后打道回家，回到家已经2点了。

 

3月15日（星期六）

 

       早上8点多起来，10点到达客户现场，把esxi02的虚拟机迁移至esxi01，迁移的过程一切正常，然后把esxi02开始进入维护模式（完全数据迁移），等待很久，速度非常缓慢，所以放弃等待，下午3点左右回家休息。人老了，昨晚熬到2 点多睡觉，脑袋仍旧没有恢复正常。岁月不挠人啊，年龄大了，别经常熬夜啊，小心脑袋头发掉光。

 

 

3月16日（星期天）

       早上10点又到达客户现场，esxi02完成进入维护模式，把esxi02从分布式交换机移除，再从vSAN和VC移除该主机。然后设置raid卡模式为HBA Mode（直通模式），移除2块300G SAS磁盘，安装2片SD卡，设置为mirror模式。从U盘安装esxi6.5，完成安装，然后配置管理地址，vSAN网络，加入分布式交换机。完成以上配置后，重新加入vSAN集群。又出现问题了，vsan存储没有增加存储容量，且vsan集群重新配置进度很慢，vCenter卡死。。。等待十几分钟后，仍没有好转。直接重启esxi02服务器，完成重启后，各个esxi主机显示vsan存储为本地磁盘组大小，脑袋一惊，要出大事了，然后查看vsan上的各各虚拟机，显示正常。然后立马把esxi02进入维护模式（无数据迁移），然后移出vsan集群，重新刷新vsan集群，其它esxi主机vsan存储空间恢复正常显示（3个esxi主机的磁盘容量）。然后使用vmkping命令检查各个esxi主机的vsan网络，再询问客户的vsan网络交换机的连接方式，2个10G网卡分别连接到两个10G网络交换机，但这二个交换机互相独立，没有做级联或堆叠。但esxi主机的vsan网络连接方式如下图所示：

 

       因此怀疑esxi01、esxi03和esxi04的vmkernel vsan是从上面的vmk9物理网口通信，而esxi02则是使用vmk4网口ccep信，而两个10G交换机又不相互通信，因此出现上面的故障现象。因此又修复vSAN网络配置，把esxi02重新添加到VMware vSAN集群，VMware vSAN存储一切正常。如下图所示:

 

       经过以上各种坑，感觉胜利的希望在眼前了，想着下午可以休息休息了，心里开始乐起来了。然后让客户把虚拟机迁移至esxi02，以检验是否一切正常，当用户开始把虚拟机vmtion到esxi02的时候，esxi02出现无响兴，管理网络无法ping通，到机房检查esxi02情况，显示器上显示紫屏，心情直接要快下雨的难受。然后开始查看esxi日志，显示本地磁盘无法访问，状态为busy，然后建议客户重新弄新拔插硬盘，raid卡总线及10G以太HBA卡，以便排除在安装sd时带来PCI卡的松动。然后再重新开机，再去尝试vmotion，仍旧紫屏（PSOD）。然后打VMware 400电话，客户说该用户为5*8服务，星期天不处理用户case。然后打dell 400电话，询问raid卡的在VMware的直通模式下有无需要特殊设置。然后根据dell的建议重新使用Ctrl+F2进入raid卡bios界面重新设置成no-raid模式，然后重启，vmotion虚拟机仍旧PSOD。然后记得VMware vSAN的硬件兼容说h730 mini的固件版本为25.5，查看当前h730 mini的固件版本为25.4，询问dell如何升级固件版本，根据dell的文档升级固件到25.5版本，然后重新安装esxi6.5，重新配置vsan网络，迁移至vsan集群，一切正常，然后再尝试vmotion虚拟机到esxi02，仍旧紫屏（PSOD）。快要到了放弃的边缘，准备工作日开case询问。

最后把该紫屏的截图发到Cloud Foundation讨论群，群里的各位大神及朋友说，这是一个bug，即vsphere 6.5a发行说明里修复的一个bug，如下图所示：

 

       我立马检查准备迁移的虚拟机的vcpu数量，居然设置为10vcpu，且是vsphere 6.0版本创建的虚拟机，而我当时安装的esxi6.5版本为刚发布的版本，刚好符合bug的描述。因此确定我碰到了bug，而昨天esxi01升级完做虚拟机vmotion时，其虚拟机vcpu数量全部少于或等于8vcpu。而整个vsan集群中只有今天需要迁移虚拟机的vcpu数量为10，因此昨天没有触发bug。

       而回想最开始下载esxi的时候，原本也是下载esxi6.5a的版本，但由于vmware官网没有dell oem镜像，然后到dell官网下载oem esxi镜像，而其镜像为esxi 6.5刚发布的版本，因此存在此bug。

       下载补丁包，升级esxi02和esxi01到vsphere 6.5a版本，该问题修复。到此完成2台esxi主机的raid卡模式改换及版本升级。

 

总经：

       经过2天一夜的人肉工程师，总算完成一半的工作内容，由此可见vSAN的运维相对比较费时间。因此说vSAN这产品不好码？那肯定不是的，为什么会出现这些乱七八的问题，根本原因就是项目最开始的规划，如服务器配置的是h730 mini低端的raid卡，且磁盘为6T SATA磁盘，而6T SATA磁盘速度相对比较慢，一个大容量磁盘其存放的虚拟机组件会比较多，即会出现一块磁盘关联很多个虚拟机，且主机数量只有4个，因此很大机率出现二块磁盘（不同主机）故障而导致虚拟机不可用。同时HDD的磁盘和SSD磁盘的容量比不符合10%的比率。项目实施工程师在实施过程中不去查看硬件兼容性推荐设置，即推荐使用直通模式，却使用raid0模式，而vsan网络没有设置主备之分（在交换机不做堆叠及级联情况下）。

       从本次项目经验可以看出，一个vSAN效果好坏，是由前的售前工程师（vSAN规划）和实施工程师来决定，如果vSAN硬件规划存在不合理，再加上实施工程师的水平限制，导致vSAN后续维护麻烦，且需要花费太多时间（esxi主机进入维护模式需要好几个小时，有可能十多个小时），会让客户望尔却步。因此vSAN不是表象那么简单，一定要把控好规划和实施过程，再加上一定IT水平的维护人员，才能把vSAN用好，才能真正发挥vSAN强大优势！以上仅仅个人的理解，欢迎大家指正，谢谢！