文章目录

说明
故障发现【任意节点执行】
单个osd up全过程【故障节点执行】
- 查看ceph osd状态
- lsblk查看日志软连接
- 查看软连接【定位问题】
- 重建软连接【确定问题后】
- up osd
- 说明
后续
对日志盘重新进行分区
- 删除日志盘记录信息及恢复

说明

这是一份处理的过程记录文档

原因和处理方法
这种情况是整个物理机的osd无法启动【比如一个盘分了sdg1，sdg2…sda8，盘符软连接变的是sdg，比如sdg变成了sdh，所以整个服务器都无法启动】
掉的osd无法up的原因是物理机重启后导致日志盘符改变，修改日志软连接即可解决！
下面中加了很多中文解释，方便你明白其中原理！

故障发现【任意节点执行】

ceph osd tree |grep down【查看down掉的osd】
…
根据前面的巡检记录，发现以下osd是在29号上午8点46左右down掉的

 -4  43.67993     host stor03                                   16   5.45999         osd.16     down        0          1.00000 17   5.45999         osd.17     down        0          1.00000 18   5.45999         osd.18     down        0          1.00000 19   5.45999         osd.19     down        0          1.00000 20   5.45999         osd.20     down        0          1.00000 21   5.45999         osd.21     down        0          1.00000 22   5.45999         osd.22     down        0          1.00000 23   5.45999         osd.23     down        0          1.00000 -6  43.67993     host stor05                                   33   5.45999         osd.33     down        0          1.00000
-11  43.67993     host stor10                                   72   5.45999         osd.72     down        0          1.00000
-12  43.67993     host stor11   87   5.45999         osd.87     down        0          1.00000
-15  43.67993     host stor14
109   5.45999         osd.109    down        0          1.00000
-17  43.67993     host stor16
125   5.45999         osd.125    down        0          1.00000
127   5.45999         osd.127    down        0          1.00000
-20  43.67993     host stor19
144   5.45999         osd.144    down        0          1.00000
146   5.45999         osd.146    down        0          1.00000

30号凌晨2点左右，ceph集群数据同步还差1.5%，但是已经不同步数据了。其中有7个pgs down
启动了25个down掉的osd，其中大部分osd是以前down的

单个osd up全过程【故障节点执行】

查看ceph osd状态

service ceph status

lsblk查看日志软连接

一般会有一个盘会化很多分区用来分别存储每一个osd的日志，如这个就是sdg盘（有多少个osd就会有多少个分区）

[root@stor12 dev]# lsblk【列出所有可用块设备的信息,而且还能显示他们之间的依赖关系】
NAME                 MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT【其他硬盘单个做osd】
sda                    8:0    0   5.5T  0 disk
└─sda1                 8:1    0   5.5T  0 part /var/lib/ceph/osd/ceph-90
sdb                    8:16   0   5.5T  0 disk
└─sdb1                 8:17   0   5.5T  0 part /var/lib/ceph/osd/ceph-91
sdc                    8:32   0   5.5T  0 disk
└─sdc1                 8:33   0   5.5T  0 part /var/lib/ceph/osd/ceph-92
sdd                    8:48   0   5.5T  0 disk
└─sdd1                 8:49   0   5.5T  0 part /var/lib/ceph/osd/ceph-93
sde                    8:64   0   5.5T  0 disk
└─sde1                 8:65   0   5.5T  0 part /var/lib/ceph/osd/ceph-94
sdf                    8:80   0   5.5T  0 disk
└─sdf1                 8:81   0   5.5T  0 part /var/lib/ceph/osd/ceph-95
sdg                    8:96   0 893.8G  0 disk 【2个固态硬盘做raid1，做日志的软连接存储目录】
├─sdg1                 8:97   0  92.2G  0 part
├─sdg2                 8:98   0  92.2G  0 part
├─sdg3                 8:99   0  92.2G  0 part
├─sdg4                 8:100  0  92.2G  0 part
├─sdg5                 8:101  0  92.2G  0 part
├─sdg6                 8:102  0  92.2G  0 part
├─sdg7                 8:103  0  92.2G  0 part
└─sdg8                 8:104  0  92.2G  0 part
sdh                    8:112  0   5.5T  0 disk
└─sdh1                 8:113  0   5.5T  0 part /var/lib/ceph/osd/ceph-88
sdi                    8:128  0   5.5T  0 disk
└─sdi1                 8:129  0   5.5T  0 part /var/lib/ceph/osd/ceph-89
sdj                    8:144  0   5.5T  0 disk 【2个硬盘做raid1，安装系统】
├─sdj1                 8:145  0     4M  0 part
├─sdj2                 8:146  0     1G  0 part /boot
└─sdj3                 8:147  0   582G  0 part ├─rhel_stor12-root 253:0    0   500G  0 lvm  /├─rhel_stor12-swap 253:1    0    32G  0 lvm  [SWAP]└─rhel_stor12-home 253:2    0    50G  0 lvm  /home

