（接上文《架构设计：系统存储（27）——分布式文件系统Ceph（安装）》）
3. 连接到Ceph系统
3-1. 连接客户端
完毕Ceph文件系统的创建过程后。就能够让客户端连接过去。
Ceph支持两种客户端挂载方式：使用Linux内核支持的mount命令进行的挂载方式。使用用户空间文件系统FUSE（Filesystem in Userspace）进行的网络磁盘挂载方式。
这两种挂载方式的本质差别是，前者须要有Linux内核的支持。而后者仅仅是工作在Linux上的一个应用软件。
3-1-1. 使用mount命令进行挂载
这里要特别说明下面，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 *"
// 也能夠在這裏找到它
[[email protected] ~]$ 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参数指定这个文件。
3-1-2. 使用FUSE进行挂载
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命令的。
3-2. 挂载时的常见问题
3-2-1. 关于error 5 = Input/output error
这个错误是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狀態返回信息，說明MDS工作是正確的
[[email protected] ~]# ceph mds stat
e95: 1/1/1 up {0=vmnode1=up:active}, 1 up:standby
// 而相似下面的MDS狀態返回信息。說明MDS可能是有問題的，甚至還沒有創建MDS角色
[[email protected] ~]# ceph mds stat
e1: 0/0/0 up- 由MON未启动或者状态错误导致的：
MON角色没有创建或者没有启动相同会导致Ceph集群工作状态错误。您能够使用下面命令检查MON的工作状态：
// 相似下面的MON工作狀態反饋。說明MON角色是正常的
[[email protected] ~]# 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的工作原理。我们将在兴许文章中进行解说。
- 由OSD未启动或者PG太少或者OSD Pool错误导致的：
从笔者使用Ceph的经验来看，OSD角色和OSD Pool是最easy出现故障的。
其本质原因是对PG的设定可能须要依照实际情况进行更改。而一些技术人员不熟悉PG的工作原理。
OSD的配置和常见问题我们也放到后文，用专门的章节进行说明。
比如，相似下面的信息仅仅能说明OSD在工作。并不能说明OSD上的PG没有问题：
[root@vmnode ~]# ceph osd stat
osdmap e48: 3 osds: 3 up, 3 in- 由NTPD时间偏移导致的（出现概率非常大）：
Ceph分布式文件系统上的各个工作节点须要保证系统时间同步。Ceph默认能够容忍的各节点最大时间偏移量为0.05S。当然这个值能够进行设定，但不建议更改设定。相似下面的Ceph系统健康警告信息。就是因为节点间时间偏移较大导致的：
......
HEALTH_WARN clock skew detected on vmnode1; 8 requests are blocked > 32 sec; Monitor clock skew detected
......另外您也能够使用下面命令查看Ceph文件系统的实时状态变化，假设发现有相似下面的警告，也说明Ceph各个节点间的系统时间偏移量过大：
[[email protected] ~]# 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 sec- 由SELinux未关闭导致的：
SELinux是一种独立执行的访问控制功能，它能控制程序仅仅能访问特定文件。笔者建议关闭Ceph分布式文件系统中，各个节点上的SELinux功能。首先。您能够通过下面命令查看SELinux功能是否在执行：
[[email protected] ~]# sestatus
......
// 假設返回的信息中存在描寫敘述，則說明SELinux在工作
SELinux status: enabled
......要关闭SELinux功能，须要改动“/etc/selinux/config”文件。将文件里的SELINUX=enforcing改为SELINUX=disabled，改动保存后一定要重新启动操作系统。
- 由其他问题导致的：
当然以上列举的导致Ceph健康状态异常的原因并不完整，比如也有可能是ceph.conf文件本身的读取权限设定问题，导致整个Ceph节点上的全部工作角色启动失败。本小节对于挂载失败情况下的问题总结也仅仅是给各位读者一个排查问题的思路。能否走完挂载Ceph文件系统的最后一步，还是要靠各位读者使用Ceph系统。甚至是使用LInux操作系统所积累的问题排查经验。兴许文章中，我们将介绍Ceph分布式文件系统中各个重要角色的分工和工作原理，以及Ceph系统的配置优化项，这些知识总结都将更有助于读者排查日常工作中Ceph文件系统出现故障的原因。
3-2-2. 关于Ceph的日志
Ceph作为一款分布式文件系统/分布式对象存储系统。在IaaS层的应用已经越来越广泛。比如我们熟知的OpenStack，在其存储方案部分就同意使用Ceph替换掉Swift。而独立应用Ceph直接作为数据持久化存储方案的样例也非常多，比如能够直接使用Ceph作为静态文件的存储方案、作为大数据分析过程中还未来得及做数据清理的原始文件（数据）的存储方案，在本专题之前介绍搭建自己的图片服务器文章时，就提到能够使用Ceph作为原始图片文件的持久化存储方案。再多说一句，这些文件不宜过小，假设存储规模在千亿级、万亿级。大小范围在1KB左右的文件。还是建议更换存储方案。后文在讨论了Ceph文件系统的工作原理后。我们再回头讨论Ceph文件系统对海量小文件（千亿级、万亿级）存储的支持。
既然Ceph在生产环境的地位越发重要，那么它的稳定性和可管理性也就越发重要了。
好消息是Ceph文件系统提供了非常全面的日志功能，帮助我们进行日常运维管理。这些日志信息依照Ceph系统中的成员角色、工作节点和日志产生时间进行划分。默认的位置在Linux系统存放日志的文件夹中（当然您能够通过更改Ceph的配置项，改变Ceph输出日志文件的位置）：
[[email protected] ~]# 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