基于ceph RBD的Iscsi target實(shí)現(xiàn)分析

runsisi AT hust.edu.cn

2015/06/12

本文總結(jié)基于ceph存儲(chǔ)后端的iSCSI target實(shí)現(xiàn)，針對(duì)幾種可能的實(shí)現(xiàn)思路進(jìn)行分析，并輸出本文檔，本文內(nèi)容組織結(jié)構(gòu)如下：

1. 描述本文的目的及內(nèi)容；

2. iSCSI使用ceph作為存儲(chǔ)后端的基本實(shí)現(xiàn)思路；

3. 分別闡述幾種可能的實(shí)現(xiàn)方式，分析其各自的特點(diǎn)和可能存在的一些技術(shù)障礙；

4. 最后簡(jiǎn)單總結(jié)全文。

1.        問(wèn)題提出

ceph作為一個(gè)真正意義上的統(tǒng)一存儲(chǔ)系統(tǒng)，有著很好的應(yīng)用前景，但到目前為止有多種原因限制了其在傳統(tǒng)存儲(chǔ)應(yīng)用領(lǐng)域真正大范圍的應(yīng)用，如客戶(hù)端僅支持GNU/Linux系統(tǒng)，內(nèi)核態(tài)客戶(hù)端實(shí)現(xiàn)也僅會(huì)合入高版本的內(nèi)核中等。而對(duì)于iSCSI這種傳統(tǒng)的存儲(chǔ)應(yīng)用而言，由于客戶(hù)端配置簡(jiǎn)單且足夠通用，常見(jiàn)的各種系統(tǒng)（包括操作系統(tǒng)和應(yīng)用系統(tǒng)）一般都對(duì)iSCSI有很好的支持，因此為了擴(kuò)大ceph的應(yīng)用范圍，特別是應(yīng)對(duì)只支持iSCSI的系統(tǒng)，ceph必須通過(guò)某種途徑實(shí)現(xiàn)對(duì)iSCSI的支持。

2.        基本思考方向

ceph集群目前支持三種形式的存儲(chǔ)接口：文件、對(duì)象、塊，其中塊接口(即RBD)與SCSI塊設(shè)備讀寫(xiě)所要求的接口一致，因此可以基于ceph的RBD提供SCSI存儲(chǔ)系統(tǒng)后端，當(dāng)然如果有足夠信心的話(huà)也可以完全拋棄ceph提供的這三種基礎(chǔ)接口，而在原始的RADOS接口上開(kāi)發(fā)新的塊接口，當(dāng)然除非原始的RBD接口有重要缺陷，否則暫時(shí)還看不到重新發(fā)明輪子的必要，注意后文的討論都將基于這一基本假設(shè)。

1. virtualization

虛擬化，與真實(shí)的、物理存在的對(duì)象相對(duì)應(yīng)，用于隔離底層物理實(shí)現(xiàn)。其中計(jì)算機(jī)硬件虛擬化是我們所熟知的虛擬化技術(shù)，如使用VirtualBox等虛擬機(jī)軟件創(chuàng)建多臺(tái)x86虛擬機(jī)器，使用qemu模擬多種硬件平臺(tái)（x86，PPC）等。其它常見(jiàn)類(lèi)型的虛擬化技術(shù)包括：操作系統(tǒng)虛擬化（Docker，FreeBSD jail），存儲(chǔ)虛擬化（pooling），應(yīng)用軟件虛擬化（virtualenv）等[1]。

runsisi AT hust

http://www.shnenglu.com/runsisi

[本文所提及的部署方法已不適用于新版的ceph-formula]
本文簡(jiǎn)單描述使用saltstack部署ceph集群（MON+OSD）的方法。

1. saltstack基本概念

master：saltstack服務(wù)端，可執(zhí)行程序?yàn)?/span>salt-master；

minion：saltstack客戶(hù)端，可執(zhí)行程序?yàn)?/span>salt-minion；

grains：客戶(hù)端節(jié)點(diǎn)自身所固有的靜態(tài)數(shù)據(jù)，如節(jié)點(diǎn)的基本信息等；

pillar：在服務(wù)端定義的、針對(duì)具體客戶(hù)端的數(shù)據(jù)。

