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

Myth丶恋晨 2022-12-29 11:20 21阅读 0赞

### 文章目录 ###

*  说明
 *  故障发现【任意节点执行】
 *  单个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`【记录日志信息，如下图】  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N1aWNob25neGlu_size_16_color_FFFFFF_t_70]

`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…】  
…  
![在这里插入图片描述][202104011817263.png]

对日志盘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` 日志盘创建分区【按指定分区位置和大小创建】

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2N1aWNob25neGlu_size_16_color_FFFFFF_t_70]: /images/20221120/a7d79f554fb04464a9f7e342ab089d8f.png
[202104011817263.png]: https://img-blog.csdnimg.cn/202104011817263.png