标签：write 经验 并且 form 这一 .text class mds set
从本篇文章开始介绍一款现在非常火的分布式文件系统Ceph，包括这款文件系统的安装、基本使用场景、常用管理命令和重要工作原理。特别是讨论了PaxOS算法的基本理后，就更容易理解Ceph分布式文件系统中各种角色的工作原理。
本文将介绍Ceph分布式文件系统如何在CentOS 7.X版本上一步一步完成安装，使读者在阅读过程中了解Ceph有哪些重要的子系统/工作模块，以及它们是如何关联工作的。请注意Ceph在Ubuntu等Linux操作系统上的安装过程和注意点大致相同，但如果读者和笔者同样选择在CentOS上安装Ceph，那么就请使用CentOS 7.X的版本，因为这个版本是Ceph官方介绍中推荐的，更重要的是CentOS 6.X已经不受支持了。
本文的演示中我们将按照以下表格安装一个三节点的Ceph分布式文件系统，并绑定一个文件系统的客户端进行文件读写操作。
| 节点 | IP地址 | 角色说明 |
|---|---|---|
| vmnode1 | 172.16.71.182 | MDN、MDS、OSD |
| vmnode2 | 172.16.71.183 | MDN、MDS、OSD |
| vmnode3 | 172.16.71.184 | MDN、MDS、OSD |
| client | 172.16.71.1 | Client |
以上表格中的角色缩写如果目前看不懂也无所谓，在后续的安装介绍中我们将说明这些功能角色的作用。Ceph的安装准备工作相对而言有一些繁琐，如果每一个节点都是全新的操作系统，那么这些节点至少需要经过创建用户、设置用户无密码登录权限、变更Ceph下载仓库、更新软件仓库等工作才能完成准备动作。其过程中往往会出现一些错误，需要在安装过程中耐心解决，下面我们就开始Ceph安装前的准备工作。
无论是测试环境还是正式环境，安装Ceph都不建议使用root账号。所以第一步我们需要专门创建一个用户和用户组，并为这个用户给定管理员权限。我们创建一个用户组ceph和一个专门用来运行Ceph各个模块的用户，用户名也叫做ceph
[......]# groupadd ceph
[......]# useradd ceph -g ceph
[......]# passwd ceph
// 修改成你想要的密码
......记得为用户设置root权限，既是在sudoers文件中加入相关配置信息：
[......]# vim /etc/sudoers
// 加入ceph的sudo权限
......
root ALL=(ALL) ALL
ceph ALL=(ALL) NOPASSWD:ALL
......参与Ceph构建的每个节点都要设置相同的用户信息，并且设置该用户在各个节点间的无密码登录功能——这是因为后面Ceph-deploy的工作过程中，将登录到各个节点上执行命令。
[ceph@vmnode1 ~]$ ssh-keygen
// 操作系统会出现一些提示，回车就行了
[ceph@vmnode1 ~]$ cd ～/.ssh/
[ceph@vmnode1 .ssh]$ cat ./id_rsa.pub >> ./authorized_keys
// 一定要更改authorized_keys的访问权限，不然无密码登录要失败
[ceph@vmnode1 ~]$ chmod 600 ./authorized_keys
// 将authorized_keys copy到你将要登录的操作系统上，注意用户的home目录要做对应关于无密码登录的设置过程就不再深入讲解了，因为是很基本的ssh设置。主要原则就是保证authorized_keys文件的公钥记录信息和这个文件在几个节点间的一致性。如果后续有新的节点加入到Ceph集群中，并且也要承担MDS Follower角色的工作，则同样要设置这个新节点到各个节点的相互无密码登录功能。
Ceph官网的下载速度奇慢(“https://download.ceph.com/“)，这实际上不怪Ceph，原因大家也都懂，呵呵。一个办法是设置国外的代理服务，有免费的，不过好用的还是付费的。另一个好消息是，Ceph有国内镜像，例如163的和aliyun的。根据笔者观察163的镜像同步要比aliyun的镜像同步及时，比如163的镜像中已经有rpm-hammer/ceph-deploy-1.5.37的下载，但是aliyun的镜像中最高版本只有ceph-deploy-1.5.36。通过以下环境变量的设置就可以使用国内的镜像（这个过程不会影响后续的任何安装步骤）：
# 你也可以改成国内其它Ceph镜像
export CEPH_DEPLOY_REPO_URL=http://mirrors.163.com/ceph/rpm-hammer/el7;
export CEPH_DEPLOY_GPG_URL=http://mirrors.163.com/ceph/keys/release.asc;另外Ceph的安装过程还需要相当的第三方组件依赖，其中一些第三方组件在CentOS yum.repo Base等官方源中是没有的（例如LevelDB），所以读者在安装过程中会有一定的几率遇到各种依赖关系异常，并要求先行安装XXX第三方组件的提示（例如提示先安装liblevel.so）。虽然我们后文将会介绍的Ceph辅助部署工具，Ceph-deploy的工作本质还是通过yum命令去安装管理组件，但是既然CentOS yum.repo Base官方源中并没有某些需要依赖的第三方组件，所以一旦遇到类似的组件依赖问题安装过程就没法自动继续了。解决这个问题，本示例中建议引入CentOS的第三方扩展源Epel。
# 关于Epel 扩展源的引入这里不过做介绍了，网络上的资料一大把。这里给出一个“目前可用”（不保证多年后依然可用）的安装地址，以及安装后生成的repo配置片段（本示例中的第三方扩展源匹配CentOS 7.X操作系统）。
http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
# repo文件的名字叫做epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
......为了保证扩展源中的组件与CentOS官方源中的组件不冲突，可以调低扩展源的优先级。当然读者也可以自行手动解决Ceph安装过程提示的组件依赖问题——使用rpm命令的方式。笔者试过，深刻的体会到什么叫生不如死。。。
设置仓库后，需要更新仓库缓存，如下：
[......]$ yum makecache
[......]$ yum updateCeph是一种分布式文件系统，既然是文件系统，那么无论它的上层如何设计如何划分，始终需要对数据持久化存储进行落地。所以Ceph需要操作块存储设备（关于块存储的相关介绍，可以参看本专题最初的几篇文章），Ceph要求块存储设备的文件系统必须为XFS、BTRFS或者EXT4，且必须在操作系统上有独立挂载点。
Ceph的安装有两种方式，第一种是使用Ceph官方提供的Ceph-deploy（部署工具）进行安装，这种方式我们需要首先yum Ceph-deploy，然后再使用Ceph-deploy提供的各种命令来安装Ceph的各个节点，但好处也很明显——Ceph的安装过程基本上是半自动化的，除了一些操作系统层面的问题需要解决外（例如用户对某个目录的读写权限设定错误，再例如防火墙的端口没有打开等等）整个过程还算比较顺利。另外一种是全人工安装，除非你的操作系统存在特殊应用场景，或者有需要特别保护的组件需要进行独立设定，否则还是建议使用前一种Ceph-deploy的方式。
首先安装ceph-deploy软件本省。请注意这个软件并不是ceph工作的一部分，它只一个增加简便性的工具。
......
[......]$ yum -y install ceph-deploy
// NTP时钟同步服务
[......]$ yum install -y ntp ntpdate ntp-doc
//使用一个亚洲公用时间同步节点进行时间同步
[......]$ ntpdate 0.asia.pool.ntp.org
......只需要在某个节点上安装ceph-deploy就行，但是NTP服务是每一个节点都要安装和进行同步，它主要是保证各节点的物理时钟同步。接下来我们使用ceph-deploy工具在将要参与Ceph分布式文件系统的各个节点上，安装Ceph软件。注意，只是安装软件，并不是说完成后就可以让这些节点承担相应的工作职责了。以下命令只需要在安装了ceph-deploy的节点上执行就行了，ceph-deploy会帮助技术人员在指定的各个节点上使用yum命令安装ceph软件。接着使用以下命令在以上各个节点上正式安装Ceph软件：
[ceph@vmnode1 ~]$ ceph-deploy install vmnode1 vmnode2 vmnode3
// 命令格式为：
ceph-deploy install {ceph-node}[{ceph-node} ...]安装Ceph软件的过程中，有一定概率会出现各种警告信息。警告信息有的是可以忽略的，有的则是必须进行处理的。这些问题一般分为几类：镜像源和下载问题，依赖问题，权限问题。如何来处理这些问题，除了需要具备一定的玩转Linux系统的经验外，主要还是细心，切忌急躁。
MON是Monitor的简称，字面意义为监控、监视。是的，它的作用是监控、管理和协调整个分布式系统环境中其它各个OSD/PG、Client、MDS角色的工作，保证整个分布环境中的数据一致性。注意，为了保证节点故障的情况下，整个Ceph分布式文件系统依然可以稳定工作，我们必须设置多个MON角色。例如在本示例中，就设置参与Ceph分布式系统的三个节点上，都安装MON角色：
// 改名了意味新的MON节点
[ceph@vmnode1 ~]$ ceph-deploy new vmnode1 vmnode2 vmnode3
// 命令格式为：
ceph-deploy new {initial-monitor-node(s)}以上命令运行后，ceph-deploy工具会在本节点生成一些文件，包括：
ceph.conf
ceph.log
ceph.mon.keyring最重要的文件当然就是ceph.conf文件了（实际上ceph.mon.keyring也很重要），观察这个文件内容：
[ceph@vmnode1 ~]$ cat ./ceph.conf
[global]
fsid = 50c157eb-6d74-4d7d-b8e8-959a7b855b55
mon_initial_members = vmnode1, vmnode2, vmnode3
mon_host = 172.16.71.182,172.16.71.183,172.16.71.184
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx可以看到ceph.conf文件中已经设置好了我们将要运行MON角色的三个节点信息。接下来我们还需要在ceph.conf文件中增加一些信息，如下（后文还会详细讲解ceph中的重要参数）：
[ceph@vmnode1 ~]$ vim ./ceph.conf
......
# 后续的文章会详细讲解ceph中重要的配置项
osd pool default size = 2
osd pool default min size = 2
max open files = 655350
cephx cluster require signatures = false
cephx service require signatures = false
......接着使用以下命令，就可以在conf文件中已配置的MON节点上启动MON服务了（前提是，这些节点已经成功安装了Ceph软件）：
# 开始初始化运行mon节点。
[ceph@vmnode1 ~]$ceph-deploy mon create-initial
# 如果需要指定一些自定义的配置参数，可以采用如下格式（命令有详细的帮助信息）来启动
[ceph@vmnode1 ~]$ceph-deploy --overwrite-conf --cluster ceph mon create-initial每一个Ceph分布式系统都会有一个名字，如果在创建MON时不给定这个名字就会默认为“ceph”。完成以上步骤后，ceph-deploy工具会在当前运行命令的目录下生成几个文件，这些文件都非常重要，请不要擅自改动。在随后的安装过程中ceph-deploy工具将按需将这些文件复制到对应角色的对应目录中去。
{cluster-name}.client.admin.keyring
{cluster-name}.bootstrap-osd.keyring
{cluster-name}.bootstrap-mds.keyring
{cluster-name}.bootstrap-rgw.keyring在Ceph中，最终进行块存储落地操作的节点叫做OSD（Object Storage Device），实际上OSD只是Ceph中进行块存储操作的若干技术的一个载体，基于它工作的RADOS、PG等模块的设计思路才更值得学习借鉴（后续的文章会着重讨论）。但是，我们要是都不先行把OSD安装好并让它运行起来，又怎么进行学些呢？上文已经提到Ceph的对于块存储设备的操作，只能基于XFS、BTRFS或者EXT4,，并且需要是独立的磁盘分区和挂载点。
我们需要在vmnode1、vmnode2、vmnode3三个测试节点上安装Ceph，这三个节点上提供给Ceph使用的磁盘分区都是/dev/sdb1，使用文件系统格式都为XFS，磁盘挂载点都是/user/cephdata。这里就不在上图，不在讲解如何进行磁盘分区和格式化了，读者可以根据自己的实际情况进行操作。以下命令用于使用ceph-deploy设定OSD节点：
[ceph@vmnode1 ~]$ ceph-deploy osd prepare vmnode1:/user/cephdata vmnode2:/user/cephdata vmnode3:/user/cephdata
# 命令格式如下:
# ceph-deploy osd prepare {ceph-node}:{path} ...ceph-node代表节点host名字，也可以直接使用IP，Path为挂载点的起始路径。如果有多个OSD节点的信息，则依次书写就行了。完成后使用以下命令启动这些OSD节点：
#启动OSD节点
[ceph@vmnode1 ~]$ ceph-deploy osd activate vmnode1:/user/cephdata vmnode2:/user/cephdata vmnode3:/user/cephdata
# 命令格式如下：
# ceph-deploy osd activate {ceph-node}:{path} ...
# 或者使用以下语句启动单个OSD节点也行
# ceph-disk -v activate --mark-init sysvinit --mount /user/cephdata/
# 你也可以使用以下命令，检查整个系统中OSD节点的状态
# sudo ceph --cluster=ceph osd stat --format=jsonOSD节点启动成功后还可以通过很多方式检查它（们）是否正常工作。例如使用以下命令进行检查：
[ceph@vmnode1 ~]$ sudo ceph osd stat
osdmap e11: 3 osds: 3 up, 3 in以上输出的信息很好理解了，唯一可能不清楚的就是“osdmap e11”这个信息。Ceph中的MON角色其中有一个重要的工作就是监控Ceph中所有的OSD节点的工作状态，例如哪些OSD节点退出了Ceph环境，哪些新的OSD节点需要加入到Ceph环境。MON中的OSD Map就负责记录这些状态。至于“e11”中的“e”是epoch的简称，中文意思就是“时代”，MON中的OSD Map信息是要提供给Ceph中其它角色进行查询的（例如Client、各个OSD节点本身），而由于是分布式环境（存在节点间被割裂的情况），所以并不能保证这些角色在第一时间拿到最新版本的OSD Map信息，这时就要求MON Leader中记录目前最新版本的OSD Map的版本信息，以便Ceph中各个角色能够确定自己当前记录的OSD Map是不是最新的，而每一个新版本都会使OSD Map的epoch信息 + 1。关于最新版本的epoch信息在整个Ceph中是怎么进行传播的，后文还会进行描述。
执行完以上步骤后，Ceph节点的主要安装过程实际上就已经完成了，但这个时候Ceph分布式文件系统还无法正常工作/无法被Client正常连接（使用原生mount或者FUSE方式，都不会挂载成功）。如果使用以下命令查看，将会返回类似信息：
[root@vmnode1 ~]# sudo ceph mds stat
e1: 0/0/0 up大意是Ceph系统中有0个MDS角色，0个节点处于工作状态。这一小节的重要工作就是为Ceph系统创建MDS角色。首先我们通过ceph-deploy创建MDS节点：
[ceph@vmnode1 ~]$ ceph-deploy mds create vmnode1 vmnode2 vmnode3注意MDS节点创建完成后不是说MDS角色就可以正常工作了，而只是说指定好了MDS角色将在哪些节点上进行工作。MDS角色的工作必须基于OSD Pool——MDS数据信息将在OSD节点上进行存储，所以我们还需要通过以下命令创建至少两个OSD Pool数据池：
[root@vmnode1 ~]# sudo ceph osd pool create cephfs_data 10
[ceph@vmnode1 ~]$ sudo ceph osd pool create cephfs_metadata 10
// 命令格式：
osd pool create <poolname> <int[0-]>
{<int[0-]>} {replicated|erasure}
{<erasure_code_profile>} {<ruleset>}
{<int>}以上命令中“cephfs_data”表示OSD Pool的名称，而指定的“10”表示这个Pool所使用的PG数量，关于PG的定义和工作方式我们将在后续文章中进行介绍。那么我们为什么要创建名叫cephfs_data和cephfs_metadata的两个OSD Pool呢？这是因为其中一个OSD Pool要用来存储真实数据，另一个OSD Pool要用来存储元（Metadata）数据，而这些元数据将被MDS角色使用。接下来基于已建立的OSD Pool创建Ceph文件系统：
[root@vmnode1 ~]# sudo ceph fs new cephfs cephfs_metadata cephfs_data
// new fs with metadata pool 2 and data pool 1
// 命令格式为：
fs new <fs_name> <metadata> <data>其中cephfs表示新创建的Ceph文件系统的名称，cephfs_metadata表示存储文件系统元数据（Metadata）所使用的OSD Pool，cephfs_data表示存储文件真实数据所使用的OSD Pool。以上关于建立MDS元数据更详尽的信息，可参见Ceph官方文档http://docs.ceph.com/docs/master/cephfs/createfs/部分的介绍。完成文件系统创建后，再次使用命令查看MDS角色状态，就可以看到以下信息：
[ceph@vmnode1 ~]$ sudo ceph mds stat
e4: 1/1/1 up {0=vmnode3=up:creating}, 2 up:standby注意，MDS角色的工作原理是主备模式。也就是说加入的新的MDS节点将作为备用节点。你也可以使用如下命令，看到目前OSD Pool的使用情况：
[ceph@vmnode1 ~]$ sudo ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
....M ....M ....M ....%
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
rbd 0 0 0 0 0
cephfs_data 1 0 0 0 0
cephfs_metadata 2 0 0 0 0 最后还可以使用以下命令，确定整个Ceph系统是健康的：
[ceph@vmnode1 ~]$ sudo ceph -s
cluster 50c157eb-6d74-4d7d-b8e8-959a7b855b55
health HEALTH_OK至此，整个Ceph分布式文件系统关于服务端各个角色的安装、配置工作才算真正完成（还没有对参数项进行优化）。接下来我们就可以将一个或者多个Client连接到Ceph系统上进行使用了。
================
（接下文）
架构设计：系统存储（27）——分布式文件系统Ceph（安装）
标签：write 经验 并且 form 这一 .text class mds set
原文地址：http://blog.csdn.net/yinwenjie/article/details/68486770