/Files/runsisi/salt-ceph.pdf

runsisi AT hust

http://www.shnenglu.com/runsisi

前言

本文對(duì)使用puppet進(jìn)行ceph集群的部署流程進(jìn)行簡(jiǎn)要總結(jié)。全文結(jié)構(gòu)如下：第一、二節(jié)分別對(duì)puppet和ceph進(jìn)行簡(jiǎn)單介紹；第三節(jié)分析puppet-ceph模塊的結(jié)構(gòu)和實(shí)現(xiàn)；第四節(jié)描述ceph集群部署的操作流程；第五節(jié)總結(jié)全文；附錄為參考文獻(xiàn)及代碼。

1.     puppet

puppet是一個(gè)開(kāi)源的配置管理工具(Puppet is an open source configuration management utility^[1])，同時(shí)也是當(dāng)前最主流的配置管理自動(dòng)化工具之一。

runsisi AT hust

http://www.shnenglu.com/runsisi

前言

CHAP認(rèn)證是iSCSI協(xié)議中最主要的認(rèn)證方式，現(xiàn)有的開(kāi)源iSCSI實(shí)現(xiàn)（包括initiator和target實(shí)現(xiàn)）基本上都只支持CHAP認(rèn)證，本文將對(duì)CHAP認(rèn)證及其在iSCSI協(xié)議中的應(yīng)用作一個(gè)簡(jiǎn)單的介紹。

CHAP協(xié)議

CHAP^[1]的全稱(chēng)是Challenge-Handshake Authentication Protocol，協(xié)議細(xì)節(jié)由RFC 1994進(jìn)行定義。CHAP最初應(yīng)用在Point to Point Protocol（PPP）中，用于實(shí)現(xiàn)PPP服務(wù)器對(duì)客戶(hù)端的身份認(rèn)證，但也可以應(yīng)用在其它需要對(duì)用戶(hù)或主機(jī)進(jìn)行身份認(rèn)證的場(chǎng)合，如iSCSI協(xié)議就規(guī)定使用iSCSI協(xié)議進(jìn)行通信的設(shè)備必須（MUST）實(shí)現(xiàn)CHAP認(rèn)證。

注：附件中的壓縮包為iSCSI discovery會(huì)話(huà)的抓包信息，兩次抓包分別為單向CHAP認(rèn)證和雙向CHAP認(rèn)證過(guò)程，
iSCSI normal會(huì)話(huà)的CHAP認(rèn)證過(guò)程和discovery會(huì)話(huà)是一樣的，沒(méi)有再單獨(dú)抓包。

/Files/runsisi/iSCSI_CHAP認(rèn)證.pdf
/Files/runsisi/iSCSI_CHAP_PCAP.7z

runsisi AT hust

http://www.shnenglu.com/runsisi

現(xiàn)在公司內(nèi)部使用的RPM系發(fā)行版應(yīng)該多數(shù)還停留在Centos6.x或RHEL6.x版本，6.x系列的版本帶的vim好像都是7.2版本的，像我這種裝了spf13提供的vim插件包的TX就比較郁悶了，這個(gè)插件包只支持7.3及以上的版本，vim官方好像是沒(méi)有提供rpm包下載的，我每次都是自己下來(lái)源代碼進(jìn)行編譯，其實(shí)挺不方便的，本來(lái)只需要進(jìn)行一次的工作，每次硬是要重新編譯打包。讓我想起了在學(xué)校維護(hù)系里的網(wǎng)站時(shí)，需要添加一個(gè)生成本科畢業(yè)設(shè)計(jì)選題統(tǒng)計(jì)word文檔的功能，大概花了我兩天的時(shí)間才把這個(gè)功能給實(shí)現(xiàn)了，每次老師們想要生成這個(gè)文檔，就在頁(yè)面上點(diǎn)擊一下按鈕，然后稍等一小會(huì)，網(wǎng)站后臺(tái)會(huì)實(shí)時(shí)生成一個(gè)word文檔提供下載，好久之后我才突然開(kāi)竅，其實(shí)只需要我自己生成一份然后掛到網(wǎng)站上就行了的，反正畢設(shè)選題每年只有一次，哪用SB似的每次都去查數(shù)據(jù)庫(kù)給生成一份:)

