前言 服务器上面的服务会因为各种各样的原因失败,磁盘故障,权限问题,或者是服务过载引起超时,这些都可能引起 这个在ceph里面systemctl unit 默认有个on-fail restart,默认的可能并不适合所有的场景,所以自动化的服务应该是尽量去适配你手动处理的过程,手动怎么处理的,就怎么去设置 启动分析 如果有osd失败了,一般上去会先启动一次,尽快让服务启动,然后去检查是否有故障,如果失败了,就开启调试日志,再次重启,在问题解决之前,是不会再启动了,所以这里我们的自动启动设置也这么设…

前言 如果看到标题,你是不是第一眼觉得写错了,这个怎么可能,完全就是两个不相关的东西,最开始我也是这么想的,直到我发现真的是这样的时候,也是很意外,还是弄清楚下比较好,不然在某个操作下,也许就会出现意想不到的情况 定位 如果你看过我的博客,正好看过这篇 <<ceph在centos7下一个不容易发现的改变>> ,那么应该还记得这个讲的是centos 7 下面通过udev来实现了osd的自动挂载,这个自动挂载就是本篇需要了解的前提 [root@lab101 ~]# df -h|grep…

在Ceph的osd节点上,启动osd进程失败,查看其日志/var/log/ceph/ceph-osd.{osd-index}.log日志,报错如下: 2017-02-14 16:26:13.558535 7fe3883f58c0 0 filestore(/var/lib/ceph/osd/ceph-1) mount: enabling WRITEAHEAD journal mode: checkpoint is not enabled 2017-02-14 16:26:13.558712 7fe…

背景 OS:Ubuntu 16.04 修改了osd的一些配置,修改后,需要重启osd服务才能生效.第一次重启后,配置立刻生效.再改了一些配置,重启osd服务后,配置却不再生效了.ps命令查看进程,发现osd进程都没有启动. 分析 osd进程未启动,第一直觉就是配置出错,osd进程启动后又挂掉.于是,进入/var/log/ceph目录,查看ceph-osd.0.log,发现日志末尾只有关闭进程的相关日志,并没有osd启动的信息.再查看该日志的时间,时间就是关闭服务时的时间.换句话说,第二次重启服务…

1  调高osd的日志等级 加上红框那一行就可以了 osd的日志路径:/var/log/ceph/ceph-osd.3.log 注意:加上了这一行后日志会刷很多,所以要特别注意日志容量的变化,以防把var目录写满了 2  缺少osdmap或者错误的osdmap 从osd日志中发现这两种错误都是属于osdmap不正常,可以从其它正常osd上拷贝osdmap到对应启动错误的osd上,假设不正常的osdmap序号是816,上图的是27601和671651 如以下图: 在一个正常osd上如osd.4上用…

1.无法发现节点的错误: 试验了很多情况,但是总是无法加入集群,后来尝试了一下步骤,问题解决: 1.删除所有数据,重启:无效: 2.统一配置,全部重启,无效: 3.关闭所有防火墙,全部重启,无效: ….n步骤以后… 5.删除整个ES应用,重新建立集群:有效: 6.加入之前拉出去的某台机器,配置一样(节点名不一样),无效,且出现ElasticSearch 主节点<UKnown>的情况: 7.删除该节点所有的elasticSearch应用相关的东西,重新建立节点,配置好后加入集群,同时安装好hea…

1.配置系统参数: JAVA_HOME:C:\Program Files\Java\jdk1.8.0_51   //本机Jdk的安装路径,已配置相关Java应用的无需再配置. CATALINA_HOME:E:\App\2.1apache-tomcat-8.0.30  //Tomcat的主文件目录 注: 配置后重新启动系统. 2.测试TOMCAT启动批处理文件 在命令行下运行:%CATALINA_HOME%\bin\startup.bat  //测试上述系统参数配置是否正确,如有误请进行调整.%C…

直接上干货: ceph自动挂载原理 系统启动后,ceph 通过扫描所有磁盘及分区的 ID_PART_ENTRY_TYPE 与自己main.py中写死的osd ready 标识符来判断磁盘(及其分区)是否准备好自动挂载(journal ,block, osd 同是一个道理) main.py中记载的状态标志 /usr/lib/python2./site-packages/ceph_disk/main.py 'osd': { 'ready': '4fbd7e29-9d25-41b8-afd0-062c…

这个案例是前两天出现的,一直没有时间总结,25号凌晨4点去处理数据库的故障问题.远程连上公司的局域网,psping检查发现服务器的1433端口不通,数据库连接不上,但是主机又能ping通,登录服务器检查发现SQL Server的SQL Server (MSSQLSERVER) Service 等服务都没有启动.从Zabix检查也发现服务停了, 真是懵了,使用systeminfo命令检查系统的情况,发现这台服务器在凌晨3:31重启了,但是对应的SQL Server服务没有自动启动, 检查错误日志,…

正常状态:…