喜迎
元旦
记一次SSD磁盘损坏导致的osd重建 | 奋斗的松鼠 - Blog

记一次SSD磁盘损坏导致的osd重建

字数统计: 2.7k字   |   阅读时长≈ 12分

ceph第二套集群正式上线一周，集群配置进行了调整并优化了系统的一些配置，运行稳定，然而，事情并不总是那么一帆风顺，这不，最近这个集群就发生了一些事情

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

SSD+HDD混合创建osd的方式存在比较大的风险，尤其是一个ssd对应多个hdd磁盘创建多个osd的情况，一旦ssd损坏，受影响的osd会很多。

发现问题

下班后打算看一下书放松一下，没想到收集微信传来告警，显示ceph集群有osd跪了，接着就传来一连串的告警，有pg出现异常状态，集群有警告等等，我的第一反应就是，是不是之前那个osd重启的bug？

赶紧打开电脑连上集群，定位到osd.150所在节点，看了下它的systemctl status，发现是fail的，auto-start多次也起不来，打开日志查看，发现有堆栈信息

1
2
3
4
5
6
7
8
9
10
11
2018-08-16 22:50:09.596495 7fd43777e700 -1 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/12.2.7/rpm/el7/BUILD/ceph-12.2.7/src/os/bluestore/BlueFS.cc: In function 'int BlueFS::_read_random(BlueFS::FileReader*, uint64_t, size_t, char*)' thread 7fd43777e700 time 2018-08-16 22:50:09.590375
/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/12.2.7/rpm/el7/BUILD/ceph-12.2.7/src/os/bluestore/BlueFS.cc: 916: FAILED assert(r == 0)

 ceph version 12.2.7 (3ec878d1e53e1aeb47a9f619c49d9e7c0aa384d5) luminous (stable)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x110) [0x7fd46b1f6850]
 2: (BlueFS::_read_random(BlueFS::FileReader*, unsigned long, unsigned long, char*)+0x737) [0x7fd46b169547]
 3: (BlueRocksRandomAccessFile::Read(unsigned long, unsigned long, rocksdb::Slice*, char*) const+0x20) [0x7fd46b190ff0]
 4: (rocksdb::RandomAccessFileReader::Read(unsigned long, unsigned long, rocksdb::Slice*, char*) const+0x2fd) [0x7fd46b561c8d]
 5: (rocksdb::ReadBlockContents(rocksdb::RandomAccessFileReader*, rocksdb::Footer const&, rocksdb::ReadOptions const&, rocksdb::BlockHandle const&, rocksdb::BlockContents*, rocksdb::ImmutableCFOptions const&, bool, rocksdb::Slice const&, rocksdb::PersistentCacheOptions const&)+0x2ae) [0x7fd46b53dc7e]
 6: (()+0xdbfe97) [0x7fd46b52ee97]
....

乍看之下似乎是断言错误导致的osd crush，跟之前遇到的一个ceph的bug 有点像，不过看起来他是BlueFS读盘的时候返回了错误，慎重起见还是检查一下对应的磁盘，用smartctl看了一下，不看不知道，一看不后悔，发现smartctl返回了大量磁盘错误！在/var/log/messge处和dmesg也发现了该ssd的io错误

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
cat /var/log/message
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#0 BRCM Debug mfi stat 0x2d, data lenrequested/completed 0x10000/0xb000
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#0 Sense Key : Medium Error [current]
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#0 Add. Sense: Unrecovered read error
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#0 CDB: Read(10) 28 00 0d 50 30 80 00 00 80 00
Aug 16 22:49:41 ceph-52-233 kernel: blk_update_request: critical medium error, dev sdr, sector 223359192
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#1 BRCM Debug mfi stat 0x2d, data lenrequested/completed 0x8000/0x6000
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#1 Sense Key : Medium Error [current]
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#1 Add. Sense: Unrecovered read error
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#1 CDB: Read(10) 28 00 0d 50 30 a8 00 00 40 00
Aug 16 22:49:41 ceph-52-233 kernel: blk_update_request: critical medium error, dev sdr, sector 223359192
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#3 BRCM Debug mfi stat 0x2d, data lenrequested/completed 0x1000/0x0
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#3 Sense Key : Medium Error [current]
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#3 Add. Sense: Unrecovered read error
Aug 16 22:49:41 ceph-52-233 kernel: sd 0:0:60:0: [sdr] tag#3 CDB: Read(10) 28 00 0d 50 30 d8 00 00 08 00
...
Aug 16 22:50:04 ceph-52-233 ceph-osd: 2018-08-16 22:50:04.300028 7ff5406e3700 -1 bdev(0x7ff57df12a00 /var/lib/ceph/osd/ceph-151/block.db) read_random direct_aligned_read 0x1b64400000~ error: (5) Input/output error

