Monthly Archives: 4月 2018

单服务器 2OSD CEPH集群故障说明

系统盘故障
demsg日志当中出现了ext4元数据不一致,引起系统盘上的mon数据无法使用
解决方法:
通过重启修复系统盘进行解决

mon数据损坏
mon无法启动,启动显示目录内的数据异常
解决方法:
在修复了系统盘后,还有部分数据异常,通过修复mon数据目录下的leveldb的数据库进行修 复

osd数据盘损坏
osd.2的文件系统损坏,出现xfs_log异常
解决方法:
修复xfs文件系统

osd内的有少量元数据异常
启动日志内显示有部分数据异常解决办法:

通过集群内其他的osd上的相同数据,拷贝过来进行修复

pg状态异常
有一个pg无法恢复正常,经过检查是有一个对象文件丢失
解决办法:
通过集群的命令进行修复后,环境恢复正常

总结
以上所有问题均为掉电下引起的文件系统异常,丢失部分磁盘上的数据引起的异常,这个建议 采用多节点集群的形式,减小数据丢失的概率,多节点的时候可以从其他节点恢复
能多mon建议多mon,无法多mon就对mon的数据进行定期备份

如果对性能要求不高,建议可以关闭raid卡上面的写缓存,有的机器老旧后,raid卡上的电池 不能很好的完成掉电保护的作用

开启“混合云”时代(转)

文章来自艾瑞克•诺尔,《信息世界》(InfoWorld)首席主编,资深评论员。

搭建混合云的方式有两种,要么自己搭建一个公有云和私有云之间的桥梁,要么直接试试现成的混合云。

在近期的一封邮件中我提到,AWS(亚马逊云服务)与微软Azure云服务相比缺少了“混合云应用”,这番话引起了某位亚马逊内部人士的不满。他在发给我的邮件中提醒到,有很多企业客户都将AWS作为混合云发展的一部分。

他所言非虚,在过去几年我曾看到不少企业将内部研发和测试的基础设施扩展到AWS上,配置公有云移动应用与本地数据库融合,将本地实例转移到AWS上以解决所需问题等等。AWS提供的服务众多,再加上一套严谨的自我服务途径,让你可以在现有操作上建立任何想要的混合扩展,这就是AWS的魅力之一。

但是我认为它只能被称作一种DIY混合形式,而微软却拥有最先进的混合应用——私有云软件,它能通过Windows,Server以及Azure Pack复制Azure公有云的基础设施。将于2016年夏发行的版本会让私有云进一步接近公有云。

这让人不得不疑惑,为什么亚马逊从没想过走这条路,从不提供私有云入口呢?其实,第一个私有云软件Eucalyptus完全就是仿造AWS开发的。为什么亚马逊不买下Eucalyptus并提供给客户以部署混合云中的私有云呢?

就我所知,亚马逊从未看好企业软件市场,因为发放周期,客户支持,市场营销等等一切都与云市场不同。此外,还必须保证本地版本与云同步,而这或将抑制其发展。

微软所处的形势则完全不同。亚马逊需要在数据中心从头建立自己的滩头阵地时,微软已经拥有了雄厚的客户资源。微软很清楚Azure吸收企业和客户的最佳方式就是利用微软服务器和系统中心提供云通道。就目前而言,这个雄心勃勃的策略已经被完成得相当出色。

我个人对企业公有云计算(无论由谁提供)的最大困惑就是云本身的最大亮点——规模。包括GE在内的几个大公司都决心致力于发展公有云,Netflix从一开始就100%使用AWS。但即使是巨头也无法承担标准价格,所以通常他们就会以以前的方式进行商谈,获得一个特殊的协议价。

虽然AWS长期处于领先地位,但企业转入公有云仍处于初级阶段。如今发展商领先将云作为各类快速创新事物的巨大优势。但一旦企业开始将数百万美元的操作成本投入到生产开发中又会如何?

有人会选择AWS,但其他人会转向已经合作的企业软件公司。这不仅仅指微软,还有IBM,甚至Oracle,谁能提供一个真正的混合云网关并快速建立起自己的云基础,谁就有机会抓住企业云这个大市场。在大规模生产下,云的销售模式越来越接近软件销售,而这场游戏的关键就在于掌握客户的购买欲和消费能力。

IDC点评网原创文章,转载请注明原文链接:https://tutorials.hostucan.cn/climbing-the-hybrid-cloud-on-ramp

无法快速识别osd down的处理方法说明

无法快速识别osd down的处理方法说明

无法快速识别osd down的处理方法说明

 

 

 

问题描述

环境在做rack故障测试的时候,osd无法快速识别出down,需要经过240s左右才能正常识 别,造成无法写入

 

环境复测

在一台机器上面通过关闭单机网络来快速模拟主机down的识别

 

 

关闭以后还是需要大概120s才能识别,通过修改

 

这个地方是由于环境特殊,副本为2,并且是只有两个rack,而ceph内部考虑了一种情况就是 子树里面网络情况不好的时候会产生误报,所以需要多个子树来报告这个down的事情,而本 环境只有一个rack内的osd异常的时候,另外一个机器的子树内的报告不足以去判断down,  所以出现了需要6  reporter都报异常的时候才会定义为down,也就出现了上面的超长超时的情况,所以解决办法如下

增加

 

 

避免mon去自动调整osd的down的时间,这个测试环境的时候为false,生产保持默认的true

 

另外参数的调整,下面方法二选一即可(两个都设置的话就是检测会比较敏感,没有特殊需 求,用一个方法即可)

方法一:

 

调整参数(默认为host)

 

 

调整为osd的时候,那么就会以osd为单位去统计,这个是可以方法二:

调整参数(默认为2)

 

 

调整完了后再去做down机测试,就会按照设置的识别

这两个参数建议是grace是比interval大的,如果还希望加快就调低grace的值即可

 

 

以下为我复测的结果,可以看到可以在24s内得到了状态的变化

 

 

下图为设置2 reporter的时候的测试值