接手過Ceph的人都有一個(gè)共識(shí)這系統(tǒng)不是裝完就完事的真正的活兒全在運(yùn)維。我在生產(chǎn)環(huán)境里折騰Ceph也有幾年了從最初的三節(jié)點(diǎn)小集群一路擴(kuò)到幾百個(gè)OSD期間經(jīng)歷過PG卡在activeremapped的焦慮也見過一塊慢盤拖得整個(gè)集群持續(xù)抖動(dòng)的現(xiàn)場(chǎng)。今天這篇不講安裝教程重點(diǎn)聊聊真正面對(duì)ceph運(yùn)維時(shí)你應(yīng)該盯哪些指標(biāo)、怎么判斷故障、以及日常監(jiān)控文檔里不會(huì)寫的那部分經(jīng)驗(yàn)。文章既適合剛接手集群的運(yùn)維工程師也適合正在評(píng)估分布式存儲(chǔ)方案的架構(gòu)師參考。很多人以為Ceph運(yùn)維就是看看儀表盤、重啟服務(wù)實(shí)際上分布式存儲(chǔ)的運(yùn)維難點(diǎn)不在于“會(huì)不會(huì)用命令”而是在于對(duì)數(shù)據(jù)分布、故障域、性能劣化這些底層機(jī)制的理解。只要把集群設(shè)計(jì)邏輯和運(yùn)維動(dòng)作配合起來很多看起來很嚇人的告警其實(shí)都能從容應(yīng)對(duì)。1. 先理解Ceph運(yùn)維到底在守什么1.1 Ceph的架構(gòu)與運(yùn)維對(duì)象的本質(zhì)Ceph最核心的資產(chǎn)不是某臺(tái)服務(wù)器而是分布在所有節(jié)點(diǎn)上的數(shù)據(jù)。它對(duì)外提供對(duì)象存儲(chǔ)、塊存儲(chǔ)和文件系統(tǒng)三種接口底層統(tǒng)一由RADOS負(fù)責(zé)數(shù)據(jù)存儲(chǔ)。運(yùn)維Ceph本質(zhì)上是在維護(hù)一個(gè)由Mon集群、OSD集群和MDS使用文件存儲(chǔ)時(shí)組成的狀態(tài)機(jī)。這里面的數(shù)據(jù)分布規(guī)則叫CRUSH算法。它不是靠中心化的元數(shù)據(jù)索引來查找數(shù)據(jù)而是根據(jù)設(shè)備權(quán)重、故障域?qū)哟斡?jì)算數(shù)據(jù)位置。帶來的好處是彈性擴(kuò)展能力很強(qiáng)壞盤后無需人工挪數(shù)據(jù)OSD會(huì)通過Peering過程自動(dòng)恢復(fù)。但反過來運(yùn)維復(fù)雜度也在這里如果故障域劃分不合理或者OSD權(quán)重配錯(cuò)恢復(fù)過程可能引發(fā)數(shù)據(jù)分布失衡甚至副本同時(shí)落在同一臺(tái)物理機(jī)上那才是真正的數(shù)據(jù)安全危機(jī)。Mon是Ceph的大腦它維護(hù)著整個(gè)集群的Cluster MapOSD之間通過心跳向Mon匯報(bào)狀態(tài)。如果Mon所在的節(jié)點(diǎn)時(shí)鐘偏移過大或者網(wǎng)絡(luò)分區(qū)導(dǎo)致多數(shù)Mon之間無法通信客戶端就完全失去讀寫能力。所以Ceph運(yùn)維不是看看磁盤容量就夠的時(shí)鐘同步、網(wǎng)絡(luò)連通性、Mon選舉狀態(tài)都是必須納入日常巡檢的一等公民。1.2 運(yùn)維場(chǎng)景和常見認(rèn)知誤區(qū)實(shí)際工作中Ceph運(yùn)維主要分布在幾個(gè)場(chǎng)景日常健康巡檢、容量與性能規(guī)劃、故障恢復(fù)、版本升級(jí)、硬件更換。每一個(gè)場(chǎng)景都有專門的動(dòng)作和話術(shù)。我見過不少剛?cè)腴T的運(yùn)維兄弟最常犯的錯(cuò)誤就是把“復(fù)制數(shù)越多越安全”當(dāng)成鐵律。其實(shí)副本數(shù)只是數(shù)據(jù)冗余的一部分如果故障域沒設(shè)計(jì)好兩個(gè)副本可能落在同一個(gè)服務(wù)器或同一個(gè)機(jī)柜里一斷電就是數(shù)據(jù)全沒。另一個(gè)誤區(qū)是看到HEALTH_WARN就慌。Ceph的告警分級(jí)里面WARN并不一定代表集群不可用有可能是某個(gè)PG處于degraded狀態(tài)正在自動(dòng)恢復(fù)也可能是mon時(shí)鐘偏差略超閾值。這時(shí)候正確的做法不是盲目重啟服務(wù)而是先看ceph health detail搞清楚告警來源和影響面再?zèng)Q定是否干預(yù)。還有人不重視Pool的PG數(shù)設(shè)置。PG數(shù)量一旦固化后續(xù)調(diào)整PGP可以讓PG分布變化但增加PG數(shù)卻會(huì)引發(fā)大規(guī)模數(shù)據(jù)遷移。很多集群初始規(guī)模很小隨便設(shè)了32或64個(gè)PG等到業(yè)務(wù)擴(kuò)容后再想調(diào)整就要承擔(dān)一次代價(jià)不低的rebalance。這個(gè)坑我在后面容量規(guī)劃部分會(huì)專門展開。2. 日常巡檢與狀態(tài)解讀把集群命門摸清楚2.1 ceph -s是醫(yī)生health detail是病歷接手任何一套Ceph集群第一件事永遠(yuǎn)是跑ceph -s。這條命令輸出包含了集群狀態(tài)、Mon狀態(tài)、OSD狀態(tài)、PG分布、數(shù)據(jù)量、已用容量等最關(guān)鍵的信息。別只看最上面的HEALTH_OK要養(yǎng)成習(xí)慣把每個(gè)字段掃一遍。如果狀態(tài)不是OK立刻執(zhí)行ceph health detail。它會(huì)告訴你具體是什么問題誰在恢復(fù)、哪個(gè)PG卡住、哪個(gè)OSD延遲過高、或者認(rèn)證過期。我個(gè)人的習(xí)慣是把ceph -s的完整輸出存檔每天對(duì)比一次集群的變化趨勢(shì)比單點(diǎn)狀態(tài)更重要。比如最近recovery速率突然下降很可能說明某塊SSD正在老化只是還沒到徹底掉線的那一步。Mon狀態(tài)也要單獨(dú)看。多個(gè)Mon節(jié)點(diǎn)之間的時(shí)鐘偏移超過50毫秒就會(huì)觸發(fā)告警偏移過大甚至?xí)绊慚on選舉的安全機(jī)制。所以生產(chǎn)環(huán)境里NTP配置必須是強(qiáng)制的不要為了省事只在一臺(tái)機(jī)器上配置所有Ceph節(jié)點(diǎn)都得統(tǒng)一時(shí)間源。2.2 巡檢必用的命令組合網(wǎng)上常有人整理linux常用命令大全運(yùn)維手冊(cè)但說句實(shí)話在Ceph場(chǎng)景里真正高頻使用的命令就那十幾條。我把它們按用途分了幾組方便照著敲。第一組是健康總覽ceph -s ceph health detail ceph mon stat第二組是OSD與數(shù)據(jù)分布ceph osd tree ceph osd df ceph osd perf ceph pg stat第三組是容量與池ceph df ceph df detail rados df ceph osd pool ls detail第四組是故障定位ceph pg dump | grep -E active|degraded|stuck ceph pg map pool/pgid ceph osd map pool object ceph daemon osd.id status為什么強(qiáng)調(diào)這些組合因?yàn)閱为?dú)跑一條命令很難建立因果關(guān)系。比如發(fā)現(xiàn)某個(gè)PG異常先ceph pg dump找到PG對(duì)應(yīng)的OSD集合再用ceph osd perf看對(duì)應(yīng)OSD的延遲就能快速判斷是磁盤問題還是網(wǎng)絡(luò)問題。盲目重啟OSD常常會(huì)把一次小故障變成全集群性能抖動(dòng)這正是運(yùn)維里最忌諱的操作。2.3 巡檢節(jié)奏怎么定我這邊建議至少分三層來做每日巡檢看ceph -s輸出是否變化磁盤空間是否接近full閾值有沒有OSD down。不需要太復(fù)雜10分鐘以內(nèi)搞定。每周巡檢檢查OSD延遲、底層磁盤SMART狀態(tài)、網(wǎng)絡(luò)丟包率、Mon時(shí)鐘偏移。這個(gè)周期通常能抓到很多“將出未出”的問題。每月巡檢全面檢查Pool配置、PG數(shù)量是否合理、故障域策略是否滿足當(dāng)前業(yè)務(wù)要求、版本是否有必要升級(jí)。這種深度巡檢最好配合業(yè)務(wù)擴(kuò)容一起做避免重復(fù)勞動(dòng)。如果團(tuán)隊(duì)有自己的監(jiān)控系統(tǒng)可以把每日巡檢自動(dòng)化但每周和每月的動(dòng)作建議保留人工判斷因?yàn)楹芏喈惓２皇强扛婢撝稻湍馨l(fā)現(xiàn)的需要?dú)v史數(shù)據(jù)對(duì)比和經(jīng)驗(yàn)判斷。3. 用Ansible把重復(fù)性運(yùn)維動(dòng)作沉淀下來3.1 為什么Ceph運(yùn)維特別適合自動(dòng)化集群規(guī)模一大手動(dòng)執(zhí)行命令就成了不現(xiàn)實(shí)的事。幾十臺(tái)OSD節(jié)點(diǎn)每臺(tái)都要看狀態(tài)、做檢查、改配置純靠SSH登進(jìn)去敲命令既慢又容易出錯(cuò)。Ansible這種自動(dòng)化工具天然適合Ceph運(yùn)維因?yàn)樗挥迷谀繕?biāo)節(jié)點(diǎn)安裝Agent只要控制機(jī)能SSH過去就能執(zhí)行這正是很多運(yùn)維團(tuán)隊(duì)偏好它的原因。自動(dòng)化最直接的價(jià)值有兩個(gè)。一是批量采集比如一次性在幾百個(gè)OSD上執(zhí)行ceph daemon osd.* perf dump把結(jié)果收集到控制機(jī)做分析。二是配置同步比如滾動(dòng)修改ceph.conf、重啟某個(gè)服務(wù)Ansible可以控制執(zhí)行順序和批次避免所有節(jié)點(diǎn)同時(shí)重啟造成集群抖動(dòng)。我用Ansible的時(shí)候最常做的是批量執(zhí)行查詢類命令已經(jīng)沉淀成一套自己的運(yùn)維腳本庫。比如批量查詢所有OSD的磁盤使用率、批量抓取系統(tǒng)日志中的Ceph錯(cuò)誤、批量重啟某個(gè)版本的OSD進(jìn)程并驗(yàn)證恢復(fù)。3.2 一套可落地的自動(dòng)化巡檢腳本下面給一個(gè)簡(jiǎn)化版的ad-hoc批次巡檢示例思路是遍歷所有OSD節(jié)點(diǎn)抓取Ceph狀態(tài)片段。ansible osd_nodes -m shell -a ceph daemon $(hostname).osd.$(hostname | awk -F- {print $NF}) perf dump | head -50不過實(shí)際生產(chǎn)上我更建議寫成一個(gè)獨(dú)立腳本定時(shí)執(zhí)行并輸出告警。大致邏輯是這樣- hosts: ceph_cluster gather_facts: false tasks: - name: 獲取集群健康狀態(tài) command: ceph health detail register: health_result - name: 展示異常信息 debug: msg: {{ health_result.stdout_lines }}寫自動(dòng)化動(dòng)作時(shí)有一個(gè)前提必須遵守只能自動(dòng)執(zhí)行“只讀”或“可回滾”的操作。比如批量巡檢、日志采集、配置備份都沒問題。至于osd out、pg reweight這類可能觸發(fā)數(shù)據(jù)遷移的命令絕不能直接寫成無人值守的playbook必須人工審核后手動(dòng)執(zhí)行。原因很簡(jiǎn)單自動(dòng)化腳本不會(huì)判斷當(dāng)前集群有沒有處于peering或者恢復(fù)狀態(tài)稍有差錯(cuò)可能把問題擴(kuò)大。3.3 自動(dòng)化操作的安全紅線使用Ansible批量操作Ceph時(shí)有兩個(gè)非常容易忽略的坑。第一個(gè)坑是并發(fā)控制。如果幾十個(gè)OSD節(jié)點(diǎn)同時(shí)執(zhí)行systemctl restart ceph-osd*短時(shí)間內(nèi)會(huì)有大量PG需要重新連接和恢復(fù)Mon處理不過來就可能放慢整個(gè)集群的響應(yīng)。所以批量執(zhí)行影響集群狀態(tài)的操作時(shí)一定要用serial: 5這類參數(shù)控制并發(fā)數(shù)量讓節(jié)點(diǎn)分批滾動(dòng)。第二個(gè)坑是命令換行和引號(hào)轉(zhuǎn)義。通過Ansible執(zhí)行包含管道符、通配符、環(huán)境變量的Ceph命令時(shí)經(jīng)常因?yàn)橐?hào)問題導(dǎo)致執(zhí)行結(jié)果不對(duì)。我的習(xí)慣是先把要執(zhí)行的命令放到一個(gè)shell腳本里再由Ansible調(diào)用這個(gè)腳本調(diào)試起來會(huì)直觀很多。自動(dòng)化運(yùn)維的精髓不是“把命令變成腳本”而是把運(yùn)維動(dòng)作標(biāo)準(zhǔn)化。一個(gè)動(dòng)作標(biāo)準(zhǔn)化后才談得上批量執(zhí)行和審計(jì)追溯。4. 故障排查實(shí)戰(zhàn)OSD down、PG異常、慢請(qǐng)求4.1 OSD down后的標(biāo)準(zhǔn)處理流程OSD down是Ceph運(yùn)維最常見的故障但每次處理的思路不能只靠重啟。首先要回答一個(gè)問題這個(gè)OSD為什么down是物理盤故障、進(jìn)程崩潰、心跳超時(shí)還是因?yàn)榫W(wǎng)絡(luò)抖動(dòng)被Mon誤判不同的原因?qū)?yīng)完全不同的處理方式。我一般按下面順序排查先看ceph osd tree確認(rèn)哪些OSD down再看ceph health detail有沒有指明原因。然后登錄對(duì)應(yīng)節(jié)點(diǎn)檢查systemctl status ceph-osdid服務(wù)狀態(tài)翻/var/log/ceph/ceph-osd.id.log最后幾百行同時(shí)看dmesg里是否有磁盤IO錯(cuò)誤。如果是磁盤硬件故障直接用ceph osd out id把它踢出集群等待對(duì)應(yīng)的PG完成遷移后再做硬件更換。如果只是進(jìn)程卡死可以嘗試重啟服務(wù)但要留意重啟后是否觸發(fā)大規(guī)模backfill。如果集群已經(jīng)負(fù)載很高建議先觀察再?zèng)Q定是否把OSD marked out。這里有個(gè)關(guān)鍵細(xì)節(jié)不要把OSD down等同于立刻ceph osd out。OSD down只是進(jìn)程不在線數(shù)據(jù)仍然保留在磁盤上而out意味著集群要把該OSD上的數(shù)據(jù)重新分布到其他地方會(huì)立刻開始數(shù)據(jù)遷移。除非確認(rèn)這盤已經(jīng)很難救回來了否則先嘗試恢復(fù)進(jìn)程是最穩(wěn)妥的。4.2 PG狀態(tài)異常的排查路徑Ceph的PG狀態(tài)機(jī)是整個(gè)系統(tǒng)最復(fù)雜也最讓人頭疼的部分。常見的異常狀態(tài)有degraded、peering、backfill、recovery、inconsistent、stuck inactive。每種狀態(tài)都需要不同的處理手法?？吹絛egraded不必太緊張只要集群在自動(dòng)恢復(fù)PG最終會(huì)回到activeclean。真正要警惕的是stuck類狀態(tài)比如stuck inactive或者stuck unclean意味著某個(gè)PG一直無法完成Peering。這時(shí)要用ceph pg query pgid查看具體卡在哪個(gè)階段。一個(gè)比較典型的場(chǎng)景是某塊OSD數(shù)據(jù)損壞導(dǎo)致PG無法完成Peering。遇到這種情況可以通過ceph pg repair嘗試修復(fù)不一致的對(duì)象但如果底層數(shù)據(jù)已經(jīng)損壞可能需要從其他副本恢復(fù)數(shù)據(jù)。操作前務(wù)必備份PG map并且逐條操作不要一次性修復(fù)大量PG。處理故障最忌諱的是“頭痛醫(yī)頭”。比如某個(gè)OSD反復(fù)down很多人的第一反應(yīng)是重啟但經(jīng)過排查發(fā)現(xiàn)是網(wǎng)卡固件觸發(fā)的TCP重傳問題。我后來總結(jié)出一個(gè)原則所有故障處理都要保留完整現(xiàn)場(chǎng)獲取對(duì)應(yīng)時(shí)間窗口的日志、監(jiān)控曲線、系統(tǒng)指標(biāo)再動(dòng)手。4.3 慢請(qǐng)求與性能劣化定位集群狀態(tài)OK但業(yè)務(wù)方反饋寫延遲很高這種問題比硬故障更難查。Ceph的慢請(qǐng)求通常表現(xiàn)為客戶端IO超時(shí)而ceph -s不一定有告警。這時(shí)第一個(gè)命令看ceph osd perf會(huì)列出每個(gè)OSD的commit latency和apply latency數(shù)值明顯偏高的OSD就是重點(diǎn)排查對(duì)象。慢盤的判定不能只看OSD層還要看底層磁盤。用iostat -x 1看util和await如果某個(gè)磁盤的await明顯高于同型號(hào)其他盤基本可以斷定是慢盤。如果所有OSD都高那就要懷疑宿主機(jī)層面的問題比如CPU綁核不合理、網(wǎng)絡(luò)跨交換機(jī)擁塞、或者ceph的backfill流量擠占了正常IO。還有一個(gè)常見但容易被忽視的原因OSD數(shù)據(jù)盤使用率超過85%時(shí)寫入延遲會(huì)明顯上升。因?yàn)镃eph在空間不足時(shí)需要做更多GC和預(yù)留空間管理這和SSD廠商建議保留OP空間是類似的道理。所以性能優(yōu)化往往不是調(diào)幾個(gè)參數(shù)的問題而是容量規(guī)劃的問題。5. 容量與性能規(guī)劃別等報(bào)警再動(dòng)手5.1 Pool與PG規(guī)劃的正確姿勢(shì)很多集群一開始沒規(guī)劃好PG數(shù)量導(dǎo)致后面擴(kuò)容時(shí)痛苦不堪。PG數(shù)量沒有絕對(duì)公式要結(jié)合OSD個(gè)數(shù)、pool數(shù)、每個(gè)OSD建議承載的PG數(shù)來估算。業(yè)界公認(rèn)的經(jīng)驗(yàn)值是每個(gè)OSD大約50到100個(gè)PG但也要看資源情況。一個(gè)常用估算公式大致是PG總數(shù)約等于 (OSD數(shù) × 100) / 副本數(shù)。比如100個(gè)OSD、3副本大概就要3300個(gè)PG。然后把這個(gè)數(shù)字合理分配到各個(gè)Pool注意PG總數(shù)盡量保持2的冪次倍數(shù)這樣CRUSH分布更均勻。Pool的PG數(shù)一旦創(chuàng)建后很難縮減提前規(guī)劃就是給未來省事。同樣要緊的是min_size。min_size表示派對(duì)可用的最小副本數(shù)通常設(shè)為1或2。建議生產(chǎn)環(huán)境至少設(shè)為2避免單副本情況下壞盤直接丟數(shù)據(jù)。但要清楚min_size為2時(shí)如果一塊盤壞了雖然還能繼續(xù)寫但已經(jīng)沒有冗余能力了此時(shí)任何第二塊盤故障都會(huì)導(dǎo)致數(shù)據(jù)丟失。5.2 容量水位管理Ceph有兩個(gè)水位線概念需要盯緊mon_osd_full_ratio和mon_osd_nearfull_ratio默認(rèn)一般接近90%和85%。超過nearfull會(huì)觸發(fā)告警超過full會(huì)拒絕寫入。注意這里是一個(gè)危險(xiǎn)行為集群會(huì)在還有好多空余空間時(shí)拒絕數(shù)據(jù)寫入業(yè)務(wù)中斷可不會(huì)跟你商量。我建議把容量報(bào)警閾值提前比如在80%時(shí)就開始規(guī)劃擴(kuò)容或清理冷數(shù)據(jù)。因?yàn)閿?shù)據(jù)均衡是動(dòng)態(tài)過程一旦某個(gè)OSD滿了哪怕全集群還有空閑容量Ceph也可能不會(huì)把新數(shù)據(jù)寫入那個(gè)OSD造成局部熱點(diǎn)。這時(shí)可以考慮用ceph balancer的upmap模式來調(diào)整部分PG分布但要謹(jǐn)慎操作因?yàn)槊恳淮螖?shù)據(jù)調(diào)整都占用IO資源。5.3 硬件選型與OSD配比建議網(wǎng)絡(luò)和磁盤的配比直接決定集群性能上限。對(duì)于全閃集群至少需要萬兆網(wǎng)絡(luò)最好25G或以上因?yàn)镺SD的帶寬很容易打滿網(wǎng)卡?；扉W集群則要控制NVMe緩存和HDD的比例一般一個(gè)NVMe緩存盤對(duì)應(yīng)4到6塊HDD太多會(huì)導(dǎo)致緩存盤成為瓶頸。CPU方面也別忽略每個(gè)OSD至少分配一核Mon節(jié)點(diǎn)不需要太強(qiáng)性能但一定要穩(wěn)定。內(nèi)存建議每TB數(shù)據(jù)至少配1GB內(nèi)存給OSD的Page Cache實(shí)際中8GB到16GB是底線。這里沒有絕對(duì)標(biāo)準(zhǔn)最好通過壓測(cè)驗(yàn)證但方向是把每個(gè)部件的能力匹配起來哪一塊短板都會(huì)影響整體表現(xiàn)。6. 工具鏈選擇與運(yùn)維心法6.1 監(jiān)控告警體系的搭建思路Ceph自帶的ceph dashboard適合看狀態(tài)但不適合做歷史趨勢(shì)分析。生產(chǎn)環(huán)境建議用Prometheus采集Ceph指標(biāo)配合Grafana展示。Ceph有官方exporter采集的指標(biāo)很全包括OSD延遲、PG狀態(tài)、容量、IOPS等。告警規(guī)則要避免“大而全”。我見過很多團(tuán)隊(duì)把幾十個(gè)告警項(xiàng)全部打開結(jié)果天天報(bào)警導(dǎo)致團(tuán)隊(duì)麻木最后真正出事反而沒人響應(yīng)。告警的價(jià)值在于“少而準(zhǔn)”。核心指標(biāo)其實(shí)就那幾個(gè)集群整體狀態(tài)、OSD down數(shù)量、可用容量百分比、慢請(qǐng)求數(shù)、Mon可用性。6.2 團(tuán)隊(duì)協(xié)作中的變更管理Ceph運(yùn)維到后期真正難的不是技術(shù)而是流程。我手上的經(jīng)驗(yàn)是任何變更都要有“影響面評(píng)估”和“回滾方案”。哪怕只是修改一個(gè)配置項(xiàng)也要先確認(rèn)它是否影響數(shù)據(jù)分布是否需要重啟是否有窗口能接受性能波動(dòng)。版本升級(jí)是變更里風(fēng)險(xiǎn)最高的動(dòng)作。我的建議是先在測(cè)試集群完整演練一遍再挑一個(gè)非核心OSD灰度升級(jí)最后滾動(dòng)升級(jí)整個(gè)集群。升級(jí)過程中禁止同時(shí)做其他變更避免故障定位無從下手。6.3 我踩過的幾個(gè)坑和最終沉淀的方法論第一個(gè)坑是輕信默認(rèn)配置。早期我部署過一個(gè)測(cè)試集群直接把默認(rèn)參數(shù)拉到生產(chǎn)用結(jié)果遇到網(wǎng)絡(luò)抖動(dòng)后集群恢復(fù)慢得離譜。后來把osd_heartbeat_grace、mon_osd_down_out_interval等參數(shù)根據(jù)實(shí)際網(wǎng)絡(luò)情況做了調(diào)整才算穩(wěn)定下來。第二個(gè)坑是恢復(fù)速度的盲目追求。有一回某個(gè)機(jī)柜斷電大量PG開始恢復(fù)時(shí)我把osd_max_backfills調(diào)得很大希望能盡快恢復(fù)。結(jié)果業(yè)務(wù)延遲飆升數(shù)據(jù)恢復(fù)速度反而因?yàn)橘Y源爭(zhēng)搶變慢了。后來我學(xué)會(huì)用ceph config set osd osd_max_backfills 1先把恢復(fù)速度壓住等業(yè)務(wù)低峰期再放開。說到底Ceph運(yùn)維考驗(yàn)的是你對(duì)數(shù)據(jù)安全底線的理解以及在關(guān)鍵時(shí)刻穩(wěn)住節(jié)奏的定力。很多問題不是技術(shù)多高深而是有沒有在故障發(fā)生前就把監(jiān)控、巡檢、預(yù)案這些基本功做扎實(shí)。每踩過一次坑把經(jīng)驗(yàn)沉淀成腳本和文檔集群才會(huì)越來越順手。