每天5分鐘複習OpenStack（十二）Ceph FileStore 和 BlueSotre

ALEX_li88發表於2023-12-05

一個最小化的Ceph叢集需要三個元件MON MGR OSD.上一章我們部署了MON,本章節我們完成剩下MGR 和OSD 的部署。在文末我們將重點介紹下什麼是FileStore和BlueStore，並詳細分析其特點，來說明為什麼Ceph社群放棄了FileStore，直接採用了BlueStore.

1、MGR 部署

  1. 建立mgr工作目錄
sudo -u ceph mkdir /var/lib/ceph/mgr/ceph-mon01
  1. 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
  1. 修改目錄的屬主和屬組為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以確保它們之間使用最新的訊息傳遞協議。

總結：

  1. msgr是MON用來訊息傳遞的協議，目前有兩個版本V1 和V2 ，V1版本使用6789埠，
    V2版本使用3300埠。

  2. 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的特點：

  1. 無論是資料還是後設資料都是先寫日誌盤，再由日誌盤同步到資料盤。存在資料雙寫問題。
  2. 無論是資料還是後設資料都是在檔案系統層之上，存在檔案系統層的寫放大問題。
  3. 日誌盤同步資料到資料盤時日誌盤不能寫入有效能問題。
  4. 為加速對後設資料的訪問，用鍵值資料庫LevelDB來最佳化其訪問,LevelDB為保證事務的持久化採用WAL。

BlueStore的誕生是為了解決FileStore同時維護一套日誌系統和基於檔案系統寫放大的問題，實現FileStore本身沒有的對SSD的最優支援

  1. BlueStore 資料是直接寫入裸盤的，不存在雙寫問題
  2. BlueStore 資料寫入的裸盤中是沒有檔案系統層的。
  3. 實現在使用者態下使用linux aio直接對裸裝置進行I/O操作，去除了本地檔案系統的消耗，減少系統複雜度，更有利於Flash介質盤發揮效能優勢
  4. 採用RockDB來儲存物件的後設資料和DB WAL 。RocksDB是一種嵌入式高效能鍵/值儲存。在快閃記憶體儲存方面表現出色，RocksDB無法直接寫入原始磁碟裝置，需要底層檔案系統來儲存其持久化資料，因此設計了BlueFS。
  5. 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磁碟是遠遠不夠的。因此下一章節我們將介紹儲存的快取技術。聊下目前比較流行的兩種儲存的快取技術。


相關文章