半天河
網(wǎng)易游戲高級運維工程師，主要負責(zé)云存儲的運維；一個既希望跟業(yè)務(wù)聊又喜歡能夠默默在后面忙活的普通運維人。

背景故障現(xiàn)場故障恢復(fù)故障恢復(fù)分析第一種方式：物理磁盤對拷第二種方式：服務(wù)啟動時跳過故障扇區(qū)來避免異常退出解決方案恢復(fù)流程找到故障扇區(qū)處的文件移走故障扇區(qū)的文件總結(jié)

背景

對于 ceph 運維而言，硬件故障導(dǎo)致的 ceph 存儲故障是占比最高的一個故障源，小到單個磁盤故障大到機器故障，每天都在上演，ceph 的多副本、故障域等機制已經(jīng)能夠保證絕大部分的硬件故障不影響整個 ceph 集群的可用性，比如：

• 多副本能夠確保只要還有一個副本在，數(shù)據(jù)就不會丟失，業(yè)務(wù)依然可用
• 故障域的劃分能夠確保一個故障域內(nèi)的機器或者機柜故障時，數(shù)據(jù)不會丟失，業(yè)務(wù)依然可用
• 有需要時還可以將故障服務(wù)踢出集群，觸發(fā)數(shù)據(jù)遷移到故障域內(nèi)其他硬盤，縮短副本數(shù)不達標(biāo)的時間，降低二次故障的影響

但是在日常實際場景中，概率低不代表不會發(fā)生，我們必須對這種雖然概率低但是影響可能很大的故障做好預(yù)案，確保一旦發(fā)生故障能夠快速恢復(fù)服務(wù)。

故障現(xiàn)場

這里先簡單介紹一下整個故障現(xiàn)場：

• ceph 的版本是Hammer 0.94.5
• 故障域是 host，副本數(shù)是 2（即同一個業(yè)務(wù)的數(shù)據(jù)會寫兩份，落在不同 host 的各一個硬盤上）
• 一臺服務(wù)器的一塊硬盤故障
• 更換磁盤，同步數(shù)據(jù)
• 另一臺服務(wù)器上又有一塊硬盤故障
• 數(shù)據(jù)兩個副本存放在這兩塊硬盤上的所有業(yè)務(wù)請求被 block 住
• 集群狀態(tài)關(guān)鍵信息如下：
  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 表示有部分?jǐn)?shù)據(jù)的兩個副本都不在線
  • 有 57 個客戶端的請求被 block 超過 32 秒
  • 注意這里是 7 個對象的狀態(tài)是 unfound

故障恢復(fù)

故障恢復(fù)分析

目前數(shù)據(jù)層的影響面及恢復(fù)分析如下：

• 毫無疑問，第一要務(wù)是先拉回所有存儲服務(wù)
• 服務(wù)都在線后才能明確兩塊硬盤先后故障是否有數(shù)據(jù)丟失
• 根據(jù)數(shù)據(jù)實際情況再決定后續(xù)恢復(fù)操作

目前是因為磁盤有壞道，讀取壞道數(shù)據(jù)出錯導(dǎo)致服務(wù)無法啟動。

第一種方式：物理磁盤對拷

最先想到也是操作最簡單的一種方法就是將故障盤數(shù)據(jù)全量拷貝到一塊新的硬盤上，忽略其中的故障扇區(qū)讀取錯誤，方法如下：

• 在同機房找到一臺空閑服務(wù)器，插上新硬盤，格式化分區(qū)
• 通過 dd+nc 的方式將故障盤數(shù)據(jù) dd 到準(zhǔn)備的新盤
  # 備用機器，新硬盤
  nc -lp {port} | dd of=/dev/sde1
  # 故障機器
  dd if=/dev/sdX conv=noerror | nc -q 10 {backup ip} {nc port}
• 拷貝完成后將新盤替換掉故障盤啟動服務(wù)即可
• 這種方法是可行的，尤其是對于較大范圍的磁盤硬件故障這是一個相對穩(wěn)妥且節(jié)省人力的方法
• 但是由于故障 SAS 盤讀寫速度也就 200MB/s 的峰值，即使保持這個速度，1.2TB 的盤同步完成也需要接近兩小時，線上業(yè)務(wù)坐等兩小時是無計可施的保底方法。

第二種方式：服務(wù)啟動時跳過故障扇區(qū)來避免異常退出

解決方案

回過頭仔細分析本次故障的信息及規(guī)避方法匯總?cè)缦?#xff1a;

• 磁盤故障范圍小，雖然 dmesg 很多報錯信息，但是都集中在同一個扇區(qū)
  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
• 存儲服務(wù)啟動時的報錯信息是讀寫錯誤，嘗試啟動一次上面的 dmesg 信息就會再刷一些通用的日志：
  FAILED assert(0 == "Input/output error")
• 找到故障扇區(qū)所在的文件，移走該文件，移走文件并不會變更該扇區(qū)所在的文件，以確保故障扇區(qū)依然被占用而不會分配給其他文件使用
• osd 啟動時就不會讀取故障扇區(qū)所在文件，就不會拋異常退出

恢復(fù)流程

經(jīng)過上述分析后，恢復(fù)流程就比較清晰而且簡單了：

找到故障扇區(qū)處的文件

