Ceph企業(yè)級分布式存儲（原理與工程實(shí)踐）

Ceph企業(yè)級分布式存儲原理與工程實(shí)踐目錄TOC\h\h第一部分Ceph原理\h第1章Ceph概述\h1.1軟件定義存儲\h1.1.1基本概念介紹\h1.1.2軟件定義存儲工作機(jī)制\h1.1.3軟件定義存儲的優(yōu)勢\h1.2Ceph的發(fā)展史\h1.2.1研究階段\h1.2.2孵化階段\h1.2.3商業(yè)化階段\h1.2.4成熟階段\h1.3Ceph的市場分析\h1.3.1存儲形態(tài)的轉(zhuǎn)型\h1.3.2存儲形態(tài)演變的特點(diǎn)\h1.3.3軟件定義存儲的市場分析\h1.4Ceph的適用場景\h1.4.1分析類應(yīng)用場景舉例\h1.4.2IaaS云平臺應(yīng)用場景舉例\h1.4.3富媒體和歸檔應(yīng)用場景舉例\h1.4.4企業(yè)文件同步和共享應(yīng)用場景舉例\h1.4.5服務(wù)器和應(yīng)用程序存儲場景舉例\h1.5軟件定義存儲的商業(yè)產(chǎn)品\h1.6本章小結(jié)\h第2章Ceph架構(gòu)分析\h2.1Ceph集群的組成架構(gòu)\h2.2Monitor節(jié)點(diǎn)分析\h2.2.1CephClusterMap\h2.2.2CephMonitor的Quorum機(jī)制\h2.2.3CephMonitor一致性\h2.3OSD節(jié)點(diǎn)分析\h2.3.1運(yùn)行OSD所需服務(wù)器配置推薦\h2.3.2OSD的Scrub\h2.3.3回填OSD\h2.3.4OSD恢復(fù)\h2.4Manager節(jié)點(diǎn)分析\h2.5Ceph對象存儲和對象網(wǎng)關(guān)\h2.5.1對象存儲\h2.5.2對象網(wǎng)關(guān)\h2.6文件存儲元數(shù)據(jù)節(jié)點(diǎn)分析\h2.6.1Ceph文件存儲\h2.6.2CephFS限制因素\h2.7iSCSI網(wǎng)關(guān)節(jié)點(diǎn)分析\h2.8本章小結(jié)\h第3章Ceph核心技術(shù)組件\h3.1Ceph的關(guān)鍵特性\h3.2存儲池\h3.2.1Ceph技術(shù)組件的全景架構(gòu)\h3.2.2存儲池定義的內(nèi)容\h3.3Ceph認(rèn)證\h3.4Ceph放置組\h3.4.1PG基本概念\h3.4.2放置組的計(jì)算方法\h3.4.3PG和PGP的區(qū)別\h3.5CRUSH算法\h3.6Ceph數(shù)據(jù)副本\h3.7Ceph糾刪碼\h3.8Ceph對象存儲技術(shù)\h3.8.1FileStore技術(shù)\h3.8.2BlueStore技術(shù)\h3.9Ceph心跳檢查\h3.10CephPeering\h3.11Ceph數(shù)據(jù)再平衡\h3.12Ceph數(shù)據(jù)完整性\h3.13本章小結(jié)\h第4章Ceph客戶端組件\h4.1Ceph支持的客戶端類型\h4.2Ceph客戶端的Watch/Notify機(jī)制\h4.3Ceph客戶端的獨(dú)占鎖\h4.4Ceph客戶端的對象映射\h4.5Ceph客戶端的數(shù)據(jù)條帶化\h4.6本章小結(jié)\h第二部分Ceph實(shí)戰(zhàn)\h第5章Ceph集群規(guī)劃\h5.1版本規(guī)劃\h5.2基礎(chǔ)環(huán)境規(guī)劃\h5.2.1推薦使用的操作系統(tǒng)\h5.2.2限制條件\h5.2.3主要支持的特性\h5.3服務(wù)器規(guī)劃\h5.3.1追求良好的IOPS的場景\h5.3.2追求良好的吞吐量場景\h5.3.3追求低成本、高容量的場景\h5.3.4實(shí)驗(yàn)環(huán)境下服務(wù)器的最小配置\h5.4組網(wǎng)規(guī)劃\h5.4.1組網(wǎng)規(guī)劃建議\h5.4.2Ceph消息通信框架\h5.4.3防火墻規(guī)劃\h5.5本章小結(jié)\h第6章Ceph集群安裝部署\h6.1基礎(chǔ)環(huán)境準(zhǔn)備\h6.1.1創(chuàng)建虛擬機(jī)\h6.1.2配置服務(wù)器\h6.2準(zhǔn)備安裝介質(zhì)\h6.3安裝前檢查\h6.4安裝Ceph\h6.5集群檢查\h6.6本章小結(jié)\h第7章使用Ceph對象存儲\h7.1部署對象網(wǎng)關(guān)\h7.2通過S3接口使用對象存儲\h7.3本章小結(jié)\h第8章使用Ceph塊存儲\h8.1創(chuàng)建和刪除池\h8.2RBD設(shè)備的配置及使用\h8.3RBD快照\h8.4RBDImage克隆\h8.5RBDImage數(shù)據(jù)的導(dǎo)入/導(dǎo)出\h8.6本章小結(jié)\h第9章使用Ceph文件存儲\h9.1部署MDS\h9.2使用CephFS\h9.3CephFS擴(kuò)展屬性\h9.4本章小結(jié)\h第10章管理Ceph集群\h10.1Ceph的常用命令\h10.2配置CRUSHMap\h10.3添加磁盤\h10.4刪除磁盤\h10.5本章小結(jié)\h第11章Ceph容災(zāi)\h11.1對象存儲容災(zāi)\h11.1.1對象存儲容災(zāi)概述\h11.1.2Ceph對象網(wǎng)關(guān)多站點(diǎn)介紹\h11.1.3配置多站點(diǎn)對象網(wǎng)關(guān)實(shí)現(xiàn)容災(zāi)\h11.2RBD塊存儲容災(zāi)\h11.2.1數(shù)據(jù)復(fù)制方向\h11.2.2數(shù)據(jù)復(fù)制模式\h11.2.3配置RBDMirror\h11.3文件存儲容災(zāi)\h11.4本章小結(jié)\h第12章調(diào)優(yōu)方法\h12.1性能測試工具\(yùn)h12.2測試用例\h12.2.1RBD測試用例\h12.2.2網(wǎng)絡(luò)測試用例\h12.2.3對象存儲測試\h12.2.4RADOS測試用例\h12.3推薦的調(diào)優(yōu)方向\h12.3.1硬件調(diào)優(yōu)\h12.3.2網(wǎng)絡(luò)調(diào)優(yōu)\h12.3.3內(nèi)存調(diào)優(yōu)\h12.3.4Scrub\h12.3.5Ceph配置參數(shù)調(diào)優(yōu)\h12.4本章小結(jié)\h第13章故障定位方法\h13.1獲取集群狀態(tài)\h13.2診斷Monitor問題\h13.3診斷對象問題\h13.4數(shù)據(jù)平衡\h13.5重要文件目錄\h13.6使用Ceph集群的注意事項(xiàng)\h13.7本章小結(jié)\h第三部分Ceph應(yīng)用\h第14章搭建開源企業(yè)網(wǎng)盤\h14.1開源企業(yè)網(wǎng)盤ownCloud\h14.2開源企業(yè)網(wǎng)盤部署架構(gòu)\h14.2.1網(wǎng)盤架構(gòu)設(shè)計(jì)考慮因素\h14.2.2網(wǎng)盤架構(gòu)的軟硬件設(shè)計(jì)\h14.2.3部署架構(gòu)\h14.3ownCloud集成Ceph\h14.3.1集成前的準(zhǔn)備工作\h14.3.2集成Ceph\h14.4本章小結(jié)\h第15章Ceph集成OpenStack\h15.1OpenStack簡介\h15.1.1OpenStack與云計(jì)算\h15.1.2OpenStack組件簡介\h15.1.3OpenStack與Ceph集成\h15.2Ceph集成OpenStackGlance\h15.2.1OpenStackGlance簡介\h15.2.2配置CephRBD為鏡像服務(wù)的后端存儲\h15.3Ceph集成OpenStack\h15.3.1OpenStack塊存儲服務(wù)介紹\h15.3.2將Ceph存儲與塊存儲集成\h15.4使用CephRGW替換OpenStackSwift\h15.4.1OpenStackSwift簡介\h15.4.2用CephRGW替換OpenStackSwift的原理\h15.4.3替換OpenStackSwift\h15.5本章小結(jié)\h第16章Ceph集成OpenShift\h16.1OpenShift支持的存儲類型\h16.1.1OpenShift簡介\h16.1.2Kubernetes概述\h16.1.3OpenShift持久存儲概述\h16.1.4OpenShift支持的持久性存儲卷類型\h16.1.5容器存儲接口\h16.1.6OpenShift容器存儲簡介\h16.2OpenShift與Ceph集成\h16.2.1OpenShiftv3與CephRBD集成\h16.2.2Ceph-CSI簡介\h16.2.3OpenShiftv4與Ceph-CSI集成\h16.3以Rook方式實(shí)現(xiàn)OpenShift與Ceph集成\h16.3.1Rook簡介\h16.3.2部署Rook-Ceph\h16.3.3通過Rook使用Ceph存儲\h16.4本章小結(jié)第一部分Ceph原理在云計(jì)算大潮的推動(dòng)下，數(shù)據(jù)量開始激增。眾多企業(yè)在考慮系統(tǒng)容量、性能、擴(kuò)展性、成本等因素的同時(shí)，還要考慮滿足數(shù)字化轉(zhuǎn)型的要求，適配多種云平臺后端存儲使用場景，因此分布式存儲開始受到重視。Ceph在開源分布式存儲解決方案中占有非常重要的地位。企業(yè)如果將分布式存儲建設(shè)合理規(guī)劃，可以在存儲上節(jié)約很多成本，同時(shí)能提高數(shù)據(jù)的安全性，降低運(yùn)維的復(fù)雜度。本書的第一部分主要介紹Ceph的基本原理，為正在規(guī)劃Ceph的企業(yè)或愛好者提供理論依據(jù)。企業(yè)只有在了解Ceph的工作原理后，才能放心地采用這種技術(shù)，對使用過程中遇到的種種現(xiàn)象進(jìn)行合理判斷。第1章

