今天，虚拟化技术通过各种方式对最终用户环境产生影响，从存储到服务器，再到网络都离不开虚拟化。而同时由此引发的问题也不断上升。尽管服务器虚拟化技术已经相当稳定，管理员还是要认真考虑负载均衡问题。每个应用对服务器都有一定的计算资源需求，因此负载均衡很重要，通过它我们可以在大量的服务器之间分配工作负载以满足各种应用的需求。

　　对于内存和I/O密集型应用也同样适用。错误的负载均衡可能导致虚拟化引发对应用程序性能和稳定性的影响，最终在主机上的所有虚拟机停止工作。在部署之前进行的测试可以识别应用对资源的确切需求以帮助管理员对负载分配做出最佳选择。

　　负载均衡最佳实践

　　一定不要追求服务器利用率100%的理论效果，更不要做过分配。虽然提高整合度是虚拟化的魅力所在，但是保留一定的计算资源以预防突然增大的应用需求是必须的，包括也要预留故障切换的空间。

　　如果每台物理机计算资源都达到100%，当其中一台失效时就没有可以完成故障切换的空间。专家的建议通常是保持服务器利用率在50%到80%之间。某些资源密集型或关键生产应用甚至在一台物理机上只安装一个单独的虚拟机。

　　时刻牢记无论是虚拟机崩溃或是物理硬件故障，都会对该服务器上运行的所有虚拟机同时产生影响。因此生产系统的潜在风险更高，尽管多数IT专家了解这一点，但他们总是忽略由于停机和重建引发的后果。

　　试想某个运行了30台虚机的服务器，如果服务器宕机，所有的30台虚机都受影响，而多数管理员对于同时处理30台服务器宕机的情况还缺乏经验。故障切换机制可以帮助我们利用其它服务器的保留资源，把虚机从故障服务器迁移出来，或是从存储系统上完成重建。当服务器修复后，没有通过故障切换功能保护的虚机，管理员需要进行手动重启或重建。

　　修复虚拟化问题是一个缓慢的进程
　
　　在物理机上重建虚拟机需要占用计算资源，这会导致可用资源的减少，从而减慢后续其它虚机的重建过程，由此会使得预先规划好的重建过程可能要占用一整天的时间。

　　First Flight Federal Credit Union是一家金融机构，他们的COO兼SVP Todd Erickson重新计算了一个控制器失效后的重建时间。

　　“所有的一切都是完美的，”他说，“所有的数据都在，我保留有备份、快照，它们都是可用的。但是我没有想到的是重建所有镜像的总体时间大约有22个小时。某些应用甚至在整个工作日内都无法工作。”

　　重建问题应该在真实故障发生之前进行有效测试和衡量。网络在虚拟化问题中提及的并不太多，但是为虚拟架构部署一个可以提供必要带宽和弹性的网络系统也很重要。例如，iSCSI SAN就不太适用于运行SQL 或Exchange系统的虚拟机。

　　类似的，像实时交易订单录入系统这样的流量密集型应用可能会影响虚拟终端的性能，导致键鼠输入延迟或者是面临大量的图像更新。任何虚拟化的部署都必须首先完成对网络系统需求的充分测试。

　　虚拟化也会导致所有故障诊断过程变得复杂。例如，某个由虚拟存储创建的LUN可能会横跨多个物理RAID组，甚至是子存储系统上的存储空间。同样我们可以方便地在多个物理服务器之间迁移虚拟机，灵活性是虚拟化技术获得成功的原因之一，但是管理员需要依靠专业知识和经验积累来帮助用户快速分离和解决问题。

　　“可以对问题虚拟机进行管理的功能已经开始崭露头角，” Ga的财务和会计领域SaaS供应商I-Business Network LLC公司的技术服务总监Ty Hacker这么说。Hacker认为很明显管理工具将成为他重点关注的领域，因为单个问题虚拟机可能会导致整个主机发生问题。