查看软连接【定位问题】

查看ceph-osd的日志盘
cd /var/lib/ceph/osd【查看全部osd的软连接】
ls -l ceph-*/journal

下面就是每个osd对应的日志软连接，如果和lsblk的对应不上，则表示该服务器重启后软连接便了（盘符变了，比如sdg变成了sda），这时候就会导致启动osd的时候找到不到日志存储盘，所以osd无法up。

[root@stor03 osd]# cd /var/lib/ceph/osd/【进到日志目录】
[root@stor03 osd]# ls -l ceph-*/journal【查看所有软连接】
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-16/journal -> /dev/sdg1
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-17/journal -> /dev/sdg2
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-18/journal -> /dev/sdg3
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-19/journal -> /dev/sdg4
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-20/journal -> /dev/sdg5
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-21/journal -> /dev/sdg6
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-22/journal -> /dev/sdg7
lrwxrwxrwx 1 root root 9 Dec 30  2019 ceph-23/journal -> /dev/sdg8
[root@stor03 osd]#

重建软连接【确定问题后】

比如发现软连接显示的磁盘目录和lsblk查看的结果不一致，进入到该osd目录，比如ceph-90不一致
cd /var/lib/ceph/osd/ceph-90/
ls -l【核实软连接和lsblk确实不一致】
rm -f journal【删除这个软连接】
ln -s /dev/sdg1 journal【重建这个软连接，以lsblk的为准】
注：上面重建软连接步骤，有多少个盘就重复多少次，比如上面有sdg1~sdg8就需要重复8次该操作。

up osd

service ceph status osd.90 【查看osd.90状态】
service ceph start osd.90【启动osd.90，也可以这样：/etc/init.d/ceph start osd.90】
service ceph status【查看全部】

【在存储节点，查看osd.90对应的日志，查看osd是否正常】
cd /var/log/ceph
tail -f ceph-osd.90.log
出现going to standby正常
有time out的是osd down的时间节点

说明

有些软连接是使用的盘名称，所以会发生上述情况，如果使用的是uuid，则一般不会发生上述情况，uuid显示结果如下

[root@stor-3 ~]# cd /var/lib/ceph/osd
[root@stor-3 osd]# ls -l ceph-*/journal
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-10/journal -> /dev/disk/by-partuuid/35534a97-7c23-4cd1-9f37-0557a21f1cf5
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-13/journal -> /dev/disk/by-partuuid/fd9a7e66-d69e-4cd6-b955-1f65fbd348e4
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-14/journal -> /dev/disk/by-partuuid/16d94f0a-92b0-4368-99d0-823d2a6fdd47
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-17/journal -> /dev/disk/by-partuuid/0ac7bfe9-5311-4b93-8c1b-b3f512054021
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-18/journal -> /dev/disk/by-partuuid/72893f30-0dd6-4183-850b-922b7789fb6a
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-1/journal -> /dev/disk/by-partuuid/2ed74354-d0b5-4a15-aa7f-103f9ab6168e
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-2/journal -> /dev/disk/by-partuuid/018f6fb7-b5db-4e81-b58b-f099bd4d631f
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-5/journal -> /dev/disk/by-partuuid/ba910d2a-4454-4618-b4c0-d002675779db
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-6/journal -> /dev/disk/by-partuuid/53631fd2-0895-4077-966d-d7a997eb7cdc
lrwxrwxrwx 1 root root 58 Dec 27  2016 ceph-9/journal -> /dev/disk/by-partuuid/2aeef55b-5e0b-4d8a-aa08-2f5dc906dc08

后续

31号下午2点，同步停止，但是还没有同步完，还是有7个pgs down
【查看哪些pg处于down+peering】【pgs down 是因为pg 的副本数少于2】【pg有2个副本就能提供服务，少于2就down】
ceph health detail【显示结果大量pg 1.1055状态是down+peering】
查看pg 1.1055信息
ceph pg 1.1055 query【查看peer是在哪个osd上】【peer下一行的blocked就有osd的编号】
查看osd
ceph daemon osd.87 status【查看osd状态】
启动osd
service ceph start osd.87
工程师启动了1个29号down掉的osd.87，osd.87启动后有6个pgs down的状态消失
1号
凌晨6点，同步停止，但是还没有同步完，还有1个pgs down
还有33 72 125 127 109 osd是29号down的没启动

ceph health detail【显示结果大量pg 4.a3状态是down+peering】

查看pg 4.a3信息
ceph pg 4.a3 query【查看不了】
其中使用ceph osd tree发现osd.125状态时down的，但是在服务器上看到的状态的runing的
在服务器上重启该osd service ceph start osd.125
重启osd 125之后，ceph pg 4.a3 query正常显示信息，pgs down状态消失

对日志盘重新进行分区

这只是演示，如果误删了日志盘后怎么弄而已。

在osd所属节点操作
lsblk【记录日志信息，如下图】

