超融合节点虚拟机密度问题？

以4节点的超融合为例，如果4台机器上的虚拟机资源消耗超过了3/4.那么。当一个节点重启的时候必然会有一部分虚拟机的资源无法的到满足而产生影响。可以通过对业务的分级来调整。比如把重要业务和不重要的业务划分开。通过策略实现当某个节点挂掉的时候优先保证重要业务。
另外还有一种就是尽可能的保证系统资源占用预留一个节点以上。保证任何一个节点重启时业务不受影响。
定期巡检。保障机房动力及环境也是超融合架构域内的重要环节。一方面不出问题。一方面就是保障出问题后的应急预案。

宿主机配置拉高，虚拟机的密度必然增大，遇到宿主机宕机的极端情况，HA切换的时间也可能会相应的延长。虽然现在虚拟化层针对HA的机制更加智能了，能序列化、并发进行，但是单台宿主机上虚拟机的密度变大，故障和风险的影响范围必然扩大不少，潜在隐患风险系数自然高。

几个经验性的建议：
1，将宿主机分成多个逻辑集群，核心业务部署在高规格集群，虚拟机密度适当降低。非核心业务部署在中低规格集群，预留充足的HA资源。
2，业务集群化部署，至少2节点部署。同时指定亲和性策略，将同一个业务的几台虚拟机分配到不同的物理节点上。同一类型的业务，不要同时放到同一区域/片区的宿主机上，避免突发极端情况，该类业务全线凉凉。
3，禁用DRS之类的功能，手工指定分配宿主机资源，如果对HA要求高，单独针对不同级别的业务制定配置HA策略。

1、先确保群集中有冗余的主机，当故障发生时，冗余的机器能够接管且性能足够
2、VM 主机的操作系统和数据盘分开，通过方案实现故障时数据的转移操作只限于操作系统层面
3、主机网络和存储网络分离，评估存储网络和主机网络，统计故障迁移时涉及的数据调整情况（主要是VM的内存大小），实际测试迁移到启动的用时（大部分的等待时间都在数据传输阶段）。网络视情况配置10G、40G或100G环境

建议规划使用冗余一台作为备份，防止突发宕机造成业务无发切换使用。
划分业务服务重要，核心重要业务优先保证，次一级的业务按需规划。
如果条件允许可以搭建私有云环境。

1、首先是使用阈值限制，至少预留一个节点资源应对物理节点故障的风险，（4节点，预算1/4，3节点，预留1/3）；
2、核心应用系统正常都是双机，分布在不同的物理节点，多节点同时宕机故障的情况发生率较低；多集群部署，主备节点部署在不同机柜/机房的不同超融合集群，及时挂掉一个集群，其他集群可以接管业务；（真正生产的核心系统必然会有一定的运营保障投入）
3、优先级策略设置，出现故障，优先保障重要核心机器的运行；
4、没钱投入就压榨员工吧，制定完备的管理和运维方案，定期对设备进行巡检、系统应用情况分析，保障集群可以健康的跑着。

一切的问题都是因为花钱少

超融合节点运行的虚拟机数量受到节点计算资源和每个虚拟机计算资源分配的双重影响，节点计算资源越多，单个虚拟机的资源越少，那么节点上的虚拟机数量自然也就越多。超融合节点一般按照CPU槽位进行授权，也可以简单的理解为按照节点进行授权，客户为了节约成本，往往会购买少量的授权，把超融合节点的计算资源配置的很高，来达到部署大量虚拟机的目的，这样必然会导致超融合集群上的虚拟机密度过高，如果这个时候发生节点故障，必然会导致大量的虚拟机HA，影响范围比较广。如果通过部署少量的虚拟机，来控制业务影响的范围，又会造成节点计算资源的浪费，成本反而升高。面对这种情况，我们在进行超融合设施初期建设时就应该合理规划超融合节点上的计算资源，在虚拟机数量和节点计算资源上进行合理的规划，避免虚拟机密度过大的同时，保证计算资源的够用，同时也需要开启资源自动调度，来保证节点上资源的合理分配。后期随着业务增长，需要更多的虚拟机时，我们应当适当的增加集群的节点数量来满足业务需求，而不是在原来的基础上增加计算资源来增加虚拟机密度。

虚拟机密度越小只能控制虚拟机影响的数量，而不能避免影响业务。当集群中节点故障，虚拟机触发HA，必然会引起虚拟机关机并在可用节点重新拉取，导致业务的短暂中断。根据业务的重要性，不可短暂中断的业务，就需要应用层能够做到高可用，当其中一个虚拟机业务出现异常时，其他虚拟机能够承担业务，做到业务不中断，然而这些不同的虚拟机，就需要使用虚拟机放置组，放置到不同的节点，避免节点故障，导致应用层虚拟机不可用，同样我们也可以考虑把虚拟机放置到不同的集群或者同城双活中，避免集群故障，以此来保证业务的可用性。