Ceph概述分布式存儲方案有很多種，Ceph是其中一種。在開源社區(qū)的大力支持下，分布式存儲技術(shù)發(fā)展穩(wěn)健，引發(fā)全球企業(yè)用戶存儲方案的變革。但尚有大量企業(yè)用戶對分布式存儲不熟悉。如果采用分布式存儲，那么企業(yè)內(nèi)哪些類型的數(shù)據(jù)可以存儲到分布式系統(tǒng)上？Ceph在眾多分布式存儲解決方案中具有什么樣的地位？本章將為大家闡述這些問題。1.1軟件定義存儲本節(jié)主要介紹軟件定義存儲的基本概念、工作機(jī)制、采用軟件定義存儲后有哪些好處，以及相比于傳統(tǒng)存儲解決方案，軟件定義存儲具有的獨(dú)特優(yōu)勢。1.1.1基本概念介紹軟件定義存儲是指存儲軟件與硬件分開的存儲體系結(jié)構(gòu)。與傳統(tǒng)的NAS或SAN存儲系統(tǒng)不同，軟件定義存儲能在任何行業(yè)標(biāo)準(zhǔn)的x86架構(gòu)服務(wù)器上部署和運(yùn)行，消除了軟件對專有硬件的依賴。將存儲軟件與硬件解耦后，用戶可以根據(jù)需要擴(kuò)展存儲容量，不必費(fèi)力地添加其他專有硬件。另外，它還允許用戶在需要時(shí)升級或降級硬件。軟件定義存儲方案將給用戶在存儲方面帶來極大的靈活性。假設(shè)多個(gè)x86服務(wù)器有不同容量的存儲單元，且都需要借助不同種類的存儲軟件才能使用這些存儲單元，那么存儲和運(yùn)維管理將是一件非常痛苦的事情。而軟件定義存儲允許將這些硬件上的存儲單元重新規(guī)劃，并將其全部變成靈活且可擴(kuò)展的存儲單元。借助軟件定義存儲，我們幾乎可以隨時(shí)按需對存儲容量進(jìn)行調(diào)整，從而使成本效益達(dá)到最佳，同時(shí)提高存儲的靈活性和擴(kuò)展性。軟件定義存儲是超融合基礎(chǔ)架構(gòu)生態(tài)系統(tǒng)的一部分，即所有軟件與硬件解耦，可以讓你自由選擇要購買的硬件以及根據(jù)需求購買和規(guī)劃存儲容量。在大多數(shù)情況下，軟件定義存儲應(yīng)該具有以下特點(diǎn)?！ぷ詣?dòng)化：安裝部署、擴(kuò)容、運(yùn)維等全面自動(dòng)化，可降低成本。·標(biāo)準(zhǔn)接口：用于管理、維護(hù)存儲設(shè)備和服務(wù)的應(yīng)用程序編程接口。·寫入類型多樣：支持應(yīng)用程序通過塊、文件和對象接口寫入數(shù)據(jù)。·擴(kuò)展性：在不影響性能的情況下，可無限擴(kuò)展存儲容量。·透明性：軟件定義存儲中的軟件自身能夠監(jiān)控和管理存儲空間使用情況，同時(shí)讓用戶知道哪些資源可用，新數(shù)據(jù)如何放置，數(shù)據(jù)的完整性如何保證等。1.1.2軟件定義存儲工作機(jī)制傳統(tǒng)的存儲是一體化方案，將硬件（通常是行業(yè)專有硬件）和專有軟件捆綁銷售。軟件定義存儲的有用之處在于它不要求綁定任何特定的硬件，即采用通用的x86架構(gòu)服務(wù)器即可完成存儲軟件的安裝和運(yùn)行。通常來說，軟件定義存儲會將存儲操作的請求抽象化，而不是對實(shí)際存儲的內(nèi)容進(jìn)行抽象。它是物理存儲設(shè)備和數(shù)據(jù)請求之間的軟件層。你可以控制數(shù)據(jù)的存儲方式和位置。軟件定義存儲提供了存儲訪問服務(wù)、網(wǎng)絡(luò)服務(wù)和存儲單元連接服務(wù)。1.1.3軟件定義存儲的優(yōu)勢軟件定義存儲主要有以下6個(gè)優(yōu)勢。（1）避免技術(shù)鎖定通常情況下，我們選擇的存儲軟件不一定與出售硬件的公司是同一家，這些提供硬件的公司也不一定有軟件定義存儲軟件，即便有相關(guān)的軟件定義存儲方案也未必是最佳的方案。因此，你可以自由地選擇軟件定義存儲軟件方案，隨后使用商用的x86服務(wù)器來構(gòu)建基于軟件定義存儲的存儲集群，避免軟件或者硬件廠商的技術(shù)鎖定。（2）節(jié)省成本軟件定義存儲是分布式的，可以橫向擴(kuò)展（無限增加存儲節(jié)點(diǎn)），而不是縱向擴(kuò)展（在單一節(jié)點(diǎn)上添加存儲資源、CPU、內(nèi)存等），從而實(shí)現(xiàn)按需調(diào)整容量。（3）介質(zhì)多樣軟件定義存儲可以使用多種存儲介質(zhì)，比如SAS盤、SATA盤、SATASSD、NVMESSD、虛擬磁盤。以上存儲介質(zhì)可以構(gòu)建成統(tǒng)一的存儲資源池。（4）簡化運(yùn)維軟件定義存儲的存儲節(jié)點(diǎn)或者磁盤發(fā)生故障時(shí)，集群會自動(dòng)調(diào)整數(shù)據(jù)副本數(shù)量，保障數(shù)據(jù)安全，并在數(shù)據(jù)發(fā)生變化的時(shí)候，保證數(shù)據(jù)在各節(jié)點(diǎn)上均勻分布。軟件定義存儲提供了多種存儲對外接口，使得很多傳統(tǒng)的存儲使用場景中的數(shù)據(jù)可以集中到一個(gè)集群，以便統(tǒng)一管理，降低運(yùn)維多套存儲設(shè)備的復(fù)雜度，減輕運(yùn)維壓力。（5）擴(kuò)展性強(qiáng)軟件定義存儲基于x86架構(gòu)服務(wù)器，使用網(wǎng)絡(luò)協(xié)議構(gòu)建存儲集群。其特點(diǎn)是存儲節(jié)點(diǎn)可以動(dòng)態(tài)添加。當(dāng)容量不足的時(shí)候，其可以通過添加新的存儲節(jié)點(diǎn)實(shí)現(xiàn)橫向擴(kuò)容。理論上講，這意味著它可以無限擴(kuò)展，即容量無限。（6）云存儲在互聯(lián)網(wǎng)高速發(fā)展，公有云、私有云、混合云共生的前提下，多種云平臺的數(shù)據(jù)存儲形式開始向分布式存儲轉(zhuǎn)變。軟件定義存儲為云平臺后端存儲提供了無縫對接方案，滿足分布式存儲要求，同時(shí)兼顧性能和安全。1.2Ceph的發(fā)展史Ceph的發(fā)展史可以分為4個(gè)階段?！ぱ芯侩A段·孵化階段·商業(yè)化階段·成熟階段1.2.1研究階段Ceph最早是加州大學(xué)SantaCruz分校的一個(gè)研究項(xiàng)目，項(xiàng)目創(chuàng)始人SageWeil被譽(yù)為“Ceph之父”。Ceph最初的研究目標(biāo)是圍繞文件系統(tǒng)使用場景構(gòu)建一個(gè)可水平擴(kuò)展的基于對象的文件系統(tǒng)，用于數(shù)據(jù)中心高性能計(jì)算。最初，Ceph利用了幾種技術(shù)，包括EBOFS（針對對象工作負(fù)載的文件系統(tǒng)）、CRUSH算法、RADOS（為Ceph提供支持底層對象存儲的算法）等，并且這幾項(xiàng)技術(shù)的監(jiān)控部分在集群內(nèi)部實(shí)現(xiàn)，這樣做的主要目的是實(shí)現(xiàn)存儲智能化。存儲集群應(yīng)該是一個(gè)智能的存儲節(jié)點(diǎn)集群，而不是擁有大量“啞”磁盤的集群。要實(shí)現(xiàn)這樣有感知的集群，需要?jiǎng)?chuàng)建一個(gè)全新的架構(gòu)。當(dāng)然，在整個(gè)Ceph設(shè)計(jì)過程中，重點(diǎn)還是構(gòu)建一致的、可靠的存儲集群，沒有單點(diǎn)故障。該項(xiàng)目早期階段的名字叫Cephalopod（軟體動(dòng)物），后來演變成Ceph。它早期還有一個(gè)可愛的LOGO，如圖1-1所示。Sage在Ceph的研究工作接近尾聲時(shí)，開始與許多傳統(tǒng)存儲供應(yīng)商談?wù)揅eph及其在該項(xiàng)目中所做的工作，試圖謀求與企業(yè)的合作，但結(jié)果都不理想。他看了很多和他有類似處境的人的經(jīng)歷后發(fā)現(xiàn)，這些人要么被大公司聘請作為研究員而放棄了自己研發(fā)的項(xiàng)目，要么將自己研究的項(xiàng)目合并到企業(yè)的大型專有系統(tǒng)里。他意識到行業(yè)巨頭需要的是人，而不是你的項(xiàng)目。加上一些外部環(huán)境因素的限制，以及Ceph項(xiàng)目自身缺少某些關(guān)鍵的企業(yè)功能（快照、克隆、配額等），Sage決定采用一種新的方式去推廣Ceph。圖1-1Ceph早期LOGO他的想法是通過開放源代碼的方式改變Ceph，從而影響存儲界，進(jìn)而效仿Solaris、Ultrix、Irix等公司的發(fā)展模式。為了實(shí)現(xiàn)此目標(biāo)，他決定使用LGPLv2許可證。該許可證既具有靈活性，又具有可控性。另外，Ceph還規(guī)定任何個(gè)人貢獻(xiàn)的代碼都可作為自身的財(cái)產(chǎn)。Ceph項(xiàng)目于2006年正式開源，代碼存放在SourceForge中。1.2.2孵化階段Ceph早期項(xiàng)目完成后，Sage獲得了博士學(xué)位。隨后他回到洛杉磯，繼續(xù)在DreamHost公司（Sage是這家公司的聯(lián)合創(chuàng)始人）研發(fā)Ceph，并取得了如下成果?！ativeLinuxKernelClient（2007）·Per-directorySnapshots（2008）·RecursiveAccounting（2008）·ObjectClasses（2009）·Librados（2009）·RGW（2009）·StrongAuthentication（2009）·RBD（2010）在Ceph孵化階段的早期，Sage和他的團(tuán)隊(duì)意識到Linux本地客戶端的支持很重要。但當(dāng)時(shí)，該客戶端是基于用戶空間文件系統(tǒng)開發(fā)的，運(yùn)行速度慢。為了讓人們更重視Ceph，他們需要有一個(gè)可以與系統(tǒng)通信的本地高性能Linux客戶端。于是，Sage通過多方探索，開始開發(fā)Linux本地客戶端。當(dāng)他們將寫好的代碼提交到Linux內(nèi)核時(shí)，前兩次嘗試均失敗。Linus質(zhì)疑該客戶端的有用性，并認(rèn)為其功能不成熟。值得慶幸的是，后續(xù)一些社區(qū)開發(fā)人員發(fā)表了支持這項(xiàng)工作的言論。最終在2010年提交2萬行補(bǔ)丁后，AndrewMorton同意接納該Linux本地客戶端。Linus將其合并到Linux2.6.34內(nèi)核主線中。被Linux內(nèi)核接受這件事在Ceph的歷史上有著至關(guān)重要的作用，意味著它已經(jīng)成為更大的生態(tài)系統(tǒng)的一部分。這時(shí)，Sage意識到他們不需要把所有要做的技術(shù)都在Ceph內(nèi)實(shí)現(xiàn)，可以依靠其他項(xiàng)目來完成。這也是Sage拋棄EBOFS而使用其他文件系統(tǒng)的主要原因。Sage最初選擇了Btrfs（具有寫時(shí)復(fù)制、循環(huán)冗余校驗(yàn)等優(yōu)點(diǎn)），但最終證明它對于生產(chǎn)用例還不成熟，后來選擇了XFS和Ext4（這兩種文件系統(tǒng)成為生產(chǎn)部署時(shí)的主要選擇）。盡管Ceph已經(jīng)做了很多改變，也取得了很多成績，但是在實(shí)際使用中還是非常不穩(wěn)定。Ceph真正邁入商業(yè)化之路是在DreamHost決定使用Ceph構(gòu)建與S3兼容的對象存儲服務(wù)時(shí)。此時(shí)，Sage及其團(tuán)隊(duì)專注于提高穩(wěn)定性，并開始考慮諸如自動(dòng)化測試和代碼審查之類的事情。隨著項(xiàng)目的不斷成熟，其他公司開始對Ceph產(chǎn)生興趣。此時(shí)，Ceph也需要一個(gè)商業(yè)實(shí)體來資助工程繼續(xù)深入，以構(gòu)建和測試產(chǎn)品。2012年年初，Ceph從DreamHost剝離出來，轉(zhuǎn)入新的合資企業(yè)Inktank。1.2.3商業(yè)化階段Ceph轉(zhuǎn)入Inktank是令人振奮的，因?yàn)镮nktank團(tuán)隊(duì)中大多數(shù)人是開源的忠實(shí)擁護(hù)者。得益于DreamHost和MarkShuttleworth的早期投資，Inktank團(tuán)隊(duì)仔細(xì)分析了諸如RedHat、SUSE、Cloudera、MySQL、Canonical等公司的商業(yè)模式，找到了構(gòu)建一個(gè)開源公司和強(qiáng)大的社區(qū)的方法，最終制定了幾個(gè)明確的目標(biāo)，具體如下?！ら_發(fā)用于生產(chǎn)部署的穩(wěn)定版本?！ぶ贫◤V泛采用Ceph的措施（平臺支持文檔、構(gòu)建/測試基礎(chǔ)結(jié)構(gòu)）?！そN售和支持團(tuán)隊(duì)?！U(kuò)大工程實(shí)踐的組織。在此過程中，Inktank聘請了專業(yè)的代理機(jī)構(gòu)來為公司和項(xiàng)目創(chuàng)建清晰的品牌。公司和項(xiàng)目將作為獨(dú)立的品牌（Inktank與Ceph）發(fā)展，以促進(jìn)與社區(qū)融合，并為建立一個(gè)健康的生態(tài)系統(tǒng)制定了“存儲的未來”的發(fā)展愿景。經(jīng)過這些舉措后，Ceph實(shí)現(xiàn)了快速部署，甚至無法追蹤它的部署過程。Ceph歷史上的下一個(gè)主要轉(zhuǎn)折點(diǎn)是與OpenStack的集成。多平臺支持、滾動(dòng)升級和版本間互操作等功能使得Inktank將所有開發(fā)資源投入Ceph的對象和塊存儲部分，這主要是為了支持OpenStack等平臺的對象和塊存儲的使用。將精力投入到對象和塊存儲后，Ceph最初致力于研發(fā)的文件系統(tǒng)反倒不被平臺支持，最終成為Ceph最后支持的部分。隨著需求的增加，公司外部貢獻(xiàn)的代碼量增多，質(zhì)量也有了很大的提高。Ceph團(tuán)隊(duì)在社區(qū)中看到了高水平、非Inktank人員開發(fā)的代碼。如此巨大的外部貢獻(xiàn)使Ceph團(tuán)隊(duì)更加努力確保開發(fā)過程透明，這也促成了Ceph開發(fā)者峰會（CDS）的舉行。為了促進(jìn)開發(fā)模型真正開放，Ceph開發(fā)人員每個(gè)季度組織一次在線會議，討論即將在Ceph上開展的工作。有意愿為Ceph貢獻(xiàn)的社區(qū)成員被要求填寫一份簡短的目標(biāo)書。每個(gè)目標(biāo)都會在CDS會議上討論。貢獻(xiàn)者可以與Sage及整個(gè)社區(qū)的人員討論，使團(tuán)隊(duì)可以為此目標(biāo)確定責(zé)任人。第一次CDS于2013年春季舉辦，之后每個(gè)季度舉辦一次。在開發(fā)的同時(shí)，Inktank銷售團(tuán)隊(duì)以驚人的速度獲得客戶，而管理團(tuán)隊(duì)積極尋求另一輪融資。Inktank創(chuàng)立了InktankCephEnterprise版本，其中包括一個(gè)名為Calamari的專有儀表板。該儀表板使企業(yè)用戶可以快速、輕松地監(jiān)控Ceph的部署。融資即將結(jié)束時(shí)，RedHat向Inktank倡導(dǎo)開放源代碼的管理文化，受到很多Inktank內(nèi)部人員的支持。1.2.4成熟階段美國東部時(shí)間2014年4月30日早上8:00，RedHat官網(wǎng)消息稱，RedHat以1.75億美元收購Inktank公司。Inktank的主要產(chǎn)品是軟件定義存儲的Ceph解決方案。至此，Ceph開始有了正規(guī)、強(qiáng)大的開源企業(yè)文化和支持。如圖1-2所示，你可以清晰地了解Ceph發(fā)展過程中的里程碑。圖1-2Ceph的發(fā)展里程碑因?yàn)镽edHat是純開源模式運(yùn)營，所以Calamari也在Ceph中自然而然地開放源代碼，這對Ceph社區(qū)的發(fā)展具有重要的推動(dòng)作用。RedHat的收購使Ceph的發(fā)展和社區(qū)互動(dòng)更加緊密。在RedHat巨大的生態(tài)系統(tǒng)下，Ceph的產(chǎn)品功能和穩(wěn)定度不斷完善，在全球的推廣更加廣泛，生態(tài)系統(tǒng)的集成認(rèn)證更加豐富，服務(wù)的企業(yè)和個(gè)人都在不斷增加。1.3Ceph的市場分析企業(yè)在引入新技術(shù)的同時(shí)，面臨存儲選擇問題。而且隨著非結(jié)構(gòu)化數(shù)據(jù)類型逐漸增多，存儲的形態(tài)從傳統(tǒng)存儲開始向分布式存儲轉(zhuǎn)變，未來對分布式存儲的需求將越來越大。本節(jié)主要介紹存儲市場的變化趨勢，洞見存儲的發(fā)展趨勢。1.3.1存儲形態(tài)的轉(zhuǎn)型存儲未來的發(fā)展方向是軟件定義存儲。市場正在從傳統(tǒng)的專有存儲產(chǎn)品轉(zhuǎn)向軟件定義存儲的產(chǎn)品，如圖1-3所示。在這些產(chǎn)品中，存儲服務(wù)獨(dú)立于硬件，并且基于開源軟件技術(shù)實(shí)現(xiàn)。其關(guān)鍵價(jià)值在于，你不需要重構(gòu)數(shù)據(jù)中心的基礎(chǔ)架構(gòu)，只需在現(xiàn)有條件下做很小的調(diào)整，即可將軟件定義存儲解決方案落地。這樣既保留了現(xiàn)有存儲服務(wù)器采購的方式，又提高了采購服務(wù)器和硬件的靈活性。如果部署專有存儲，無論是硬件還是軟件都將被某供應(yīng)商鎖定。這就是開源軟件能解決供應(yīng)商鎖定的原因。軟件定義存儲方案的軟件實(shí)現(xiàn)技術(shù)方式一定是開源（開放源代碼），這樣才能徹底挖掘出軟件定義存儲的真正潛力。圖1-3存儲形態(tài)的轉(zhuǎn)變圖1-3左側(cè)是傳統(tǒng)存儲的組織形式，其中存儲服務(wù)依賴底層專有軟硬件。存儲管理員在使用過程中會進(jìn)行管控，即用戶需要的時(shí)候提出申請，管理員負(fù)責(zé)創(chuàng)建并提供必要的存儲資源。其特點(diǎn)是使用效率和維護(hù)成本較高。右側(cè)軟件定義存儲的實(shí)現(xiàn)方式是控制平面和數(shù)據(jù)平面完全分開?？刂破矫嫣峁┓?wù)的抽象層，通過API訪問存儲層提供的基礎(chǔ)功能。這意味著不再需要管理員手動(dòng)設(shè)置最終用戶對所需存儲的使用形態(tài)。軟件定義存儲自身提供了豐富的使用接口。同時(shí)，由于底層硬件不需要依賴專有硬件設(shè)備，因此數(shù)據(jù)中心采購存儲服務(wù)器的靈活度大大增加，在標(biāo)準(zhǔn)x86架構(gòu)服務(wù)器供應(yīng)商中的選擇空間更大，議價(jià)空間也更大。而軟件定義存儲采用開源方案實(shí)現(xiàn)，這使得軟件服務(wù)層也消除了廠商鎖定的可能。1.3.2存儲形態(tài)演變的特點(diǎn)2016年，存儲形態(tài)有了根本轉(zhuǎn)變——專有硬件轉(zhuǎn)變?yōu)闃?biāo)準(zhǔn)的硬件。標(biāo)準(zhǔn)的硬件具有更高的互操作性，價(jià)格更低，并且有更廣泛的供應(yīng)鏈、更多的廠商設(shè)備。通過開源技術(shù)，廠商有機(jī)會將低成本、標(biāo)準(zhǔn)化、擴(kuò)展方便、可編程和靈活控制等特點(diǎn)融合在一起提供存儲服務(wù)。與此同時(shí)，軟件定義存儲正在從封閉的開發(fā)流程向開放的開發(fā)流程轉(zhuǎn)變，實(shí)現(xiàn)了更廣闊的生態(tài)系統(tǒng)，并為越來越多的創(chuàng)業(yè)公司提供技術(shù)基礎(chǔ)。軟件定義存儲主要給兩種類型的用戶（最終用戶、創(chuàng)業(yè)公司）帶來好處。（1）最終用戶用戶可以有更多選擇——從專有硬件向通用硬件的轉(zhuǎn)變，使得其硬件選擇更加靈活、廣泛。擴(kuò)展性由傳統(tǒng)的縱向擴(kuò)展向橫向擴(kuò)展轉(zhuǎn)變，存儲資源池的理論存儲容量無上限，同時(shí)對于按需規(guī)劃存儲和兼顧容量成本有很好地平衡。（2）創(chuàng)業(yè)公司因?yàn)橛虚_源項(xiàng)目在支撐，創(chuàng)業(yè)公司可在開源軟件基礎(chǔ)上進(jìn)行二次開發(fā)，且知識產(chǎn)權(quán)將歸自己所有。傳統(tǒng)的存儲設(shè)備需要專有軟硬件。如果公司要提供這類存儲，將面臨更多的開發(fā)和更高的技能要求。而有了軟件定義存儲，這類公司可將更多的精力放在軟件的完善上，大大縮短構(gòu)建自己的軟件定義存儲產(chǎn)品的時(shí)間，將存儲方案很快推向市場。與此同時(shí)，企業(yè)在開發(fā)自己的軟件定義存儲產(chǎn)品時(shí)，可以很好地和開源社區(qū)互通，將開發(fā)模式從封閉式開發(fā)轉(zhuǎn)為開放式互動(dòng)開發(fā)，提高代碼質(zhì)量。1.3.3軟件定義存儲的市場分析在塊、文件、對象和超融合存儲環(huán)境中，軟件定義存儲的市場份額每年以20%的速度持續(xù)增長。借助標(biāo)準(zhǔn)服務(wù)器和磁盤選件，存儲硬件成本正在下降，并且大多數(shù)非結(jié)構(gòu)化數(shù)據(jù)存放在軟件定義存儲中。據(jù)IDC的451份企業(yè)調(diào)查，已經(jīng)有54%的公司將數(shù)據(jù)遷移到軟件定義存儲產(chǎn)品中。2018年北美的一份調(diào)查報(bào)告顯示，非結(jié)構(gòu)化數(shù)據(jù)正在以每年23%的速率增加。AI/ML/HPC等技術(shù)的出現(xiàn)使得應(yīng)用此類技術(shù)的企業(yè)也迅速增多。同樣是2018年，北美的一份報(bào)告顯示，采用AI的企業(yè)以每年25%的規(guī)模增加。而在高性能計(jì)算市場中，有更多的企業(yè)正在加入。另一份IoT報(bào)告顯示，到2025年將有數(shù)十億的IoT設(shè)備產(chǎn)生數(shù)據(jù)，后端存儲數(shù)據(jù)將如海嘯般增加。此類數(shù)據(jù)如何存儲是企業(yè)降本增效的關(guān)鍵。2018年和2019年Ceph官方的用戶調(diào)查報(bào)告顯示，Ceph市場還有很大發(fā)展空間。這意味著，亞太地區(qū)的用戶對Ceph的采納程度沒有歐洲快。如圖1-4所示，你可以簡單了解Ceph技術(shù)被采納的全球分布情況。圖1-4Ceph技術(shù)被采納的全球分布情況1.4Ceph的適用場景Ceph是一種開源、高可擴(kuò)展、部署在通用架構(gòu)服務(wù)器的軟件定義存儲產(chǎn)品。其設(shè)計(jì)思路是將通用的服務(wù)器和硬盤設(shè)備通過網(wǎng)絡(luò)協(xié)議進(jìn)行集群組建，構(gòu)建成一套存儲集群，對外提供多種訪問接口，實(shí)現(xiàn)滿足多種使用場景的分布式存儲。設(shè)計(jì)原理決定其對網(wǎng)絡(luò)和硬件設(shè)備的依賴較為明顯，因此投產(chǎn)Ceph的環(huán)境必須使用萬兆網(wǎng)絡(luò)，同時(shí)配置SSD硬盤設(shè)備對集群進(jìn)行寫加速。另外，Ceph存儲數(shù)據(jù)是按照2MB為基本單位進(jìn)行讀寫的，即便是小文件也要按照此種方式進(jìn)行操作。寫入時(shí)要組成2MB的塊一次性寫入，讀取時(shí)一次性讀取2MB的塊。如果用戶數(shù)據(jù)為字節(jié)級別，頻繁讀寫將對Ceph的性能產(chǎn)生沖擊。因此，在設(shè)計(jì)原理的限制下，你在投產(chǎn)Ceph時(shí)必須要考慮清楚其使用場景。如果不滿足Ceph的使用場景，此類數(shù)據(jù)建議不要放入Ceph中。目前，推薦使用Ceph的場景如圖1-5所示，主要分為5大類：數(shù)據(jù)分析、云計(jì)算平臺、富媒體和歸檔、企業(yè)文件同步和共享、服務(wù)器和應(yīng)用程序。這5類場景特點(diǎn)主要體現(xiàn)在數(shù)據(jù)海量，對數(shù)據(jù)讀寫性能要求不苛刻，而對計(jì)算水平要求較高。圖1-5Ceph的主要適用場景1.4.1分析類應(yīng)用場景舉例由于大數(shù)據(jù)分析中捕獲的數(shù)據(jù)量巨大，并且需要在數(shù)據(jù)專家和數(shù)據(jù)分析師團(tuán)隊(duì)之間共享有限的資源，因此傳統(tǒng)的數(shù)據(jù)分析基礎(chǔ)架構(gòu)承受著巨大的壓力。各方呼吁推出一種全新的架構(gòu)和存儲形態(tài)。一些數(shù)據(jù)平臺團(tuán)隊(duì)正在將ApacheHadoop和Spark大數(shù)據(jù)分析平臺作為其數(shù)據(jù)分析的主要工具，后端采用Hadoop分布式文件系統(tǒng)（HDFS）集群。不幸的是，由于HDFS通常不會在不同集群之間共享數(shù)據(jù)，因此在大型計(jì)算集群中的每個(gè)集群間復(fù)制數(shù)據(jù)會付出很高的代價(jià)。一些團(tuán)隊(duì)希望其集群的分析工具盡量穩(wěn)定，因此不愿意更新版本，而其數(shù)據(jù)分析的業(yè)務(wù)單元需要加載最新的分析工具版本。最終，這些團(tuán)隊(duì)都構(gòu)建了自己單獨(dú)的、量身定制的分析集群，以免與其他團(tuán)隊(duì)競爭資源。使用傳統(tǒng)的Hadoop時(shí)，每個(gè)單獨(dú)的分析集群通常都有自己專用的HDFS數(shù)據(jù)包。為了在不同的Hadoop/HDFS集群中能訪問相同的數(shù)據(jù)，平臺團(tuán)隊(duì)必須在集群之間復(fù)制非常大的數(shù)據(jù)集，以保持?jǐn)?shù)據(jù)的一致性和時(shí)效性。因此，公司維護(hù)了許多單獨(dú)的固定分析集群（其中一家公司中有50多個(gè)集群）。每個(gè)集群在HDFS中都有自己的冗余數(shù)據(jù)副本。就資本支出（Capex）和運(yùn)營支出（Opex）而言，在各個(gè)集群上維護(hù)5PB、10PB或20PB副本數(shù)據(jù)的成本都非常高。Ceph和IaaS云、PaaS云的結(jié)合為解決上述一系列問題提供了新的方案。Ceph在底層多集群間可以實(shí)現(xiàn)數(shù)據(jù)自動(dòng)同步，這大大降低了集群數(shù)據(jù)復(fù)制的開銷和運(yùn)營成本，為Hadoop或Spark的大數(shù)據(jù)分析工具提供了另一種分布式存儲選擇。1.4.2IaaS云平臺應(yīng)用場景舉例Openstack作為開源IaaS云平臺的典型代表，已經(jīng)經(jīng)過全球眾多企業(yè)實(shí)踐檢驗(yàn)。其可靠性和擴(kuò)展性為企業(yè)帶來了良好的使用體驗(yàn)。其自身眾多模塊化的組件都需要外部存儲提供支持，保證平臺功能的正常發(fā)揮。Ceph作為OpenStack云原生的后端存儲已經(jīng)在業(yè)界成為標(biāo)準(zhǔn)。OpenStack中的多種模塊使用了不同的存儲接口，其中Ceph提供的三種存儲接口在OpenStack中都可以無縫對接，如圖1-6所示。OpenStack的不同模塊調(diào)用Ceph的不同接口實(shí)現(xiàn)雙方的集成應(yīng)用。圖1-6OpenStack使用Ceph的幾種接口如圖1-7所示，OpenStack2017的后端存儲統(tǒng)計(jì)顯示CephRBD排名第一，遠(yuǎn)超其他存儲。圖1-7OpenStack的后端存儲使用比例1.4.3富媒體和歸檔應(yīng)用場景舉例中國銀監(jiān)會、證監(jiān)會、保監(jiān)會發(fā)出行業(yè)規(guī)范，要求逐步實(shí)施金融類產(chǎn)品在銷售過程中錄音和錄像（簡稱“雙錄”）同步，加強(qiáng)金融類產(chǎn)品的全過程風(fēng)險(xiǎn)管理。因此，錄音和錄像等大文件的存儲發(fā)生了新的變化。此部分?jǐn)?shù)據(jù)的使用率較低，但是需要在線查看，因此容量大、低成本、安全、可靠成為存儲的新要求。傳統(tǒng)制造業(yè)面臨同樣的需求。公司內(nèi)部的研發(fā)數(shù)據(jù)、掃描單據(jù)、文檔等都需要?dú)w檔備份。不論哪個(gè)場景，此類數(shù)據(jù)的共同特點(diǎn)是要求存儲容量大、安全、可靠。很多企業(yè)在考慮使用基于網(wǎng)絡(luò)的備份解決方案（NBU），支持所有完善的操作系統(tǒng)（例如Linux、UNIX、Windows、macOSX）可以備份到磁盤、磁帶驅(qū)動(dòng)器以及磁帶庫。除了完整、增量和差異備份等常見備份策略外，企業(yè)還要求解決方案有遷移、副本、去重等功能。而基于網(wǎng)絡(luò)的備份解決方案提供的備份機(jī)制和策略很難完全滿足要求，因此數(shù)據(jù)需要存放在更加靈活、安全、可靠的分布式存儲系統(tǒng)中。Ceph成為這類網(wǎng)絡(luò)備份的首選后端存儲方案。較為典型的開源備份軟件有Bareos、Bacula、Amanda等。Ceph提供了與這類備份軟件的集成方案，可以將備份直接寫入后端，傳輸過程中對數(shù)據(jù)進(jìn)行加密，因此很安全。企業(yè)通過這類開源備份軟件自我備份，可以在發(fā)生災(zāi)難時(shí)迅速恢復(fù)數(shù)據(jù)運(yùn)行。如圖1-8所示，Ceph集成Bareos/Bacula/Amanda備份軟件，可以實(shí)現(xiàn)應(yīng)用數(shù)據(jù)文件的備份。從圖1-8中可以清晰地看出，數(shù)據(jù)中心現(xiàn)有的應(yīng)用程序或客戶端產(chǎn)生的數(shù)據(jù)不論存放在Ceph集群還是傳統(tǒng)存儲中，你都可以搭建開源備份軟件對數(shù)據(jù)進(jìn)行備份和歸檔。而如果采用Ceph，你就采用了分布式技術(shù)，也就意味著數(shù)據(jù)存放在更加安全的存儲資源池中，使未來存儲擴(kuò)容更加便捷。同時(shí)，Ceph底層技術(shù)提供數(shù)據(jù)容災(zāi)，從某種意義上講對備份方案是一種補(bǔ)充，提高了備份歸檔方案的靈活性。圖1-8數(shù)據(jù)備份架構(gòu)1.4.4企業(yè)文件同步和共享應(yīng)用場景舉例隨著企業(yè)業(yè)務(wù)的不斷發(fā)展，協(xié)同辦公需求變得更為常見。如何保證數(shù)據(jù)中心的業(yè)務(wù)數(shù)據(jù)能實(shí)時(shí)共享及集中管理，是企業(yè)IT團(tuán)隊(duì)要考慮的。企業(yè)云盤成為此種需求較為常用的解決方案。企業(yè)云盤的核心價(jià)值在于將數(shù)據(jù)保存在公司內(nèi)部，提供了多種用戶訪問接口，便于數(shù)據(jù)共享，保證了數(shù)據(jù)安全。開源企業(yè)云盤有很多，使用較為廣泛且全球認(rèn)可度較高的軟件包括ownCloud和Seafile等。開源企業(yè)云盤在數(shù)據(jù)中心提供數(shù)據(jù)訪問接口，因此保證通過云盤存入的數(shù)據(jù)安全和云盤可擴(kuò)展性非常重要。Ceph提供的塊存儲、文件存儲、對象存儲接口可與現(xiàn)有的開源云盤軟件完美對接。這樣，存儲空間的擴(kuò)展、數(shù)據(jù)的安全和容災(zāi)由Ceph負(fù)責(zé)，使云盤軟件在企業(yè)中落地的方案完整度更佳。1.4.5服務(wù)器和應(yīng)用程序存儲場景舉例在使用服務(wù)器時(shí)，你經(jīng)常遇到磁盤空間不足，需要擴(kuò)容或者添加新磁盤的情況。如果是在服務(wù)器（裸機(jī)或VM）上的Linux系統(tǒng)中添加磁盤，需要通過網(wǎng)絡(luò)將磁盤映射到本地，以便新設(shè)備對其進(jìn)行分區(qū)格式化處理。Ceph提供的RBD塊存儲映射到服務(wù)器后，在服務(wù)器后端即可看到/dev/目錄下生成了新的RBD設(shè)備。對這個(gè)設(shè)備的所有操作都將寫入Ceph集群。另一種場景是Linux服務(wù)器上的某個(gè)目錄空間不足，不需要新增磁盤，只需要將CephFS文件系統(tǒng)掛載到該目錄下，將原有數(shù)據(jù)重新映射進(jìn)來，即可使用CephFS提供的存儲空間。此目錄下所有的數(shù)據(jù)都將落入服務(wù)器外部的Ceph集群。這樣，服務(wù)器目錄的擴(kuò)展問題通過Ceph提供的存儲空間得到了有效解決。如圖1-9所示，服務(wù)器以添加CephRBD的方式增加服務(wù)器系統(tǒng)上的塊設(shè)備。圖1-9Ceph塊存儲應(yīng)用對于企業(yè)應(yīng)用產(chǎn)生的數(shù)據(jù)，你可以直接在應(yīng)用程序中將數(shù)據(jù)或者日志寫入后端存儲。實(shí)現(xiàn)方法是調(diào)用Ceph的對象存儲S3兼容接口，將應(yīng)用數(shù)據(jù)直接寫入Ceph的S3URL地址，這樣數(shù)據(jù)可通過Ceph對象網(wǎng)關(guān)寫入Ceph集群，實(shí)現(xiàn)數(shù)據(jù)共享。圖1-10給出了應(yīng)用程序集成Ceph示意圖。圖1-10應(yīng)用程序集成Ceph示意圖1.5軟件定義存儲的商業(yè)產(chǎn)品你在選擇軟件定義存儲產(chǎn)品的時(shí)候，可以綜合考慮開源程度、社區(qū)活躍度、全球使用基礎(chǔ)、公司規(guī)模和發(fā)展?fàn)顩r等因素。國外一家企業(yè)級技術(shù)產(chǎn)品審查網(wǎng)站（ITCentralStation）顯示的2019年全球提供軟件定義存儲的廠商及其產(chǎn)品如表1-1所示。（表中的企業(yè)及其相應(yīng)軟件定義存儲產(chǎn)品按名稱順序排列，其先后順序不代表產(chǎn)品的全球占有率或者排名。）個(gè)人認(rèn)為此表僅代表大部分企業(yè)的軟件定義存儲產(chǎn)品，比如中國的很多公司的軟件定義存儲產(chǎn)品不在其中。雖然中國企業(yè)的軟件定義存儲產(chǎn)品在全球占有率低，影響也相對較小，但本地化產(chǎn)品有其獨(dú)特優(yōu)勢。表1-1提供商用軟件定義存儲的企業(yè)及其產(chǎn)品對于表1-1中提及的產(chǎn)品，海外某組織根據(jù)全球用戶的關(guān)注程度設(shè)計(jì)了相應(yīng)算法，得出了平均評分。其中，前十名產(chǎn)品如圖1-11所示。除了平均分這項(xiàng)衡量指標(biāo)外，你可以看到有三家企業(yè)的產(chǎn)品關(guān)注度在10000+，分別是RedHatCephStorage、NutanixAcropolis、ScaleIO。由圖1-11可見，作為開源產(chǎn)品，Ceph在企業(yè)中落地有更大的潛在機(jī)會。圖1-11關(guān)注度排名前十的分布式存儲產(chǎn)品1.6本章小結(jié)本章主要介紹了Ceph的相關(guān)定義、發(fā)展歷史、使用場景和分布式存儲相關(guān)商業(yè)軟件等。如果你在選型分布式存儲的相關(guān)企業(yè)級產(chǎn)品，可以從本章獲取到主流的企業(yè)產(chǎn)品，從而進(jìn)行評估實(shí)踐。如果你在企業(yè)中謀求分布式存儲的使用場景，本章也給出了幾種典型的使用場景，請?jiān)谝?guī)劃分布式存儲前，仔細(xì)研究，從而更好地在成本、容量、性能之間做好平衡，更好地服務(wù)于企業(yè)生產(chǎn)實(shí)踐。通過本章內(nèi)容，你可能想到Ceph有這么多優(yōu)點(diǎn)，那它究竟是如何實(shí)現(xiàn)的，如果構(gòu)建這樣的存儲集群有哪些因素要考慮，具體的工作原理如何。你將從第2章中獲取答案。第2章

