基于ceph RBD的Iscsi target實現分析

runsisi AT hust.edu.cn

2015/06/12

本文總結基于ceph存儲后端的iSCSI target實現，針對幾種可能的實現思路進行分析，并輸出本文檔，本文內容組織結構如下：

1. 描述本文的目的及內容；

2. iSCSI使用ceph作為存儲后端的基本實現思路；

3. 分別闡述幾種可能的實現方式，分析其各自的特點和可能存在的一些技術障礙；

4. 最后簡單總結全文。

1.        問題提出

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

2.        基本思考方向

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

1. virtualization

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

runsisi AT hust

http://m.shnenglu.com/runsisi

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

1. saltstack基本概念

master：saltstack服務端，可執行程序為salt-master；

minion：saltstack客戶端，可執行程序為salt-minion；

grains：客戶端節點自身所固有的靜態數據，如節點的基本信息等；

pillar：在服務端定義的、針對具體客戶端的數據。

/Files/runsisi/salt-ceph.pdf

runsisi AT hust

http://m.shnenglu.com/runsisi

前言

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

1.     puppet

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

runsisi AT hust

http://m.shnenglu.com/runsisi

前言

CHAP認證是iSCSI協議中最主要的認證方式，現有的開源iSCSI實現（包括initiator和target實現）基本上都只支持CHAP認證，本文將對CHAP認證及其在iSCSI協議中的應用作一個簡單的介紹。

CHAP協議

CHAP^[1]的全稱是Challenge-Handshake Authentication Protocol，協議細節由RFC 1994進行定義。CHAP最初應用在Point to Point Protocol（PPP）中，用于實現PPP服務器對客戶端的身份認證，但也可以應用在其它需要對用戶或主機進行身份認證的場合，如iSCSI協議就規定使用iSCSI協議進行通信的設備必須（MUST）實現CHAP認證。

注：附件中的壓縮包為iSCSI discovery會話的抓包信息，兩次抓包分別為單向CHAP認證和雙向CHAP認證過程，
iSCSI normal會話的CHAP認證過程和discovery會話是一樣的，沒有再單獨抓包。

/Files/runsisi/iSCSI_CHAP認證.pdf
/Files/runsisi/iSCSI_CHAP_PCAP.7z

runsisi AT hust

http://m.shnenglu.com/runsisi

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

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://m.shnenglu.com/runsisi

1． 獲取源代碼

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

http://ceph.com/download/

在該路徑下下載相應發行版本的源代碼tar包即可，同時也可以使用git版本管理工具獲取最新的開發版本的源代碼^[1]：

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

2． 建立編譯環境

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

/Files/runsisi/ceph_build.pdf

runsisi AT hust

http://m.shnenglu.com/runsisi

該錯誤在執行命令：ceph-deploy mon create-initial 時出現，說明該 monitor 節點曾經部署過 ceph 環境，該問題的解決方法很簡單，在執行該命令之前刪除該 monitor 節點 /etc/ceph/ 下的{cluster}.client.admin.keyring 文件（cluster名默認配置情況下是ceph）。

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

1． 啟動 monitor 節點的 ceph monitor 守護進程；

2． monitor 節點執行 ceph-create-keys 命令；

3． ceph-create-keys創建 {cluster}.client.admin.keyring；

4． ceph-create-keys創建 bootstrap-{osd, mds}/{cluster}.keyring；

5． ceph-deploy 所在運行節點從 monitor 節點取 {cluster}.client.admin.keyring, {cluster}.mon.keyring, bootstrap-{osd, mds}/{cluster}.keyring 到當前路徑；

6． 以上任何一步如果文件已存在，則不會新建（或去 monitor 節點?。┪募?。

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

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

/Files/runsisi/ceph_bootstrap_key_fail.pdf