问题引入：
很多公司在使用自己的私有云环境时，会选择划分主机集合，像这种
很好，做得很好，但是新建主机集合的精髓在于：区分对待，每个zone内包含物理节点拥有不同的物理配置
比方说：
1.zone1用来新建cpu密集型云主机
2.zone2用来新建内存要求较高的云主机
3.zone3用来新建硬盘io要求较高云主机
如果不区分对待，那划分什么主机集合。
下列就是发生在我们公司的一个案例：
一：问题:生产环境DB主机主节点在19号中午突然宕机，导致公司某业务中断。
二：问题解决：
生产以第一时间恢复业务为准则，所以来不及细查原因
1.用horizon和cli两种方式启动云主机均失败,主机状态为ERROR，此状态只可执行删除操作
2.卸载云主机云盘失败，云主机在此刻是无法卸载云盘的，所以删掉原来的云主机，云盘重新回到available状态
3.cli下加载admin环境变量nova reset-state --active backend-mysql-01，状态重置后制作快照，执行（此时是无法rebuild的，只能以从快照新建主机，指定固定ip）
nova boot prod-zabbix02-mysql01 --flavor c1.medium --p_w_picpath 7388c74b-bf8f-4b64-911e-40f838840602 --security_group zabbix-sec-group --nic net-id=bcb3cef7-da93-450c-9f2f-83279d24e9a4,v4-fixed-ip=172.30.0.21
4.重新挂载云盘
5.db组启服务ok
三：天空飞来一封邮件（下列内容来自数据库总监邮件，邮件发送时，故障已经解决）:
近期生产环境DB服务器连续多次出现突发宕机，从服务器/var/log/message中没有任何相关信息，从监控来看，故障时段数据库负载很低，希望云计算部能从虚拟机层面分析一下原因。
9月19日 20:30左右 Zabbix系统 数据库突然宕机 172.30.0.21 prod-zabbix02-mysql01
9月19日 12:00左右 后台管理项目 数据库突然宕机 172.40.0.34 backend-mysql-01 MySQL节点01
9月3日 21:20左右 后台管理项目 数据库突然宕机 172.40.0.36 backend-mysql-03 MySQL节点03
另外，以前虚拟机的故障后一般能很快重新启动，但这几次虚拟机都无法启动，导致故障恢复时间较长。
四：被迫分析原因（刚开始其实我是拒绝的，我良辰谁都不服，直到副总也发来贺电）
针对昨天prod环境backend-mysql-01意外宕机原因分析如下
backend-mysql-01运行与compute03节点，compute03节点报错日志 
出现该问题的原因是由于VM分配的内存过大（甚至超过的物理主机的内存大小），backend-mysql-01使用m2.xlarge,内存为32G
而compute03物理内存剩余为10G，所以一旦数据库负载过高导致内存使用量大则会产生宕机现象，重启由于compute03物理内存不足，是无法重启成功的
补充一点：
云主机在新建时内存的分配都是超分的，比例为ram_allocation_ratio=1.5（这是默认配置）
这样，如果物理节点剩余内存为10G，那么在该物理节点上可以新建15G内存的云主机。
这在资源充足的情况下是一种优化策略（每个主机实际都无法用到100%内存，内存超配后，意味着我们可以新建更多的云主机）,但是针对db这种对内存需求极高的应用来说，该配置就成了一种导致云主机宕机且无法重新启动的×××（内存溢出）。
五：三种解决方案
解决方案一：
新增compute节点（内存配置高），单独划分主机集合供db部门使用，超分设置ram_allocation_ratio=1.0
解决方案二：
升级计算节点内存
解决方案三：
1.统计生产环境资源，筛选资源充足主机
2.新增主机集合，将现有的资源充足的主机纳入该集合内，以后新建主机使用该主机集合去创建
三种方案对比（本着db应用与其他应用分开，db应用运行与单独的物理节点的原则）：
方案一：最优，无须停节点，数据库应用对性能的独特要求决定了：它应该与其他应用处于不同的物理节点。所以需要单独分配高性能物理机
方案二：较优，需要停节点升级内存，但是也是一种解决问题的方法
方案三：最烂，可以解决短期内的问题，仍然没有将db应用于其他应用分离