Ceph架構(gòu)分析Ceph存儲集群是一種分布式對象存儲，旨在提供出色的性能、可靠性和擴(kuò)展性。分布式存儲是存儲的未來，因?yàn)樗钸m合非結(jié)構(gòu)化數(shù)據(jù)的存儲，并且提供了多種客戶端訪問接口。Ceph集群具有超高的可擴(kuò)展性，支持PB到EB級甚至更大的容量。本章主要介紹Ceph集群架構(gòu)、各功能節(jié)點(diǎn)的作用以及關(guān)鍵技術(shù)的實(shí)現(xiàn)原理。2.1Ceph集群的組成架構(gòu)Ceph集群服務(wù)端主要有3種類型的守護(hù)進(jìn)程，每種類型的守護(hù)進(jìn)程最后都被規(guī)劃到特定服務(wù)器節(jié)點(diǎn)上。下面對這3種類型的守護(hù)進(jìn)程進(jìn)行簡單描述。1）CephOSD：利用Ceph節(jié)點(diǎn)上的CPU、內(nèi)存和網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)復(fù)制、糾錯(cuò)、重新平衡、恢復(fù)、監(jiān)控和報(bào)告等。2）CephMonitor：維護(hù)Ceph集群的主副本映射、Ceph集群的當(dāng)前狀態(tài)以及處理各種與運(yùn)行控制相關(guān)的工作。3）CephManager：維護(hù)PlacementGroup（放置組）有關(guān)的詳細(xì)信息，代替CephMonitor處理元數(shù)據(jù)和主機(jī)元數(shù)據(jù)，能顯著改善大規(guī)模集群的訪問性能。CephManager處理許多只讀CephCLI的查詢請求，例如放置組統(tǒng)計(jì)信息。CephManager還提供了RESTfulAPI。Ceph客戶端接口負(fù)責(zé)和Ceph集群進(jìn)行數(shù)據(jù)交互，包括數(shù)據(jù)的讀寫?？蛻舳诵枰韵聰?shù)據(jù)才能與Ceph集群進(jìn)行通信?！eph配置文件或集群的名稱（通常命名為ceph）、Monitor地址·存儲池名稱·用戶名和密鑰路徑Ceph客戶端維護(hù)對象ID和存儲對象的存儲池名稱。為了存儲和檢索數(shù)據(jù)，Ceph客戶端訪問CephMonitor并檢索最新的ClusterMap副本，然后由Ceph客戶端向Librados提供對象名稱和存儲池名稱。Librados會使用CRUSH算法為要存儲和檢索的數(shù)據(jù)計(jì)算對象的放置組和主OSD?？蛻舳诉B接到主OSD，并在其中執(zhí)行讀取和寫入操作。圖2-1展示了Ceph集群的組成架構(gòu)。它包含構(gòu)建一個(gè)Ceph集群所需的必要功能節(jié)點(diǎn)以及網(wǎng)絡(luò)關(guān)聯(lián)關(guān)系，只有少部分集群的網(wǎng)關(guān)節(jié)點(diǎn)未在圖中顯示。圖2-1Ceph集群的組成架構(gòu)圖2-1中有兩個(gè)重要的關(guān)注點(diǎn)。（1）網(wǎng)絡(luò)這里有兩個(gè)萬兆網(wǎng)絡(luò)，集群對外通信網(wǎng)絡(luò)和集群內(nèi)部通信網(wǎng)絡(luò)。我們也可以在該網(wǎng)絡(luò)中增加一個(gè)管理網(wǎng)絡(luò)，但由于管理數(shù)據(jù)的流量很小，可將管理網(wǎng)絡(luò)和公網(wǎng)網(wǎng)絡(luò)合并。由于Ceph集群最初的設(shè)計(jì)是為了提高集群的性能，并且考慮到集群網(wǎng)絡(luò)的帶寬要求，因此將集群內(nèi)部流量與客戶端到集群流量進(jìn)行隔離，從而設(shè)計(jì)了兩層網(wǎng)絡(luò)。在較小的集群上，1G網(wǎng)絡(luò)可能適用于正常操作環(huán)境，但不適用于繁重的負(fù)載或故障恢復(fù)環(huán)境。如果驅(qū)動(dòng)器發(fā)生故障，則跨1G網(wǎng)絡(luò)復(fù)制1TB數(shù)據(jù)需要3小時(shí)。這對于集群的使用體驗(yàn)來說是不能接受的。而對于10G網(wǎng)絡(luò)，復(fù)制同樣的數(shù)據(jù)時(shí)間則在20分鐘內(nèi)。這也是生產(chǎn)環(huán)境中一定要使用萬兆網(wǎng)絡(luò)，甚至服務(wù)器綁定多萬兆網(wǎng)卡的原因。（2）服務(wù)器這里面的服務(wù)器分了幾種角色，每種角色都對應(yīng)集群的一類功能，主要包括MON（Ceph集群的Monitor節(jié)點(diǎn)）、OSD（Ceph集群的存儲節(jié)點(diǎn)）、MGR（Ceph集群的管理節(jié)點(diǎn)）、RGW（Ceph集群的對象網(wǎng)關(guān)節(jié)點(diǎn)）、MDS（CephFS元數(shù)據(jù)節(jié)點(diǎn)）、iSCSI網(wǎng)關(guān)、NFS集群網(wǎng)關(guān)和Ceph客戶端。接下來，我們對集群中涉及的主要服務(wù)器角色進(jìn)行逐一分析，闡述其具體功能。2.2Monitor節(jié)點(diǎn)分析每個(gè)Monitor節(jié)點(diǎn)上都在運(yùn)行守護(hù)進(jìn)程（ceph-mon）。該守護(hù)進(jìn)程可維護(hù)集群映射的主副本，包括集群拓?fù)鋱D。這意味著Ceph客戶端只需連接到一個(gè)Monitor節(jié)點(diǎn)并檢索當(dāng)前的集群映射，即可確定所有Monitor和OSD節(jié)點(diǎn)的位置。Ceph客戶端讀寫OSD節(jié)點(diǎn)之前，必須先連接到Monitor節(jié)點(diǎn)。借助集群映射的當(dāng)前副本和CRUSH算法，Ceph客戶端可以計(jì)算任何對象的位置。這是Ceph具有高擴(kuò)展性和高性能的一個(gè)非常重要的因素。CephMonitor的主要作用是維護(hù)集群的數(shù)據(jù)主副本映射關(guān)系。同時(shí)，它為每個(gè)組件維護(hù)一個(gè)單獨(dú)的信息圖，包括OSDMap、MONMap、MDSMap、PGMap和CRUSHMap等。所有集群節(jié)點(diǎn)均向Monitor節(jié)點(diǎn)報(bào)告，并共享有關(guān)其狀態(tài)的每個(gè)更改信息。Monitor不存儲實(shí)際數(shù)據(jù)。存儲數(shù)據(jù)是OSD的工作。CephMonitor還提供身份驗(yàn)證和日志服務(wù)。Monitor將監(jiān)控服務(wù)中的所有更改信息寫入單個(gè)Paxos，并且Paxos更改寫入的K/V存儲，以實(shí)現(xiàn)強(qiáng)一致性。CephMonitor使用K/V存儲的快照和迭代器（LevelDB數(shù)據(jù)庫）來執(zhí)行整個(gè)存儲的同步。換句話說，Paxos是CephMonitor的核心服務(wù)，專門負(fù)責(zé)數(shù)據(jù)一致性工作。Paxos服務(wù)解決的問題正是分布式一致性問題，即一個(gè)分布式系統(tǒng)中的各個(gè)進(jìn)程如何就某個(gè)值（決議）達(dá)成一致。Paxos服務(wù)運(yùn)行在允許有服務(wù)器宕機(jī)的系統(tǒng)中，不要求可靠的消息傳遞，可容忍消息丟失、延遲、亂序和重復(fù)。它利用大多數(shù)（Majority）機(jī)制保證了2N+1的容錯(cuò)能力，即2N+1個(gè)節(jié)點(diǎn)的系統(tǒng)最多允許N個(gè)節(jié)點(diǎn)同時(shí)出現(xiàn)故障。如圖2-2所示，CephMonitor中包含分別負(fù)責(zé)OSDMap、MonitorMap、PGMap、CRUSHMap等的Paxos服務(wù)。Paxos服務(wù)負(fù)責(zé)將自己對應(yīng)的數(shù)據(jù)序列化為K/V并寫入Paxos層。Ceph集群中所有與Monitor節(jié)點(diǎn)的交互最終都是在調(diào)用對應(yīng)的Paxos服務(wù)功能，多種Paxos服務(wù)將不同組件的Map數(shù)據(jù)序列化為K/V，共用同一個(gè)Paxos實(shí)例。對于Paxos的原理，這里不做過多介紹。圖2-2Monitor中的數(shù)據(jù)一致性保證機(jī)制2.2.1CephClusterMapClusterMap是許多Ceph組件的組合，包括MonitorMap、OSDMap和PGMap。ClusterMap跟蹤許多重要事件，具體如下?！eph集群中有哪些進(jìn)程狀態(tài)為In?！eph集群中的哪些進(jìn)程已啟動(dòng)、正在運(yùn)行或已關(guān)閉?！し胖媒M是處于活動(dòng)狀態(tài)、非活動(dòng)狀態(tài)、清潔狀態(tài)還是其他某種狀態(tài)?！ぜ寒?dāng)前狀態(tài)的其他詳細(xì)信息，例如總存儲空間或已使用的存儲量。當(dāng)集群狀態(tài)發(fā)生重大變化時(shí)，比如CephOSD掉線、放置組進(jìn)入降級狀態(tài)等。ClusterMap會更新，以反映集群的當(dāng)前狀態(tài)。此外，CephMonitor還維護(hù)集群的歷史狀態(tài)記錄。MonitorMap、OSDMap和PGMap均保留其映射版本的歷史記錄。每個(gè)版本稱為Epoch。在操作Ceph集群時(shí)，跟蹤這些狀態(tài)是集群管理的重要工作。2.2.2CephMonitor的Quorum機(jī)制單Monitor節(jié)點(diǎn)能保證集群的功能完整運(yùn)行，但是存在單點(diǎn)故障風(fēng)險(xiǎn)。為了確保生產(chǎn)環(huán)境下Ceph存儲集群的高可用性，一定要采用多個(gè)Monitor節(jié)點(diǎn)來運(yùn)行Ceph，這樣即便單個(gè)Monitor節(jié)點(diǎn)發(fā)生故障，也不會導(dǎo)致整個(gè)存儲集群故障。當(dāng)一個(gè)Ceph存儲集群運(yùn)行多個(gè)Monitor以實(shí)現(xiàn)高可用性時(shí)，Monitor使用Paxos算法來保證分布式數(shù)據(jù)一致。ClusterMap一致性的保證需要集群的大多數(shù)Monitor存活，以建立仲裁集。例如3個(gè)Monitor中有2個(gè)存活，5個(gè)Monitor中有3個(gè)存活，6個(gè)Monitor中有4個(gè)存活等，這就是大多數(shù)Monitor存活原則。在生產(chǎn)環(huán)境中至少要運(yùn)行3個(gè)Monitor，以確保高可用性。當(dāng)集群規(guī)模增大的時(shí)候，考慮增加Monitor的存活個(gè)數(shù)到5個(gè)以上。2.2.3CephMonitor一致性Ceph客戶端和其他守護(hù)進(jìn)程使用配置文件發(fā)現(xiàn)Monitor。Monitor間的相互發(fā)現(xiàn)是使用MonitorMap，而不是配置文件。MonitorMap存在于集群中，需要的時(shí)候可以執(zhí)行命令導(dǎo)出，這樣Ceph集群的管理信息就比存放在配置文件中更安全。例如在配置文件中指定Ceph啟動(dòng)端口時(shí)寫錯(cuò)，導(dǎo)致Ceph不可用，而有了MonitorMap，即便是端口錯(cuò)誤，Ceph集群的各個(gè)Monmap依舊在集群中，并不影響多Monitor間的通信。另外，你對Ceph集群所做的任何更新，都要由Paxos來保證ClusterMap分布式的一致性。2.3OSD節(jié)點(diǎn)分析CephOSD是Ceph的對象存儲守護(hù)進(jìn)程。它負(fù)責(zé)存儲數(shù)據(jù)，處理數(shù)據(jù)復(fù)制、恢復(fù)、重新平衡，并通過檢查其他守護(hù)進(jìn)程是否有故障來向CephMonitor提供一些監(jiān)控信息。每個(gè)存儲服務(wù)器（存儲節(jié)點(diǎn)）運(yùn)行一個(gè)或多個(gè)OSD守護(hù)進(jìn)程，通常每個(gè)磁盤存儲設(shè)備對應(yīng)一個(gè)OSD守護(hù)進(jìn)程。之所以說它是守護(hù)進(jìn)程，是因?yàn)樵贑eph集群中啟動(dòng)所有的OSD管理相應(yīng)的磁盤時(shí)都是在宿主機(jī)操作系統(tǒng)中啟動(dòng)一個(gè)進(jìn)程。集群中不管是設(shè)置3副本還是采用2:1的糾刪碼方式，都至少需要3個(gè)OSD才能實(shí)現(xiàn)冗余和高可用。存儲節(jié)點(diǎn)支持的存儲磁盤類型包括HDD、SSD、NVMeSSD。2.3.1運(yùn)行OSD所需服務(wù)器配置推薦Ceph集群中的每個(gè)節(jié)點(diǎn)都需要通過不同的配置來滿足生產(chǎn)環(huán)境所要求的高效，包含對CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等的要求。你可在12.3節(jié)獲取更詳細(xì)的調(diào)優(yōu)建議。本節(jié)概括性地闡述配置推薦。1.內(nèi)存使用推薦Ceph集群的性能有很多影響因素，其中每個(gè)磁盤對應(yīng)的OSD守護(hù)進(jìn)程都需要一定的內(nèi)存來緩存熱數(shù)據(jù)。磁盤數(shù)量的多少決定了每個(gè)存儲節(jié)點(diǎn)中服務(wù)器的內(nèi)存需求量。在采購硬件服務(wù)器的時(shí)候，你應(yīng)該先規(guī)劃存儲容量，然后確定內(nèi)存容量，配合其他衡量指標(biāo)得到最后的服務(wù)器硬件配置參數(shù)。在生產(chǎn)環(huán)境下，部署Ceph集群在兼顧性能的同時(shí)，還有幾種內(nèi)存推薦比例可以使用?！?GBRAM對應(yīng)1TB數(shù)據(jù)·3～6GBRAM對應(yīng)1OSD進(jìn)程·8～12GBRAM對應(yīng)1SSD進(jìn)程例如單存儲節(jié)點(diǎn)有24個(gè)磁盤插槽，其中4個(gè)是SSD插槽，20個(gè)是HDD（SATA/SAS）插槽，你就可以為其配置如下內(nèi)存容量，以保證其能在生產(chǎn)環(huán)境中穩(wěn)定、高效地運(yùn)行?！?6GBRAM（操作系統(tǒng)運(yùn)行+服務(wù)進(jìn)程）·3～6GBRAM×20（每個(gè)HDD類型的OSD進(jìn)程使用）·8～12GBRAM×4（每個(gè)SSD類型的OSD進(jìn)程使用或做加速）綜上所述，我們需要為這樣的服務(wù)器節(jié)點(diǎn)配置184GB（16+6×20+12×4）內(nèi)存。如果你購買的是16GB一條的內(nèi)存條，需要為服務(wù)器配置12條（184/16=11.5，取整）內(nèi)存條，即服務(wù)器節(jié)點(diǎn)內(nèi)容應(yīng)該有192GB。2.CPU配置推薦Ceph集群的每個(gè)存儲節(jié)點(diǎn)上都運(yùn)行了許多（根據(jù)磁盤數(shù)量決定）OSD進(jìn)程來執(zhí)行最終數(shù)據(jù)落盤的相關(guān)操作，涉及數(shù)據(jù)的分片和重組，因此對CPU有一定的要求。目前，對CPU的依賴程度主要看使用者追求的是哪方面性能，例如數(shù)據(jù)吞吐量和IOPS?！OPS（Input/OutputPerSecond，每秒輸入/輸出量或讀寫次數(shù)）：衡量磁盤性能的主要指標(biāo)之一。IOPS是指單位時(shí)間內(nèi)系統(tǒng)能處理的I/O請求數(shù)量。I/O請求通常為讀寫數(shù)據(jù)操作請求。對于隨機(jī)讀寫頻繁的應(yīng)用，IOPS是關(guān)鍵衡量指標(biāo)，比如使用MySQL數(shù)據(jù)庫?！?shù)據(jù)吞吐量：單位時(shí)間內(nèi)可以成功傳輸?shù)臄?shù)據(jù)量。對于大量順序讀寫的應(yīng)用，我們更應(yīng)關(guān)注吞吐量指標(biāo)。簡而言之：·磁盤的IOPS，也就是在一秒內(nèi)磁盤執(zhí)行多少次讀寫?！ご疟P的吞吐量，也就是磁盤每秒I/O的流量，即磁盤每秒寫入及讀出的數(shù)據(jù)量。所以追求IOPS的使用者可以將SSD磁盤作為高性能磁盤存儲設(shè)備，提高單位時(shí)間內(nèi)的讀寫次數(shù)，但這在一定程度上也會增加Ceph集群的整體造價(jià)。追求吞吐量的使用者可以使用HDD+SSD（加速用）的方式進(jìn)行配置，這樣Ceph集群造價(jià)會降低很多。如果優(yōu)化得當(dāng)，也能得到不錯(cuò)的IOPS效果。對于追求吞吐量的場景，假設(shè)CPU主頻是2GHz，一般每個(gè)HDD類型的OSD進(jìn)程需要分配0.5~1core。例如存儲節(jié)點(diǎn)有24個(gè)磁盤插槽（20HDD+4SSD加速盤），在2GHz主頻下要為其配置24core（20×1core（OSD用）+4core（系統(tǒng)用））。如果服務(wù)器是2路CPU，每個(gè)CPU要提供12core。對于追求IOPS的場景，假設(shè)CPU主頻是2GHz，一般每個(gè)NVMeSSD類型的OSD進(jìn)程需要分配10core。此種場景對CPU的要求較高。對于存儲非結(jié)構(gòu)化數(shù)據(jù)的用戶，選用吞吐量大的方案即可。3.網(wǎng)絡(luò)配置推薦2.1節(jié)提到Ceph集群有兩個(gè)網(wǎng)絡(luò)，要求生產(chǎn)環(huán)境下兩個(gè)網(wǎng)絡(luò)帶寬為萬兆，并且盡可能多端口綁定以增加冗余或者并行帶寬。在生產(chǎn)環(huán)境下，強(qiáng)烈推薦使用獨(dú)立的網(wǎng)絡(luò)部署Ceph。所有集群服務(wù)器內(nèi)萬兆網(wǎng)口都需要使用萬兆交換機(jī)進(jìn)行鏈路打通。一個(gè)典型的萬兆交換機(jī)包含48個(gè)10G端口和4個(gè)40G端口。所有的10G端口用來連接Ceph集群的各個(gè)服務(wù)器，而4個(gè)40G端口用來連接主干交換機(jī)，以提高最大吞吐量。Ceph集群究竟需要多大網(wǎng)絡(luò)帶寬，這和集群內(nèi)的硬件資源配置有很大關(guān)系，要看追求的是IOPS還是吞吐量。如果是配置在全NVMeSSD的高性能服務(wù)器上，推薦每2個(gè)NVMeSSD類型的OSD使用10G網(wǎng)絡(luò)；如果是配置在追求吞吐量的服務(wù)器上，可以配置12個(gè)HDD類型的OSD使用10G網(wǎng)絡(luò)。而Ceph的兩個(gè)網(wǎng)段將使用相同的配置。以24個(gè)HDDOSD的服務(wù)器磁盤配置為例，Ceph的Cluster和Public網(wǎng)絡(luò)的配置推薦如下?！ublic網(wǎng)絡(luò)：24OSD/12=2個(gè)10G端口·Cluster網(wǎng)絡(luò)：24OSD/12=2個(gè)10G端口因此，Ceph集群需要4個(gè)10G端口。注意，這里的4個(gè)10G端口不能配置成主備模式，而是真實(shí)的并行帶寬。4.磁盤配置推薦Ceph集群的存儲節(jié)點(diǎn)數(shù)量多，每個(gè)節(jié)點(diǎn)的磁盤數(shù)量也很多。其為數(shù)據(jù)安全做了軟件層面的冗余，通過副本或糾刪碼實(shí)現(xiàn)了數(shù)據(jù)安全。另外，如果磁盤配置了磁盤陣列（RAID），也會給Ceph的性能帶來影響，而且在成本和存儲空間上造成了不必要的浪費(fèi)，因此在硬件層面不推薦配置RAID，將服務(wù)器的磁盤直接配置成JBOD模式即可。如果服務(wù)器不支持JBOD模式，就配置成RAID0。為了提高Ceph的數(shù)據(jù)讀寫速度，我們還要關(guān)注另外一個(gè)因素——Ceph的數(shù)據(jù)日志加速，不論使用Filestore模式還是Bluestore模式對Ceph數(shù)據(jù)進(jìn)行底層落盤處理，都需要對日志落盤進(jìn)行加速，通常會配置SATASSD或NVMeSSD作為日志加速盤。而日志加速盤和數(shù)據(jù)存儲盤之間的配比關(guān)系要看選擇的SSD加速盤類型，這里推薦的容量配比如下：·SATASSD:HDD=1:5·NVMeSSD:HDD=1:10如果使用的是24HDD×4TB磁盤容量的服務(wù)器，單節(jié)點(diǎn)容量為96TB；如果使用SATASSD，就要配置約20TB（96/5=19.2）容量的SSD；如果使用NVMeSSD，就要配置9.6TB的NVMeSSD。該配置看起來對日志加速盤的要求很高。在生產(chǎn)環(huán)境下，你也可以兼顧服務(wù)器磁盤插槽數(shù)量和容量。2.3.2OSD的ScrubScrub是Ceph集群對放置組進(jìn)行數(shù)據(jù)清洗（掃描）的操作，用于檢測副本數(shù)據(jù)間的一致性，確保數(shù)據(jù)完整。Scrub類似于對象存儲層上的fsck命令，包括Light-scrubing和Deep-scrubing。其中，Light-scrubing只對元數(shù)據(jù)進(jìn)行掃描，速度比較快；Deep-scrubing不僅要對元數(shù)據(jù)進(jìn)行掃描，還要對數(shù)據(jù)進(jìn)行掃描，速度比較慢。對于每個(gè)放置組，Ceph都會為所有對象生成目錄，并比較每個(gè)主要對象及其副本，以確保沒有對象丟失或不匹配。Light-scrubing每天檢查對象的大小和屬性。Deep-scrubing每周讀取數(shù)據(jù)并使用校驗(yàn)和確保數(shù)據(jù)完整性。Scrub操作對于保持?jǐn)?shù)據(jù)完整很重要，但是會降低性能。你可以調(diào)整Scrub操作的頻率來兼顧數(shù)據(jù)完整與性能。2.3.3回填OSD當(dāng)將OSD添加到集群或從集群中刪除時(shí)，CRUSH算法通過將放置組移入或移出OSD來重新平衡集群數(shù)據(jù)分布，以達(dá)到數(shù)據(jù)均勻分布。放置組及其包含的對象的遷移可能會大大降低集群的運(yùn)行性能。為了保持集群性能，Ceph通過回填（Backfill）方式來執(zhí)行遷移。簡單來說，你可以通過配置Ceph降低回填操作的優(yōu)先級，使得其比讀取或?qū)懭霐?shù)據(jù)的請求的優(yōu)先級還低，以保證集群的讀寫性能，同時(shí)在集群讀寫請求優(yōu)先級較低的時(shí)候，完成數(shù)據(jù)再平衡。2.3.4OSD恢復(fù)當(dāng)集群啟動(dòng)或者CephOSD意外終止并重新啟動(dòng)時(shí)，在可能發(fā)生寫操作之前，該OSD開始與其余CephOSD配對檢查。如果CephOSD崩潰并重新上線，通常它與其他CephOSD數(shù)據(jù)不同步，而其他CephOSD在放置組中包含的對象版本最新。掉線又重新恢復(fù)的OSD中的對象版本較老舊。發(fā)生這種情況時(shí)，CephOSD進(jìn)入恢復(fù)模式，尋求獲取數(shù)據(jù)的最新副本并將其映射恢復(fù)到最新狀態(tài)。根據(jù)CephOSD掉線的時(shí)間判斷OSD的對象和放置組是否已過時(shí)。同樣，如果某個(gè)故障域發(fā)生故障，例如機(jī)架故障，則可能同時(shí)有多個(gè)CephOSD上線，這會使恢復(fù)過程既耗時(shí)又耗資源。為了保障性能，Ceph會限制恢復(fù)請求的數(shù)量。控制線程數(shù)和對象塊大小可以讓Ceph在Degraded狀態(tài)下表現(xiàn)出良好的性能。2.4Manager節(jié)點(diǎn)分析CephManager從整個(gè)集群中收集狀態(tài)信息。CephManager守護(hù)進(jìn)程與Monitor守護(hù)進(jìn)程一起運(yùn)行，提供了附加的監(jiān)控功能，并與外部監(jiān)控系統(tǒng)和管理系統(tǒng)連接。它還提供其他服務(wù)（如CephDashboardWebUI）、跟蹤運(yùn)行時(shí)指標(biāo)，并通過基于Web瀏覽器的儀表板和RESTfulAPI公開集群信息。將CephManager和CephMonitor放在同一節(jié)點(diǎn)上運(yùn)行比較明智，但不強(qiáng)制。其中，CephManager中有很多功能以模塊的形式存在如表2-1所示。表2-1CephManager中的功能模塊其中比較重要的就是Dashboard和Prometheus等。你可以通過設(shè)置將Ceph集群的管理和監(jiān)控工作圖形化。Dashboard提供管理和監(jiān)視功能。你可以使用它管理和配置集群，或者獲取集群和性能統(tǒng)計(jì)信息。同時(shí)，這些信息都能可視化。它主要集成了Prometheus和Grafana。每個(gè)節(jié)點(diǎn)上的node-exporter守護(hù)進(jìn)程負(fù)責(zé)收集統(tǒng)計(jì)信息，傳遞給Prometheus，最后通過Grafana展示。2.5Ceph對象存儲和對象網(wǎng)關(guān)Ceph對象網(wǎng)關(guān)提供了客戶端訪問Ceph集群的接口。本節(jié)對Ceph的對象存儲和對象網(wǎng)關(guān)進(jìn)行深入分析。2.5.1對象存儲對象存儲是一種解決和處理離散單元的方法。離散后的數(shù)據(jù)稱為對象，因此數(shù)據(jù)會離散出很多對象。與傳統(tǒng)的文件系統(tǒng)中的文件不同，對象存儲不像文件系統(tǒng)那樣通過目錄樹或者子目錄樹對文件進(jìn)行組織。對象存儲是在一個(gè)平坦的命名空間通過使用對象的ObjectID（有時(shí)稱為對象密鑰）來檢索離散后的所有數(shù)據(jù)對象。應(yīng)用程序使用WebAPI來訪問對象，與訪問文件系統(tǒng)的方式不同。通常，有兩種訪問對象API的方式：AmazonS3和OpenStackSwift（OpenStack對象存儲）。AmazonS3將對象的扁平命名空間稱為桶（Bucket），OpenStackSwift將其稱為容器（Container）。Bucket不能嵌套。使用一個(gè)賬戶可以訪問同一存儲集群上的多個(gè)桶。這些桶可能具有不同的訪問權(quán)限，并且可能用于不同的對象存儲。對象存儲的優(yōu)點(diǎn)是簡單易用、易于擴(kuò)展。每個(gè)對象的唯一ID允許被存儲或檢索，無須最終用戶知道該對象所在的確切位置。對象存儲消除了傳統(tǒng)文件系統(tǒng)中的目錄層次結(jié)構(gòu)，因此可以簡化對象之間的關(guān)系。對象（像文件一樣）包含二進(jìn)制數(shù)據(jù)流，并且大小無限制。對象還包含描述數(shù)據(jù)的元數(shù)據(jù)。文件也同樣有元數(shù)據(jù)，包括文件權(quán)限、修改時(shí)間等。對象本身支持?jǐn)U展元數(shù)據(jù)信息，通常以K/V形式管理元數(shù)據(jù)——將有關(guān)對象中數(shù)據(jù)的信息存儲在鍵–值對中。2.5.2對象網(wǎng)關(guān)RADOS網(wǎng)關(guān)（也稱為Ceph對象網(wǎng)關(guān)、RADOSGW或RGW）是一項(xiàng)服務(wù)，可為使用標(biāo)準(zhǔn)對象存儲API的客戶端提供對Ceph集群的訪問，同時(shí)支持AmazonS3和OpenStackSwiftAPI。RADOS網(wǎng)關(guān)是建立在Librados之上的對象存儲接口，旨在為應(yīng)用程序提供通往RADOS集群的RESTfulAPI。RADOS網(wǎng)關(guān)支持兩個(gè)接口?！3兼容接口：與AmazonS3RESTfulAPI的大部分子集接口兼容?！wift兼容接口：與OpenStackSwiftAPI的大部分子集接口兼容。RADOS網(wǎng)關(guān)是用于與Librados交互的FastCGI模塊。由于它提供與OpenStackSwift和AmazonS3兼容的接口，因此RADOSGateway具有獨(dú)立的用戶管理功能。S3和SwiftAPI共享一個(gè)名稱空間，因此可以使用其中一個(gè)API寫入數(shù)據(jù)，使用另一個(gè)API檢索數(shù)據(jù)。圖2-3是客戶端通過對象網(wǎng)關(guān)訪問Ceph集群數(shù)據(jù)的示意圖。核心守護(hù)進(jìn)程radosgw提供以Librados庫為基礎(chǔ)封裝的接口。它通常將自己的Web服務(wù)器Civetweb作為前端來處理請求。應(yīng)用程序或其他客戶端使用標(biāo)準(zhǔn)API與RADOS網(wǎng)關(guān)通信，RADOS網(wǎng)關(guān)通過Librados庫與Ceph存儲集群通信。RADOS網(wǎng)關(guān)擁有自己的用戶集，與Ceph集群用戶不同。換句話說，RADOS網(wǎng)關(guān)的客戶端通過AmazonS3或OpenStackSwiftAPI來使用自己的用戶集進(jìn)行身份驗(yàn)證。我們可以使用radosgw-admin工具或基于LDAP的外部身份驗(yàn)證服務(wù)來配置用戶。對于大型的多站點(diǎn)安裝，將RADOS網(wǎng)關(guān)部署在ZoneGroup和Realm的某一區(qū)域中。通常，我們在生產(chǎn)環(huán)境下部署多個(gè)RADOS網(wǎng)關(guān)，以防單點(diǎn)故障。圖2-3對象網(wǎng)關(guān)的使用邏輯2.6文件存儲元數(shù)據(jù)節(jié)點(diǎn)分析Ceph的元數(shù)據(jù)管理服務(wù)器（MDS）提供了客戶端訪問Ceph集群的接口。本節(jié)對Ceph的分布式文件系統(tǒng)進(jìn)行深入分析。2.6.1Ceph文件存儲CephFS是基于RADOS的高性能分布式文件系統(tǒng)。它是一個(gè)可擴(kuò)展的、符合POSIX標(biāo)準(zhǔn)的分布式并行文件系統(tǒng)。該系統(tǒng)將其數(shù)據(jù)和元數(shù)據(jù)作為對象存儲在Ceph中。CephFS依賴運(yùn)行MDS來協(xié)調(diào)對RADOS集群的訪問，并管理與其文件相關(guān)的元數(shù)據(jù)。CephFS的目標(biāo)是盡可能與POSIX標(biāo)準(zhǔn)文件系統(tǒng)一樣。兩個(gè)不同主機(jī)上運(yùn)行的進(jìn)程應(yīng)與在同一主機(jī)上運(yùn)行的進(jìn)程相同，即在不同主機(jī)上對文件讀寫、實(shí)時(shí)同步的效果和操作與在同一臺主機(jī)上的效果和操作一樣。例如，與許多其他常見的網(wǎng)絡(luò)文件系統(tǒng)（如NFS）相比，CephFS保證了客戶端強(qiáng)大的緩存一致性。但是，在某些情況下，CephFS與嚴(yán)格的POSIX語義有所不同。CephFS至少需要運(yùn)行一個(gè)MDS守護(hù)進(jìn)程（ceph-mds）。MDS守護(hù)進(jìn)程管理存儲在Ceph文件系統(tǒng)中與文件相關(guān)的元數(shù)據(jù)，并協(xié)調(diào)對共享Ceph存儲集群的訪問。2.6.2CephFS限制因素首先看一下客戶端訪問CephFS的過程。在CephFS中，客戶端是使用CephFS的所有操作請求的入口?？蛻舳藢⒃獢?shù)據(jù)讀寫請求發(fā)送到活躍的MDS，從中獲取文件元數(shù)據(jù)，并且安全地緩存元數(shù)據(jù)和文件數(shù)據(jù)。MDS將元數(shù)據(jù)提供給客戶端，緩存熱的元數(shù)據(jù)是為了減少對后端元數(shù)據(jù)池的請求，管理客戶端的緩存是為了保證緩存一致性。CephFS工作過程是，在活躍的MDS之間復(fù)制熱的元數(shù)據(jù)，并將元數(shù)據(jù)變化信息合并到日志，定期刷新到后端元數(shù)據(jù)池中，使數(shù)據(jù)在集群間實(shí)時(shí)同步，具體如圖2-4所示。在使用CephFS過程中，我們應(yīng)注意以下幾點(diǎn)。（1）采用多MDS節(jié)點(diǎn)部署方式為了使生產(chǎn)環(huán)境下的數(shù)據(jù)可用，你要采用多MDS節(jié)點(diǎn)部署方式。部署完成后，MDS節(jié)點(diǎn)分為主節(jié)點(diǎn)和備節(jié)點(diǎn)。當(dāng)主節(jié)點(diǎn)異常時(shí)，備節(jié)點(diǎn)將接管客戶端的訪問，保證數(shù)據(jù)持續(xù)提供。默認(rèn)情況下，CephFS僅使用一個(gè)活躍的MDS守護(hù)進(jìn)程。但是，你可以給文件系統(tǒng)配置為使用多個(gè)活躍的的MDS守護(hù)進(jìn)程，以處理更大的工作負(fù)載。圖2-4CephFS工作過程（2）重點(diǎn)保護(hù)元數(shù)據(jù)池如圖2-4所示，RADOS底層需要提供兩個(gè)后端存儲池，其中一個(gè)存儲數(shù)據(jù)，另一個(gè)存儲元數(shù)據(jù)。你在創(chuàng)建MDS的時(shí)候，要首先創(chuàng)建這兩個(gè)數(shù)據(jù)池，且一定要做好對存儲數(shù)據(jù)池的保護(hù)，比如采用更高的副本級別，這個(gè)池中的任何數(shù)據(jù)丟失都會導(dǎo)致整個(gè)文件系統(tǒng)無法訪問。另外，你也可以考慮使用延遲較低的存儲設(shè)備，例如固態(tài)驅(qū)動(dòng)器（SSD）磁盤，因?yàn)檫@直接影響到客戶端操作的反饋延遲。（3）使用一個(gè)CephFS默認(rèn)情況下，禁止在一個(gè)集群中創(chuàng)建多個(gè)CephFS，因?yàn)閯?chuàng)建多個(gè)CephFS可能會使得MDS或者客戶端服務(wù)異常。2.7iSCSI網(wǎng)關(guān)節(jié)點(diǎn)分析作為存儲管理員，你可以為Ceph集群安裝和配置iSCSI網(wǎng)關(guān)。借助iSCSI網(wǎng)關(guān)，你可以有效地對Ceph塊存儲進(jìn)行功能接口適配，采用熟悉和常用的iSCSI來訪問Ceph。iSCSI網(wǎng)關(guān)將Ceph與iSCSI標(biāo)準(zhǔn)集成在一起，以提供將RADOS塊設(shè)備（RBD）映像導(dǎo)出為SCSI磁盤的高可用iSCSI啟動(dòng)器。iSCSI協(xié)議允許啟動(dòng)器通過TCP/IP網(wǎng)絡(luò)將SCSI命令發(fā)送到iSCSI目標(biāo)器，以此提供在異構(gòu)客戶端訪問Ceph集群的能力。簡單來說，Ceph集群實(shí)現(xiàn)了iSCSI啟動(dòng)器的多點(diǎn)（多機(jī)頭）集群，保證了訪問的高可用性，為Windows等系統(tǒng)提供數(shù)據(jù)存儲能力。因此，部署iSCSI網(wǎng)關(guān)時(shí)，我們需要指定多節(jié)點(diǎn)。2.8本章小結(jié)本章主要介紹了Ceph集群的角色組件，每種角色組件的核心功能及其Ceph特性，這些特性如何保證數(shù)據(jù)的安全和一致；同時(shí)介紹了Ceph的多種網(wǎng)關(guān)，包括這些網(wǎng)關(guān)的主要功能，以及與現(xiàn)有存儲接口的兼容性，如Ceph對象存儲與AmazoneS3和OpenStackSwiftAPI的兼容。你可能要問，Ceph的角色功能已經(jīng)在本章描述了，那么Ceph是如何實(shí)現(xiàn)數(shù)據(jù)存儲的？這些角色組件通過什么技術(shù)將數(shù)據(jù)安全地組織起來？在第3章中，我們將重點(diǎn)介紹Ceph的核心技術(shù)組件的實(shí)現(xiàn)原理。第3章

