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