每天5分鐘複習OpenStack（十二）Ceph FileStore 和 BlueSotre
一個最小化的Ceph叢集需要三個元件MON MGR OSD.上一章我們部署了MON,本章節我們完成剩下MGR 和OSD 的部署。在文末我們將重點介紹下什麼是FileStore和BlueStore，並詳細分析其特點，來說明為什麼Ceph社群放棄了FileStore，直接採用了BlueStore.
1、MGR 部署
- 建立mgr工作目錄
sudo -u ceph mkdir /var/lib/ceph/mgr/ceph-mon01
- mgr 授權
#例子 ceph auth get-or-create mgr.$name mon \
# 'allow profile mgr' osd 'allow *' mds 'allow *'
# allow profile mgr 表示允許管理和設定mgr 的許可權
ceph auth get-or-create mgr.mon01 mon \
'allow profile mgr' osd 'allow *' mds 'allow *' \
> /var/lib/ceph/mgr/ceph-mon01/keyring
- 修改目錄的屬主和屬組為ceph使用者，並啟動ceph-mgr 程序
chown -R ceph:ceph /var/lib/ceph/mgr/
systemctl restart ceph-mgr@mon01
systemctl enable ceph-mgr@mon01
4、檢查叢集狀態
[root@mon01 tmp]# ceph -s
cluster:
id: 51be96b7-fb6b-4d68-8798-665278119188
health: HEALTH_WARN
mon is allowing insecure global_id reclaim
1 monitors have not enabled msgr2
services:
mon: 1 daemons, quorum mon01 (age 44m)
mgr: mon01(active, since 1.5342s)
osd: 0 osds: 0 up, 0 in
data:
pools: 0 pools, 0 pgs
objects: 0 objects, 0 B
usage: 0 B used, 0 B / 0 B avail
pgs:
此時發現mgr: mon01 顯示active 為活動狀態表示部署成功。 但是Ceph 叢集的狀態還是顯示為HEALTH_WARN。
- 問題1 ： 1 monitors have not enabled msgr2
msgr2協定 是Ceph中的新訊息傳遞協定，它帶來了一些效能和安全性方面的改進。在叢集中，所有的監視器都應該啟用msgr2以確保它們之間使用最新的訊息傳遞協定。
總結：
-
msgr是MON用來訊息傳遞的協定，目前有兩個版本V1 和V2 ，V1版本使用6789埠，
V2版本使用3300埠。 -
ceph mon enable-msgr2開啟V2版 訊息傳遞協定。
【思考】：做過ceph運維的小夥伴肯定會遇見一種情況就是執行ceph -s 或其他ceph命令時命令一直卡住，很長時間都沒有反應，第一次遇見此情況的小夥伴甚至懷疑叢集宕機了。
【實驗】 禁止本機3300埠
#使用iptables 規制禁止了3300埠的存取
iptables -A INPUT -p tcp -m tcp --dport 3300 -j DROP
現在我們使用ceph -s 命令背後的邏輯
- 先確定其程序編號
- lsof 檢視其命令存取的埠號
從上圖中發現其確實存取的3300埠。因此我們得出結論，當執行ceph命令時，程序卡住了，先檢查下3300 和6789 埠是否能正常存取。 iptables -F 清空filter 表後恢復正常
- 問題2： mon is allowing insecure global_id reclaim
#關閉非安全的叢集id 回收
ceph config set mon \
auth_allow_insecure_global_id_reclaim false
2、OSD 部署
OSD的安裝可以分兩步：初始化、啟用，也可以一步到位。
#初始化
ceph-volume lvm prepare --data /dev/sdb
ceph-volume lvm list
#來獲取osd.id 和 osd fsid
#啟用
ceph-volume lvm activate 0 acdadb1a-ed18-4068-bbcb-432ba0cfcdb2
驗證第一個osd
第二個osd 和第三三個osd 安裝使用create 等於上面的兩步
ceph-volume lvm create --data /dev/sdc
ceph-volume lvm create --data /dev/sdd
到此整個ceph 叢集就部署完成了，一個MON ，一個MGR 和3個OSD 組成了一個最小化的Ceph叢集。
不過上述的部署方式僅限於測試環境，生產環境切勿直接使用上述命令。為什麼？
對ceph 有過生產經驗的小夥伴都知道，Ceph是需要紀錄檔盤的。這裡我們只使用了資料盤，那紀錄檔盤了？
要解釋清楚這個問題，我們先弄清楚FileStore 和 BlueStore
3、Filestore or Bluestore
在之前的章節中我們曾介紹說，一般資料可以簡單分為兩部分，資料和後設資料，在Ceph叢集中，資料在寫入叢集時，將被使用者端分割成4MB為單位的物件。每個物件都會寫入OSD來實現落盤。在FileStore中每一個物件都需要通過FileStore的功能來實現將物件寫入磁碟。
Ceph採用的是全紀錄檔系統，也就是說將所有資料存放在紀錄檔中（資料和後設資料都存放在紀錄檔中），這樣做的好處是Ceph可以先把一些零散的、隨機的I/O請求儲存到快取中並進行合併，然後再統一向核心發起I/O請求。這樣做效率會比較高，其帶來的問題就是一旦OSD崩潰，快取中的資料就會丟失。因此Ceph的紀錄檔是事務紀錄檔。事務紀錄檔不是真正去修改資料，而是記錄資料修改的操作，這樣當資料崩潰後，只要基於當前時間節點回放事務紀錄檔就能還原資料。
寫紀錄檔有兩種模式：Parallel和Writeahead。
- Parallel（並行寫）： 是紀錄檔和磁碟資料同時寫；
- Writeahead（預寫紀錄檔）： 是先寫紀錄檔，只要紀錄檔寫成功，就返回，後臺每隔一段時間會同步紀錄檔中的寫操作，實現落盤。這種方法帶來的好處就是，可以把很多小I/O請求合併，形成順序寫盤，提高每秒讀寫次數。通常在生產環境中，我們使用SSD來單獨儲存紀錄檔檔案，以提高Ceph讀寫效能。
在Writeahead模式下，Ceph物件（資料和後設資料）一旦寫入紀錄檔盤之後，就返回給使用者端寫入完成，之後按照一定的同步週期來將資料同步到後端真正的資料盤中。也就是說，當用戶寫入了一個物件資料（Ceph 中一切皆物件）返回成功時，可能該資料僅僅只是寫了紀錄檔盤，還沒有真正落入後端的儲存磁碟。這就引入了第一個問題，FileStore 的雙寫問題（資料先寫了紀錄檔盤，之後按一定週期寫入後端磁碟）。
其次是在ceph按一定週期將紀錄檔盤的資訊寫入後端資料盤時，其前端對紀錄檔的寫操作是要暫停的。專門執行紀錄檔資料到檔案系統的同步。紀錄檔系統空間大小代表能快取的資料量，同步時間的設定也會影響Ceph的效能。
在從檔案系統的角度來看，FileStore底層使用POSIX規範的檔案系統介面，例如xfs、ext4、btrfs,無論是資料還是後設資料，都需要先寫入檔案系統層（如圖中的XFS檔案系統），然後由XFS檔案系統介面來實現資料的落盤操作。我們可以簡單理解為其在檔案系統層也有寫放大的問題，增加了檔案系統層IO操作。
前文中我們提過，資料的後設資料的一些隨機的小IO，在FileStore 中使用Leveldb鍵/值資料庫來存放其後設資料，而Leveldb 為了保證自身事務的一致性，也採用事務紀錄檔來記錄其操作，而不是真正的後設資料進行操作。這些只是記錄操作本身，而不對真正資料操作的行為都可以稱為WAL（Write Ahead Log預寫紀錄檔），其優點是一方面提高了效率（將隨機IO變成了順序IO），另一方面也保證事務的唯一性要求。（其思想反覆應用在各種資料庫中）.
下面我們總結下FileSore的特點：
- 無論是資料還是後設資料都是先寫紀錄檔盤，再由紀錄檔盤同步到資料盤。存在資料雙寫問題。
- 無論是資料還是後設資料都是在檔案系統層之上，存在檔案系統層的寫放大問題。
- 紀錄檔盤同步資料到資料盤時紀錄檔盤不能寫入有效能問題。
- 為加速對後設資料的存取，用鍵值資料庫LevelDB來優化其存取,LevelDB為保證事務的持久化採用WAL。
BlueStore的誕生是為了解決FileStore同時維護一套紀錄檔系統和基於檔案系統寫放大的問題，實現FileStore本身沒有的對SSD的最優支援
- BlueStore 資料是直接寫入裸盤的，不存在雙寫問題
- BlueStore 資料寫入的裸盤中是沒有檔案系統層的。
- 實現在使用者態下使用linux aio直接對裸裝置進行I/O操作，去除了本地檔案系統的消耗，減少系統複雜度，更有利於Flash媒介盤發揮效能優勢
- 採用RockDB來儲存物件的後設資料和DB WAL 。RocksDB是一種嵌入式高效能鍵/值儲存。在快閃記憶體儲存方面表現出色，RocksDB無法直接寫入原始磁碟裝置，需要底層檔案系統來儲存其持久化資料，因此設計了BlueFS。
- BlueFS：簡化的檔案系統，解決後設資料、檔案及磁碟的空間分配和管理問題
無論是FileStore 還是BlueStore中為加速後設資料的存取都使用鍵值儲存資料庫，鍵值儲存資料是依賴檔案系統的。FileStore 採用了LevelDB ,BlueStore採用了BlueFS .為了持久化儲存事務紀錄檔都採用了預寫紀錄檔的方式（DB WAL）。
因此在生產中FileStore一般是用SSD磁碟作為為紀錄檔盤來使用，而資料盤一般是HDD磁碟。 而在BlueStore環境中 一般是採用兩塊SSD磁碟 ，一塊用作RockDB ,一塊用作DB WAL。體現在命令上如下
FileStore 環境
#--data 指定資料盤 --journal 指定紀錄檔盤，一般為分割區。
ceph-volume --cluster ceph lvm create --osd-id 0 /
--filestore --data /dev/sdb--journal /dev/sda1
#--data 指定資料盤 --block.db 指定RocksDB --block.wal 指定WAL
ceph-volume lvm create --bluestore \
--data /dev/{data_device} \
--block.db /dev/{db_device} \
--block.wal /dev/{wal_device}
問題：如何判斷一個Ceph叢集使用的是FileStore還是BlueStore ?
通過磁碟的type來判斷是比較通用的方式
[root@mon01 ~]# cat /var/lib/ceph/osd/ceph-0/type
bluestore
寫在最後
生產中儲存系統的IO上限就決定了整個系統的磁碟IO的上限。因此為了追求極致的IO，僅僅對後設資料的加速存取使用SSD或NVME磁碟是遠遠不夠的。因此下一章節我們將介紹儲存的快取技術。聊下目前比較流行的兩種儲存的快取技術。