看来这块ssd盘情况不妙，十有八九是坏了，虽然目前看来仅仅是一个osd挂了，但是与这个ssd相关的osd恐怕都难逃一劫，这个ssd分配给了6个hdd磁盘做加速

故障的处理

在发现第一个osd跪了半小时之后，又传来了两个osd跪掉的信息，看来担心的事情发生了，即使是ssd磁盘，一个块的损坏也可能会引发其他块出问题，前端仍在全速写入，因为采取的是2副本模式，坏掉的ssd的osd属于同一个故障域，所以即使集群跪掉3个osd，也不会影响写入功能，为了保证写入，我们第一时间设置了osd noout

1
sudo ceph osd set noout

在osd noout的情况下，pg不会马上发生迁移，不过一大批pg降级也是很危险的；我们马上联系机房帮忙给设备加插ssd磁盘，磁盘到位后，取消了ceph的noout标记并在数据恢复后，删除了osd

1
sudo ceph osd unset noout

等待漫长的数据恢复…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[tanweijie@ceph-52-236 ~]$ sudo ceph -s
  cluster:
    id:     0f8960f5-6bb0-4d4c-a64b-253baeb90f17
    health: HEALTH_WARN
            noscrub,nodeep-scrub flag(s) set
            Degraded data redundancy: 19201700/2502790398 objects degraded (0.767%), 542 pgs degraded, 542 pgs undersized

  services:
    mon: 3 daemons, quorum ceph-52-234,ceph-52-235,ceph-52-236
    mgr: ceph-52-233(active), standbys: ceph-52-234
    osd: 184 osds: 181 up, 181 in; 542 remapped pgs
         flags noscrub,nodeep-scrub
    rgw: 4 daemons active

  data:
    pools:   6 pools, 17536 pgs
    objects: 1193M objects, 208 TB
    usage:   489 TB used, 1017 TB / 1507 TB avail
    pgs:     19201700/2502790398 objects degraded (0.767%)
             16994 active+clean
             542   active+undersized+degraded+remapped+backfilling

  io:
    client:   9380 kB/s rd, 117 MB/s wr, 8335 op/s rd, 20164 op/s wr
    recovery: 1412 MB/s, 8138 objects/s

使用脚本安全删除osd

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
cat  delete_osd.sh
#!/bin/bash

sudo ceph osd out $1
sleep 2
sudo systemctl stop ceph-osd@$1.service
sleep 2
sudo ceph osd crush remove osd.$1
sleep 2
sudo ceph auth del osd.$1
sleep 2
sudo ceph osd rm $1
sleep 2
if [ -d "/var/lib/ceph/osd/ceph-$1" ];then
    sudo umount /var/lib/ceph/osd/ceph-$1
    sleep 2
    sudo rm -rf /var/lib/ceph/osd/ceph-$1
fi

osd删除后，查找到osd对应的pv、vg和lv，进行了手工删除

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash

lvremove -y /dev/ceph-3aa53c5f-1cec-4be8-93d2-e74c4c8cadc7/osd-block-8962ee76-8f69-42b4-ae5c-66284ced7152
lvremove -y /dev/ceph-077ea2ea-9610-420b-a941-c0b0676210b9/osd-block-44a63df1-96ce-46e1-a529-ae9bcb515e51
lvremove -y /dev/ceph-c04b176c-f77d-4335-badf-d9d7f4cc4938/osd-block-f3ce3a48-228a-4746-8bb8-ad2cc7cd3989

vgremove -y ceph-c04b176c-f77d-4335-badf-d9d7f4cc4938
vgremove -y ceph-077ea2ea-9610-420b-a941-c0b0676210b9
vgremove -y ceph-3aa53c5f-1cec-4be8-93d2-e74c4c8cadc7

pvremove -y /dev/sdck
pvremove -y /dev/sdcp
pvremove -y /dev/sdcy

vgscan --cache
pvscan --cache
lvscan --cache

