VMware虚拟化实施配置平台高可用.docx

VMware虚拟化实施配置平台高可用提供一个稳固安全高效的虚拟化架构平台其实并不是一件很简单的事情。其中的网络虚拟化设计、集群高可用设计、资源调度策略设计、存储的高可用高性能设计、部署实现动态化及运维的自动化等等都是需要精心考虑、细致琢磨、频繁优化才能使其成为一个功能扩展性强、功能稳定可靠、性能发挥持久化的基础平台。在社区上周的交流活动“VMware虚拟化实施过程中的最佳实践点探讨 - 如何配置平台高可用细节策略”中，众多社区会员分享了相关经验。由活动嘉宾Zhao Hai梳理、补充知识，形成如下典型案例及知识点。【案例篇】案例分享之一：存储Thin模式也可能导致的问题案例问题描述：由于开发测试环境存储资源使用状况非常不均衡带来的空间浪费情况太严重，于是对于所有的开发测试环境进行了重组。第一、虚拟化环境内的所有虚拟机存储采用Thin模式。第二、存储设备上划出的Lun也采用Thin模式。第三、开启虚拟化上存储集群的DRS开关。第四、建立严格的存储空间使用监控机制。重组问题一个一个来执行，大量的虚机该重建重建，该迁移迁移。整整折腾了好几天。当所有人都在积极忙于监控自动化以及监控策略的时候，问题发生了，开发人员说开发环境有问题，应用发布失败，有的甚至都无法登录系统了。过程描述：起初有点傻了，感觉是之前的重组过程有问题导致的问题。登上虚拟化环境一看，好多虚拟机处于灰色状态，几乎处于不可操作的状态。好多开发人员的虚拟机报出磁盘写入错误。= 查存储吧。1.果然，存储告警。怎么可能，留的空间明明不少啊，虽然是Thin模式也不至于两天就满了啊。2.从虚拟化环境内，查虚拟机的具体占用情况。一查总的占用量，果然超了。3.查具体的虚拟机，发现有几个虚拟机，占用空间量惊人。两天之内从实际占用空间的100G，直接超过1T。= 应用IO，BUG，导致狂占磁盘到最大限度。因为虚拟机一开始分配的时候，由于是Thin模式，几乎所有的虚机都是看似非常大，但是实际占用非常小的模式。因为运维的同事认为他们平均使用空间不可能超过100G空间，而Thin模式的阀值是按照每个机器150G的余量来设计的，所以认为不足为虑。问题总结：这个问题本其实是一个很简单的问题。但是从运维管理上，对我们应该有所启示：1 Thin模式的设计本身来讲，是为了节省资源。实际上也帮我们做到了这一点。理论上只要我们做好监控，及时补充存储空间的不足，那么这个模式应该是个性价比很高的事情。2 任何事情都会有特殊场合，如果我们对特殊情况没有预想到，那么很可能会走到另一个弊端上。假设我们对Thin模式资源的最大申请比率也有一个控制，比如说最大300G。那么再异常的情况的影响面儿仅限于某个虚拟机。案例分享之二：高可用策略不合理导致的面积性故障案例问题描述：某天早上，公司内部好多办公系统登录失败。邮件系统、流程管理、代码管理等。但是过了大概一个小时，基本所有情况都恢复正常。问题确认：业务系统的状况：没有任何异常情况，一切访问正常。数据中心基础实施：连续好多系统报警，而且还有物理主机报警，问题一大堆。解决过程：先来描述一下环境，基本90%以上系统运行在Vmware虚拟化平台之上，业务系统和内部办公管理系统完全隔离为两个不同的集群环境。办公区为8台宿主机组成的物理集群，集群共享一台存储设备上的存储资源。首先，我们再一次确认了宿主机的情况，5台宿主机当前运行状态正常，虚拟机也处于正常状态。只有一台宿主机处于失联状态。当把这一台宿主机再次重新启动之后，它也恢复正常了。再次，查看问题发生时间的日志，包括宿主机日志。我们发现有好多虚拟机发生了HA切换，不仅仅是故障主机上的虚拟机，而且还包括其他非故障主机上的虚拟机。再仔细看，还有好多虚拟机发生了热迁移，有的迁移失败，有的迁移成功。总之几乎所有主机上的虚拟机发生过HA和热迁移现象。随后，我们再次确认宿主机硬件日志，发现故障时刻点先后有三台宿主机发生重新启动。这样的话，事情就清楚了，几台宿主机先后发生重新启动，触发宿主机上的虚拟机发生HA，在这个过程中由于资源使用的瞬间不均衡，又触发了DRS的自动迁移。这么多事情发生的时间又是如此之集中，那么最终导致面积性的故障发生。问题总结：此次问题之后，我们根据环境资源重新评估了HA和DRS等的策略，将激进策略修改为相对保守的策略。本来虚拟化的HA和DRS策略是为了保障虚拟机的平衡和高可用性的机制，但是在某种不合理策略策略和极端物理故障场合下就有可能导致比正常故障范围还要大很多的面积性故障。试想，如果DRS处于非激进状态，那么在发生HA的时候，即使资源不够，那么故障范围仅限于很小一部分虚拟机，不会发生彼此影响，而且时间集中化的影响。尤其是Windows的虚拟机，成功热迁移的概率比Linux要低很多。所以提醒大家合理设置高可用策略。案例分享之