管理员如何避免VMware错误

　　我们经常会看到一些帖子介绍管理员在虚拟环境中应该做哪些事，这里罗列一些你应该避免去做的事情。

　　到目前为止，我写的大多数指南都提到了用户应该做些什么以便更好地维护VMware。现在来看看用户不应该做哪些事。一些VMware错误虽然数量庞大，影响工作，但仍然可以修复。

　　这篇文章介绍的技巧并不全面，系统管理员可以作为参考，或许适用于基础设施。

　　也许我可以提供最简单的技巧之一，就是通过客户端(web或胖客户端)关闭主机时，不要通过SSH控制台重新启动。是的，这可以做到的，如果主机处于维护模式不应该有任何问题。唯一的问题是，我重启了错误的主机。幸好受影响的主机也在维护模式下。我得到了教训。虽然更耗费时间，但它更安全，也是有用的完整性检查。

　　集群准许政策是一个经常被忽视的VMware领域，人们也常常使用不当。理解它的工作原理至关重要。如果管理员希望关闭集群准许政策，确保系统有足够的能力随时应对来自最大主机故障的负载。很少的主机负载大量虚拟机的做法并不可取。

　　企业经常使用高端服务器并用负载100多个虚拟机的主机包装它们。开始还行，直到你由于某种原因或主机崩溃需要把主机调成维护模式。重新启动其他集群的100个虚拟机将对基础设施造成巨大压力并带来潜在的I/O风暴。对于虚拟机的数量还有一个硬性限制，可以重新启动一次。这意味着一些服务器需要排队才能重新启动。服务器需要在新的主机上等待重启，导致停机时间延长。

　　只对一个主机使用存储本地的做法更糟糕。这样做意味着虚拟机连接一个单独的主机是有效的。当主机出现故障时，虚拟机不能在另一个主机启动，存储也不可用。

　　还有些人把“人造”集群放到VMware的环境中。这时通常需要一个共享SCSI总线，因此所有虚拟节点必须驻留在相同的物理主机，这打破了书中的每一个HA（高可用性集群）的设计规则。

　　单台主机的损失意味着整个集群的失败。这可能是一个适合开发的环境，但在生产环境中使用它是有风险的。同样，VMware容错(FT)并非避免集群问题的万全之策。采用FT时，CPU的局限性仍然是一个主要限制。

　　再来说说更复杂的VMware错误，主要版本更新有时会引发问题。在升级期间的失败——尤其是如果使用外部数据库主机，不一定会阻止用户工作。没有集中管理就更困难了。

　　连快照都无法拯救你。当你升级时，数据库模式通常是升级。回滚后将数据库置于危险境地，更有可能的是，你的vCenter数据库将被当成垃圾。如果你能够回滚，vCenter和数据库表的恢复备份是唯一出路。这是VMware建议在升级时不能做的原因之一，从另一方面说明vCenter设备更容易直接升级。

　　如果有问题的网站使用自动精简配置，它只能设置用于存储阵列或VMware的一侧。两侧都用意味着正在运行自动精简配置的两倍，如果大意了，管理就失败了。你应该使用相同的存储设置集群宽度。

　　最后许多新秀管理忽视的是硬件兼容性列表(HCL)，它详细说明了VMware支持的硬件配置。尽管公平地说，大多数硬件工作没有问题，如果你没有按照HCL使用硬件，那就只能看人品了。主机出现故障甚至情况更糟并不是你想要听到的。收拾受伤的心并确保你按照HCL购买硬件。

　　还有许多需要注意的事，我只是抛砖引玉。常识是管理员的最佳工具，紧随其后的是在实践过程中保持谨慎。除此之外,也要时刻积累经验，有时VMware错误是不可避免的。