完成删除后，对新加入的ssd磁盘重新分区，然后重建osd，这里osd是在osd自己的节点上创建，使用指定osd-id的方式创建，创建的时候遇到一个很dan疼的问题，由于我们使用的磁盘柜子使用了两根HBA线连接，导致在linxu系统中看到的是两倍磁盘的盘符(它并没有自动识别成多路径，事实上我们也不使用多路径，因为多路径性能太差了，况且设备在机房管理，安全性很高)

在对磁盘创建osd的时候报错

1
2
3
4
5
6
7
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
WARNING: PV sX0LGa-seB5-5xkx-C4Yn-TQH6-d4eY-POt84L on /dev/sdw was already found on /dev/sdbm.
WARNING: PV oaw1UR-YMtm-uDY9-VSWe-M087-YwK3-dSSW2e on /dev/sdam was already found on /dev/sdcc.
WARNING: PV 7jRpvo-6uAI-phi2-rKf3-rC0w-Ehi4-sLnMZp on /dev/sdbc was already found on /dev/sdcs
...

这就是因为系统识别多路径磁盘的时候，大量警告的情况下，创建osd一直失败，查了好久的google，最终查到解决办法，就是通过设置lvm.conf对多路径下的重复情况进行过滤，因为我们创建osd使用使用的分区是/dev/disk/by-id/下的磁盘，所以对lvm.conf的filter进行了设置

1
2
3
4
5
6
7
在global区域设置
filter = [ "a|/dev/disk/by-id/.*|", "r|.*/|" ]
设置后重新进行lvm分区的扫描

vgscan --cache
pvscan --cache
lvscan --cache

不在global处设置会不生效

因为我们设置了osd_crush_update_on_start = false，所以新创建的osd不会自动加入crush map，这样做的好处很多，一方面新建osd可以在加入集群前进一些必要的配置，例如配置它的weight，这个很重要，一个盘10TB的情况下，weight相差一点点，就有可能相差好几个pg，就有可能相差几十GB的实际用量，而且如果osd创建之后就自动加入到crushmap中，每次加入一个osd就会触发pg重新计算，并且pg分布一旦不均匀，就会引发大量无效的数据迁移，我们集群虽然只用了30%多，但是实际存储图片量已经超过10亿，这个数量级的集群数据迁移是相当耗时的，另外一方面，我们在集群建好的时候就进行了crushmap的定制并保存了那时候的crushmap，在此时可以直接set这个crushmap，一键解决crushmap的问题

在osd重建并加入集群后，为了保证前端写入业务不受影响，我们控制了集群的恢复速度，恢复即使慢点，也不能影响线上业务

1
sudo ceph tell osd.* injectargs '--osd_recovery_max_single_start 8 --osd_recovery_sleep_hdd 0 --osd_recovery_max_active 8 --osd_max_backfills 8'

经验与总结

此次ssd坏掉导致osd重建的问题，其实算是比较常规的问题，磁盘损坏在所难免，不过集群数据量超过500TB，而且是线上机器，多少还是有些担心，处理过程中也暴露了一些考虑不周的问题

  • 1、部署完之后没有生成osd-lvm-wal的对照表，导致重建osd重建之前要慢慢找osd对应的lvm，手工删除
  • 2、实际上我们在out osd之后，没有马上删除该osd，其实应该马上删除该osd的
  • 3、ssd磁盘监控仍然不够完善深入，没能做到提前预警，不过顺便吐槽一下三星的DCT磁盘，才写了一周就跪了
  • 4、处理过程中有部分前端写入失败，是因为恢复速度开得太大，这个恢复速度综合考虑的东西不少

经验

  • 1、完备的磁盘健康监控要做好
  • 2、创建osd所使用的全部磁盘及分区要使用/dev/disk/by-id/下面的设备，避免因盘符漂移引发osd异常，关于这点后面会有文章专门深入分析
  • 3、集群部署完成后，要记录每个osd对应的分区、lvm及weight，方便osd的重建
  • 4、集群高可用规划要做好，目前我们在设计一个可靠性更高的方案，线上业务是首先要保证的
  • 5、别省钱，有钱就上3副本吧
赏

谢谢你请我吃糖果

支付宝
微信
  • 本文作者： 奋斗的松鼠
  • 本文链接： http://www.strugglesquirrel.com/2018/08/17/记一次SSD磁盘损坏导致的osd重建/
  • 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

松鼠哥，存储研发专家
曾就职于深信服北京研发中心，负责存储相关产品的调研测试
在分布式存储领域深耕近十年，实战经验和理论经验功力深厚
累计管理及上线生产集群超过600个，机器超3万台，磁盘总数超过80万块，总容量达到EB级别。