做试卷的网站,精美网页设计欣赏,邢台163信息港,知名企业营销案例100例半天河网易游戏高级运维工程师#xff0c;主要负责云存储的运维#xff1b;一个既希望跟业务聊又喜欢能够默默在后面忙活的普通运维人。背景故障现场故障恢复故障恢复分析第一种方式#xff1a;物理磁盘对拷第二种方式#xff1a;服务启动时跳过故障扇区来避免异常退出解决…半天河网易游戏高级运维工程师主要负责云存储的运维一个既希望跟业务聊又喜欢能够默默在后面忙活的普通运维人。背景故障现场故障恢复故障恢复分析第一种方式物理磁盘对拷第二种方式服务启动时跳过故障扇区来避免异常退出解决方案恢复流程找到故障扇区处的文件移走故障扇区的文件总结背景 对于 ceph 运维而言硬件故障导致的 ceph 存储故障是占比最高的一个故障源小到单个磁盘故障大到机器故障每天都在上演ceph 的多副本、故障域等机制已经能够保证绝大部分的硬件故障不影响整个 ceph 集群的可用性比如多副本能够确保只要还有一个副本在数据就不会丢失业务依然可用故障域的划分能够确保一个故障域内的机器或者机柜故障时数据不会丢失业务依然可用有需要时还可以将故障服务踢出集群触发数据迁移到故障域内其他硬盘缩短副本数不达标的时间降低二次故障的影响但是在日常实际场景中概率低不代表不会发生我们必须对这种虽然概率低但是影响可能很大的故障做好预案确保一旦发生故障能够快速恢复服务。故障现场 这里先简单介绍一下整个故障现场ceph 的版本是Hammer 0.94.5故障域是 host副本数是 2即同一个业务的数据会写两份落在不同 host 的各一个硬盘上一台服务器的一块硬盘故障更换磁盘同步数据另一台服务器上又有一块硬盘故障数据两个副本存放在这两块硬盘上的所有业务请求被 block 住集群状态关键信息如下2 pgs down; 2 pgs peering; 57 requests are blocked 32 sec;recovery 4292086/381750087 objects degraded (1.124%);recovery 7/137511185 unfound (0.000%);21/967 in osds are down;down 表示有部分数据的两个副本都不在线有 57 个客户端的请求被 block 超过 32 秒注意这里是 7 个对象的状态是 unfound故障恢复 故障恢复分析目前数据层的影响面及恢复分析如下毫无疑问第一要务是先拉回所有存储服务服务都在线后才能明确两块硬盘先后故障是否有数据丢失根据数据实际情况再决定后续恢复操作目前是因为磁盘有坏道读取坏道数据出错导致服务无法启动。第一种方式物理磁盘对拷最先想到也是操作最简单的一种方法就是将故障盘数据全量拷贝到一块新的硬盘上忽略其中的故障扇区读取错误方法如下在同机房找到一台空闲服务器插上新硬盘格式化分区通过 ddnc 的方式将故障盘数据 dd 到准备的新盘 # 备用机器新硬盘 nc -lp {port} | dd of/dev/sde1 # 故障机器 dd if/dev/sdX convnoerror | nc -q 10 {backup ip} {nc port}拷贝完成后将新盘替换掉故障盘启动服务即可这种方法是可行的尤其是对于较大范围的磁盘硬件故障这是一个相对稳妥且节省人力的方法但是由于故障 SAS 盘读写速度也就 200MB/s 的峰值即使保持这个速度1.2TB 的盘同步完成也需要接近两小时线上业务坐等两小时是无计可施的保底方法。第二种方式服务启动时跳过故障扇区来避免异常退出解决方案回过头仔细分析本次故障的信息及规避方法汇总如下磁盘故障范围小虽然 dmesg 很多报错信息但是都集中在同一个扇区Sep 26 16:09:33 cld-XXXX-XX kernel: [51720946.582063] end_request: critical medium error, dev sdd, sector 49382788...Sep 26 16:23:02 cld-XXXX-XX kernel: [51721756.747154] end_request: critical medium error, dev sdd, sector 49382788存储服务启动时的报错信息是读写错误尝试启动一次上面的 dmesg 信息就会再刷一些通用的日志FAILED assert(0 Input/output error)找到故障扇区所在的文件移走该文件移走文件并不会变更该扇区所在的文件以确保故障扇区依然被占用而不会分配给其他文件使用osd 启动时就不会读取故障扇区所在文件就不会抛异常退出恢复流程经过上述分析后恢复流程就比较清晰而且简单了找到故障扇区处的文件在配置文件中调大 osd 服务的 debug_filestore 日志级别到 20/20启动故障盘的存储服务从日志中可以看到故障扇区的文件如下7f08ae8ee700 10 filestore(/home/ceph/var/lib/osd/ceph-387) FileStore::read(28.7cb_head/b7e767cb/rb.0.8e1ad1d.238e1f29.00000000a418/head//28) pread error: (5) Input/output error得到关键信息PG 是 28.7cb ,目录结构是b7e767cb故障扇区所在文件是 rb.0.8e1ad1d.238e1f29.00000000a418 根据 filestore 的存储规则定位到该对象在磁盘上的绝对路径如下/home/ceph/var/lib/osd/ceph-387/current/28.7cb_head/DIR_B/DIR_C/DIR_7/DIR_6/rb.0.8e1ad1d.238e1f29.00000000a418__head_B7E767CB__1cTIPSfilestore 是以文件的形式存储同时为了避免单目录下文件数过多影响性能osd 会将这些对象分多级目录存储从前面的日志中可以看到对象路径是pg_id/b7e767cb/object_name这里面的b7e767cb就是用来分子目录时的目录名根据当前目录层级是 4由当前 pool 的总对象数和各层文件数决定可知道这个 object 存储在磁盘上的路径是pg_id/DIR_B/DIR_C/DIR_7/DIR_6/object_name移走故障扇区的文件这时候通过 cat 尝试查看这个文件可以看到中途会卡住dmesg 也会继续刷上面的扇区错误进一步实锤了磁盘坏道所在文件即为rb.0.8e1ad1d.238e1f29.00000000a418__head_B7E767CB__1c 移动故障对象mv /home/ceph/var/lib/osd/ceph-387/current/28.7cb_head/DIR_B/DIR_C/DIR_7/DIR_6/rb.0.8e1ad1d.238e1f29.00000000a418__head_B7E767CB__1c /home/ceph/var/lib/osd/ceph-387拉起服务成功运行一段时间后集群状态如下这个 object 状态仍然是 unfound1 requests are blocked 32 sec; recovery 1/137522689 unfound (0.000%); 注意这里的recovery 1/137524092 unfound (0.000%)前面服务没有拉起来时 ceph 提示有 7 个对象处于 unfound现在只剩下一个了这个对象的 osd 的日志提示如下# 从名字上看也恰好是故障扇区的那个文件28.7cb missing primary copy of b7e767cb/rb.0.8e1ad1d.238e1f29.00000000a418/head//28, unfoundTIPSceph 的对象包括三个部分的数据一个是纯数据部分一个是文件系统扩展属性提供的元数据一个 ceph 自己实现的 omap 元数据这里的 unfound 表示 ceph 在本地没有找到跟元数据中记录的版本一致的对象unfound 数量变少说明经过版本比对其他 6 个对象的版本和其他副本的版本是一致的。这时候只能用以下命令通过 ceph 将这个 pg 下的 object 回滚到另一个副本上的版本了ceph pg 28.7cb mark_unfound_lost revertTIPS因为第一块盘故障离线期间 ceph 是还可以继续使用的这期间有对象发生数据更新而更新的这部分数据就只在第二块故障盘上有因此就造成了这个对象有两个版本新的版本不可用因此使用 revert 来告诉 ceph 使用较老版本如果两个副本同时不可用只能使用 lost 来标记对象丢失来恢复服务。至此集群完全恢复后续的步骤就是根据这个故障对象名找到 rbd继而找到所属的虚拟机请求业务确认影响面并检查虚拟机。总结 以上就是我们针对双副本对象的两个副本因为故障先后离线这种极端情况下进行数据抢救的过程。针对故障、抢救过程以及后续优化总结如下单个磁盘故障可能会导致整个机器的 raid 卡控制器 reset在一个副本故障期间又有新的磁盘硬件故障就导致了本问描述的严重故障三副本能大大减少本次故障概率如果硬盘故障在完全恢复前不要删除数据或者格式化硬盘以免碰到另一个副本也故障时连回滚来版本的机会也没有了抢救的根本方法是找到问题症结如本次故障中采用移走故障文件的方式就可以解决无法启动问题ceph 故障都会有比较详细的日志提示根据提示结合 ceph 的结构特点做针对性的处理即可双副本发生二次故障的概率更高尤其是使用年限较高深圳过保的老集群对于关掉了 deep-scrub 的集群需要手动不定期去触发 deep-scrub防止一些可能隐藏的磁盘故障。往期精彩﹀﹀﹀那些年CDN踩过的坑智能监控中的时间序列预测使用 d3.js 绘制资源拓扑图运维里的人工智能CI构建环境下的docker build最佳实践