dd if=/dev/zero of=/dev/sdg bs=1M count=10 oflag=sync 【整个日志盘重建，能正常使用最好不要执行该命令】
parted -s /dev/sdg mklabel gpt【格式化】
parted -s /dev/sdg mkpart primary 2048s 20G 【开始分区，一个日志盘20G】
parted -s /dev/sdg mkpart primary 20G 40G 【多少个硬盘，就执行多少次，一个sdg对应一个硬盘的日志盘，创建后用lsblk查看会自动成为sdg1，sdg2…】
…

对日志盘10个分区依次设置标签，下面以sdg1 ，2为例【跳过】
sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/sdg【除了=后面的序号和最后面的/dev/要变，其他是固定的格式内容】
sgdisk --typecode=2:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/sdg【除了=后面的序号和最后面的/dev/要变，其他是固定的格式内容】
【设置好之后输入partprobe 分区设备名刷新下磁盘信息，或重启下系统】

删除日志盘记录信息及恢复

一般没人删除这玩意，误删除后计算前后的结束扇区，然后用下面命令创建吧；
比如误删了sdg3的日志盘，计算方法是sdg2的结束扇区+1，sdg4的起始扇区-1；

【如果要删除日志盘，先使用fdisk查看指定的分区起始和结束扇区，然后用下面命令创建】【osd所属存储节点执行】

parted -s /dev/sdg mkpart primary 206176256s 374865919s 日志盘创建分区【按指定分区位置和大小创建】

openstack的osd，up不起来原因【重建osd日志盘软连接方法】相关推荐

xp mysql字符集与乱码_MySQL乱码的原因和设置UTF8数据格式的方法介绍-mysql教程-学派吧...
本篇文章给大家带来的内容是关于MySQL乱码的原因和设置UTF8数据格式的方法介绍,有一定的参考价值,有需要的朋友可以参考一下,希望对你有所帮助. MySQL使用时,有一件很痛苦的事情肯定是结果乱码. ...
win7电脑连接无线网络怎么连接服务器未响应,Win7无线网络无法连接的原因及Wifi无法连接解决方法大全...
目前无线网络连接已经是大家使用的设备连接网络的主要方式,然而很多朋友在使用Win7系统笔记本或是电脑时会遇到Win7无线网络无法连接的问题,无线网络无法连接的原因其实有很多种,解决方法也要根据故障的原 ...
共享计算机添加打印机后无法打印机驱动,打印机无法打印原因？打印机设置共享的方法...
我们平常也经常打印资料,那么打印机是什么呢?小编给大家科普一下,打印机是计算机的输出设备之一,用于将计算机处理结果打印在相关介质上.衡量打印机好坏的指标有三项:打印分辨率,打印速度和噪声.将计算机的运 ...
w ndows10QQ远程,Win10提示“QQ远程系统权限原因,暂时无法操作”的解决方法
我们可能会使用到QQ上的远程控制功能来协助对方帮助解决电脑各种系统问题或者帮助别人安装某软件.调试等,但是如果对方的电脑(被控端)是Windows10系统,使用QQ远程桌面控制对方电脑的时候,在操作的 ...
android电视直播卡顿,电视盒子看直播卡顿原因分析以及教你解决方法！
原标题:电视盒子看直播卡顿原因分析以及教你解决方法! 其实关于智能机顶盒.智能电视大家最想了解的就是想知道到底能不能流畅的看直播.看视频电影,这里我可以很负责的告诉大家:想要高清.完全不卡顿的看直播电 ...
飞机荷兰滚产生原因、受力分析、解决方法
飞机荷兰滚产生原因.受力分析.解决方法产生原因飞机横向静稳定性过强,航向静稳定性过弱,易产生明显的摆飘现象,称为荷兰滚. 受力分析当某时刻出现正侧滑β>0,航向静稳定导数产出正向的偏航力矩 ...
Openstack中用秘钥对(keypair)生成和访问虚机的方法
Openstack中用秘钥对(keypair)生成和访问虚机的方法 Openstack中用镜像文件生成的image来创建虚机(VM或Instance)时, 通常不支持用户名加密码的ssh方式登录访问该 ...
php7应用程序无法启动,window_win7系统打开软件提示应用程序无法启动的故障原因分析及2种解决方法， nbs - phpStudy...
win7系统打开软件提示应用程序无法启动的故障原因分析及2种解决方法 win7系统打开软件提示应用程序无法启动,因为应用程序的并行配置不正确,具体问题现象如下图所示: 故障原因分析: 一个可能是Win ...
飞机螺旋（又称尾旋）产生原因、受力分析、解决方法、螺旋改出
飞机螺旋/尾旋产生原因.受力分析.解决方法.螺旋改出螺旋产生原因飞机横向静稳定性过弱,航向静稳定性过强,产生螺旋不稳定. 受力分析飞机受扰动左滚,产生左侧滑,横向静稳定性弱,飞机改平坡度慢航 ...

openstack的osd，up不起来原因【重建osd日志盘软连接方法】