首页 > 代码库 > 云平台数据库主机意外宕机问题

云平台数据库主机意外宕机问题

问题引入:

很多公司在使用自己的私有云环境时,会选择划分主机集合,像这种

技术分享

很好,做得很好,但是新建主机集合的精髓在于:区分对待,每个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

云平台数据库主机意外宕机问题