Ceph核心技術(shù)組件Ceph集群可以容納大量節(jié)點(diǎn)，以實(shí)現(xiàn)無限擴(kuò)展、高可用和其他性能要求。每個(gè)節(jié)點(diǎn)利用相互之間通信的非專有硬件和Ceph守護(hù)進(jìn)程來實(shí)現(xiàn)以下功能?！ぷx寫數(shù)據(jù)?！嚎s資料?！ねㄟ^副本和糾刪碼確保數(shù)據(jù)安全?！けO(jiān)控并報(bào)告集群運(yùn)行狀況?！?dòng)態(tài)地重新分配數(shù)據(jù)?！ご_保數(shù)據(jù)完整性?！す收匣謴?fù)。Ceph集群看起來像一個(gè)存儲池，用于存儲數(shù)據(jù)。所有在Librados中的操作對Ceph客戶端而言是透明的。Ceph客戶端和CephOSD都使用CRUSH算法。本章會介紹Ceph核心技術(shù)組件的功能。3.1Ceph的關(guān)鍵特性Ceph有很多關(guān)鍵特性，這些關(guān)鍵特性也是Ceph產(chǎn)品的核心，因此，對這些特性的了解有助于在后續(xù)提升性能。Ceph的關(guān)鍵特性如表3-1所示。目前，這些特性都是在企業(yè)生產(chǎn)環(huán)境中可用的。表3-1Ceph的關(guān)鍵特性接下來分析Ceph中各個(gè)核心功能組件的作用。3.2存儲池Ceph集群將數(shù)據(jù)對象存儲在池的邏輯分區(qū)中。Ceph管理員可以為特定類型的數(shù)據(jù)（例如塊設(shè)備、對象網(wǎng)關(guān)）創(chuàng)建池，或者使用池將一組用戶與另一組用戶分開。從客戶端角度來看，Ceph集群非常簡單。當(dāng)Ceph客戶端使用I/O上下文讀取或?qū)懭霐?shù)據(jù)時(shí)，總是連接到Ceph集群中的存儲池。Ceph客戶端指定池名稱、用戶和密鑰，因此該池看起來像是一個(gè)邏輯分區(qū)，便于對數(shù)據(jù)對象進(jìn)行訪問控制。實(shí)際上，存儲池是用于存儲對象的邏輯分區(qū)，在Ceph集群分發(fā)和存儲數(shù)據(jù)方面起著至關(guān)重要的作用。這些復(fù)雜的操作對Ceph客戶端是完全透明的。3.2.1Ceph技術(shù)組件的全景架構(gòu)Ceph的技術(shù)組件邏輯組織關(guān)系如圖3-1所示。首先通過Ceph客戶端接口將文件、視頻、圖片等數(shù)據(jù)寫入，并將用戶數(shù)據(jù)分割成對象（對象和定義的存儲池關(guān)聯(lián)），將對象放入存儲池生成規(guī)則集，由CRUSH算法計(jì)算出放置組，最后將放置組關(guān)聯(lián)到具體服務(wù)器的硬盤，從而打通數(shù)據(jù)落盤前的各個(gè)關(guān)鍵路徑。圖3-1Ceph的技術(shù)組件邏輯組織關(guān)系3.2.2存儲池定義的內(nèi)容存儲池是Ceph的邏輯單元，可以實(shí)現(xiàn)不同數(shù)據(jù)的邏輯隔離，給數(shù)據(jù)管控帶來更多好處。存儲池包含的概念介紹如下。1）池類型：在早期的Ceph版本中，存儲池僅維護(hù)對象的多個(gè)深層副本。如今，Ceph可以維護(hù)一個(gè)對象的多個(gè)副本，也可以使用糾刪碼來確保數(shù)據(jù)可靠。存儲池類型定義了創(chuàng)建池時(shí)的數(shù)據(jù)持久化方法（副本或糾刪碼）。存儲池類型對客戶端完全透明。2）放置組：在EB級存儲集群中，存儲池可能存儲了數(shù)百萬個(gè)數(shù)據(jù)對象。Ceph可通過副本或糾刪碼實(shí)現(xiàn)數(shù)據(jù)持久性，通過清洗或循環(huán)冗余校驗(yàn)保證數(shù)據(jù)完整，實(shí)現(xiàn)復(fù)制、重新平衡和故障恢復(fù)。Ceph通過將存儲池劃分為放置組來解決性能瓶頸問題。CRUSH算法用于在Ceph中定位存儲數(shù)據(jù)的位置，并計(jì)算放置組中的OSD目標(biāo)集。CRUSH算法將每個(gè)對象放入一個(gè)放置組，然后將每個(gè)放置組存儲在一組OSD中。系統(tǒng)管理員在創(chuàng)建或修改存儲池時(shí)設(shè)置放置組數(shù)。3）CRUSH規(guī)則集：CRUSH扮演著另一個(gè)重要角色，可用于檢測故障域和性能域。CRUSH可以按存儲介質(zhì)類型識別OSD。CRUSH使OSD能夠跨故障域存儲對象副本。例如，對象副本可能會存儲在不同的服務(wù)器機(jī)房、機(jī)架和節(jié)點(diǎn)中。如果集群的很大一部分節(jié)點(diǎn)發(fā)生故障（例如機(jī)架），集群仍可以降級狀態(tài)運(yùn)行，直到集群恢復(fù)正常為止。此外，CRUSH能夠使客戶端將數(shù)據(jù)寫入特定類型的硬件，例如SSD。3.3Ceph認(rèn)證為了識別用戶并防止系統(tǒng)被攻擊，Ceph提供了Cephx身