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

runsisi AT hust.edu.cn

2015/06/12

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

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

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

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

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

1.        問題提出

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

2.        基本思考方向

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

1. virtualization

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

runsisi AT hust

http://www.shnenglu.com/runsisi

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

1. saltstack基本概念

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

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

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

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

/Files/runsisi/salt-ceph.pdf

runsisi AT hust

http://www.shnenglu.com/runsisi

前言

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

1.     puppet

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

runsisi AT hust

http://www.shnenglu.com/runsisi

前言

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

CHAP協(xié)議

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

注：附件中的壓縮包為iSCSI discovery會話的抓包信息，兩次抓包分別為單向CHAP認(rèn)證和雙向CHAP認(rèn)證過程，
iSCSI normal會話的CHAP認(rèn)證過程和discovery會話是一樣的，沒有再單獨(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就比較郁悶了，這個插件包只支持7.3及以上的版本，vim官方好像是沒有提供rpm包下載的，我每次都是自己下來源代碼進(jìn)行編譯，其實(shí)挺不方便的，本來只需要進(jìn)行一次的工作，每次硬是要重新編譯打包。讓我想起了在學(xué)校維護(hù)系里的網(wǎng)站時，需要添加一個生成本科畢業(yè)設(shè)計(jì)選題統(tǒng)計(jì)word文檔的功能，大概花了我兩天的時間才把這個功能給實(shí)現(xiàn)了，每次老師們想要生成這個文檔，就在頁面上點(diǎn)擊一下按鈕，然后稍等一小會，網(wǎng)站后臺會實(shí)時生成一個word文檔提供下載，好久之后我才突然開竅，其實(shí)只需要我自己生成一份然后掛到網(wǎng)站上就行了的，反正畢設(shè)選題每年只有一次，哪用SB似的每次都去查數(shù)據(jù)庫給生成一份:)

google被GFW給屏蔽了，因此vim的代碼也取不下來了，只好從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包即可，同時也可以使用git版本管理工具獲取最新的開發(fā)版本的源代碼^[1]：

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

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

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

/Files/runsisi/ceph_build.pdf

runsisi AT hust

http://www.shnenglu.com/runsisi

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

該錯誤的具體原因待會解釋，先簡單介紹一下該命令執(zhí)行過程中發(fā)生的事情：

1． 啟動 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． 以上任何一步如果文件已存在，則不會新建（或去 monitor 節(jié)點(diǎn)取）文件。

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

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

/Files/runsisi/ceph_bootstrap_key_fail.pdf