Ceph 磁盘损坏现象和解决方法

简介: Damaged disks对于存储系统,磁盘是消耗品,损坏是很常见的,所以这篇文章记录一下 Ceph 中出现磁盘损坏时的现象,以及如何定位和更换损坏的磁盘。
img_060d54170d64fb321f45744dbdef826d.png
Damaged disks

对于存储系统,磁盘是消耗品,损坏是很常见的,所以这篇文章记录一下 Ceph 中出现磁盘损坏时的现象,以及如何定位和更换损坏的磁盘。

1. 磁盘损坏

1.1 现象

工作环境中出现问题的 Ceph 的数据是双备份的,OSD 35 所在的磁盘出现了坏道,表现出来的现象是 ceph 经常会报出存储在 OSD 35 上的 pg 数据不一致,以及报出 scrub error,以下是 ceph health detail 命令输出新相关信息。

$ ceph health detail
......
OSD_SCRUB_ERRORS 31 scrub errors
PG_DAMAGED Possible data damage: 5 pgs inconsistent
    pg 41.33 is active+clean+inconsistent, acting [35,33]
    pg 41.42 is active+clean+inconsistent, acting [29,35]
    pg 51.24 is active+clean+inconsistent, acting [35,43]
    pg 51.77 is active+clean+inconsistent, acting [28,35]
    pg 51.7b is active+clean+inconsistent, acting [35,46]
......

1.2 数据状态

因为数据只有双备份,ceph 无法确定哪个备份中的数据是可用的,所以此时虽然显示 pg 状态是 active+clean,但有问题的数据其实是不可用的。

1.3 临时解决方法

作为临时的解决方案,可以执行 ceph pg repair 解决,此时由于磁盘坏道造成不可读的数据会拷贝到其他位置。但这不能从根本上解决问题,磁盘损坏会持续报出类似的错误。

$ ceph pg repair 41.33
$ ceph pg repair 41.42
$ ceph pg repair 51.24
$ ceph pg repair 51.77
$ ceph pg repair 51.7b

2. 定位并检查故障磁盘

知道 OSD 35 有问题,但我们现在还不知道对应的是具体哪块磁盘。我们可以登录到对应到 OSD 服务器上查看 OSD 35 的目录名称,并查看 PVS 的对应关系来解决。

$ ceph osd tree
ID CLASS WEIGHT    TYPE NAME      STATUS REWEIGHT PRI-AFF 
-1       127.09767 root default                           
-5       127.09767     host osd7                          
......
33   hdd   5.52599         osd.35     up  1.00000 1.00000 
......

通过这个命令,我们可以知道 OSD.35 是位于 OSD7 这台服务器上。接下来,我们登录到 OSD7 上,并切换为 root 权限。

$ ssh osd7
$ sudo -i

然后进入到 OSD.35 的目录里。

# cd /var/lib/ceph/osd/ceph-35

再来查看 PVS 信息。

# pvs -o+pv_used
......
  PV         VG                                        Fmt  Attr PSize   PFree Used   
  /dev/sda5  ubuntu-vg                                 lvm2 a--  446.65g    0  446.65g
  /dev/sdc   ceph-320de131-5f26-48a7-aa64-c7f08f87cd85 lvm2 a--    5.46t    0    5.46t  
......

好,现在我们终于知道,/dev/sdc 就是 OSD.35

3. 获取磁盘错误信息

我们已经知道是哪个磁盘出错,接下来就要向磁盘的提供商报修,或者联系购买新磁盘了。如果是报修,对方必然要求提供磁盘出错信息,接下来咱们就看一下如何拿到这些信息,这里我们要用到的命令好工具是 SMART monitor tool,Debian 系的系统可以通过 APT 安装:

$ sudo apt install -y smartmontools

RedHat 系的系统用 yum 安装:

$ sudo yum install -y smartmontools

安装完成后用如下命令获取输出信息即可,这里需要注意一下输出中序列号这项信息,这次磁盘的唯一标识,后面会用到:Serial Number: 57J6KA41F6CD

