ceph的在正常執行的時候基本不會出現故障，出現故障一般在變動的時候，具體有下面幾種可能出現的情形
以上這些操作過程中是最可能出現異常的情形，並不是一定會出問題，以上問題除了網路和磁碟問題出現的異常是基本無法避免外，其他出現的時候，一般是非正常操作引起的，也就是我通常認為的人為事故，這個一般出現在操作的不謹慎上
本篇記錄了一次故障的修復過程，這個故障不是出現在我們公司的產品上，是看到乙個ceph社群群裡有乙個成員在裡面問到乙個異常是否能解決，這個不同於普通的問題，從他貼出的資訊來看，集群已經是非常嚴重的狀態了
正好看到是周五，週六還可以休息下，所以即使快到了晚上12點了，我還是聯絡了一下那哥們，從簡短的幾句交流後，基本可以判斷對方對於ceph基本處於剛接觸的階段，在詢問是否有其他人能協助他做一些比較有難度的操作的時候，他說沒有，就他乙個人，我想在目前中國很多公司，都是讓乙個並不太熟悉ceph的運維人員，或者完全就是開發人員維護著儲存著非常寶貴的資料的雲儲存環境，上面執行的應該都是客戶的資料，想想我們自己的電腦在硬碟損壞後，自己有多麼不爽，而對於企業來說，乙個執行環境的損壞有多麼嚴重，一方面損失了資料，另一方面，基本不會再選擇這個服務的提供商了，而這些都是乙個定時炸彈，執行在中國的開源儲存網路環境當中，而且基本都是初創小企業，大企業會有專門的專業的相關人員，而乙個資料損失基本會對這些初創企業帶來巨大的損失，這些都是需要企業的boss多關注的，這也是我一直持有的乙個觀點，越來越多的企業是用ceph，也意味著儲存需要修復的出現機率就越大，其實我們也是乙個小企業，我個人是非常關注資料恢復這一塊的，這個比調優更加的重要，大環境的吐槽就到這裡，下面開始講下具體的經過
這個對方正好有這個環境允許我的登陸，雖然中間經過了堡壘機，雖然執行命令比較卡頓，但好歹能上去，這個是我個人非常支援的一種做法，不管怎樣，是vpn也好，**也好，一定留乙個外網的ssh埠能夠讓連上機器，這個能允許隨時隨地能上去處理問題，等你運維人員到達現場，真是黃花菜都涼了，對於比較保密的環境，最好也能夠有乙個在緊急情況下開啟遠端允許環境的條件，這個具體花費，乙個上網絡卡，一台破舊的筆記本就基本能實現了，在需要遠端操作的時候能夠連上去處理，目前已經協助了幾個朋友處理了一些簡單的問題，基本都是ssh連過去的，而沒有遠端環境的，我也是無能為力的
登陸上去以後，檢查環境發現提示的是2個pg的狀態imcomplete，這個是pg的資料不一致的提示，而在檢查了對應的osd上的這個pg的資料的時候，發現對映計算到的3個上面有兩個是沒有資料的，有乙個是有資料的，在詢問對方做過的操作後，對方是做了乙個刪除osd的操作，並且是多台機器上面都做過刪除，到這裡我詢問了一下對方，對方是按照一些通用的操作去做的刪除操作，命令肯定是沒有問題的，這個在後面我處理完後，基本能判斷出對方是人為的操作失誤引起的
開始想起之前做過的一次模擬修復，本來以為這個可以把環境弄好了，基本想法就是如下流程：
在進行到資料的匯入的時候提示了pg is blocked，這個在我之前的做的測試中是沒有遇到過的，後來進行pg的狀態查詢時候，發現是pg的顯示的資料全是0，也就是集群認為這個pg是沒有資料的，並且被幾個已經刪除了的osd blocked,而且做ceph osd lost 也是無法操作的，提示沒有osd，這個應該是pg狀態不一致，也就是這個pg狀態完全異常了，並且還無法匯入了
到這裡我個人判斷基本是回天無力了，再次跟對方確認刪除的過程，發現對方好在資料盤都保留了，並且還插在機器上，只是有部分osd在進行增加的時候還占用了刪除的osd的id
到這裡我基本想出來兩種方法：
這個集群之所以能挽回，有幾個特殊點正好都在，缺一不可
刪除的資料盤居然沒被格式化，或者搞掉，這個如果弄沒了，資料必丟
刪除的資料盤的盤位部分被新加的節點占用了，部分還沒有被占用，而這個缺失資料的pg的資料所刪除的osd正好又沒有被占用（所以以後替換osd的時候最好是用新的編號，老的盤和編號保留著）
之前我加節點的操作都是用的ceph-deploy，可以說基本沒有遇到過手動能做的ceph-deploy無法完成的，好吧這次我知道了還是有無法完成的，手動的還是多學學比較好，好在我比較熟悉，就按步驟去做
1、增加認證
我們在刪除osd的最後一步的時候操作都是ceph auth del
我就反向的操作
ceph auth add osd.0 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd0/keyring這一步操作完成後auth裡面就有osd.0了
2、建立osd
ceph osd create這一步相對於刪除裡面的操作應該就是 ceph osd rm 的操作了
3、增加crush
ceph osd crush add osd.0 0.9 host=node14、啟動osd
/etc/init.d/ceph start osd.0集群的刪除操作隨意，集群的資訊基本無記錄，環境的基礎記錄都沒有，這個是這個事故的最大原因，再往上走就是對於資料操作這塊，公司沒有乙個重視的態度，上面的boss永遠不會關心你運維做了什麼操作，而運維人員也可以說是我按標準流程操作的，也沒法去定誰的責任，丟了就是丟了，運維最多也就是丟了工作，而企業損失應該就是以萬為單位的損失加客戶的流失了
到這裡也許這家公司的頭並不知道發生了什麼，也許只是認為是乙個小的業務中斷，但真的某一天出事了，這就是大事了，所以一定要重視系統的監控和系統操作的謹慎
by 運維-武漢-磨渣2023年04月11日夜
記一次manila故障
排查過程 1.檢視manila的日誌，api.log scheduler.log share.log,排程日誌最具參考性，但是顯示建立成功 實際狀態為creating 排到share時出現大量報錯 get all share usage failed 2.檢查後端儲存，節點均正常 排查過程 1.關閉...
記一次grub引導修復
今早起床發現deepin出了問題，還好週六備份過一次，於是直接用映象覆蓋了主分割槽 但是開機後出現了引導錯誤，即grub 的命令列介面 參考乙個部落格，有驚無險的修復了 ls 出現了很多裝置，逐個測試 ls hd,gpt?有ext檔案系統的就是boot分割槽 ls hd1,gpt7 設定root，p...
記週日一次故障意外
記週日一次故障意外 找了waf工程師問，並且我這裡也在同步測試，tcping 網域名稱沒返回，不得不 ctrl c 中斷退出 說解析異常，222這個位址不通，然後給我們明確回覆說 47.91.170.222不是waf的入口 ip，切別的ip是沒用的 因為解析異常之後，我是有叫他切到別的能用的waf ...