• 在配置文件中調(diào)大 osd 服務(wù)的 debug_filestore 日志級別到 20/20
• 啟動故障盤的存儲服務(wù)，從日志中可以看到故障扇區(qū)的文件，如下
  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
• 得到關(guān)鍵信息：PG 是 28.7cb ,目錄結(jié)構(gòu)是b7e767cb，故障扇區(qū)所在文件是 rb.0.8e1ad1d.238e1f29.00000000a418
• 根據(jù) filestore 的存儲規(guī)則定位到該對象在磁盤上的絕對路徑如下：
  /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

TIPS：filestore 是以文件的形式存儲，同時為了避免單目錄下文件數(shù)過多影響性能，osd 會將這些對象分多級目錄存儲，從前面的日志中可以看到對象路徑是<pg_id>/b7e767cb/<object_name>，這里面的b7e767cb就是用來分子目錄時的目錄名，根據(jù)當(dāng)前目錄層級是 4（由當(dāng)前 pool 的總對象數(shù)和各層文件數(shù)決定），可知道這個 object 存儲在磁盤上的路徑是：<pg_id>/DIR_B/DIR_C/DIR_7/DIR_6/<object_name>

移走故障扇區(qū)的文件

這時候通過 cat 嘗試查看這個文件可以看到中途會卡住，dmesg 也會繼續(xù)刷上面的扇區(qū)錯誤，進一步實錘了磁盤壞道所在文件即為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
• 拉起服務(wù)，成功運行，一段時間后集群狀態(tài)如下這個 object 狀態(tài)仍然是 unfound：
  1 requests are blocked > 32 sec;
  recovery 1/137522689 unfound (0.000%);
• 注意這里的recovery 1/137524092 unfound (0.000%)，前面服務(wù)沒有拉起來時 ceph 提示有 7 個對象處于 unfound，現(xiàn)在只剩下一個了，這個對象的 osd 的日志提示如下：
  # 從名字上看也恰好是故障扇區(qū)的那個文件
  28.7cb missing primary copy of b7e767cb/rb.0.8e1ad1d.238e1f29.00000000a418/head//28, unfound

TIPS：ceph 的對象包括三個部分的數(shù)據(jù)，一個是純數(shù)據(jù)部分，一個是文件系統(tǒng)擴展屬性提供的元數(shù)據(jù)，一個 ceph 自己實現(xiàn)的 omap 元數(shù)據(jù)，這里的 unfound 表示 ceph 在本地沒有找到跟元數(shù)據(jù)中記錄的版本一致的對象，unfound 數(shù)量變少，說明經(jīng)過版本比對，其他 6 個對象的版本和其他副本的版本是一致的。

• 這時候只能用以下命令通過 ceph 將這個 pg 下的 object 回滾到另一個副本上的版本了
  ceph pg 28.7cb mark_unfound_lost revert

TIPS：因為第一塊盤故障離線期間 ceph 是還可以繼續(xù)使用的，這期間有對象發(fā)生數(shù)據(jù)更新，而更新的這部分?jǐn)?shù)據(jù)就只在第二塊故障盤上有，因此就造成了這個對象有兩個版本，新的版本不可用，因此使用 revert 來告訴 ceph 使用較老版本；如果兩個副本同時不可用，只能使用 lost 來標(biāo)記對象丟失來恢復(fù)服務(wù)。

至此，集群完全恢復(fù)，后續(xù)的步驟就是根據(jù)這個故障對象名找到 rbd，繼而找到所屬的虛擬機，請求業(yè)務(wù)確認(rèn)影響面并檢查虛擬機。

總結(jié)

以上就是我們針對雙副本對象的兩個副本因為故障先后離線這種極端情況下進行數(shù)據(jù)搶救的過程。針對故障、搶救過程以及后續(xù)優(yōu)化總結(jié)如下：

• 單個磁盤故障可能會導(dǎo)致整個機器的 raid 卡控制器 reset
• 在一個副本故障期間，又有新的磁盤硬件故障，就導(dǎo)致了本問描述的嚴(yán)重故障，三副本能大大減少本次故障概率
• 如果硬盤故障，在完全恢復(fù)前不要刪除數(shù)據(jù)或者格式化硬盤，以免碰到另一個副本也故障時，連回滾來版本的機會也沒有了
• 搶救的根本方法是找到問題癥結(jié)，如本次故障中采用移走故障文件的方式就可以解決無法啟動問題
• ceph 故障都會有比較詳細的日志提示，根據(jù)提示結(jié)合 ceph 的結(jié)構(gòu)特點做針對性的處理即可
• 雙副本發(fā)生二次故障的概率更高，尤其是使用年限較高深圳過保的老集群
• 對于關(guān)掉了 deep-scrub 的集群，需要手動不定期去觸發(fā) deep-scrub，防止一些可能隱藏的磁盤故障。

往期精彩

﹀

﹀

﹀

那些年，CDN踩過的坑

智能監(jiān)控中的時間序列預(yù)測

使用 d3.js 繪制資源拓撲圖

運維里的人工智能

CI構(gòu)建環(huán)境下的docker build最佳實踐

總結(jié)

以上是生活随笔為你收集整理的sleep期间读取所有_ceph部分数据所有副本先后故障的抢救的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。