架構設計：系統存儲（28）——分布式文件系統Ceph（掛載）
（接上文《架構設計：系統存儲（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
[.....]# grub 如今您能夠使用CentOS 7 操作系統提供的mount命令，將Ceph分布式文件系統作為您的本地磁盤進行掛載了。
可是在掛載之前還有最後一個步驟須要確認：您須要獲得Ceph分布式文件系統給Client的權限信息。
這個權限信息在文件“ceph.client.admin.keyring”中，這個文件在您安裝的每一個Ceph節點的“/etc/ceph”文件夾位置。另外，您還能夠在執行ceph-deploy的安裝節點的中，ceph用戶的主文件夾下找到它：
// 能夠在這裏找到它
[.....]# sudo cat /etc/ceph/ceph.client.admin.keyring 接下來能夠進行掛載了：
[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 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
// 使用演示樣例為：
[[email protected] ~]# ceph -w
// 實際上我們之前介紹的ceph -s命令，算是它的一個簡化版本號
[[email protected] ~]# ceph -s最後建議在檢查/排查Ceph文件系統問題時，第一步就是使用ceph -w命令檢視當前Ceph文件系統的活動變化情況。
3-2-3. 關於又一次安裝
安裝Ceph文件系統的過程，特別是第一次安裝Ceph文件系統的過程，絕對不會順利。筆者最悲催的經歷是連續搞了三次，整整花了2天時間。才把一個10節點的Ceph文件系統部署成功（最後總結發現是多種常見問題疊加導致的後果）。
一旦出現故障，又長時間的無法解決。那麽最暴力的辦法就是回到第一步，又一次安裝整個Ceph文件系統。
好消息是ceph-deploy為我們提供了簡便的命令。清除整個Ceph系統上全部節點的安裝痕跡。恢復節點到初始狀態：
// 下面命令清除指定節點上的ceph相關組件，相似於執行yum remove ceph ....
[[email protected] ~]# ceph-deploy purge {ceph-node} [{ceph-node}]
// 命令演示樣例為:
[[email protected] ~]# ceph-deploy purge vmnode1 vmnode2 vmnode3
// 下面命令清除指定節點上ceph的相關文件夾、文件信息
// 相似於執行 rm -rf /home/ceph/* /etc/ceph/ ......
[[email protected] ~]# ceph-deploy purgedata {ceph-node} [{ceph-node}]
// 命令演示樣例為:
[[email protected] ~]# ceph-deploy purgedata vmnode1 vmnode2 vmnode3註意，ceph-deploy屬於“安裝助手”性質，所以ceph-deploy本身沒有必要也刪除掉。
架構設計：系統存儲（28）——分布式文件系統Ceph（掛載）