Ceph萬字總結(jié)|如何改善存儲性能以及提升存儲穩(wěn)定性
本文轉(zhuǎn)載自微信公眾號「新鈦云服」，作者祝祥 。轉(zhuǎn)載本文請聯(lián)系新鈦云服公眾號。
「Ceph – 簡介」
Ceph是一個即讓人印象深刻又讓人畏懼的開源存儲產(chǎn)品。通過本文，用戶能確定Ceph是否滿足自身的應用需求。在本文中，我們將深入研究Ceph的起源，研究其功能和基礎(chǔ)技術(shù)，并討論一些通用的部署方案和優(yōu)化與性能增強方案。同時本文也提供了一些故障場景以及對應的解決思路。
背景
Ceph是一個開源的分布式存儲解決方案，具有極大的靈活性和適應性。Ceph項目最早起源于Sage就讀博士期間的論文(最早的成果于2004年發(fā)表)，并隨后貢獻給開源社區(qū)。在經(jīng)過了數(shù)年的發(fā)展之后，目前已得到眾多云計算廠商的支持并被廣泛應用。RedHat及OpenStack都可與Ceph整合以支持虛擬機鏡像的后端存儲。
Ceph在2014年被RedHat收購后，一直由RedHat負責維護。Ceph的命名和UCSC(Ceph 的誕生地)的吉祥物有關(guān)，這個吉祥物是 “Sammy”，一個香蕉色的蛞蝓，就是頭足類中無殼的軟體動物。這些有多觸角的頭足類動物，是對一個分布式文件系統(tǒng)高度并行的形象比喻。自從2012年7月3日發(fā)布第一個版本的Argonaut以來，隨著新技術(shù)的整合，Ceph經(jīng)歷了幾次開發(fā)迭代。借助適用于Openstack和Proxmox的虛擬化平臺，Ceph可支持直接將iSCSI存儲呈現(xiàn)給虛擬化平臺。同時Ceph也擁有功能強大的API。在世界上的各大公司都能發(fā)現(xiàn)Ceph的身影——提供塊存儲，文件存儲，對象存儲。
由于Ceph是目前唯一提供以下所有功能的存儲解決方案，因此Ceph越來越受歡迎，并吸引了許多大型企業(yè)的極大興趣：
- 「軟件定義」：軟件定義存儲 (SDS) 是一種能將存儲軟件與硬件分隔開的存儲架構(gòu)。不同于傳統(tǒng)的網(wǎng)絡(luò)附加存儲 (NAS) 或存儲區(qū)域網(wǎng)絡(luò) (SAN) 系統(tǒng)，SDS 一般都在行業(yè)標準系統(tǒng)或 x86 系統(tǒng)上運行，從而消除了軟件對于專有硬件的依賴性。借助Ceph，還可以為諸如糾錯碼，副本，精簡配置，快照和備份之類的功能提供策略管理。
- 「企業(yè)級」 ：Ceph旨在滿足大型組織在可用性，兼容性，可靠性，可伸縮性，性能和安全性等方面的需求。它同時支持按比例伸縮，從而使其具有很高的靈活性，并且其可擴展性潛力幾乎無限。
- 「統(tǒng)一存儲」：Ceph提供了塊+對象+文件存儲，從而提供了更大的靈活性(大多數(shù)其他存儲產(chǎn)品都是僅塊，僅文件，僅對象或文件+塊;ceph提供的三種混合存儲是非常罕見)。
- 「開源」：開源實現(xiàn)技術(shù)的敏捷性，通常提供多種解決問題的方法。開源通常也更具成本效益，并且可以更輕松地使組織開始規(guī)模更小，規(guī)模更大。開源解決方案背后的許多意識形態(tài)孕育了一個相互協(xié)作且參與度高的專業(yè)社區(qū)，這些社區(qū)反應靈敏且相互支持。更不用說開源是未來的方向。Web，移動和云解決方案越來越多地建立在開源基礎(chǔ)架構(gòu)上。
「為什么選擇Ceph?」
「Ceph 分布式核心組件」
集群文件系統(tǒng)最初始于1990年代末和2000年代初。Lustre是最早利用可伸縮文件系統(tǒng)實現(xiàn)產(chǎn)品化的產(chǎn)品之一。多年來，出現(xiàn)了其他一些Lustre衍生產(chǎn)品，包括GlusterFS，GPFS，XtreemFS和OrangeFS等。這些文件系統(tǒng)都集中于為文件系統(tǒng)實現(xiàn)符合POSIX的掛載，并且缺乏通用的集成API。
Ceph的架構(gòu)并不需要考慮到需要與POSIX兼容的文件系統(tǒng)——這完全得益于云的時代。利用RADOS，Ceph可以擴展不受元數(shù)據(jù)約束限制的塊設(shè)備。這極大地提高了存儲性能，但是卻使那些尋求基于Ceph的大型文件系統(tǒng)掛載方法的人們望而卻步。直到Ceph Jewel(10.2.0)版本發(fā)布為止，CephFS已經(jīng)是穩(wěn)定且可靠的文件系統(tǒng)——允許部署POSIX掛載的文件系統(tǒng)。
Ceph支持塊，對象和文件存儲，并且具有橫向擴展能力，這意味著多個Ceph存儲節(jié)點(服務(wù)器)共同提供了一個可快速處理上PB數(shù)據(jù)(1PB = 1,000 TB = 1,000,000 GB)的存儲系統(tǒng)。利用作為基礎(chǔ)的硬件組件，它還可以同時提高性能和容量。
Ceph具有許多基本的企業(yè)存儲功能，包括副本，糾錯碼，快照，自動精簡配置，分層(在閃存和普通硬盤之間緩存數(shù)據(jù)的能力——即緩存)以及自我修復功能。為了做到這一點，Ceph利用了下面將要探討的幾個組件。
從Ceph Nautilus(v14.2.0)開始，現(xiàn)在有五個主要的守護程序或服務(wù)，它們集成在一起以提供Ceph服務(wù)的正常運行。這些是：
- 「ceph-mon」：Monitor確實提供了其名稱所暗示的功能——監(jiān)視群集的運行狀況。該監(jiān)視器還告訴OSD在replication期間將數(shù)據(jù)放置在何處，并保留主CRUSH Map。
- 「ceph-osd」：OSD是Ceph的基礎(chǔ)數(shù)據(jù)存儲單元，它利用XFS文件系統(tǒng)和物理磁盤來存儲從客戶端提供給它的塊數(shù)據(jù)。
- 「ceph-mds」：MDS守護程序提供了將Ceph塊數(shù)據(jù)轉(zhuǎn)換為存儲文件的POSIX兼容掛載點的功能，就像您使用傳統(tǒng)文件系統(tǒng)一樣。
- 「ceph-mgr」：MGR守護程序顯示有關(guān)群集狀態(tài)的監(jiān)視和管理信息。
- 「ceph-rgw」：RGW守護程序是一個HTTP API守護程序，對象存儲網(wǎng)關(guān)實際上是調(diào)用librados的API來實現(xiàn)數(shù)據(jù)的存儲和讀取。而該網(wǎng)關(guān)同時提供了兼容AWS S3和OpenStack Swift的對象存儲訪問接口(API)。
從術(shù)語的角度來看，Ceph需要了解一些重要的知識。
Ceph基于CRUSH算法構(gòu)建， 并支持多種訪問方法(文件，塊，對象)。CRUSH算法確定對象在OSD上的位置，并且可以將這些相同的塊拉出以進行訪問請求。
Ceph利用了可靠，自治，分布式的對象存儲(或RADOS)，該對象存儲由自我修復，自我管理的存儲節(jié)點組成。前面討論的OSD守護程序是RADOS群集的一部分。
放置組(PG)的全稱是placement group，是用于放置object的一個載體，所以群集中PG的數(shù)量決定了它的大小。pg的創(chuàng)建是在創(chuàng)建ceph存儲池的時候指定的，同時跟指定的副本數(shù)也有關(guān)系，比如是3副本的則會有3個相同的pg存在于3個不同的osd上，pg其實在osd的存在形式就是一個目錄。PG可以由管理員設(shè)置，新版本中也可以根據(jù)集群使用情況自動縮放。
RBD即RADOS Block Device的簡稱，RBD塊存儲是最穩(wěn)定且最常用的存儲類型。RBD塊設(shè)備類似磁盤可以被掛載。RBD塊設(shè)備具有快照、多副本、克隆和一致性等特性，數(shù)據(jù)以條帶化的方式存儲在Ceph集群的多個OSD中?？梢栽贑eph中用于創(chuàng)建用于虛擬化的鏡像塊設(shè)備，例如KVM和Xen。通過利用與RADOS兼容的API librados，VM的訪問不是通過iSCSI或NFS，而是通過存儲API來實現(xiàn)的。
使用場景
正如我們已經(jīng)描述的那樣，Ceph是一個非常靈活和一致的存儲解決方案。對Ceph存儲對象的訪問可以通過多種方式來完成，因此Ceph具有其他類似產(chǎn)品所缺乏的大量生產(chǎn)用例。
可以將Ceph部署為S3/Swift對象存儲的替代品。通過它的RADOS網(wǎng)關(guān)，可以使用http GET請求以及大量可用的Amazon S3 API工具箱訪問存儲在Ceph中的對象。
也可以通過librados API或iSCSI/NFS在包括VMWare和其他專有虛擬化平臺在內(nèi)的虛擬化環(huán)境中直接使用Ceph。
可以部署CephFS為需要訪問大型文件系統(tǒng)的操作系統(tǒng)提供POSIX兼容的掛載點。
根據(jù)以上的這些場景，我們可以利用單個存儲平臺來滿足各種計算和存儲需求。
「潛在的部署方案」
常用的Ceph部署工具主要有：ceph-deploy，ceph-ansible，基于kubernetns的Rook以及新版本基于容器的kubeadm等。當然工具不僅僅是這些。每一種部署方案都有大量的生產(chǎn)實踐。以下簡單介紹以下這幾種常用的部署方式：
「Ceph-deply」：該工具可用于簡單、快速地部署 Ceph 集群，而無需涉及繁雜的手動配置。它在管理節(jié)點上通過 ssh 獲取其它 Ceph 節(jié)點的訪問權(quán)、通過 sudo 獲取其上的管理權(quán)限、通過底層 Python 腳本自動化各節(jié)點上的 Ceph 安裝進程。它簡單到可以運行在工作站上，不需要服務(wù)器、數(shù)據(jù)庫或任何其它的自動化工具。使用ceph-deploy安裝和拆除集群非常簡單。然而它不是通用部署工具，是專為想快速安裝、運行 Ceph 的人們設(shè)計的專用工具，這樣的集群只包含必要的的初始配置選項，就沒必要安裝像 Chef 、 Puppet 或 Juju 這樣的部署工具。
「Ceph-ansible」：用于部署Ceph分布式系統(tǒng)的ansible playbook，ceph-ansible是安裝和管理完整ceph集群的最靈活的方法，當前大量的生產(chǎn)環(huán)境都會使用該安裝方式。
「Rook」：Rook 是一個編排器，能夠支持包括 Ceph 在內(nèi)的多種存儲方案。Rook 簡化了 Ceph 在 Kubernetes 集群中的部署過程。Rook 是一個可以提供 Ceph 集群管理能力的 Operator。Rook 使用 CRD 一個控制器來對 Ceph 之類的資源進行部署和管理。
「Cephadm」：較新的集群自動化部署工具，支持通過圖形界面或者命令行界面添加節(jié)點，目前不建議用于生產(chǎn)環(huán)境。cephadm的目標是提供一個功能齊全、健壯且維護良好的安裝和管理層，可供不在Kubernetes中運行Ceph的任何環(huán)境使用。Cephadm通過SSH從manager守護進程連接到主機來部署和管理Ceph集群，以添加、刪除或更新Ceph守護進程容器。它不依賴于外部配置或編排工具，如Ansible、Rook或Salt。
「結(jié)論」
Ceph的性能與功能不斷得到提升，存儲特性也不斷豐富，甚至可以與傳統(tǒng)專業(yè)存儲媲美，完備的存儲服務(wù)和低廉的投資成本，使得越來越多的企業(yè)和單位選用Ceph提供存儲服務(wù)。大量的生產(chǎn)最佳實踐也使得Ceph成為標準SDS的最優(yōu)解決方案之一。
Cephadm管理Ceph集群的整個生命周期，是官方以后力推的部署以及管理Ceph的解決方案。它首先在單個節(jié)點(一個監(jiān)視器和一個管理器)上引導一個很小的Ceph集群，然后使用編排接口擴展集群以包括所有主機并提供所有Ceph守護進程和服務(wù)。這可以通過Ceph命令行界面(CLI)或儀表板(GUI)來執(zhí)行。
Cephadm是Octopus發(fā)行版中的一個新功能，在生產(chǎn)中的使用有限。社區(qū)希望用戶嘗試cephadm，特別是對于新的集群，但請注意，有些功能仍然很粗糙。當前社區(qū)持續(xù)在改進以及相應BUG修復中。
5種最常見的CEPH失敗方案
Ceph是一種廣泛使用的存儲解決方案，可在整個分布式集群中實現(xiàn)對象級，塊級和文件級存儲。Ceph是創(chuàng)建不圍繞單個故障點進行擴展的高效存儲系統(tǒng)的理想選擇。但是，如果管理不當，Ceph可能很容易成為失敗場景的雷區(qū)，這可能是一件難以完全避免的事情。本處，我們將探討最常見的五種Ceph失敗方案。
「Monitor數(shù)目不正確」
在最新版本的Ceph中，至少需要三臺運行Ceph Mon守護程序的服務(wù)器。這些可以是物理服務(wù)器(理想情況下)或者也可以是虛擬機。但是，如果您超出了Mon服務(wù)器的最小數(shù)量，則在Ceph構(gòu)建中始終保持運行奇數(shù)個守護程序非常重要。這個奇數(shù)很重要，因為它允許系統(tǒng)正確地建立一個主機來控制CRUSH Map。在確定主服務(wù)器時，每臺服務(wù)器都會“投票”認為最適合維護crush map的服務(wù)器。維護奇數(shù)個Ceph守護程序可確保永遠不會出現(xiàn)投票平局的現(xiàn)象，并且始終會建立一個主服務(wù)器。如果沒有維護奇數(shù)個守護程序，則可能會導致不穩(wěn)定，并最終導致Ceph崩潰。
「OSD數(shù)目不正確」
根據(jù)在Ceph集群中所設(shè)置的副本數(shù)，您將需要足夠數(shù)量的硬盤(OSD——對象存儲設(shè)備)。當您計劃購買或升級當前Ceph中的OSD前，最重要的是要根據(jù)當前狀況進行數(shù)據(jù)量預測，以匹配未來生產(chǎn)的數(shù)據(jù)量。通常，最好至少提前6到12個月進行估算，并將此存儲量乘以所需的對象冗余量(即32TB數(shù)據(jù)* 3(副本數(shù))= 96TB所需的存儲空間)。通過適當?shù)念A測，您可以避免OSD過載，并保持CEPH環(huán)境正常運行。
「RADOS網(wǎng)關(guān)冗余不足」
RADOS (「Reliable, Autonomic Distributed Object Store」) 是Ceph的核心之一，作為Ceph分布式文件系統(tǒng)的一個子項目，特別為Ceph的需求設(shè)計，能夠在動態(tài)變化和異質(zhì)結(jié)構(gòu)的存儲設(shè)備集群之上提供一種穩(wěn)定、可擴展、高性能的單一邏輯對象(Object)存儲接口和能夠?qū)崿F(xiàn)節(jié)點的自適應和自管理的存儲系統(tǒng)。RADOS構(gòu)成了Ceph集群的核心，并且與Ceph CRUSH Map結(jié)合使用時，可以使您在服務(wù)器的集群中保持數(shù)據(jù)一致且可安全的進行數(shù)據(jù)同步與復制。可以以多種不同方式訪問Ceph數(shù)據(jù)。其中之一是通過稱為RADOS網(wǎng)關(guān)的HTTP API前端進行的。RADOS網(wǎng)關(guān)公開了一個存儲API，供外部人員調(diào)用。
如果通過RADOS網(wǎng)關(guān)訪問您的Ceph集群，那么促進API訪問的前端服務(wù)器必須冗余且能夠負載均衡，這一點非常重要。在理想的配置中，多個RADOS服務(wù)器將可用于接受請求，并且所有請求都應由一個冗余的負載均衡器進行管理。如果未進行正確配置，則非冗余RADOS網(wǎng)關(guān)服務(wù)器的故障將導致您完全失去對CEPH群集的API訪問權(quán)限。您可以使用混合的解決方案，該混合解決方案會利用本地RADOS網(wǎng)關(guān)，當發(fā)生故障時則會回退到基于云的冗余網(wǎng)關(guān)上。這可以最大程度地減少額外的不必要轉(zhuǎn)換，同時保持對存儲解決方案的冗余和可靠訪問。
「硬件配置不足」
為CEPH集群維護硬件時，最重要的是要確保硬件配置滿足實際需求，具體需要考慮的如下：
- 「電源」：確保主機的電源模塊至少是雙路冗余。還要確保每臺CEPH服務(wù)器都有一個備用電源，該備用電源的功率足以完全滿足服務(wù)器的需求。沒有適當?shù)娜哂?，您將面臨不可挽回的數(shù)據(jù)丟失的風險。
- 「CPU」：最佳實踐要求在所有CEPH服務(wù)器上使用相同型號相同配置的CPU。這有助于在整個ceph集群中保持一致性以及穩(wěn)定性。
- 「內(nèi)存」：與CPU相似，您使用的內(nèi)存應在CEPH服務(wù)器之間平均分配。理想情況下，存儲服務(wù)器的品牌和規(guī)格應該相同。此外，在發(fā)生硬件故障時，還應具有大量可用的冗余內(nèi)存(備件)。
- 「硬盤」：建議將SAS磁盤用于OSD。如果有可能的話，使用故障率低于SAS盤的NVMe磁盤則會更為理想。
- 「其他」：如果有可能的話，可以提供一些冷備機器。當存儲節(jié)點存現(xiàn)故障的時候，極端情況下可以直接進行備機更換(保留物理磁盤)。
「CEPH專業(yè)知識」
通常，CEPH失敗的原因是由于缺乏CEPH相關(guān)的專業(yè)知識。例如，所有CEPH群集中OSD節(jié)點都將利用硬盤直通模式來確保性能和可靠性。但是，如果改用RAID的話，則不僅是不推薦的，而且還會因為磁盤陣列故障而導致出現(xiàn)單點故障，最終可能引起大量數(shù)據(jù)丟失。這種錯誤很簡單，但從長遠來看，這樣的錯誤代價高昂，并且可能需要更高級的ceph專家去解決相應的問題。
Ceph常規(guī)排障
如果Ceph集群崩潰該怎么辦
由于Ceph在軟件層就內(nèi)置了所有可用的冗余和故障保護功能，因此簡單的故障不太可能造成災難性的后果，并且一般的故障相對都是比較容易恢復的。但問題是，當遇到一系列意外事件導致集群停止響應存儲請求或使所有VM虛擬機脫機時，那又該怎么辦?
「保持冷靜」
Ceph非常強大，其Crush算法可確保數(shù)據(jù)的完整性和可用性。記住這一關(guān)鍵事實將有助于您確定中斷的原因。
最常見的災難性故障場景之一是群集丟失的OSD超過維護所需的冗余級別所需的OSD。在這種情況下，快速識別并更換有問題的OSD將使您的群集恢復工作狀態(tài)。同時也讓我們確定其他潛在故障觸發(fā)因素。
「記錄和狀態(tài)」
Ceph在mon(monitor)節(jié)點和osd(object storage daemon)節(jié)點上提供了多個日志和狀態(tài)查看命令，您應該首先利用Ceph相關(guān)命令行來查看群集的運行狀況。
要評估Ceph集群的當前狀態(tài)，請輸入：
- # ceph status
或者使用：
- # ceph -s
兩次命令的結(jié)果都應輸出類似于以下內(nèi)容：
- cluster b370a29d-9287-4ca3-ab57-3d824f65e339
- health HEALTH_OK
- monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1
- osdmap e63: 2 osds: 2 up, 2 in
- pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects
- 115 GB used, 167 GB / 297 GB avail
- 1 active+clean+scrubbing+deep
- 951 active+clean
如果您看到健康狀況為“HEALTH_OK”，那就說明集群狀態(tài)健康。
在某些情況下，尤其是與OSD相關(guān)的情況下，將返回HEALTH_WARN或HEALTH_ERR。這可能是由于一些不影響群集整體性能的因素所致，例如OSD重新均衡或存儲池的PG的深度清理。這些都可以安全地忽略。
在某些情況下，Ceph的命令行界面可能根本不響應這兩個命令。如果您的Ceph的身份驗證有問題，或者運行Monitor服務(wù)的節(jié)點硬件有問題，通常會發(fā)生這種情況。在第二種情況下，則需要診斷Monitor節(jié)點服務(wù)器本身的硬件問題。
「mon(Monitor)調(diào)試」
當使用多個Ceph Mon運行時，Ceph則需要仲裁(Quorum)。仲裁是確保一致性的可靠方法，因為群集需要最少的“投票”數(shù)才能繼續(xù)進行replication。
可以使用以下幾個命令來確定Ceph Mon的狀態(tài)。
- # ceph mon stat
上述命令將輸出集群中所有mon的當前狀態(tài)，例如：
- e3: 3 mons at {pve1=10.103.6.109:6789/0,pve2=10.103.6.110:6789/0,pve3=10.103.6.111:6789/0}, election epoch 30, leader 0 pve1, quorum 0,1,2 pve1,pve2,pve3
上面表示有三個Ceph Mon已經(jīng)啟動并成功運行。其中有一個仲裁節(jié)點，狀態(tài)顯示集群運行正常。您會注意到ceph mon stat的輸出中有幾條重要的信息，包括選舉之間的時間間隔(以秒為單位)。選舉在這些時間間隔內(nèi)發(fā)生，以確定哪個監(jiān)視器應該是集群的“leader”。
與使用仲裁作為確保一致性的方法的非技術(shù)機構(gòu)一樣，每個節(jié)點都有一票表決權(quán)。在Ceph中，最佳實踐堅持我們利用大于或等于3的奇數(shù)個Ceph Mon節(jié)點。這確保了我們的群集在失去一個或者兩個仲裁節(jié)點的小概率事件中維持仲裁能力和一定程度的冗余。
如果我們真的失去了法定人數(shù)(quorum)，或者沒有贏得法定人數(shù)的投票。那么，由于監(jiān)視器在其Ceph運行中所起的重要作用，則會導致Ceph群集將完全無法響應。從跟蹤數(shù)據(jù)存放位置到維護OSD的實時Map。Ceph Mon節(jié)點還提供用于返回“Ceph health”和“Ceph -s”輸出功能。如果沒有一個正常工作的Ceph Mon仲裁，則所有命令都不會有任何返回值。
檢查監(jiān)視器狀態(tài)的其他有用命令包括：
- #dumping the mon map
- # ceph mon dump
- dumped monmap epoch 3
- epoch 3
- fsid 4a1dc77a-37f8-4b5b-9476-853f7cace716
- last_changed 2020-8-18 10:50:36.846268
- created 2020-8-18 10:50:25.571368
- 0: 10.103.6.109:6789/0 mon.pve1
- 1: 10.103.6.110:6789/0 mon.pve2
- 2: 10.103.6.111:6789/0 mon.pve3
- # ceph quorum_status --format json-pretty #looking at quorum status
- {
- "election_epoch": 30,
- "quorum": [
- 0,
- 1,
- 2
- ],
- "quorum_names": [
- "pve1",
- "pve2",
- "pve3"
- ],
- "quorum_leader_name": "pve1",
- "monmap": {
- "epoch": 3,
- "fsid": "4a1dc77a-37f8-4b5b-9476-853f7cace716",
- "modified": "2020-8-18 10:50:36.846268",
- "created": "2020-8-18 10:50:25.571368",
- "features": {
- "persistent": [
- "kraken",
- "luminous"
- ],
- "optional": []
- },
- "mons": [
- {
- "rank": 0,
- "name": "pve1",
- "addr": "10.103.6.109:6789/0",
- "public_addr": "10.103.6.109:6789/0"
- },
- {
- "rank": 1,
- "name": "pve2",
- "addr": "10.103.6.110:6789/0",
- "public_addr": "10.103.6.110:6789/0"
- },
- {
- "rank": 2,
- "name": "pve3",
- "addr": "10.103.6.111:6789/0",
- "public_addr": "10.103.6.111:6789/0"
- }
- ]
- }
- }
「守護進程套接字(「Daemon Socket」)」
Ceph管理套接字(daemon socket)允許您直接連接到所有正在運行的Ceph守護進程。從OSD到Mon和MGR，Ceph守護程序管理套接字可以提供診斷功能，這些功能在Ceph Mon發(fā)生故障并且Ceph客戶端停止響應時可能會變得不可用。
以下命令可直接連接到Ceph守護程序，根據(jù)需求進行狀態(tài)查看。
- # ceph daemon {daemon-name} ##OR
- # ceph daemon {path-to-socket-file} ##For Example
- # ceph daemon osd.0 help
- {
- "calc_objectstore_db_histogram": "Generate key value histogram of kvdb(rocksdb) which used by bluestore",
- "compact": "Commpact object store's omap. WARNING: Compaction probably slows your requests",
- "config diff": "dump diff of current config and default config",
- "config diff get": "dump diff get : dump diff of current and default config setting ",
- "config get": "config get : get the config value",
- "config help": "get config setting schema and descriptions",
- "config set": "config set [ ...]: set a config variable",
- "config show": "dump current config settings",
- "dump_blacklist": "dump blacklisted clients and times",
- "dump_blocked_ops": "show the blocked ops currently in flight",
- "dump_historic_ops": "show recent ops",
- "dump_historic_ops_by_duration": "show slowest recent ops, sorted by duration",
- "dump_historic_slow_ops": "show slowest recent ops",
- "dump_mempools": "get mempool stats",
- "dump_objectstore_kv_stats": "print statistics of kvdb which used by bluestore",
- "dump_op_pq_state": "dump op priority queue state",
- "dump_ops_in_flight": "show the ops currently in flight",
- "dump_pgstate_history": "show recent state history",
- "dump_reservations": "show recovery reservations",
- "dump_scrubs": "print scheduled scrubs",
- "dump_watchers": "show clients which have active watches, and on which objects",
- "flush_journal": "flush the journal to permanent store",
- "flush_store_cache": "Flush bluestore internal cache",
- "get_command_descriptions": "list available commands",
- "get_heap_property": "get malloc extension heap property",
- "get_latest_osdmap": "force osd to update the latest map from the mon",
- "getomap": "output entire object map",
- "git_version": "get git sha1",
- "heap": "show heap usage info (available only if compiled with tcmalloc)",
- "help": "list available commands",
- "injectdataerr": "inject data error to an object",
- "injectfull": "Inject a full disk (optional count times)",
- "injectmdataerr": "inject metadata error to an object",
- "log dump": "dump recent log entries to log file",
- "log flush": "flush log entries to log file",
- "log reopen": "reopen log file",
- "objecter_requests": "show in-progress osd requests",
- "ops": "show the ops currently in flight",
- "perf dump": "dump perfcounters value",
- "perf histogram dump": "dump perf histogram values",
- "perf histogram schema": "dump perf histogram schema",
- "perf reset": "perf reset : perf reset all or one perfcounter name",
- "perf schema": "dump perfcounters schema",
- "rmomapkey": "remove omap key",
- "set_heap_property": "update malloc extension heap property",
- "set_recovery_delay": "Delay osd recovery by specified seconds",
- "setomapheader": "set omap header",
- "setomapval": "set omap key",
- "status": "high-level status of OSD",
- "trigger_scrub": "Trigger a scheduled scrub ",
- "truncobj": "truncate object to length",
- "version": "get ceph version"
例如，當多個Ceph monitor守護進程同時失敗時，Ceph守護程序可用于更新mon map。這將使您可以將新的mon map更新并導入到無法運行的Ceph Mon節(jié)點中，這也是Ceph中非常常見的一個故障解決方案。
「規(guī)避風險」
用戶應該盡量熟悉這兩種從Ceph群集崩潰或意外中斷中恢復的重要方法。這些工具功能強大，學習如何利用它們則能盡量減少數(shù)據(jù)丟失的風險，同時也能夠最快，最全的恢復Ceph集群。
當然，每一個故障場景都不同，本處僅僅是提供了一些常規(guī)的集群崩潰故障以及對應的解決方案。但更復雜的場景需要用戶根據(jù)自身所遇到的場景進行更加具體的分析以及處理。
Ceph — OSD Flapping(抖動)調(diào)試和恢復
下面我們將特別討論如果當您發(fā)現(xiàn)Ceph OSD因意外而進行peering，出現(xiàn)scrubbing或集群連接斷斷續(xù)續(xù)的情況時候該如何進行排查以及解決問題。其實，上述的這些行為也可以稱之為抖動(flapping)，而且這因多種原因而引起的故障會損害群集的性能和持久性以及穩(wěn)定性。
「故障」
當一個OSD或多個OSD開始抖動(flapping)時，您可能首先會注意到讀寫速度明顯下降。這是出于多種原因。當OSD在不停的抖動(flapping)期間停止時，您實際上已經(jīng)失去了正在抖動(flapping)的所有OSD的總吞吐量，也就是說這些抖動(flapping) OSD不僅不能提供正常的存儲能力，還影響了整個集群的性能。尤其是在一個擁有數(shù)萬IOPS讀寫的大型集群上，這可能是災難性的。
OSD服務(wù)正常后，群集要做的第一件事就是嘗試進行恢復?；謴筒⒉皇且粋€非常簡單的過程，其中需要對在多個不同主機上的多個OSD中副本的塊進行校驗和驗證，以確保完整性。如果校驗和不匹配，則需要重新復制該塊。
此校驗和驗證和文件重新傳輸過程會引起Ceph集群的大量硬件資源消耗。最直接的體現(xiàn)是：服務(wù)器設(shè)備耗電量會大幅度增加，群集網(wǎng)絡(luò)上的網(wǎng)絡(luò)流量也會急劇增加。如果當前Ceph集群已經(jīng)處于一個高負載的環(huán)境，這種額外的不必要的負載可能會導致性能進一步下降，甚至導致集群停止響應，極端情況會引起Ceph集群的一連串的崩潰。
那么，如何查看Ceph集群的癥狀，以查看性能問題是否與OSD的抖動(flapping)相關(guān)?第一種也是最簡單的方法是簡單地檢查群集的運行狀況。這可以通過使用Luminous及更高版本中提供的Ceph儀表板來完成?？赏ㄟ^“http://IPCEPHNODE:7000” (7000為訪問端口，在初始化的時候可以根據(jù)需求進行自定義)。您還可以在任何啟用了ceph-admin的主機上通過命令行查看Ceph群集的狀態(tài)?？梢允褂?ldquo; ceph -s”命令，該命令將輸出集群的當前運行狀況。如果正在進行修復或OSD當前被標記為down，該命令將向您發(fā)出輸出警報。
「原因和解決方法」
通常，導致OSD抖動(flapping)的原因與導致OSD失敗的原因相似。不良的硬件狀況，過多的發(fā)熱，網(wǎng)絡(luò)問題以及整個系統(tǒng)的負載都可能導致OSD抖動(flapping)。
從硬件的角度來看，底層的存儲磁盤可能出現(xiàn)物理故障。所有硬盤都可通過SMART屬性監(jiān)視其當前狀態(tài)。這些值提供有關(guān)硬盤各種參數(shù)的信息，并可提供有關(guān)磁盤剩余壽命或任何可能的錯誤的信息。此外，可以執(zhí)行各種SMART測試，以確定磁盤上的任何硬件問題。因此，可以利用Smartctl來確定當前環(huán)境中的SAS或者SATA磁盤是否處于不健康狀態(tài)——這可能導致OSD故障并不停重啟。通過登錄到可能受影響的主機并輸入“ smartctl -a /dev/sdX”(其中X是設(shè)備ID)來定位物理設(shè)備，從而檢查硬盤驅(qū)動器的SMART狀態(tài)。同時還可以通過grep正則匹配去過濾所需要的參數(shù)。通過該方式，不僅將輸出硬盤當前的狀態(tài)，同時會顯示即將發(fā)生故障。如果可以的話，請及時更換有故障的硬盤!
OSD抖動(flapping)的另一個原因可能很簡單，比如您的Ceph存儲網(wǎng)絡(luò)接口上的MTU不匹配。MTU或Maximum Transmission Unit，用來通知對方所能接受數(shù)據(jù)服務(wù)單元的最大尺寸，說明發(fā)送方能夠接受的有效載荷大小，也就是允許接口發(fā)送的最大數(shù)據(jù)包大小——有效地將數(shù)據(jù)包拆分為較小的塊，以適合系統(tǒng)指定的MTU。因為Ceph是一種處理大型數(shù)據(jù)塊的存儲技術(shù)，所以MTU越大，代表系統(tǒng)以最少的工作量就可以獲得更多的吞吐量。
如果整個集群中的任何地方的MTU不匹配，即一臺服務(wù)器的MTU設(shè)置為9000，另一臺服務(wù)器的MTU設(shè)置為1500，你最終會遇到這樣的情況：數(shù)據(jù)傳輸卡頓，并且Ceph集群的復制也會基本停止。這也可能是Ceph OSD抖動(flapping)的另外一個原因(健康檢查與低MTU的競爭帶寬)。
要檢查接口的MTU，請在命令行上鍵入“ ifconfig”或“ ip addr”。將MTU與接口匹配，并比較群集中所有主機接口的MTU配置是否一致。
「結(jié)論」
Ceph OSD的抖動是存儲使用過程中最常見的一種故障，該故障不一定會致命，但往往會對集群性能產(chǎn)生嚴重的影響。及時發(fā)現(xiàn)OSD抖動，合理解決問題，盡量避免對集群產(chǎn)生過多的影響。
「Ceph性能優(yōu)化與增強」
上文介紹了Ceph的入門背景，討論了Ceph在云計算和對象存儲中的功能和主要組件，并簡要概述了其部署工具以及常規(guī)的故障現(xiàn)象以及對應的解決思路。下文，我們將研究Ceph的強大的功能，并探索最優(yōu)的方法來提高存儲性能。
Ceph是一個非常復雜的存儲系統(tǒng)，它具有幾種我們可以用來提高性能的方式。幸運的是，Ceph的開箱即用非常好，許多性能設(shè)置幾乎利用了自動調(diào)整和縮放功能。在探索一些性能增強時，了解您的工作負載很重要，這樣您就可以選擇最適合您的選項。
「配置說明」
Ceph有幾種部署方案，其中最常見的是針對虛擬化環(huán)境，符合POSIX的文件系統(tǒng)和塊存儲的組合。這些場景中的每一個都有明顯不同的配置要求。例如，在CephFS提出的POSIX文件系統(tǒng)中，將文件系統(tǒng)元數(shù)據(jù)存儲在高速SSD或NVMe驅(qū)動器上是非常重要。對于虛擬化環(huán)境中使用RBD場景，Ceph的caching tier功能可以使用SSD或NVMe為后端普通廉價的存儲提供高速緩存的功能。
「通用硬件」
「Hyper-Threading(HT)」基本做云平臺的，VT和HT打開都是必須的，超線程技術(shù)(HT)就是利用特殊的硬件指令，把兩個邏輯內(nèi)核模擬成兩個物理芯片，讓單個處理器都能使用線程級并行計算，進而兼容多線程操作系統(tǒng)和軟件，減少了CPU的閑置時間，提高的CPU的運行效率。
「關(guān)閉節(jié)能」關(guān)閉節(jié)能后，對性能還是有所提升的，所以堅決調(diào)整成性能型(Performance)。當然也可以在操作系統(tǒng)級別進行調(diào)整，詳細的調(diào)整過程請參考鏈接，但是不知道是不是由于BIOS已經(jīng)調(diào)整的緣故，所以在CentOS 6.6上并沒有發(fā)現(xiàn)相關(guān)的設(shè)置。
- for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f <span class="katex math inline">CPUFREQ ] || continue; echo -n performance></span>CPUFREQ; done
「NUMA」簡單來說，NUMA思路就是將內(nèi)存和CPU分割為多個區(qū)域，每個區(qū)域叫做NODE,然后將NODE高速互聯(lián)。node內(nèi)cpu與內(nèi)存訪問速度快于訪問其他node的內(nèi)存，NUMA可能會在某些情況下影響ceph-osd。解決的方案，一種是通過BIOS關(guān)閉NUMA，另外一種就是通過cgroup將ceph-osd進程與某一個CPU Core以及同一NODE下的內(nèi)存進行綁定。但是第二種看起來更麻煩，所以一般部署的時候可以在系統(tǒng)層面關(guān)閉NUMA。CentOS系統(tǒng)下，通過修改/etc/grub.conf文件，添加numa=off來關(guān)閉NUMA。
- kernel /vmlinuz-2.6.32-504.12.2.el6.x86_64 ro root=UUID=870d47f8-0357-4a32-909f-74173a9f0633 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM biosdevname=0 numa=off
「RAM」
為Ceph選擇的主機及其基礎(chǔ)服務(wù)應具有足夠的CPU線程，內(nèi)存和網(wǎng)絡(luò)設(shè)備，以處理群集的預期吞吐量。Ceph建議每1TB OSD原始磁盤空間使用1GB RAM。如果主機具有96TB的原始磁盤空間，則應計劃至少需要96GB的RAM。我們建議每個OSD至少使用1個CPU內(nèi)核。OSD可以定期消耗整個CPU來執(zhí)行重新平衡操作。
「避免使用超融合!」
不建議以超融合方式在Ceph節(jié)點上運行其他應用程序，因為在由于磁盤故障而導致的群集重建過程中，每個OSD的OSD RAM使用量可能遠遠超過建議的1GB。如果其他應用程序爭奪RAM，則重建性能以及隨后的Ceph群集本身的讀寫性能都會受到嚴重影響。
「不要使用硬件RAID控制器!」
讓Ceph為您完成數(shù)據(jù)處理。使用硬件RAID控制器可能導致Ceph在RAID重建期間未意識到的不一致和性能下降。SAS HBA的價格為$100-$200，高性能的僅占很小的溢價。這將是確保Ceph集群性能的最佳配置。
「基礎(chǔ)存儲OSD」
當構(gòu)建一個新的Ceph群集時，其中一個主要的工作是對象存儲守護程序(OSD)的底層存儲的選擇。容量需求可能決定了該解決方案所需要的底層存儲。預算可能允許購買大容量的SSD驅(qū)動器或NVMe。無論選擇了什么樣的底層存儲，累計底層存儲的性能都將直接影響Ceph集群的性能(OSD性能越佳，則Ceph集群性能也越佳)。
在需要使多個10G萬兆網(wǎng)絡(luò)接口的環(huán)境中，或者對于讀寫時延極低的應用程序，選擇SSD或NVMe磁盤可能更有意義。這些將為OSD提供企業(yè)級磁盤的完整吞吐量，包括在整個群集中的組合IOPS。
SATA和SAS類型磁盤確實提供了比SSD和NVMe更大的標準存儲容量，但是IOPS與吞吐量有限(受限于OSD所使用的存儲介質(zhì))。因此，群集中將需要更大的磁盤陣列，以提供與更快的磁盤相似的甚至遠超的性能。
「緩存層」
Ceph Luminous中的新增功能，對于出于預算原因或使用大容量磁盤的項目，可以充分提前預估存儲容量的用戶而言，緩存層(Cache Tier)是一項極佳的性能增強解決方案。構(gòu)建緩存層(Cache Tier)需要為每個Ceph存儲節(jié)點提供少數(shù)量的SSD或NVMe磁盤，并修改Crush Map映射以創(chuàng)建單獨的存儲類。
最佳實踐表明，除非您能夠準確預測實際數(shù)據(jù)量，否則緩存應不小于活動存儲池的1/10到1/8的容量。因此，如果您有100TB的數(shù)據(jù)池，則應計劃為您的緩存層提供大約10TB的存儲空間。
「Crush Map」
CRUSH 算法通過計算數(shù)據(jù)存儲位置來確定如何存儲和檢索。CRUSH 授權(quán) Ceph 客戶端直接連接 OSD ，而非通過一個集中服務(wù)器或代理。數(shù)據(jù)存儲、檢索算法的使用，使 Ceph 避免了單點故障、性能瓶頸、和伸縮的物理限制。
CRUSH 需要一張集群的 Map，且使用 CRUSH Map 把數(shù)據(jù)偽隨機地、盡量平均地分布到整個集群的 OSD 里。CRUSH Map 包含 OSD 列表、把設(shè)備匯聚為物理位置的“桶”列表、和指示 CRUSH 如何復制存儲池里的數(shù)據(jù)的規(guī)則列表。
CRUSH Map負責確保數(shù)據(jù)最終到達群集中應有的位置，并在將IO請求轉(zhuǎn)換為磁盤位置以進行數(shù)據(jù)檢索中發(fā)揮作用。正確的CRUSH Map將考慮設(shè)備的適當權(quán)重，通常由磁盤大小決定，盡管您可以根據(jù)磁盤IOPS等其他因素來修改權(quán)重(一般不建議這樣做)。
「系統(tǒng)調(diào)整」
一個經(jīng)過適當調(diào)優(yōu)的系統(tǒng)將是實現(xiàn)Ceph預期性能的關(guān)鍵。請?zhí)貏e關(guān)注網(wǎng)絡(luò)和sysctl優(yōu)化。一些關(guān)鍵參數(shù)包括：
- 「系統(tǒng)MTU」 ：將其設(shè)置為9000以允許大幀。眾所周知，存儲流量在TCP堆棧上非常頻繁，應允許其盡可能多地傳輸數(shù)據(jù)而不會造成碎片，以確保您能夠充分使用存儲網(wǎng)絡(luò)。
- 「Swappiness」 ：通常，使用swap分區(qū)是不太好的。每當您從內(nèi)存切換到磁盤時，操作系統(tǒng)就會用完執(zhí)行基本功能所需的內(nèi)存，并且不得不將其中的某些內(nèi)存強制降低到速度慢得多的磁盤上。在查看性能時，不能忽略Ceph群集的RAM分配的正確大小。可以在linux系統(tǒng)中配置Sysctl相應的參數(shù)，以強制linux停止使用交換分區(qū)。我們建議值為1，默認值通?？梢栽?0到40之間。數(shù)字越大，內(nèi)核嘗試交換的頻率就越高。
- 「“ noatime”」 ：在大多數(shù)已掛載的文件系統(tǒng)上使用此選項，以跟蹤磁盤上文件的上次訪問時間。由于這是由OSD自己單獨處理的，因此在速度較慢的磁盤上禁用noatime可以提高性能。
「Ceph架構(gòu)調(diào)整」
關(guān)于Ceph的配置以及優(yōu)化的思路整體涉及如下：
- Mon節(jié)點對于群集的正常運行至關(guān)重要。嘗試并使用獨立的Mon節(jié)點，請確保資源獨享;或者，如果它們在共享環(huán)境中運行，則需要隔離Mon進程。為了實現(xiàn)冗余，請在Ceph集群中將Mon節(jié)點盡量均勻分布。
- Journal日志因雙寫緣故，對影響影響較大。理想情況下，您應該在單獨的物理磁盤上運行操作系統(tǒng)，OSD數(shù)據(jù)和OSD日志，以最佳的方式提高整體吞吐量?？梢钥紤]將SSD用作Journal分區(qū)來提供讀寫吞吐量。
- 如果使用的是bluestore而非filestore的話，也請考慮rocksdb與wal的存儲使用SSD分區(qū)。
- 糾錯碼是對象存儲的一種數(shù)據(jù)持久性特性。當存儲大量一次寫入、不經(jīng)常讀取的數(shù)據(jù)時，請使用糾錯碼。但是請記住，這是一個折衷方案：糾錯碼可以大大降低每GB的成本，但與副本相比，其IOPS性能較低。
- 支持dentry和inode緩存可以提高性能，尤其是在具有許多較小對象的群集上。
- 使用緩存分層，可以根據(jù)需求在熱層和冷層之間自動遷移數(shù)據(jù)，從而提高群集的性能。為了獲得最佳性能，請將SSD用于高速緩存池，并將存儲池托管在具有較低延遲的服務(wù)器上。
- 部署奇數(shù)個Mon節(jié)點(3個或5個)以進行法定投票。添加更多的Mon可使您的群集更持久。但是，這有時會降低性能，因為Mon之間還有更多數(shù)據(jù)要保持同步。
- 排查群集中的性能問題時，請始終從最低級別(磁盤，網(wǎng)絡(luò)或其他硬件)開始，然后逐步升級至更高級別(塊設(shè)備和對象網(wǎng)關(guān))。
- PG和PGP數(shù)量一定要根據(jù)OSD的數(shù)量進行調(diào)整，不合理的PG數(shù)目會導致數(shù)據(jù)分布不均衡。
- Ceph OSD存在木桶原理，單個OSD的性能下降可能會影響整個集群的性能，所以要及時發(fā)現(xiàn)低性能的OSD，然后更換或者直接踢出集群。
「結(jié)論」
根據(jù)以上幾種方法可以正確實現(xiàn)Ceph以提供您期望的性能。利用磁盤緩存，緩存分層和適當配置的系統(tǒng)，可以確保磁盤性能不會成為基礎(chǔ)架構(gòu)的瓶頸。
寫在最后
雖然開源存儲對于希望減少集中式商業(yè)存儲上的用戶而言來說是一個福音，但文檔和支持可能會受到限制。在沒有商業(yè)支持的前提下，除了靠社區(qū)的支持外，剩下的就靠用戶對軟件本身的熟悉程度。只有不斷的嘗試，不斷的優(yōu)化，不斷的回饋社區(qū)，才能使開源軟件發(fā)展的更好。
參考：
https://ceph.readthedocs.io
http://www.slideshare.net/Inktank_Ceph/dell-ceph-22nd-london-v5
http://ceph.com/docs/master/start/hardware-recommendations/
http://www.inktank.com/inktank-ceph-enterprise/inktank-ceph-enterprise-1-2-arrives-with-erasure-coding-and-cache-tiering
