标签：包含 fse org 问题 func lan att rpm text
（接上文《架构设计：系统存储（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各个节点所使用的port（不止包含6789这个port）。以上的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是最easy出现故障的。
其本质原因是对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（挂载）
标签：包含 fse org 问题 func lan att rpm text
原文地址：http://www.cnblogs.com/blfbuaa/p/7374958.html