$ sudo smartctl -a /dev/sdc
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-121-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     TOSHIBA MG04ACA600E
Serial Number:    57J6KA41F6CD
LU WWN Device Id: 5 000039 7cb9822be
Firmware Version: FS1K
User Capacity:    6,001,175,126,016 bytes [6.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Aug  7 14:46:45 2018 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
...

4. 点亮硬盘指示灯

最后,存储厂商同意保修,或者购买新硬盘进行更换,都需要知道磁盘具体插在哪个 PCIe 口上。虽然我们已经知道是哪个设备了,本例中是 /dev/sdc,但这依旧不够直观,如果能让坏掉的硬盘的指示灯亮起,那么就非常方便维修人员查找和更换了。这就需要用到 SAS-x integrated RAID configuration utility 了。

该文件没有提供 APT 和 YUM 源的下载方式,只能从网上找到 RPM 或可执行文件,以下链接是该文件的百度云盘地址:
sas3ircu

下载好后,先执行 display 命令,查找全部磁盘信息。

$ sudo ./sas3ircu 0 display
......
Device is a Hard disk
  Enclosure #                             : 2
  Slot #                                  : 0
  SAS Address                             : 5003048-0-1867-f140
  State                                   : Ready (RDY)
  Size (in MB)/(in sectors)               : 5723166/11721045167
  Manufacturer                            : ATA     
  Model Number                            : TOSHIBA MG04ACA6
  Firmware Revision                       : FS1K
  Serial No                               : 57J6KA41F6CD
  Unit Serial No(VPD)                     : 57J6KA41F6CD
  GUID                                    : 50000397cb9822be
  Protocol                                : SATA
  Drive Type                              : SATA_HDD

......

从输出结果来看,Serial No : 57J6KA41F6CD,和之前 smartctl 查询到的结果一致,那么我们就知道这次磁盘的位置是

  Enclosure #                             : 2
  Slot #                                  : 0

接下来执行下面的命令点亮对应硬盘的指示灯:

sudo ./sas3ircu 0 locate 2:0 on

另外更换完毕后,自然还要执行该命令关掉指示灯:

sudo ./sas3ircu 0 locate 2:0 off
目录
相关文章
|
4月前
|
存储 运维 数据挖掘
服务器数据恢复—EqualLogic PS存储硬盘故障导致存储崩溃的数据恢复案例
一台某品牌EqualLogic PS系列某型号存储,存储中有一组由16块SAS硬盘组建的RAID5磁盘阵列,RAID5上划分VMFS文件系统存放虚拟机文件。存储系统上层一共分了4个卷。 raid5阵列中磁盘出现故障,有2块硬盘的指示灯显示黄色,存储不可用,存储设备已经过保,用户方联系我们数据恢复中心要求恢复存储中的数据。
服务器数据恢复—EqualLogic PS存储硬盘故障导致存储崩溃的数据恢复案例
|
4月前
|
存储 Unix 数据挖掘
【北亚服务器数据恢复】LUN映射出错导致文件系统一致性出错的数据恢复案例
服务器数据恢复环境: san环境下的存储上一组由6块硬盘组建的RAID6,划分为若干LUN,MAP到跑不同业务的服务器上,服务器上层是SOLARIS操作系统+UFS文件系统。 服务器故障: 业务需求需要增加一台服务器跑新增的应用,工作人员在原服务器在线的状态下将其中一个lun映射到一台新服务器上。实际上这个刚映射过去的卷已经map到了solaris生产系统上的某个lun上了。新服务器对这个映射过来的卷进行初始化,原来的solaris系统上的磁盘报错,重启服务器后这个卷已经无法挂载了。 联系原厂工程师寻求帮助,原厂工程师检测后执行了fsck操作,完成fsck操作后文件系统挂载成功,查看数据时发
|
2月前
|
存储 安全 数据挖掘
服务器数据恢复—异常断电导致EVA存储中RAID信息丢失的数据恢复案例
意外断电导致raid硬件损坏或者riad管理信息丢失等raid模块损坏而导致数据丢失的情况非常普遍。正常情况下,磁盘阵列一旦创建完成就不会再对管理模块中的信息进行更改,但是raid管理模块中的信息属于可修改信息,一次或多次的意外断电可能会导致这部分信息被篡改或丢失。断电次数过多甚至会导致raid卡上的元器损坏。
|
4月前
|
存储 安全 数据挖掘
服务器数据恢复—正常断电后重启的服务器中Raid5阵列崩溃的数据恢复案例
服务器数据恢复环境: 一台某品牌DL380 G4服务器,服务器通过该服务器品牌smart array控制器挂载了一台国产的磁盘阵列,磁盘阵列中有一组由14块SCSI硬盘组建的RAID5。服务器安装LINUX操作系统,搭建了NFS+FTP,作为内部文件服务器使用。 服务器故障: 搬迁机房后,工作人员将服务器和磁盘阵列打扫了一下,连接所有线缆后,将服务器和磁盘阵列开机,发现服务器无法识别RAID,提示未做初始化。 北亚企安数据恢复工程师到达现场后对服务器和磁盘阵列进行简单的初检,经过初检发现数据丢失的原因是raid信息丢失,该RAID的冗余采用双循环的校验方式。
|
24天前
|
SQL 数据库 数据安全/隐私保护
服务器数据恢复—raid5阵列故障因操作不当导致数据无法恢复的案例
服务器数据恢复环境: 一台服务器中有一组由4块SCSI硬盘组建的raid5磁盘阵列,划分了一个逻辑卷,操作系统为WINDOWS SERVER,作为SQL SERVER服务器使用。 服务器故障: 运行过程中该服务器raid5磁盘阵列瘫痪,管理员检查服务器发现raid5阵列中已经有3块磁盘离线。管理员选择其中2块离线硬盘进行强制上线操作,强制上线后操作系统无法启动。使用WINPE光盘启动操作系统后,可以看到数据。
|
1月前
|
存储 Unix 数据挖掘
服务器数据恢复—SAN环境下LUN Mapping出错导致文件系统一致性出错的数据恢复案例
服务器存储数据恢复环境: 一台存储中有一组由6块硬盘组成的RAID6,划分为若干LUN,MAP到不同业务的SOLARIS操作系统服务器上。 服务器存储故障: 由于业务变化需要增加一台服务器,在存储在线的状态下将该存储中的某个LUN映射到这台新增加的服务器上并开始初始化,不料映射的这个LUN已经MAP到其他SOLARIS服务器上了。由于该LUN已经进行了部分的初始化,磁盘报错,重启后发现卷无法挂载。
|
4月前
|
存储 关系型数据库 MySQL
服务器数据恢复—EVA存储异常断电重启后虚拟机无法启动的数据恢复方案
服务器存储数据恢复环境: 某品牌EVA8400,服务器上安装VMware ESXi虚拟化平台,虚拟机的虚拟磁盘包括数据盘(精简模式)+快照数据盘,部分虚拟机中运行oracle数据库和mysql数据库。 服务器存储故障&检测: 存储异常断电重启后,存储中一台虚拟机无法启动。工作人员推测故障原因是异常断电导致电源模块出现故障,清空cache后重新启动存储发现该虚拟机仍无法正常启动。
|
4月前
|
存储 运维 安全
服务器数据恢复—异常断电导致RAID5阵列信息丢失的数据恢复案例
服务器数据恢复环境: 某品牌ProLiant DL380系列服务器,服务器中有一组由6块SAS硬盘组建的RAID5阵列,WINDOWS SERVER操作系统,作为企业内部文件服务器使用。 服务器故障: 机房供电几次意外中断,服务器出现故障前最后一次异常断电重启后RAID报错,提示无法找到存储设备,进入RAID管理模块做任何操作都死机,重启服务器后问题依旧,用户联系北亚企安数据恢复中心寻求帮助。
|
4月前
|
存储 运维 安全
服务器数据恢复—存储互斥不当导致VMFS卷损坏的数据恢复案例
某公司的信息管理平台,通过3台虚拟机共享了一台存储设备供企业内部使用,存储设备中存放了公司内部重要的数据文件。 由于业务增长的需要,管理员又在这个存储网络上连接了一台Windows server服务器,结果这台存储变得不可用了。 管理员对该存储进行故障排查时发现存储中虚拟磁盘丢失,分区表丢失。重启该存储设备后故障依旧。 由于存储中的数据十分重要,没有备份。管理员为了安全起见,联系北亚企安数据恢复中心寻求帮助。 经过硬件工程师的检测,没有发现存储存在硬件故障。存储中的硬盘经过硬件工程师的检测后也没有发现任何物理故障,都可以正常读取。基本上可以排除故障是由于硬件导致的。
|
10月前
|
运维 数据挖掘 数据库
服务器数据恢复—服务器raid5磁盘故障导致分区无法访问的数据恢复案例
某品牌DL380服务器中有一组由三块SAS硬盘组建的RAID5阵列。数据库存放在D分区,数据库备份存放在E分区。 服务器上有一块硬盘的状态灯显示红色,D分区无法识别,E分区可识别,但是拷贝文件报错。管理员重启服务器,离线的硬盘上线,同步了一段时间但是还没有完成同步时候,管理员将服务器强制关机,之后就没有动过服务器。
服务器数据恢复—服务器raid5磁盘故障导致分区无法访问的数据恢复案例