标签：知识 范围 通过 cloc ber cte 活动 process 日志
（接上文《架构设计：系统存储（27）——分布式文件系统Ceph（安装）》）
完成Ceph文件系统的创建过程后，就可以让客户端连接过去。Ceph支持两种客户端挂载方式：使用Linux内核支持的mount命令进行的挂载方式；使用用户空间文件系统FUSE（Filesystem in Userspace）进行的网络磁盘挂载方式。这两种挂载方式的本质区别是，前者需要有Linux内核的支持，而后者只是工作在Linux上的一个应用软件。
这里要特别说明以下，CentOS 6.X和CentOS 7早期版本的内核都不支持使用mount命令直接进行Ceph分布式文件系统客户端的挂载，这主要是Kernel内核版本的原因，所以如果您发现您使用的操作系统有这个问题，就需要首先升级CentOS的版本（另外建议使用首先选用CentOS 7操作系统，或者版本较高的Ubuntu操作系统） 。关于Kernel内核版本升级的操作，后文也会进行介绍。另外从Kernel 3.10 版本开始（从其它网络资料上看，不用单独进行内核升级便可直接使用mount命令进行挂载的版本号，还可以往前推）。
还记得当上篇文章中，我们在介绍Ceph的安装过程时，曾经介绍了一个CentOS的第三方扩展源epel吗？在这个源中，还可以直接升级您CentOS 7操作系统的Kernel内核：
[.....]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[.....]# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
[.....]# yum install -y yum-plugin-fastestmirror
[.....]# yum --enablerepo=elrepo-kernel install kernel-ml kernel-ml-devel
[.....]# grub2-set-default 0
// 重启，一定要重启
[.....]# reboot 现在您可以使用CentOS 7 操作系统提供的mount命令，将Ceph分布式文件系统作为您的本地磁盘进行挂载了。但是在挂载之前还有最后一个步骤需要确认：您需要获得Ceph分布式文件系统给Client的权限信息。这个权限信息在文件“ceph.client.admin.keyring”中，这个文件在您安装的每个Ceph节点的“/etc/ceph”目录位置，另外，您还可以在运行ceph-deploy的安装节点的中，ceph用户的主目录下找到它：
// 可以在这里找到它
[.....]# sudo cat /etc/ceph/ceph.client.admin.keyring
[client.admin]
key = AQDh991Y7T7hExAAYStCjopatfvUC+/AEHqjcQ==
caps mds = "allow"
caps mon = "allow *"
caps osd = "allow *"
// 也可以在这里找到它
[ceph@vmnode1 ~]$ cat ./ceph.client.admin.keyring
[client.admin]
key = AQDh991Y7T7hExAAYStCjopatfvUC+/AEHqjcQ==
caps mds = "allow"
caps mon = "allow *"
caps osd = "allow *"接下来可以进行挂载了：
[root@client ~]# mkdir /mnt/cephclient
[root@client ~]# mount.ceph vmnode1:6789:/,vmnode2:6789:/,vmnode3:6789:/ /mnt/cephclient/ -o name=admin,secret=AQDh991Y7T7hExAAYStCjopatfvUC+/AEHqjcQ==
// 或者以下命令也行
[root@client ~]# mount -t ceph vmnode1:6789:/,vmnode2:6789:/,vmnode3:6789:/ /mnt/cephclient/ -o name=admin,secret=AQDh991Y7T7hExAAYStCjopatfvUC+/AEHqjcQ==注意，请确保防火墙没有阻挡Ceph各个节点所使用的端口（不止包括6789这个端口）。以上的vmnode1、vmnode2、vmnode3表示MON角色所在的节点，注意携带的name参数和secret参数都来源于ceph.client.admin.keyring文件中的内容，其中name属性，对应文件中的“[client.admin]”，secret属性，对应文件中的“key”。您还可以直接将ceph.client.admin.keyring拷贝到Ceph Client节点，然后在挂载时，使用secretfile参数指定这个文件。
ceph-fuse可以通过ceph-deploy进行安装，也可以使用yum命令进行安装。如果要运行ceph-fuse命令，Client节点上就必须要有ceph.conf和ceph.client.admin.keyring这两个文件。
// 记得首先设置ceph的安装镜像
[root@client ~]# yum install -y ceph-fuse接着可以使用以下命名进行挂载：
[root@client ~]# ceph-fuse -m vmnode1,vmnode2,vmnode3 /mnt/cephclient/同之前讲解的命令大致相同，vmnode1、vmnode2、vmnode3表示MON角色所在的节点。另外可以使用“-c” 参数指定ceph.conf文件所在位置，还可以使用”-k”参数指定ceph.client.admin.keyring文件所在位置。否则这两个文件就是放置在运行这个命令时，所在的目录下。例如以上示例中就是在root用户的工作目录/root/下运行ceph-fuse命令的。
这个错误是Ceph Client在进行挂载操作时，最常见的一种错误。引起这类错误最直接的原因，就是Ceph分布式文件系统的健康状态不正确，或者换一个更明确的说法：使用“ceph -s”命令查看Ceph系统状态时，返回的信息不为“health HEALTH_OK”。
无论你是使用Linux操作系统原生的mount命令进行Ceph Client的挂载，还是使用Ceph-Fuse进行挂载，在挂载前必须确认Ceph系统的工作状态为“health HEALTH_OK”，其它任何带有警告信息、报错信息的状态返回，都会导致Ceph Client挂载失败。那么“error 5 = Input/output error”这个问题实际上就转变为了，Ceph文件系统的健康状态常见的错误有哪些了。
您可以使用以下命令检查MDS的工作状态：
// 类似以下的MDS状态返回信息，说明MDS工作是正确的
[root@vmnode ~]# ceph mds stat
e95: 1/1/1 up {0=vmnode1=up:active}, 1 up:standby
// 而类似以下的MDS状态返回信息，说明MDS可能是有问题的，甚至还没有创建MDS角色
[root@vmnode ~]# ceph mds stat
e1: 0/0/0 upMON角色没有创建或者没有启动同样会导致Ceph集群工作状态错误，您可以使用以下命令检查MON的工作状态：
// 类似以下的MON工作状态反馈，说明MON角色是正常的
[root@vmnode ~]# ceph mon stat
e2: 3 mons at {vmnode1=......:6789/0,vmnode2=.......:6789/0,vmnode3=.......:6789/0}, election epoch 84, quorum 0,1,2 vmnode1,vmnode2,vmnode3
由于Ceph文件系统中MON角色采用主备（Leader/Follower）模式，所以只要有至少一个MON是在正常工作的就行。关于以上示例中查看MON工作状态的返回信息，也反映了MON的工作原理，我们将在后续文章中进行讲解。
从笔者使用Ceph的经验来看，OSD角色和OSD Pool是最容易出现问题的。其本质原因是对PG的设定可能需要按照实际情况进行更改，而一些技术人员不熟悉PG的工作原理。OSD的配置和常见问题我们也放到后文，用专门的章节进行说明。例如，类似以下的信息只能说明OSD在工作，并不能说明OSD上的PG没有问题：
[root@vmnode ~]# ceph osd stat
osdmap e48: 3 osds: 3 up, 3 inCeph分布式文件系统上的各个工作节点需要保证系统时间同步，Ceph默认能够容忍的各节点最大时间偏移量为0.05S，当然这个值可以进行设定，但不建议更改设定。类似以下的Ceph系统健康警告信息，就是由于节点间时间偏移较大导致的：
......
HEALTH_WARN clock skew detected on vmnode1; 8 requests are blocked > 32 sec; Monitor clock skew detected
......另外您也可以使用以下命令查看Ceph文件系统的实时状态变化，如果发现有类似以下的警告，也说明Ceph各个节点间的系统时间偏移量过大：
[root@vmnode1 ~]# ceph -w
......
XXXXXXXXX mon.0 [WRN] mon.1 172.16.71.186:6789/0 clock skew 0.424674s > max 0.05s
......我们一般使用Linux系统下的NTPD时间同步服务，来保证每个节点的时间同步，您可以运行ntpdate命令并保证Ceph系统中的所有节点都使用同一个时区服务。例如：
......
[root@vmnode ~]# ntpdate 0.asia.pool.ntp.org
// 运行完成后，最好重启ntpd服务
[root@vmnode ~]# service ntpd restart 注意以上命令并不是要求Linux系统立即同步时间，而只是设定了时间同步服务，所以会有一定的同步延迟，另外您还需要保证这个节点能够访问外部网络。如果仍然有关于时间偏移的健康警告，则重启整个Ceph系统。
另外你可以使用Ceph系统中的一个节点作为基准时间节点，然后其它节点的时间都已前者为准进行同步（这种方式网络上有很多资料可以参考）。或者可以使用以下命令进行强制同步：
[root@vmnode1 ~]# ntpdate -u asia.pool.ntp.org
XXXXXXX ntpdate[3864]: adjust time server 202.156.0.34 offset -0.073284 secSELinux是一种独立运行的访问控制功能，它能控制程序只能访问特定文件。笔者建议关闭Ceph分布式文件系统中，各个节点上的SELinux功能。首先，您可以通过以下命令查看SELinux功能是否在运行：
[root@vmnode ~]# sestatus
......
// 如果返回的信息中存在描述，则说明SELinux在工作
SELinux status: enabled
......要关闭SELinux功能，需要修改“/etc/selinux/config”文件，将文件中的SELINUX=enforcing改为SELINUX=disabled，修改保存后一定要重启操作系统。
当然以上列举的导致Ceph健康状态异常的原因并不完整，例如也有可能是ceph.conf文件本身的读取权限设定问题，导致整个Ceph节点上的所有工作角色启动失败。本小节对于挂载失败情况下的问题总结也只是给各位读者一个排查问题的思路。是否能走完挂载Ceph文件系统的最后一步，还是要靠各位读者使用Ceph系统，甚至是使用LInux操作系统所积累的问题排查经验。后续文章中，我们将介绍Ceph分布式文件系统中各个重要角色的分工和工作原理，以及Ceph系统的配置优化项，这些知识总结都将更有助于读者排查日常工作中Ceph文件系统出现问题的原因。
Ceph作为一款分布式文件系统/分布式对象存储系统，在IaaS层的应用已经越来越广泛。例如我们熟知的OpenStack，在其存储方案部分就允许使用Ceph替换掉Swift；而独立应用Ceph直接作为数据持久化存储方案的例子也很多，例如可以直接使用Ceph作为静态文件的存储方案、作为大数据分析过程中还未来得及做数据清理的原始文件（数据）的存储方案，在本专题之前介绍搭建自己的图片服务器文章时，就提到可以使用Ceph作为原始图片文件的持久化存储方案。再多说一句，这些文件不宜过小，如果存储规模在千亿级、万亿级，大小范围在1KB左右的文件，还是建议更换存储方案。后文在讨论了Ceph文件系统的工作原理后，我们再回头讨论Ceph文件系统对海量小文件（千亿级、万亿级）存储的支持。
既然Ceph在生产环境的地位越发重要，那么它的稳定性和可管理性也就越发重要了。好消息是Ceph文件系统提供了非常全面的日志功能，帮助我们进行日常运维管理。这些日志信息按照Ceph系统中的成员角色、工作节点和日志产生时间进行划分，默认的位置在Linux系统存放日志的目录中（当然您可以通过更改Ceph的配置项，改变Ceph输出日志文件的位置）：
[root@vmnode1 ~]# ll /var/log/ceph/
......
-rw------- 1 root root 0 4月 13 09:28 ceph.audit.log
-rw------- 1 root root 1503 4月 11 04:26 ceph.audit.log-20170411.gz
-rw------- 1 root root 2098 4月 13 08:34 ceph.audit.log-20170413.gz
-rw------- 1 root root 133 4月 13 09:29 ceph.log
-rw------- 1 root root 1470 4月 11 04:27 ceph.log-20170411.gz
-rw------- 1 root root 63911 4月 13 09:24 ceph.log-20170413.gz
-rw-r--r-- 1 root root 0 4月 13 09:28 ceph-mds.vmnode1.log
-rw-r--r-- 1 root root 727 4月 11 04:27 ceph-mds.vmnode1.log-20170411.gz
-rw-r--r-- 1 root root 5446 4月 13 08:37 ceph-mds.vmnode1.log-20170413.gz
-rw-r--r-- 1 root root 888 4月 13 09:33 ceph-mon.vmnode1.log
-rw-r--r-- 1 root root 3520 4月 11 04:27 ceph-mon.vmnode1.log-20170411.gz
-rw-r--r-- 1 root root 38353 4月 13 09:27 ceph-mon.vmnode1.log-20170413.gz
-rw-r--r-- 1 root root 0 4月 13 09:28 ceph-osd.0.log
-rw-r--r-- 1 root root 528 4月 11 04:12 ceph-osd.0.log-20170411.gz
-rw-r--r-- 1 root root 164041 4月 13 09:13 ceph-osd.0.log-20170413.gz
-rw-r--r-- 1 root root 50865 4月 13 09:13 ceph-osd.3.log
......为了方便管理您可以使用我们在之前专题介绍的Apache Flume对日志文件信息进行转移和汇总，以便于在一个固定的管理节点上查看所有节点的日志信息。Ceph文件系统还提供了一个系列用来即时反应文件系统内部变化，并输出到终端屏幕的命令：
-w, --watch watch live cluster changes
--watch-debug watch debug events
--watch-info watch info events
--watch-sec watch security events
--watch-warn watch warn events
--watch-error watch error events
// 使用示例为：
[root@vmnode2 ~]# ceph -w
// 实际上我们之前介绍的ceph -s命令，算是它的一个简化版本
[root@vmnode2 ~]# ceph -s最后建议在检查/排查Ceph文件系统问题时，第一步就是使用ceph -w命令检视当前Ceph文件系统的活动变化情况。
安装Ceph文件系统的过程，特别是第一次安装Ceph文件系统的过程，绝对不会顺利。笔者最悲催的经历是连续搞了三次，整整花了2天时间，才把一个10节点的Ceph文件系统部署成功（最后总结发现是多种常见问题叠加导致的后果）。一旦出现问题，又长时间的无法解决，那么最暴力的办法就是回到第一步，重新安装整个Ceph文件系统。
好消息是ceph-deploy为我们提供了简便的命令，清除整个Ceph系统上所有节点的安装痕迹，恢复节点到初始状态：
// 以下命令清除指定节点上的ceph相关组件，类似于运行yum remove ceph ....
[root@vmnode1 ~]# ceph-deploy purge {ceph-node} [{ceph-node}]
// 命令示例为:
[root@vmnode1 ~]# ceph-deploy purge vmnode1 vmnode2 vmnode3
// 以下命令清除指定节点上ceph的相关目录、文件信息
// 类似于运行 rm -rf /home/ceph/* /etc/ceph/ ......
[root@vmnode1 ~]# ceph-deploy purgedata {ceph-node} [{ceph-node}]
// 命令示例为:
[root@vmnode1 ~]# ceph-deploy purgedata vmnode1 vmnode2 vmnode3注意，ceph-deploy属于“安装助手”性质，所以ceph-deploy本身没有必要也删除掉。
架构设计：系统存储（28）——分布式文件系统Ceph（挂载）
标签：知识 范围 通过 cloc ber cte 活动 process 日志
原文地址：http://blog.csdn.net/yinwenjie/article/details/69237776
