基于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://www.cppblog.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://www.cppblog.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://www.cppblog.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://www.cppblog.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://www.cppblog.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://www.cppblog.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