VMware的vSphere虚拟化平台以可靠性著称，内置了诸如高可用（HA）等功能，确保物理服务器故障对最终用户的影响降到最低，但不是所有Vmware用户都使用了这些功能或类似的技术，即使使用了这些功能也不能保证不会发生意外，于是一个非常现实的问题就摆在了我们面前：当虚拟机速度变慢或宕机，ESXi服务器或vCenter失去响应等异常发生时，我们该做些什么？
vSphere故障解决概述
为了准备Vmware认证高级专家 – 数据中心管理员认证，以及vSphere故障解决课程，我花了大量时间解决各种vSphere故障，我甚至故意将vSphere破坏掉，然后尝试进行修复，大多数时候我会成功，但也有失败的情况。如果你也想在解决vSphere故障时取得成功，需要考虑的事情太多了，只要下面任何一项未考虑到，整个虚拟化基础设施（VI）可能就会崩溃。
◇ 物理服务器：ESX和ESXi服务器需要电源、CPU、内存和本地磁盘，这些组件都有可能出现故障。
◇ 物理网络：当你运行vSphere客户端时，本地LAN为物理服务器、交换机、SAN/NAS、DNS服务器、终端用户和你（管理员）提供连接保障（vSphere客户端是一个管理工具，管理vSphere全靠它）。
◇ 共享存储：存储通常由SAN或NAS提供，大多数时候，如果SAN或NAS失去响应或连接丢失，虚拟基础设施将会受到影响。
◇ ESX和ESXi服务器Hypervisor：服务器上的操作系统当然得正常运行，如果ESX或ESXi服务器遇到PSOD（紫屏），预示着马上要出大问题了。
◇ vCenter：虽然vCenter不是虚拟机或ESX/ESXi服务器正常运行必需的东西，但借助它你可以查看虚拟基础设施的运行状态。
◇ 虚拟机（VM）：如果Windows VM遇到BSOD（蓝屏），恰好这个VM提供关键网络服务，如域名解析服务，活动目录或vCenter，如果它宕机了，整个基础设施都将受到影响。
方法论
由于虚拟基础设施（VI）正常工作涉及到的核心组件太多，你需要一个标准的，系统的问题解决方法，对于不同的组织可以采用不同的方法，但重要的是，无论你使用什么方法，每次遇到VI故障时，都应该使用相同的方法，并按同样的顺序执行操作。
例如，你的方法可能以开放系统互联（OSI）模型为基础，那么你应该从物理层开始，然后逐层上升，直到应用程序层，或者从应用程序层向下到物理层。但我建议你从OSI模型的中间层（网络层）开始，根据问题的具体情况决定是向上还是向下排查。
◇ Ping ESX/ESXi服务器和vCenter服务器：验证服务器是否开机或网络是否连通，如果ping失败，你应该先检查网络和电源，如果成功，则可以跳到下一步。
◇ 尝试使用vSphere客户端登录到vCenter：如果不成功，尝试登录到ESX/ESXi主机，如果成功，继续通过vSphere查看存储是否可用，主机是否出现故障，运行vCenter的VM是否宕机等等。
◇ 检查vCenter进程：假设vCenter不可用，但VM运行在一个正常的主机上，如果需要，可以重启vCenter进程。
这些只是解决虚拟基础设施（VI）常见问题的一般步骤，下面我们一起来看一个更特殊的例子。
vSphere崩溃后该做些什么
有人向你报告问题时，你首先要做的是获取更多与问题相关的信息，如什么服务不可用？的确如此吗？物理服务器出了问题吗？vCenter VM蓝屏还是服务被停掉了？核心网络交换机被锁住了？SAN电力供应出现问题？仅仅是一个VM宕机，还是所有VM都当掉了吗？没错，你应该先回答这些问题，找到确切的答案。
用户不知道究竟是什么当掉了，他们也不关心这个，但这是你的工作，你可能猜到问题处在哪里，也许只需要一个小小的测试便能得知问题的根源，但需要注意的是，即使你相信自己真的找到了问题的根源，也要做完全面的测试，我不止一次遇到因测试不完整就确定问题根源而做出的错误决定，如原本是网络问题，误认为是服务器问题。
仅凭某个用户报告的不确定问题要查明vSphere的真正问题根源是很困难的，用户通常只会报告他们的应用程序不能正常工作了，你需要快速地得到该用户正在使用哪些服务，对应的应用程序是否运行在VM上，然后一步步查找到问题之所在。
例如，如果你通过vSphere客户端连接到vCenter服务器，这一结果可以得知许多事情 – 网络肯定是连通的，DNS工作正常，你的PC可以连接到vCenter服务器，SAN运行正常，你的vCenter服务器和ESX主机通信正常等。
换句话说，如果你熟悉基础设施，只需要简单的测试，就可以快速找出问题的根源。
虚拟基础设施（VI）中的大多数问题都与操作系统或应用程序有关，而不是VI自身的问题，在一些有前瞻性的企业里，总是能看到强大的系统管理工具，在终端用户感知到问题发生之前，你可以提前预知可能出现的问题，但在许多企业中，还是终端用户最先发现并报告问题，我们还是以上面的例子来解释，假设终端用户报告某个应用程序不能使用，你知道这个应用程序运行在VM上。
图 1 vSphere客户端图形化显示一台ESXi服务器的性能指标
首先检查客户机操作系统和应用程序，你通过vSphere客户端连接到VM的控制台来实施检查，操作系统是否蓝屏？服务对应的应用程序出了问题？如果发现是客户机操作系统或应用程序的问题，首先应该解决它们的问题。
假设你发现ESX/ESXi服务器启动并运行正常，VM已开机，客户机操作系统运行也正常，但运行在VM上的应用程序响应仍然很慢。
这时你应该检查ESX/ESXi主机的性能 – 通常使用vSphere客户端，但你也可以使用第三方工具，在这个例子中，一切看起来都很正常。
图 2 vSphere客户端图形化显示一个虚拟机的性能指标
从上图可以看出，主机只有25%的内存利用率，CPU、磁盘和网络利用率也都在合理范围内。
接下来，切换到vSphere客户端的“性能”标签，检查VM的内存性能。
注意观察性能不佳应用程序驻留的VM的内存利用率，你可以获得两个结果：这个VM的内存配置过低，或应用程序本身消耗的内存过多。
使用Windows任务管理器检查内存利用率，你会发现消耗内存过多的进程，在这个例子中，VM只分配了1GB内存，而这个应用程序就消耗了462MB，几乎用掉了一半内存。
图 3 通过Windows任务管理器查看内存消耗过多的进程
如果内存被不是你希望的应用程序使用（如一个恶意软件或一个游戏），你可以杀掉它对应的进程或卸载那些应用程序。
另一方面，如果它是一个合法的进程，它的内存使用量也是可以调整的，你应该增加VM的内存，为操作系统和应用程序提供更多的内存
如果VM开启了vSphere热插拔内存（或热添加CPU）功能，你可以在VM运行期间动态分配更多的内存，不需要关闭客户机操作系统或停止终端用户的应用程序。
图 4 在虚拟机运行期间动态增加内存
延伸阅读提示
Vmware发布了一份名叫“Vmware vSphere 4.1性能故障排除”的完整指南，它提供了详细的故障排除流程图，这份68页的文档比我这篇文章要详细得多，涵盖了vSphere故障解决的方方面面。
vSphere通常是非常可靠的，并且内置了许多功能保护终端用户应用程序，防止服务器故障，但是，随着使用vSphere（或其它Hypervisor）的时间增长，出现物理硬件（服务器、SAN或网络）故障或软件（ESX、ESXi、vCenter或客户机操作系统）故障的几率就越大，遇到问题时，要综合考虑这些组件，才能帮助你快速地解决问题。
原文名：Virtualization: What to do when vSphere goes down 作者：David Davis
译文链接：http://virtual.51cto.com/art/201105/259668.htm
