机器角色:cloudstack虚拟机的宿主机:ceph存储机器. 事件:ceph存储的物理机器由于内存异常,需要停机更换,仅仅是把该物理机上面的虚拟机迁移走,同时启动了停机维护,然后就直接关机.结果造成重启之后ceph异常 原因:由于异常关闭,ceph进程的相关信息没有正常关闭,信息没有同步到文件系统,如pid文件等信息 现象并尝试解决: 1)检查osd的整体信息 [root@haha1~]# ceph osd tree ID WEIGHT    TYPE NAME             UP

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

在前面一篇文章中,我们看到,当使用filestore时,osd会把磁盘分成data和journal两部分.这主要是为了支持object的transaction操作.我的想法是,ceph需要具有数据保护功能,从client端写入的数据(以返回I/O Completion为标志)不能丢失.对于object为什么要使用journal,ceph官方也给出了解释: 速度:有了journal分区后,写数据速度更快.这主要是因为journal的写都是顺序写. 一致性:ceph要求I/O操作是原子性的,比如更新

假如需要新增一个主机名:osd4 ip:192.168.0.110的OSD1.在osd4创建挂载目录及放置配置文件的目录 ssh 192.168.0.110 (这里是从mon主机ssh到osd4主机) mkdir /ceph/osd.4 mkdir /etc/ceph 2.在osd4上格式化ext4的sda3分区,挂载分区. mkfs.ext4 /dev/sda3 mount -o user_xattr /dev/sda3 /ceph/osd.43.将mon主机的id_dsa.pub拷至osd4

一.删除osd ceph osd out 1ceph osd down 1systemctl stop ceph-osd@1ceph osd crush remove osd.1ceph osd rm 1ceph auth del osd.1   二.用ceph-deploy方式新增一个osd 1.登录deploy节点,打开集群创建目录 root@ceph01:~# cd /root/my-cluster/ root@ceph01:~/my-cluster# 2.准备一块硬盘:/dev/sdb1

目录 简介 更换OSD操作步骤 1. 故障磁盘定位 2. 摘除故障磁盘 3. 重建raid0 4. 重建osd 控制数据恢复及回填速度 简介 首先需要说明的是,ceph的osd是不建议做成raid10或者raid5的,一般建议单盘跑.在我们的环境中,为了充分利用raid卡的缓存,即使是单盘,我们还是将其挂在raid卡下做成raid0. 这样不可避免的问题就是磁盘的损坏,需要在ceph当中做一些摘除动作,同时还需要重建raid. 在更换完磁盘重建raid之后,需要重新添加osd.新的osd加入到集

先将osd.2移出集群 root@ceph-monster:~# ceph osd out osd.2 marked out osd.2. root@ceph-monster:~# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.79999 root default -2 0.39999 host ceph-monster 0 0.20000 osd.0 up 1.00000 1.00000 1 0

前言 之前写过一篇关于查询OSD的运行的CPU的情况的分享,本篇是讲的获取内存占用的,代码包括两种输出,一种是直接的表格,一种是可以方便解析的json 代码 直接上代码,python才用不久,所以可能代码实现比较低级,主要是看实现的方法 #!/usr/bin/env python # -*- coding: UTF-8 -*- import os import sys import json import psutil import commands from prettytable impor

前言 如果你是新手,应该出现过敲盘符的时候,敲错的情况,有些操作可能没什么问题,查询类的操作都没问题,但是写入的情况,就可能比较麻烦了,当然老手也可能有误操作,本篇将讲述在误操作把分区表给弄丢了的情况,来看看我们应该如何恢复 实践过程 我们现在有一个正常的集群,我们假设这些分区都是一致的,用的是默认的分区的方式,我们先来看看默认的分区方式是怎样的 破坏环境 [root@lab8106 ceph]# ceph-disk list ··· /dev/sdb : /dev/sdb1 ceph data

ceph在部署过程中是先进行部署,再去写配置文件的,而一些新手在部署完了后,并没有写配置文件,在重启服务器后,因为挂载点没有挂载,所以服务无法启动,所以需要写好配置文件 还有一种情况是集群有几百个osd,在新加入或者修改的时候,再去进行变更配置文件就是一个很麻烦的事情,所以写配置文件这个如果脚本来处理,就可以节约很多时间,所以写了一个脚本如下,这个地方如果熟悉python的可以用python写,我这个是自己使用,并且使用的频率不会太高,因此,怎么方便怎么来 脚本里面用了一个二进制文件是解析jso

修改主机名和 /etc/hosts 关闭防火墙和 SELINUX 安装和配置 NTP ceph-deploy 节点安装 安装 ceph-deploy sudo yum install ceph-deploy -y 配置 SSH(生成公秘钥实现免密访问) 添加 OSD ceph-deploy disk zap ceph2:/dev/vdb ceph3:/dev/vdb ceph-deploy osd prepare ceph2:/dev/vdb ceph3:/dev/vdb ★ 注意:[prepa

尝试一.直接重新激活所有osd 1.查看osd树 root@ceph01:~# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 0.29279 root default -2 0.14639 host ceph01 0 0.14639 osd.0 up 1.00000 1.00000 -3 0.14639 host ceph02 1 0.14639 osd.1 down 0 1.00000 发现osd.

https://my.oschina.net/wangzilong/blog/1549690 ceph集群中允许使用混合类型的磁盘,比如一部分磁盘是SSD,一部分是STAT.如果针对某些业务小高速磁盘SSD,某些业务需要STAT,在创建资源池的时候可以指定创建在某些OSD上. 基本步骤有8步: 当前只有STAT没有SSD,但是不影响实验结果. 1    获取crush map [root@ceph-admin getcrushmap]# ceph osd getcrushmap -o /opt/

前言 ceph里面的数据是以对象的形式存储在OSD当中的,有的时候因为磁盘的损坏或者其它的一些特殊情况,会引起集群当中的某一个对象的异常,那么我们需要对这个对象进行处理 在对象损坏的情况下,启动OSD有的时候都会有问题,那么通过rados rm的方式是没法发送到这个无法启动的OSD的,也就无法删除,所以需要用其他的办法来处理这个情况 处理步骤 查找对象的路径 [root@lab8106 ~]# ceph osd map rbd rbd_data.857e6b8b4567.000000000000

systemctl restart ceph-mon@mon-node3 systemctl stop ceph-mon@mon-node3 systemctl start ceph-mon@mon-node3

在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

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上用

一.心跳选项 完成基本配置后就可以部署.运行 Ceph 了.执行 ceph health 或 ceph -s 命令时,监视器会报告 Ceph 存储集群的当前状态.监视器通过让各 OSD 自己报告.并接收 OSD 关于邻居状态的报告来掌握集群动态.如果监视器没收到报告,或者它只收到集群的变更报告,那它就要更新集群运行图. 关于监视器与 OSD 的交互 Ceph 提供了合理的默认值,然而你可以覆盖它们.下面几段从集群监控角度描述了 Ceph 监视器与 OSD 如何交互. OSD 验证心跳 各 OSD

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

前言 之前有一篇文章介绍的是,在centos7的jewel下面如果自己做的分区如何处理自动挂载的问题,当时的环境对journal的地方采取的是文件的形式处理的,这样就没有了重启后journal的磁盘偏移的问题 如果采用的是ceph自带的deploy去做分区的处理的时候,是调用的sgdisk去对磁盘做了一些处理的,然后deploy能够识别一些特殊的标记,然后去做了一些其他的工作,而自己分区的时候,是没有做这些标记的这样就可能会有其他的问题 我们看下如何在部署的时候就处理好journal的uuid的