首页 > 代码库 > 云平台数据库主机意外宕机问题
云平台数据库主机意外宕机问题
问题引入:
很多公司在使用自己的私有云环境时,会选择划分主机集合,像这种
很好,做得很好,但是新建主机集合的精髓在于:区分对待,每个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 --image 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应用于其他应用分离
本文出自 “一个好人” 博客,请务必保留此出处http://egon09.blog.51cto.com/9161406/1854592
云平台数据库主机意外宕机问题