前兩天下班前某位運營同事跑過來跟我說業(yè)務系統(tǒng)又卡了數(shù)據(jù)庫備份目錄快滿了得趕緊想辦法。我一看那臺老存儲服務器單塊磁盤的容量已經(jīng)見底RAID5陣列擴容又不敢隨便動整個磁盤I/O在高峰期幾乎被打滿。說白了就是存儲不夠用擴不動還怕數(shù)據(jù)丟。那時候我腦子里第一個閃過的方案就是Ceph。這套東西在存儲圈子里名聲很大幾乎搞云平臺、搞虛擬化、搞容器的人都繞不開它。Ceph本質(zhì)上就是一套把普通服務器的磁盤聚合成一個超大存儲池的分布式存儲系統(tǒng)支持塊存儲、文件存儲和對象存儲三種接口部署起來有一定門檻但一旦跑順了擴展就是加機器的事。這篇文章我就把這幾年折騰Ceph的經(jīng)驗整理一下從核心概念到集群部署再到一個完整的塊存儲使用案例全部揉在一起講。如果你正要給云平臺或者虛擬化環(huán)境選一套存儲后端或者手里就有那種“量大、又不能停”的存儲需求這篇文章應該能幫你少走不少彎路。1. Ceph核心概念拆解先把架構講透在做任何部署之前我的習慣是先搞明白這東西到底是靠什么機制把數(shù)據(jù)存下來的。直接上手敲命令當然很快但出了問題就抓瞎了。Ceph的整個設計思路其實不復雜核心就是“去中心化”和“自動數(shù)據(jù)分布”。1.1 先搞清楚Ceph在一眾存儲方案里的位置很多剛接觸分布式存儲的朋友會問Ceph和傳統(tǒng)的磁盤陣列、和GlusterFS、和MinIO這些到底有什么不一樣。我習慣用一個類比來解釋傳統(tǒng)磁盤陣列就像你租了一個大型倉庫倉庫的容積是固定的里面每個貨架怎么擺、擺在哪都得你自己操心而Ceph更像是你有了一群小倉庫這些小倉庫分布在不同的地方你只管把貨扔進去系統(tǒng)會自動判斷放在哪個倉庫還能自動多放幾份備份倉庫不夠了就再租幾間。放在技術語境里這句話有幾層意思第一Ceph的存儲節(jié)點和磁盤是普通硬件不需要專用設備第二數(shù)據(jù)寫入時Ceph會通過算法決定數(shù)據(jù)落在哪些節(jié)點的哪些磁盤上而不是人工指定第三默認情況下數(shù)據(jù)會保存多份副本單個磁盤甚至整個節(jié)點的損壞都不會讓數(shù)據(jù)丟失。這種去中心化的架構決定了Ceph天然具備橫向擴展能力——想增加容量加機器就行業(yè)務不用停。Ceph對外提供的三種接口也是它被廣泛應用的關鍵。塊存儲RBD是給虛擬機、云主機、數(shù)據(jù)庫這類需要像本地硬盤一樣使用的場景文件存儲CephFS提供符合POSIX規(guī)范的文件系統(tǒng)掛載對象存儲RGW提供類似S3的接口適合海量非結構化數(shù)據(jù)的存取。這篇文章的重點在使用最廣泛、也是我實際踩坑最多的塊存儲也就是RBD。1.2 組成Ceph集群的角色各司其職Ceph集群不是一個大整體而是由多個不同角色的進程協(xié)作完成的。理解這些角色部署時候才知道自己配的每一臺機器到底在干什么。MONMonitor監(jiān)控節(jié)點這是集群的“指揮中心”負責維護整個集群的集群圖譜Cluster Map包括哪些OSD在線、哪些磁盤掛了、PG怎么分布。MON節(jié)點需要一半以上達成一致才能形成多數(shù)派所以生產(chǎn)環(huán)境一般至少部署3個。它不存業(yè)務數(shù)據(jù)但對整個集群的穩(wěn)定性至關重要。OSD對象存儲守護進程這是真正干活的角色。每一塊數(shù)據(jù)磁盤通常對應一個OSD進程負責數(shù)據(jù)的讀寫、副本復制、數(shù)據(jù)恢復等。集群里所有數(shù)據(jù)都以對象的形式分散存儲在OSD上所以OSD的數(shù)量直接決定了集群的容量和并行性能。MGR管理器監(jiān)控和管理OSD、PG、客戶端的狀態(tài)為外部監(jiān)控系統(tǒng)提供接口。通俗講它是集群的“儀表盤和秘書”Ceph Dashboard的很多數(shù)據(jù)就是MGR提供的。MDS元數(shù)據(jù)服務器只在用CephFS文件存儲時才需要它負責管理和緩存文件系統(tǒng)的元數(shù)據(jù)比如目錄結構、文件名。塊存儲場景下這個角色可以不用部署。如果還用倉庫來類比MON是倉管員辦公室OSD是各個貨架MGR是監(jiān)控攝像頭加報表系統(tǒng)MDS則是貨物清單管理員。各個角色通過網(wǎng)絡通信、協(xié)同工作任何一個角色出問題集群的健康狀態(tài)都會反映出來。1.3 數(shù)據(jù)落盤的完整過程PG與CRUSH算法很多人第一次看ceph -s的時候會被一堆縮寫搞暈比如PG、CRUSH、Pool這些概念是理解Ceph工作流程的關鍵。數(shù)據(jù)寫入Ceph時不是直接寫到一個磁盤上的?？蛻舳苏{(diào)用接口后數(shù)據(jù)先被切分成多個對象Object每個對象有唯一的ID標識。然后這些對象會被組合進一個個邏輯分組Ceph里叫歸置組Placement Group簡稱PG。再通過CRUSH算法將每個PG映射到一組具體的OSD上。這個過程可以類比成你要把一本書的每一頁拆散先分到幾十個信封里再通過一個固定算法決定每個信封寄給哪幾個不同的人這些人各保存一份副本。所以創(chuàng)建一個存儲池Pool的時候最關鍵的兩個參數(shù)就是PG數(shù)量和副本數(shù)。PG數(shù)量決定了數(shù)據(jù)在整個集群中的分布粒度太少會導致單個PG壓力巨大太多則會增加系統(tǒng)的調(diào)度開銷。副本數(shù)決定了數(shù)據(jù)冗余程度默認一般是雙副本或三副本。后續(xù)我會講具體怎么算這個數(shù)字。了解了這些其實你已經(jīng)掌握了Ceph最核心的底層邏輯后面無論是部署還是排障都是在跟這些概念打交道。2. 部署Ceph集群實操細節(jié)決定成敗部署一套Ceph集群整體流程不復雜但每一步都埋著坑。我部署過幾次之后最大的體會是環(huán)境準備花了30%的時間部署命令只花10%的時間剩下60%都在處理和網(wǎng)絡、系統(tǒng)參數(shù)、權限相關的問題。下面我按最常用、也最穩(wěn)妥的方式逐步展開。2.1 節(jié)點規(guī)劃與環(huán)境準備首先說節(jié)點規(guī)劃。我比較推薦的最小生產(chǎn)集群是3節(jié)點每個節(jié)點既是MON也是OSD同時額外部署MGR。這樣既保證了MON的多數(shù)派可用又降低了硬件成本。如果條件允許每個節(jié)點再額外加一塊獨立的系統(tǒng)盤和數(shù)據(jù)盤業(yè)務數(shù)據(jù)盤和操作系統(tǒng)的IO互不相擾這才是最理想的配置。需要說明的是這里討論的是在物理機或虛擬機集群上手動部署的常見套路。我最近幫朋友公司搭的就是一套3臺物理機的環(huán)境每臺機器2顆CPU、64GB內(nèi)存、4塊SSD做數(shù)據(jù)盤、1塊SATA盤做系統(tǒng)盤。以下是這類節(jié)點的建議配置節(jié)點角色數(shù)量建議配置要求注意事項MONMGR≥3個2核4GB即可無需大容量磁盤生產(chǎn)環(huán)境別少于3個避免腦裂OSD按容量需求數(shù)據(jù)盤盡量獨立避免與系統(tǒng)盤混用單盤容量過大時恢復時間會延長網(wǎng)絡業(yè)務/集群分離萬兆網(wǎng)卡起步業(yè)務網(wǎng)和存儲網(wǎng)隔離網(wǎng)絡帶寬直接決定集群性能上限系統(tǒng)層面Ubuntu 20.04或CentOS/Rocky 8都可以跑Ceph新版Ceph如Quincy、Reef對內(nèi)核版本有要求建議內(nèi)核在5.x以上另外所有節(jié)點的主機名hostname和/etc/hosts解析必須做好因為Ceph節(jié)點間是通過主機名通信的依賴IP解析會在出問題時非常難排查。時鐘同步NTP/Chrony也是必須項MON節(jié)點之間時鐘偏移過大會直接導致集群異常。2.2 系統(tǒng)參數(shù)調(diào)優(yōu)別忽略這一步很多初學者直接裝了Ceph就開始添加OSD結果跑了一段時間發(fā)現(xiàn)性能很差甚至數(shù)據(jù)均衡老是異?；仡^才意識到系統(tǒng)底層都沒有調(diào)好。這里有幾個關鍵的操作關閉防火墻和SELinux或者在Ceph端口規(guī)則上放行。很多詭異的客戶端連接失敗、OSD之間通信異常跟防火墻脫不了干系。生產(chǎn)環(huán)境建議放行Ceph通信端口或者用專門的規(guī)則總之別讓SELinux在背后搗亂。修改內(nèi)核參數(shù)比如vm.swappiness建議設為10以下減少緩存交換vm.max_map_count適當調(diào)大防止文件映射數(shù)量不夠net.core.rmem_default、net.core.wmem_default等網(wǎng)絡緩沖區(qū)參數(shù)也需要調(diào)大以支撐萬兆網(wǎng)絡的大數(shù)據(jù)包傳輸。數(shù)據(jù)磁盤建議使用獨立的文件系統(tǒng)并掛載為OSD專用磁盤調(diào)度器設置為SPN或類似模式提升隨機IO性能固態(tài)盤和機械盤不要混在同一個池里會嚴重拉低整體性能。這些參數(shù)看起來瑣碎但它們的價值會在壓力測試的時候凸顯。我見過一套沒有調(diào)整這些參數(shù)的集群同樣硬件條件跑出來的隨機寫性能差了將近一倍調(diào)完之后才勉強達到預期。如果你不想花幾小時排查老老實實把這些前置工作做完再動手。2.3 部署流程與關鍵命令實錄接下來是核心部署環(huán)節(jié)?，F(xiàn)在官方推薦的部署工具是cephadm它基于容器方式管理Ceph組件部署和升級都比較方便。以一套5.x版本的Ceph為例大致流程如下在第一個節(jié)點安裝cephadmcurl --silent --remote-name --location https://download.ceph.com/rpm-5.0.0/el8/RPMS/noarch/cephadm chmod x cephadm ./cephadm add-repo --release quincy ./cephadm install使用cephadm bootstrap初始化monitor這一步會自動部署MON和MGRcephadm bootstrap --mon-ip 192.168.10.11 --cluster-network 192.168.20.0/24其中--mon-ip是第1個MON節(jié)點的管理IP--cluster-network是專用的集群通信網(wǎng)段。如果你沒有規(guī)劃獨立的集群組網(wǎng)這一步可以省略但我不建議在生產(chǎn)環(huán)境這樣做集群數(shù)據(jù)同步流量會對業(yè)務網(wǎng)絡產(chǎn)生較大壓力。將其他節(jié)點加入集群cephadm add-host node2 192.168.10.12 cephadm add-host node3 192.168.10.13在所有節(jié)點上添加OSD。這一步會根據(jù)每個節(jié)點的磁盤信息把未使用的磁盤逐個加入ceph orch apply osd --all-available-devices執(zhí)行完后用ceph -s查看集群狀態(tài)。如果看到HEALTH_OK就說明基礎集群已經(jīng)搭起來了。2.4 初始化后的健康檢查以及那些防不勝防的坑集群搭起來不代表萬事大吉初始化后的檢查非常關鍵。第一是確認MON數(shù)量ceph mon dump可以看到第二是確認所有OSD都處于up和in狀態(tài)ceph osd tree很直觀第三是檢查PG的分布情況看有沒有出現(xiàn)嚴重不均的情況。正常的集群輸出里應該沒有紅色告警各OSD的PG數(shù)量相差不大。我在這里把常見部署問題列一下給各位做個速查問題現(xiàn)象常見原因解決辦法MON之間無法形成quorum時鐘不同步、主機名解析失敗檢查NTP狀態(tài)檢查/etc/hosts和主機名OSD啟動后頻繁報up then down磁盤寫滿、網(wǎng)絡通信異常檢查磁盤空間集群網(wǎng)絡是否通bootstrap時拉取鏡像失敗網(wǎng)絡限制導致無法下載容器鏡像配置鏡像倉庫加速或?qū)С?導入離線鏡像cephadm add-host無法連接SSH免密環(huán)境未配置好確保各節(jié)點間能通過SSH密鑰互相訪問尤其要提一句SSH免密這一步很多新手會漏。雖然cephadm自帶公鑰分發(fā)機制但使用輔助功能時仍然依賴SSH連通性。真實環(huán)境里我遇到過add-host之后CEPH集群的其他節(jié)點無法自動化加入ttl的BUG排查很久才發(fā)現(xiàn)是SSH互信有問題。先把鏈路通了再談下一步這話在任何分布式系統(tǒng)部署里都適用。3. 塊存儲案例從創(chuàng)建池到客戶端掛載集群就緒后就該看真正能用的東西了。Ceph最常見的應用場景之一就是把集群作為云平臺比如某開源云平臺的統(tǒng)一存儲后端通過RBD協(xié)議把虛擬機的系統(tǒng)盤和數(shù)據(jù)盤放在Ceph里。這樣做的好處是虛擬機調(diào)度到任何一臺宿主機都能掛載同一份數(shù)據(jù)。下面是完整的操作過程。3.1 梳理塊存儲的核心使用場景在開源云平臺或者虛擬化環(huán)境里塊存儲幾乎是必備的模塊。虛擬機實例需要系統(tǒng)盤數(shù)據(jù)庫需要數(shù)據(jù)盤這些都需要塊存儲接口。Ceph RBD的優(yōu)勢在于它天然支持稀疏分配——也就是創(chuàng)建一個大容量鏡像時并不立即占用物理空間只有數(shù)據(jù)真正寫入時才占用。這在很多傳統(tǒng)存儲陣列上是做不到的也讓Ceph在容量利用率上非常有吸引力。同時RBD支持快照、克隆、在線擴容等高級功能虛擬機可以通過rbd resize在線擴展磁盤大小整個過程不需要停止業(yè)務。這些能力對于存儲管理員來說都是剛需。所以我每次給用戶講解Ceph都喜歡用RBD作為第一個案例因為它是用得最多、最直觀、也最能展示分布式存儲價值的接口。3.2 創(chuàng)建存儲池PG數(shù)量和副本數(shù)的計算在Ceph里存儲池Pool是邏輯隔離的單位。先創(chuàng)建池才能在池里創(chuàng)建RBD鏡像。ceph osd pool create ssd-pool 128 128 replicated其中128是PG數(shù)量128是PGP數(shù)量用于數(shù)據(jù)分布的歸置組數(shù)量通常和PG數(shù)保持一致。replicated表示副本模式。如果你有EC糾刪碼的需求可以改成erasure模式但這在塊存儲場景里相對少見這里不展開。PG數(shù)量的選擇是一門學問。太少了單個PG承載的數(shù)據(jù)過多數(shù)據(jù)均衡性差太多了PG調(diào)度開銷大。通常的建議是每個OSD承載大約50到100個PG總PG數(shù) OSD總數(shù) × 副本數(shù) × 50~100 / 副本數(shù)。舉個例子一套12塊OSD盤、副本數(shù)3的集群總PG數(shù)可以按12 × 100 1200左右估算再分配到每個池中。當然實際還要看池的數(shù)量和數(shù)據(jù)量適合對象的數(shù)可以先用公式估算后續(xù)根據(jù)監(jiān)控數(shù)據(jù)調(diào)整。創(chuàng)建完池以后可以設置應用類型讓Ceph知道這個池是給RBD用的ceph osd pool application enable ssd-pool rbd3.3 創(chuàng)建RBD鏡像并映射到客戶端池創(chuàng)建好后就可以創(chuàng)建RBD鏡像了。比如創(chuàng)建一個10GB大小的鏡像命令如下rbd create --pool ssd-pool --size 10240 rbd-image-01命令里的大小單位是MB所以10GB寫成10240。創(chuàng)建完成后可以使用rbd info ssd-pool/rbd-image-01查看鏡像屬性確認是否正常。要在客戶端掛載客戶端需要安裝ceph-common包并獲取集群的admin密鑰。然后執(zhí)行rbd map ssd-pool/rbd-image-01rbd map成功后系統(tǒng)里會出現(xiàn)一個類似/dev/rbd0的設備。這一步如果報了權限或者功能異常通常跟RBD鏡像的feature有關。新版RBD默認開啟了exclusive-lock、object-map、fast-diff等特性某些內(nèi)核版本不支持建議在創(chuàng)建鏡像或映射時禁用不必要的特性比如加上--image-feature layering。映射后就可以像操作本地磁盤一樣對它進行分區(qū)、格式化和掛載mkfs.xfs /dev/rbd0 mkdir /mnt/ceph-data mount /dev/rbd0 /mnt/ceph-data3.4 讓業(yè)務真正用起來注意掛載參數(shù)與權限到這里塊存儲已經(jīng)下發(fā)到指定路徑且可以寫入文件。但在真實的生產(chǎn)環(huán)境中我更關注幾個細節(jié)很多人往往忽略掛載參數(shù)XFS文件系統(tǒng)掛載時建議加上noatime減少不必要的元數(shù)據(jù)寫入如果業(yè)務需要掉電保護可以適當調(diào)整日志參數(shù)。Ceph本身自帶多副本所以在大多數(shù)場景下文件系統(tǒng)層的RAID功能不需要開啟反而會重復占用存儲空間。開機自動掛載客戶機一般都有多個RBD設備建議通過UUID方式配置/etc/fstab要保證設備掛載順序穩(wěn)定。如果rbd map設備號不固定極有可能掛載錯設備釀成數(shù)據(jù)錯亂事故。我吃過這個虧后來就老老實實改成UUID。多客戶端訪問RBD設備默認同一時刻只允許一個客戶端寫入如果要實現(xiàn)多客戶端同時讀寫需要配合共享文件系統(tǒng)模式比如cephfs或支持共享的集群文件系統(tǒng)。就虛擬機場景來說默認的單個客戶端訪問模型是足夠安全的。3.5 快照管理與克隆回滾生產(chǎn)中最重要的功能之一就是快照。Ceph RBD的快照創(chuàng)建非常迅捷一條命令即可rbd snap create ssd-pool/rbd-image-01snap-20250101 rbd snap ls ssd-pool/rbd-image-01快照可以用于快速恢復誤刪文件或數(shù)據(jù)庫回滾。要刪除此快照使用rbd snap rm如果需要基于快照創(chuàng)建新鏡像做業(yè)務驗證或臨時擴容可以用rbd clone完成靈活派生。rbd snap protect ssd-pool/rbd-image-01snap-20250101 rbd clone ssd-pool/rbd-image-01snap-20250101 ssd-pool/clone-volume-01快照和clone功能的組合非常適合開發(fā)測試場景——比如需要給多個研發(fā)同事各自分配一個干凈的測試環(huán)境直接從基礎鏡像克隆出多個副本秒級完成也不會占用額外大量空間原理是Copy-on-Write。實際運維里快照不是越多越好?？煺者^多會占用大量元數(shù)據(jù)空間恢復時會變慢而且如果一個鏡像有幾千個快照性能會有明顯下降。建議按備份策略定期清理保留最近N份即可。4. 常見故障定位與性能優(yōu)化Ceph部署和業(yè)務配置搞定之后真正的挑戰(zhàn)才剛剛開始——運維。再穩(wěn)定的集群也會在某個深夜給你一個告警。下面是我積累的幾個高頻故障和性能優(yōu)化方向都是實打?qū)嵉慕?jīng)驗。4.1 PG狀態(tài)異常認識正常與異常的邊界ceph -s如果顯示的不是HEALTH_ERR但也并非完全健康通常跟PG狀態(tài)異常有關。我們先認識幾個PG狀態(tài)的含義狀態(tài)含義處理建議activeclean健康狀態(tài)數(shù)據(jù)均衡且完整無需處理degraded有副本數(shù)據(jù)不完整如某個OSD宕機檢查OSD狀態(tài)待其恢復后自動恢復peeringPG在查找存活OSD并同步狀態(tài)通常短暫存在長時間卡在該狀態(tài)需檢查MONstaleOSD與MON失聯(lián)PG狀態(tài)無法更新檢查網(wǎng)絡OSD進程是否存活undersized副本數(shù)不足可能由OSD故障導致盡快恢復失效節(jié)點避免數(shù)據(jù)風險看到degraded不要慌如果只是單個OSD掛了等它重新上線數(shù)據(jù)會自動恢復。但要注意PG長時間處于inactive或peering狀態(tài)這往往意味著MON和OSD之間的心跳出問題或者網(wǎng)絡嚴重丟包。此時優(yōu)先檢查節(jié)點負載和網(wǎng)絡監(jiān)控。4.2 OSD故障替換流程要穩(wěn)妥OSD故障是存儲集群最常見的事故。一塊盤壞了Ceph會自動把數(shù)據(jù)分散到其他OSD上但這期間性能會受影響數(shù)據(jù)安全性也會降至最低。我處理的套路是確認故障盤ceph osd tree查看OSD狀態(tài)結合dmesg和硬盤告警確認物理盤是否損壞。將故障OSD標記為out暫時停止參與數(shù)據(jù)分布ceph osd out osd.5確認該OSD上的PG已經(jīng)遷移到其他節(jié)點數(shù)據(jù)均衡完成后再執(zhí)行ceph orch osd rm osd.5 --zap如果磁盤是好的只是進程異?？梢試L試重啟OSD容器如果確實損壞更換物理盤后重新使用cephadm添加OSD。這里有一個重要提醒不要在數(shù)據(jù)沒遷移完成前就去刪除OSD的信息。否則可能造成數(shù)據(jù)不可恢復。替換磁盤前最好先對磁盤信息做完整記錄避免誤改其他正常盤的標識。生產(chǎn)環(huán)境里我曾經(jīng)看到過同事在慌亂中反掛磁盤導致一臺正常OSD被刪除擴容順便變成縮容的尷尬情況。4.3 性能優(yōu)化的切入方向部署完成之后性能優(yōu)化是繞不開的話題。Ceph的性能取決于硬件、網(wǎng)絡和配置的聯(lián)動網(wǎng)絡是最大的瓶頸集群網(wǎng)絡建議萬兆起步并且要使用獨立的集群網(wǎng)段。如果業(yè)務流量和集群復制流量共用網(wǎng)絡數(shù)據(jù)恢復和正常業(yè)務會互相拖累。有條件可以做bond并開啟網(wǎng)卡的TSO/GRO。磁盤類型決定下限全SSD集群的隨機IO能力遠高于HDD集群但成本高。可以按不同磁盤類型劃分不同存儲池比如把熱數(shù)據(jù)放在SSD池冷數(shù)據(jù)放在HDD池然后按業(yè)務需求選擇不同池。OSD配置每塊盤單獨掛載目錄避免多盤共享同一個文件系統(tǒng)對于塊存儲建議開啟bluestore存儲后端它比舊版filestore性能好很多。當前新版本默認就是bluestore?？蛻舳藚?shù)虛擬機使用RBD時調(diào)整queue depth和io scheduler為none能有效降低虛擬化層的IO延遲。性能測試的話用fio或Ceph自帶的rbd bench-write和rbd bench-read最直觀。我通常先跑一輪4K隨機讀寫和一輪1M順序讀寫分別觀察IOPS和帶寬數(shù)據(jù)結合監(jiān)控看瓶頸是出在磁盤還是網(wǎng)絡還是CPU上。4.4 安全與權限配置端到端的最小控制最后說一個容易被忽視的方面——權限。Ceph默認開啟了Cephx認證客戶端必須擁有key才能訪問集群。這本身沒問題問題在于不少管理員圖省事直接把client.admin密鑰分發(fā)到所有機器這等于把集群管理權限公開了。合理方式是每個業(yè)務模塊單獨創(chuàng)建客戶端用戶并配置最小權限ceph auth get-or-create client.cinder \ mon allow r \ osd allow class-read object_prefix rbd_children, allow rwx poolssd-pool創(chuàng)建完之后把這個keyring文件拷貝到對應客戶端機器上并在ceph.conf里指定該用戶的權限信息。這樣即使某臺機器被攻破攻擊者能拿到的最多是那一個池的訪問權而不是整個集群的管理權限。另外Ceph Dashboard的賬號密碼也別忘了改默認設置開啟雙因素認證避免管理面裸奔。結尾一些個人體會與建議大概是因為我前幾年吃過太多虧現(xiàn)在回過頭看Ceph最需要重視的不是部署命令本身而是對集群機制的理解和對細節(jié)的把控。真正遇到故障能幫你解決問題的不是某一條命令而是你知道數(shù)據(jù)是什么狀態(tài)、它會從什么路徑恢復、什么情況下絕對不能亂操作。那套集群跑到現(xiàn)在快一年了中間換過系統(tǒng)盤、加過兩個新節(jié)點業(yè)務幾乎沒停過。印象最深的還是剛上線時我做了一次全量壓力測試發(fā)現(xiàn)某個節(jié)點網(wǎng)絡抖動一次導致整個集群的寫延遲瞬間拉高從哪兒開始查還不是先從網(wǎng)絡和時鐘下手。所以我的建議非常簡單部署前留出時間做好規(guī)劃和系統(tǒng)調(diào)優(yōu)部署后第一時間配置好監(jiān)控告警不要省壓測。這種存儲系統(tǒng)平時不聲不響出問題時都是大問題——趁早有準備比到時候手忙腳亂強得多。