对于VMware虚拟化技术，大家可能或多或少都接触过，第一印象都是上手简单。但是真正在生产环境实施VMware虚拟化基础架构的时候，前人通过宝贵的经验和血泪的教训告诫我们，千万不要犯以下4个错误：
1.想当然，不按流程走
案例：操作失误导致的写入失败
问题描述：
有一个DataStore始终写入失败，报错很简单，就是写入失败。
解决过程：
第一反应，先确定是宿主机问题还是存储问题。测试其他DataStore，完全正常。那就把问题缩小到这个DataStore上来。可能是挂载或者格式化的时候出现了问题，重新来呗，结果还是一样。
第二反应，重新挂，从存储上把Lun抽回去然后再分配给主机。还是一个熊样。
第三反应，查看Vmware底层日志，看似有锁信息。
第四反应，谁加的锁呢?为什么不释放呢?
第五反应，仔细询问实施工程师，原来这个DataStore并没有从Vmwware层面进行卸载就通知存储工程师将其重新分配了。他说这么干过很多次了，重来没没有出过问题。
第六反应，不用想了，Vmare对这个Datastore加了scsi锁，这个锁加在了Lun的盘头。在非正常释放Datastore的场合下，及时存储回收了，当它再次给到Vmware的时候，盘头信息并没有消除。锁依然存在，所以无法写入。
第七反应，存储上讲该存储回收再次分配。问题消除。
问题总结：
试想，如果当时工程师按照正常的流程，把磁盘从Vmware层面进行卸载，然后存储再回收，那就不会有这个问题了。
999的成功不等于1000一定成功，因为我们面对的外在环境不一定相同或者相似，所以一切操作请按照正确的流程去做。
2.只关注自己的一亩三分地
案例：防火墙导致的宿主机失联
环境介绍：
多套vmware虚拟化集群组成一个VDC，分别位于不同的安全隔离区内，VC处于一个独立的安全隔离区内，每套虚拟化集群当中有若干宿主机。也就是说宿主机和VC分别属于不同的安全隔离区，分属不同的网段。
问题描述：
虚拟化基础架构部署全部完毕，运行一致良好。突然间有一天发现其中一个安全隔离区内的宿主机有一个掉线了。还没等我来的及区调查原因，这个宿主机又恢复正常了。
解决过程：
第一反应，别的先别说，不可再现的问题，先看日志吧。结果发现其中一个宿主机掉线非常频繁，其他几个宿主机偶尔都会发生掉线现象。而且现象只发生在其中一个安全隔离区内，其他隔离区内没有此现象。
第二反应，问问应用那边，看看有没有察觉到异常。结果没有。
第三反应，那不用多想了，这个离线一定是宿主机跟VC之间的通讯断掉了，没有影响到正常的业务系统。
第四反应，看看日志，第一感觉没啥有价值的线索。为啥其他集群没事儿呢，想想这个区和其他区的区别在哪里?同一个VC，只不过分属不同的安全隔离区而已，只不过这个区属于互联网区，网络层多了几层隔离而已。
第五反应，一方面，收集日志发给厂商。另外一方面，交叉测试，于是乎，交叉换网卡，还是一个德行。
交换换交换机，好像好一点，但是还会出现类似问题。
第六反应，那剩下的区别就在防火墙上了，防火墙这个区用的是莫某家的，跟其他不一样。不至于吧，虽然国产，但是也经得起推敲啊。于是把网络的运维工程师以及厂商叫过来抓包，抓了好几天，问题没有重现。等吧，Vmware那边终于给回复了，说是VC和宿主机的通讯被周期性阻断了。
第七反应，多半是防火墙上的设置，找吧。对比两家厂商的防火墙设置，终于发现了一个配置“Keep Alive”,问网络厂商是不是可以像别人家的防火墙把这个开关关掉。回答说不能。靠，为什么?回答说，产品默认设置。问曰，你们有没有在别家跟虚拟化产品配合过?回答曰，配合过，没这个问题啊。啥也别说了，升级给网络后线吧。过了几天，回复了，“Keep Alive”在防火墙上可以吧UDP的关掉，TCP的不能关掉。OK，要的就是这句话，把UDP关掉之后，观察了N天，一切OK。
问题总结：
对于这个案例来讲，更多的关注点是在虚拟化架构与其他厂商设备配合过程中的问题。一个很不经意的配置可能会引起很严重的问题。
大家多多交流，上下游交流，同游交流，不仅仅知道自己的一亩三分地，也同时知道他人的一亩三分地，对于实施来讲就会带来更大的专家价值。
3.实施后不重视检验过程
案例：网卡绑定失误导致的业务中断案例
环境介绍：
宿主机四台，每台配置两块双口万兆网卡;接入交换机两台。
网络分管理网段和业务网段，每一个网卡上的双口分别上联两个不同交换机，交换机对端口设置Trunk模式，允许任何网段通过，不需要做绑定。网卡侧需要按照交叉方式绑定四个端口为两组，分别走业务和管理，交换机不需要绑定。
问题描述：
所有虚拟化环境部署完毕，在结合业务做切换测试的过程中，开发人员报告部分业务系统不可访问。
解决过程：
第一反应，先做客户端到应用系统的Ping测试。DNS解析没有问题，但是网络不可达。
第二反应，网络可能有问题，检查客户端到目标网段的网关可达性。网关全部可达。
第三反应，问题出在接入交换机和宿主机链接上，难道发生了双点故障?于是询问运维人员设备监控情况如何?运维人员说一切正常，没有发现异常。
第四反应，什么情况?监控一点直觉没有么?再问。
问：某某机柜某某交换机有没有问题?某某机柜某某服务器有没有报警?
答：回答说，没有报警，不过....不过什么?有一个交换机在升级firmware，属于正常停机，不在异常范围之内。
问：就一个?
答：对，就一个。
第五反应，不对啊，任何单点都不可能影响到架构的高可用啊。VC登录上去查具体的机器状态，结果所有机器处于运行状态。再次确认问题出在接入交换机和宿主机之间的链接上。于是让运维人员进入机房再查网卡以及交换机状态。报告说有一台机器的其中一个网卡的两个口全部没有上联信号。
第六反应，网卡帮错了。再查，网卡绑定顺序与其他同类型的机器顺序一样啊。查MAC对应关系，结果发现这台机器的Vmware显示的网卡顺序确实与其他机器识别达到的网卡设备名顺序不一样。当初实施工程师仅仅靠着一个样本机的网卡设备文件名与物理网口的对应关系就按照一个标准实施了。
问题总结：
对于这个案例来讲，其实高可用的设计也好，网卡绑定技术也好都不是问题。问题的关键是工程师想当然认为一种型号的机器对于IO设备文件名的识别顺序是完全一致的。其实不然，不同场合下可能设备文件名的顺序会产生不一致。幸亏这个问题是在测试阶段发生。
第一个案例已经说过不要想当然，此处更要强调实施后的检验过程非常重要，可以救你一条命。
4.不能未雨绸缪、防微杜渐
案例：VMware虚拟机响应异常故障排查案例
问题描述：
某日，根据运维同事反映，在VMware虚拟化平台上的某系统出现严重的延迟现象，在通过操作系统登陆后，进行操作的响应时间特别长，且较之前有明显的卡顿现象。针对此问题，针对该虚拟机的运行情况进行了分析。
解决过程：
首先，想到的是排查该虚拟机所在的Esxi主机的性能，发现该主机CPU利用率在20%左右，内存利用率在40%左右，IO读写延迟不超过1ms，且该Esxi主机上面的其他虚拟机都运行正常，所以基本排除了该物理主机的问题。
接着，便在Vcenter中重点对该虚拟机的配置及日志进行检查，通过登陆Vcenter管理控制台查看该虚拟机的配置，发现该虚拟机的磁盘文件下面存在大量的-delta.vmdk文件，不同于其他普通的.vmdk文件。初步将该问题定位于此，并将该问题发送给VMware工程师，经过分析，确认是过多的delta文件直接导致了系统响应异常。
那么为什么会产生这么多delta文件?一般而言，虚拟机快照会产生delta文件，VDP备份软件也会在备份之前进行虚拟机快照从而产生delta文件。而当客户操作系统内执行一个磁盘操作时，磁盘I / O重新解析磁盘文件链中的每个delta文件。这将产生额外的主机磁盘开销，从而导致性能问题。而该虚拟机的应用系统因平时变更频繁，所以运维同时在变更前都要执行快照，且长时间没有将快照删除。
问题总结：
经过该问题的出现，日后在VMware化平台的维护中特别注意将重复快照的删除，否则时间久了，且存在大量的快照会影响虚拟机的性能。同时，要定期通过SSH登陆到ESXi服务器，查找是否有delta文件产生。如果文件数量过多的话可能导致更为严重的无法连接的错误，需要及时解决。
本例中分享者做到了一旦发现问题，就要考虑将来要未雨绸缪、防微杜渐，及时和定期操作。
本文结合生产环境实施 VMware 虚拟化基础架构实例分析，但其实以上错误，在任何项目实施中都不应该犯。
抢沙发