google被GFW給屏蔽了，因此vim的代碼也取不下來(lái)了，只好從Centos7的yum源里取了一份，路徑如下：

http://vault.centos.org/7.0.1406/os/Source/SPackages/

/Files/runsisi/centos6.x編譯打包vim7.4.pdf

runsisi AT hust

http://www.shnenglu.com/runsisi

1． 獲取源代碼

獲取源代碼有多種途徑，其中ceph官方發(fā)布的源代碼路徑如下：

http://ceph.com/download/

在該路徑下下載相應(yīng)發(fā)行版本的源代碼tar包即可，同時(shí)也可以使用git版本管理工具獲取最新的開(kāi)發(fā)版本的源代碼^[1]：

git clone --recursive https://github.com/ceph/ceph.git

2． 建立編譯環(huán)境

編譯打包ceph需要相應(yīng)的工具鏈以及一系列的第三方庫(kù)，基于deb的發(fā)行版和基于rpm的發(fā)行版所需要的依賴(lài)并不盡相同，如果使用git從github獲取的源代碼，則在源代碼的根目錄有兩個(gè)文件：deps.deb.txt, deps.rpm.txt，這兩個(gè)文件分別記錄了這兩種類(lèi)型的發(fā)行版建立編譯環(huán)境所需的工具及第三方依賴(lài)庫(kù)，但是這兩個(gè)文件所記錄的依賴(lài)關(guān)系并不一定完全準(zhǔn)確，如果有缺失的依賴(lài)，編譯體系進(jìn)行構(gòu)建時(shí)會(huì)報(bào)錯(cuò)，再安裝相應(yīng)的依賴(lài)即可。

/Files/runsisi/ceph_build.pdf

runsisi AT hust

http://www.shnenglu.com/runsisi

該錯(cuò)誤在執(zhí)行命令：ceph-deploy mon create-initial 時(shí)出現(xiàn)，說(shuō)明該 monitor 節(jié)點(diǎn)曾經(jīng)部署過(guò) ceph 環(huán)境，該問(wèn)題的解決方法很簡(jiǎn)單，在執(zhí)行該命令之前刪除該 monitor 節(jié)點(diǎn) /etc/ceph/ 下的{cluster}.client.admin.keyring 文件（cluster名默認(rèn)配置情況下是ceph）。

該錯(cuò)誤的具體原因待會(huì)解釋?zhuān)群?jiǎn)單介紹一下該命令執(zhí)行過(guò)程中發(fā)生的事情：

1． 啟動(dòng) monitor 節(jié)點(diǎn)的 ceph monitor 守護(hù)進(jìn)程；

2． monitor 節(jié)點(diǎn)執(zhí)行 ceph-create-keys 命令；

3． ceph-create-keys創(chuàng)建 {cluster}.client.admin.keyring；

4． ceph-create-keys創(chuàng)建 bootstrap-{osd, mds}/{cluster}.keyring；

5． ceph-deploy 所在運(yùn)行節(jié)點(diǎn)從 monitor 節(jié)點(diǎn)取 {cluster}.client.admin.keyring, {cluster}.mon.keyring, bootstrap-{osd, mds}/{cluster}.keyring 到當(dāng)前路徑；

6． 以上任何一步如果文件已存在，則不會(huì)新建（或去 monitor 節(jié)點(diǎn)取）文件。

回到我們遇到的錯(cuò)誤，由于 monitor 節(jié)點(diǎn)之前可能使用 ceph-deploy 工具進(jìn)行過(guò)部署，再次部署時(shí)沒(méi)有將 {cluster}.client.admin.keyring 原有的配置文件進(jìn)行清理，因此第3步不會(huì)創(chuàng)建新的 keyring 文件，仍然使用上次部署使用的keyring，從而導(dǎo)致第4步操作會(huì)失敗，最終出錯(cuò)。

從上面的介紹，可以知道，如果要使用 ceph-deploy 工具再次對(duì) ceph 集群進(jìn)行部署，最好將各節(jié)點(diǎn)（包括 ceph-deploy 工具所在節(jié)點(diǎn)）上原有的配置文件清理之后再進(jìn)行部署。

/Files/runsisi/ceph_bootstrap_key_fail.pdf