3.Ceph 基礎篇 - RBD 塊儲存使用

阿新 • • 發佈：2022-03-18

文章轉載自：https://mp.weixin.qq.com/s?__biz=MzI1MDgwNzQ1MQ==&mid=2247485253&idx=1&sn=24d9b06a3c48ce74b30acf08807a243b&chksm=e9fdd2b1de8a5ba72ab7b221f3484a95f2a977ff7a607413e3a7b92d042d117c1f05c48a34b2&scene=178&cur_album_id=1600845417376776197#rd

資料儲存原理

The Ceph storage system supports the notion of ‘Pools’, which are logical partitions for storing objects.

Ceph Clients retrieve a Cluster Map from a Ceph Monitor, and write objects to pools. The pool’s size or number of replicas, the CRUSH rule and the number of placement groups determine how Ceph will place the data.

Ceph儲存系統支援“池”的概念，“池”是用於儲存物件的邏輯分割槽。

Ceph客戶端從Ceph監控器檢索叢集對映，並將物件寫入池中。池的大小或副本數，CRUSH規則和放置組的數量決定了Ceph將如何放置資料。

Pools set at least the following parameters:

Ownership/Access to Objects

The Number of Placement Groups, and

The CRUSH Rule to Use.

池至少設定以下引數：

所有權/對物件的訪問展示位置組數，以及使用的CRUSH規則。

Each pool has a number of placement groups. CRUSH maps PGs to OSDs dynamically. When a Ceph Client stores objects, CRUSH will map each object to a placement group.

每個儲存池中有很多的歸置組（PG），當一個Ceph 客戶端儲存一個物件時，CURSH 將對映每個物件到一個歸置組中，CRUSH map 動態對映 PGs 到OSDs。

Mapping objects to placement groups creates a layer of indirection between the Ceph OSD Daemon and the Ceph Client. The Ceph Storage Cluster must be able to grow (or shrink) and rebalance where it stores objects dynamically. If the Ceph Client “knew” which Ceph OSD Daemon had which object, that would create a tight coupling between the Ceph Client and the Ceph OSD Daemon. Instead, the CRUSH algorithm maps each object to a placement group and then maps each placement group to one or more Ceph OSD Daemons. This layer of indirection allows Ceph to rebalance dynamically when new Ceph OSD Daemons and the underlying OSD devices come online. The following diagram depicts how CRUSH maps objects to placement groups, and placement groups to OSDs.

為了建立檔案物件到歸置組的對映，在 Ceph OSD Daemon 和 Ceph Client 建立一個間接層；Ceph 儲存叢集能夠儲存資料時動態的增長（或縮減）和再平衡。如果 Ceph Client 知道哪個 Ceph OSD 程序擁有哪個物件，那麼會在 Ceph Clinet 與 OSD 程序間建立一個緊密的耦合，CRUSH 演算法把檔案物件對映成歸置組，每個 PG 又對映成一個或多個 OSD；當一個新的Ceph OSD 程序和底層 OSD 設定加入後，這個中間層允許Ceph 動態再平衡資料；下圖描述了CRUSH 如何對映，物件到PG，PG再到OSD。

With a copy of the cluster map and the CRUSH algorithm, the client can compute exactly which OSD to use when reading or writing a particular object.

通過叢集對映和CRUSH演算法的副本，客戶機可以精確地計算在讀寫特定物件時要使用哪個OSD。

在上面這張資料流轉圖中，每一臺主機上面可以存在多個 osd ，每一個 osd，我們通常認為是一個磁碟，當然如果你使用的是 filestore 引擎，這裡就是一個目錄。我們這裡使用預設bluestore 引擎，代表一塊磁碟，注意就算是使用一個目錄，也應該是整個磁碟當作一個分割槽，格式化完成以後，掛載到某個目錄下面，我們應該這麼使用才對。

Osd: 物件儲存裝置 Object storage device，每一塊磁碟就叫做一個osd，每臺主機上面有多個 osd，多臺主機構成 Rados cluster (RADOS 儲存叢集)，在這個叢集內，除了儲存節點外，還有一類節點叫 mon，叫元資料節點，ceph 不是沒有元資料叢集節點嗎？而ceph叢集沒有說叫元資料節點，而是叫監視器mon——>monitor，它是用來管理整個叢集的，比如你總共有多少個節點，每一個節點上面有多少個 osd，每一個 osd 是否健康，每一個 osd 位於哪個節點上等等，它會持有整個叢集的執行圖，或者叫執行狀態、元資料，或者叫叢集元資料，注意不是檔案元資料。如果這個叢集元資料節點掛了，整個叢集將無法工作了，因此需要為這個 mon 節點需要做高可用，它使用 paxos 協議來實現叢集的一致性，就像 etcd 使用 raft 協議一樣，每一個節點都有完整的副本，它屬於節點級冗餘，這裡的 mon 也是節點級冗餘，為了確保資料在各節點上面是強一致的，每個節點都可寫，寫完之後，同步給其它節點，同時寫的話，如果修改了同一個鍵，同步給另外的節點，發現不一樣，是不是就衝突了，為了避免這種情況，他使用了一種叫分散式強一致性協議 paxos，它也是分散式最早的一種協議，mon 就是使用 paxos 協議在多個節點來協作的，這叫叢集元資料；有了叢集，為了監控整個叢集，我們需要對 RADOS 叢集中的 mon 做查詢，就需要頻繁訪問這個 mon，或者監控軟體需要週期性採集資料，而 mon 是實時查詢叢集資料的，大家知道這種實時查詢代價是很高的，因此 mon 不太適用於頻繁的週期性的採集叢集資料的這種監控操作，但是監控又是必須的，所以 ceph 的新版本，引入了一個新元件，叫做 mgr，manager 的簡寫，這個元件專門維護這種查詢類的操作，他的查詢方式是在叢集空閒的時候去查詢，然後把查詢到的叢集資訊快取下來，等有監控來採集資料時，直接返回並響應，這叫mgr。有了這些元件才是一個完整的RADOS叢集。

當我們要把一個檔案存入到叢集時，怎麼存呢？通常情況下，當你接入ceph儲存叢集，你必須通過一個客戶端來實現，基礎架構篇講過了三種（rbd、rgw、cephfs），或者根據 API 自研，無論通過哪種方式，都需要藉助 API 介面把檔案切分成固定大小的物件，而這個物件儲存到哪裡去？好了，到了抽象的概念了，ceph 的儲存空間是沒有目錄的，所有的物件都是儲存在一個平面上的，注意，所有的物件都在同一個平面上，所以所有的物件都不能重名，但是即便如此，我們儲存1億個物件，放在同一個名稱空間下就可以管理了，但是將來遷移可以管理都不是很方便，因此 RADIOS 把它的儲存切分成了多個分割槽，你可以理解為多個大磁碟，方便管理，每一個分割槽就叫一個儲存池（pool），儲存池的大小取決於下面的儲存空間的大小，它和我們真正意義上的分割槽，不是一回事，你可以把儲存池類比為 k8s 裡面的名稱空間就行了。而我們不能叫它名稱空間，我們叫儲存池，而儲存池存放的資料有可能也很大；而儲存池可以進一步劃分，並非是必備元件，它是可選的，它被叫做名稱空間，每一個儲存池進一步切分成名稱空間，這是兩級管理的邏輯元件，接著是三級，每一個儲存池中有多個 PG 存在，PG 叫歸置組，儲存池 pool 是抽象的概念，歸置組 PG 也是抽象的概念，事實上，並不存在任何一個 PG，它是一個看不見，摸不著的，更不是一個實體。那麼任何一個檔案存放到 RADOS 儲存系統的時候，如何儲存呢？一個物件放在了哪一個osd上面？這中間是靠 cursh 演算法來完成，每個物件存放在哪個儲存池上面是固定的，儲存池必須建立才能使用，這點各位要注意，但 PG 是不可捉摸的東西，它是一個虛擬的中間層，當我們把一個物件真正存入到 osd 中時，一定是要向某個儲存池請求的，而後，我們需要把物件的名字，做一致性 hash 計算，計算完以後，會落到某個 PG 上面，比如說我們規定儲存池中有64個 PG，比如說我們物件的名字對64做一致性hash計算，對映到 hash 環上，hash 環上並沒有 PG，某個物件，一定屬於某個儲存池的某個 PG上面來的；但 PG 是假的，虛擬的，事實上，是不存在的，要注意這點，只是一個計算的結果，把每一個 PG 存放在 osd 上面，PG 怎麼到 osd，關鍵點來了，這是cursh 演算法的第二步，我們需要把 PG 根據這個儲存池的副本冗餘數量和儲存池的型別，找到足量的 osd 來存，儲存池有型別，儲存池的型別就是管理儲存池冗餘資料的，資料冗餘無非是做資料分片的副本，這兒不叫分片，叫 PG，我們叫主 PG，也叫活動 PG 和副本 PG，我們這樣來稱呼就行了，一個 PG 裡面的物件是統一被管理的，寫的時候，一定是先寫主 PG，然後再由主 PG 同步給副本 PG，當然如何同步是 OSD 內部管理的，所以我們的儲存池和 crush 演算法一定要確保哪個是主 PG 哪個是副本 PG，如果冗餘1份，就是1主1副PG，如果冗餘5份，就是1主5從，一般來講傳統的儲存池，只冗餘2份，一共3份，但是這樣一來，我們的儲存資源的利用率也只有1/3。

ceph 叢集也支援另外的一種儲存池，叫糾刪碼儲存池，類似於 RAID，這樣一來，利用率變高了，一樣的有冗餘能力。檔案儲存到儲存系統分為兩步；

檔案被按固定大小的切分成塊，對映為儲存池中的 PG；
把 PG 對映為 osd，這兩步都是由 crush 演算法完成的；

當然了 ceph 不光是要完成對映，萬一哪個 osd 壞了，還要把壞的修復過來，這是內部的工作邏輯，自行修復。

RDB 基礎

1. 使用 create 建立 pool 池（還有一種是通過init 的方式建立）

# 檢視叢集中的 pools
[root@ceph-node01 ~]# ceph osd lspools

# 使用 create 方式建立 pool 池
[root@ceph-node01 ~]# ceph osd pool create ceph-demo 64 64
pool 'ceph-demo' created

# 再次檢視
[root@ceph-node01 ~]# ceph osd lspools
1 ceph-demo
[root@ceph-node01 ~]#

建立命令時需要指定PG、PGP數量，還可以指定複製模型還是糾刪碼模型，副本數量等等

[root@ceph-node01 ~]# ceph osd pool create
Invalid command: missing required parameter pool(<poolname>)
osd pool create <poolname> <int[0-]> {<int[0-]>} {replicated|erasure} {<erasure_code_profile>} {<rule>} {<int>} {<int>} {<int[0-]>} {<int[0-]>} {<float[0.0-1.0]>} : create pool
Error EINVAL: invalid command
[root@ceph-node01 ~]#

獲取 pool 池屬性資訊，可以重新設定，有很多引數，都可以如下設定

# 獲取 pg 個數
[root@ceph-node01 ~]# ceph osd pool get ceph-demo pg_num
pg_num: 64

# 獲取 pgp 個數
[root@ceph-node01 ~]# ceph osd pool get ceph-demo pgp_num
pgp_num: 64

# 獲取副本數
[root@ceph-node01 ~]# ceph osd pool get ceph-demo size
size: 3

# 獲取使用模型
[root@ceph-node01 ~]# ceph osd pool get ceph-demo crush_rule
crush_rule: replicated_rule

# 設定副本數
[root@ceph-node01 ~]# ceph osd pool set ceph-demo size 2

# 設定 pg 數量
[root@ceph-node01 ~]# ceph osd pool set ceph-demo pg_num 128

# 設定 pgp 數量
[root@ceph-node01 ~]# ceph osd pool set ceph-demo pgp_num 128

建立完 pool 後，需要初始化 pool

[root@ceph-node01 ceph-deploy]# rbd pool init ceph-demo

這裡先不做，看下報錯，然後我們排查問題；

建立 rbd 塊裝置

# 檢視 塊裝置
[root@ceph-node01 ~]# rbd -p ceph-demo ls

# 建立 塊裝置方式一
[root@ceph-node01 ~]# rbd create -p ceph-demo --image rbd-demo.img --size 10G

# 建立 塊裝置方式二
[root@ceph-node01 ~]# rbd create ceph-demo/rbd-demo2.img --size 10G

# 檢視 塊裝置
[root@ceph-node01 ~]# rbd -p ceph-demo ls
rbd-demo.img
rbd-demo2.img
[root@ceph-node01 ~]#

檢視塊裝置資訊

[root@ceph-node01 ceph-deploy]# rbd info ceph-demo/rbd-demo2.img
rbd image 'rbd-demo2.img':
  size 10 GiB in 2560 objects
  order 22 (4 MiB objects)  # 每塊 4 M，預設
  snapshot_count: 0
  id: 6150b827120b # 塊裝置 ID 號
  block_name_prefix: rbd_data.6150b827120b
  format: 2
  features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
  op_features:
  flags:
  create_timestamp: Sat Oct 3 23:40:53 2020
  access_timestamp: Sat Oct 3 23:40:53 2020
  modify_timestamp: Sat Oct 3 23:40:53 2020
[root@ceph-node01 ceph-deploy]#

刪除塊裝置

[root@ceph-node01 ~]# rbd rm -p ceph-demo --image rbd-demo2.img
Removing image: 100% complete...done.
[root@ceph-node01 ~]#

裝置掛載

由於沒有虛擬機器進行掛載，所以需要使用核心 map 進行掛載；

[root@ceph-node01 ~]# rbd map ceph-demo/rbd-demo.img
rbd: sysfs write failed
RBD image feature set mismatch. Try disabling features unsupported by the kernel with "rbd feature disable".
In some cases useful info is found in syslog - try "dmesg | tail".
rbd: map failed: (6) No such device or address
[root@ceph-node01 ~]#

對映的過程當中出現錯誤，這是因為 Centos7 當中不支援這幾個特性，我們可以在建立時指定 features 。

[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img deep-flatten
[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img fast-diff
[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img object-map
rbd: failed to update image features: 2020-09-29 10:29:37.787 7fc8a06ddc80 -1 librbd::Operations: one or more requested features are already disabled(22) Invalid argument

[root@ceph-node01 ~]# rbd feature disable ceph-demo/rbd-demo.img exclusive-lock
[root@ceph-node01 ~]#

再次掛載，掛載成功

[root@ceph-node01 ~]# rbd map ceph-demo/rbd-demo.img
/dev/rbd0
[root@ceph-node01 ~]#

檢視裝置列表

[root@ceph-node01 ~]# rbd device list
id pool namespace image snap device
0 ceph-demo rbd-demo.img - /dev/rbd0
[root@ceph-node01 ~]#

通過fdisk 檢視裝置列表

[root@ceph-node01 ~]# fdisk -l

......

磁碟 /dev/rbd0：10.7 GB, 10737418240 位元組，20971520 個扇區
Units = 扇區 of 1 * 512 = 512 bytes
扇區大小(邏輯/物理)：512 位元組 / 512 位元組
I/O 大小(最小/最佳)：4194304 位元組 / 4194304 位元組

[root@ceph-node01 ~]#

使用 rbd 裝置

# 格式化為 ext4
[root@ceph-node01 ~]# mkfs.ext4 /dev/rbd0
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: 完成
檔案系統標籤=
OS type: Linux
塊大小=4096 (log=2)
分塊大小=4096 (log=2)
Stride=1024 blocks, Stripe width=1024 blocks
655360 inodes, 2621440 blocks
131072 blocks (5.00%) reserved for the super user
第一個資料塊=0
Maximum filesystem blocks=2151677952
80 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: 完成
正在寫入inode表: 完成
Creating journal (32768 blocks): 完成
Writing superblocks and filesystem accounting information: 完成

# 檢視裝置
[root@ceph-node01 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 252:0 0 50G 0 disk
├─vda1 252:1 0 500M 0 part /boot
└─vda2 252:2 0 49.5G 0 part
  ├─centos-root 253:0 0 44.5G 0 lvm /
  └─centos-swap 253:1 0 5G 0 lvm [SWAP]
vdb 252:16 0 100G 0 disk
└─ceph--f80dea0c--8b8c--46aa--95aa--35589c59b708-osd--block--136f6cf7--05a0--4325--aa92--ad316560edff
                                                                                 253:2 0 100G 0 lvm
vdc 252:32 0 100G 0 disk
rbd0 251:0 0 10G 0 disk
[root@ceph-node01 ~]#

mount rbd 裝置

[root@ceph-node01 ~]# mkdir /mnt/rbd-demo
[root@ceph-node01 ~]# mount /dev/rbd0 /mnt/rbd-demo/
[root@ceph-node01 ~]# df -h
檔案系統 容量 已用 可用 已用% 掛載點
。。。
/dev/rbd0 9.8G 37M 9.2G 1% /mnt/rbd-demo
[root@ceph-node01 ~]# cd /mnt/rbd-demo
[root@ceph-node01 rbd-demo]# ls
lost+found
[root@ceph-node01 rbd-demo]# echo `date` >test
[root@ceph-node01 rbd-demo]# ll
總用量 20
drwx------ 2 root root 16384 9月 29 10:36 lost+found
-rw-r--r-- 1 root root 43 9月 29 10:41 test
[root@ceph-node01 rbd-demo]#

塊裝置擴容

裝置可以擴容，也可以縮容，但不建議使用縮容，有可能產生資料丟失。

[root@ceph-node01 rbd-demo]# rbd resize ceph-demo/rbd-demo.img --size 20G
Resizing image: 100% complete...done.
[root@ceph-node01 rbd-demo]# rbd -p ceph-demo info --image rbd-demo.img
rbd image 'rbd-demo.img':
  size 20 GiB in 5120 objects # 已經擴容到了20G
  order 22 (4 MiB objects)
  snapshot_count: 0
  id: 12e14e0cad6b
  block_name_prefix: rbd_data.12e14e0cad6b
  format: 2
  features: layering
  op_features:
  flags:
  create_timestamp: Tue Sep 29 10:13:59 2020
  access_timestamp: Tue Sep 29 10:13:59 2020
  modify_timestamp: Tue Sep 29 10:13:59 2020
[root@ceph-node01 rbd-demo]#

我們通過 fdisk -l 發現裝置也擴容成功了，但 df -h 檔案系統沒有擴容，我們要使用檔案系統能夠識別到這個空間，就需要使用 resize2fs 命令；

[root@ceph-node01 rbd-demo]# resize2fs /dev/rbd0
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/rbd0 is mounted on /mnt/rbd-demo; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 3
The filesystem on /dev/rbd0 is now 5242880 blocks long.

[root@ceph-node01 rbd-demo]# df -h
檔案系統 容量 已用 可用 已用% 掛載點
。。。
/dev/rbd0 20G 44M 19G 1% /mnt/rbd-demo
[root@ceph-node01 rbd-demo]#

塊裝置擴容一般會涉及ny三方面的內容：

底層儲存的擴容；
磁碟分割槽的擴容；
檔案系統的擴容；

這裡第 2 步省略了，我們直接使用了整塊盤，其實在虛擬化環境中，也不建議對磁碟再分割槽。

RBD 資料寫入流程

一個物件會切割成多個object(預設是4M)

[root@ceph-node01 ~]# rbd -p ceph-demo info rbd-demo.img
rbd image 'rbd-demo.img':
  size 20 GiB in 5120 objects 
  order 22 (4 MiB objects)
  snapshot_count: 0
  id: 12e14e0cad6b
  block_name_prefix: rbd_data.12e14e0cad6b
  format: 2
  features: layering
  op_features:
  flags:
  create_timestamp: Tue Sep 29 10:13:59 2020
  access_timestamp: Tue Sep 29 10:13:59 2020
  modify_timestamp: Tue Sep 29 10:13:59 2020
[root@ceph-node01 ~]#

這裡最多有 5120 個object，object 的字首都是以rbd_data. 開頭；

檢視 object 資訊；

[root@ceph-node01 ~]# rados -p ceph-demo ls|grep rbd_data.12e14e0cad6b
rbd_data.12e14e0cad6b.000000000000042f
rbd_data.12e14e0cad6b.0000000000000060
rbd_data.12e14e0cad6b.0000000000000020
rbd_data.12e14e0cad6b.0000000000000c00
。。。
[root@ceph-node01 ~]#

檢視每個object的大小

[root@ceph-node01 ~]# rados -p ceph-demo stat rbd_data.12e14e0cad6b.000000000000042f
ceph-demo/rbd_data.12e14e0cad6b.000000000000042f mtime 2020-10-04 00:50:12.000000, size 4194304
[root@ceph-node01 ~]#

注意，當前檢視的這個 object的大小為 4M，有些 object 有可能小於 4M，但不可能大小4M；

檢視 object 落在哪個 PG 上面

[root@ceph-node01 ~]# ceph osd map ceph-demo bd_data.12e14e0cad6b.000000000000042f
osdmap e37 pool 'ceph-demo' (1) object 'bd_data.12e14e0cad6b.000000000000042f' -> pg 1.46b3a134 (1.34) -> up ([2,1], p2) acting ([2,1], p2)
[root@ceph-node01 ~]#

資源池 ceph-demo中的1號物件，然後是objcect id，經過crush演算法得到 PG為1.34，最終落到OSD 2和 1上面，通過ceph osd tree，可以檢視對應的節點；

[root@ceph-node01 ~]# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.39067 root default
-3 0.09769 host ceph-node01
 0 hdd 0.09769 osd.0 up 1.00000 1.00000
-5 0.09769 host ceph-node02
 1 hdd 0.09769 osd.1 up 1.00000 1.00000
-7 0.19530 host ceph-node03
 2 hdd 0.19530 osd.2 up 1.00000 1.00000
[root@ceph-node01 ~]#

osd.2 對應的是 ceph-node03 節點，osd.1 對應的是 ceph-node02 節點；

[root@ceph-node01 ~]# for i in `rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b`
> do
> ceph osd map ceph-demo $i
> done
osdmap e37 pool 'ceph-demo' (1) object 'rbd_data.12e14e0cad6b.000000000000042f' -> pg 1.38cd6b20 (1.20) -> up ([2,1], p2) acting ([2,1], p2)
osdmap e37 pool 'ceph-demo' (1) object 'rbd_data.12e14e0cad6b.0000000000000060' -> pg 1.cf585158 (1.58) -> up ([2,0], p2) acting ([2,0], p2)
osdmap e37 pool 'ceph-demo' (1) object 'rbd_data.12e14e0cad6b.0000000000000020' -> pg
。。。
'rbd_data.12e14e0cad6b.0000000000000421' -> pg 1.8116d2df (1.5f) -> up ([2,0], p2) acting ([2,0], p2)
[root@ceph-node01 ~]#

通過上面可以看到 rbd-demo.img 儲存分佈到了不同的 PG，然後 PG 又對映到了不同的 OSD 上面；

RBD 特性之一瘦分配

瘦分配隨著空間使用的情況，自動的擴這個空間，大約使用了144M；

[root@ceph-node01 ~]# for i in `rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b`; do rados -p ceph-demo stat $i | gawk '{print $NF}'; done>size.log
[root@ceph-node01 ~]# cat size.log |gawk 'BEGIN{SUM=0}{SUM+=$1}END{print SUM/1024/1024}'
144.652
[root@ceph-node01 ~]#

現在我們自動化通過監控 watch -n 1 'rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b|wc -l' object 數量的變化來檢視動態擴空間來說明瘦分配機制，開啟另一個視窗，向 /mnt/ rbd-demo/ 目錄中寫入1G的資料檔案，可以看到動態分配磁碟空間；

[root@ceph-node01 rbd-demo]# dd if=/dev/zero of=/mnt/rbd-demo/test.log count=1024 bs=1014k
記錄了1024+0 的讀入
記錄了1024+0 的寫出
1063256064位元組(1.1 GB)已複製，1.61673 秒，658 MB/秒
[root@ceph-node01 rbd-demo]#

再次進行計算，大約佔了一個多G的量，通過df對比下；

[root@ceph-node01 ~]# for i in `rados -p ceph-demo ls |grep rbd_data.12e14e0cad6b`; do rados -p ceph-demo stat $i | gawk '{print $NF}'; done>size.log
[root@ceph-node01 ~]# cat size.log |gawk 'BEGIN{SUM=0}{SUM+=$1}END{print SUM/1024/1024}'
1158.67
[root@ceph-node01 ~]#

通過df 檢視空間，基本與上面計算的一致；

[root@ceph-node01 ~]# df -h
檔案系統 容量 已用 可用 已用% 掛載點
。。。
/dev/rbd0 20G 1.1G 18G 6% /mnt/rbd-demo
[root@ceph-node01 ~]#

總結

資料儲存流程

檔案物件；
切割成大小為4M的 object 物件；
object 物件通過CRUSH 演算法對映到 PG；
PG 通過CRUSH演算法對映到OSD；

基本使用

建立 pool 池：ceph osd pool create ceph-demo 64 64
在 Pool 池中建立 rbd 物件：
rbd create -p ceph-demo --image rbd-demo.img --size 10G
使用核心map 掛載rbd物件：rbd map ceph-demo/rbd-demo.img
格式化塊裝置：mkfs.ext4 /dev/rbd0
掛載塊裝置：mount /dev/rbd0 /mnt/rbd-demo/
設定 pool 池資訊：ceph osd pool set ceph-demo size 2
擴容 rbd 塊裝置：rbd resize ceph-demo/rbd-demo.img --size 20G
擴容掛載後文件系統：resize2fs /dev/rbd0
刪除塊裝置：rbd rm -p ceph-demo --image rbd-demo2.img

資訊檢視

檢視pool池中的rbd塊裝置：rbd -p ceph-demo ls

檢視塊裝置詳細資訊方式一：rbd info ceph-demo/rbd-demo2.img、

檢視塊裝置詳細資訊方式二：rbd -p ceph-demo info rbd-demo.img

檢視本機rbd裝置列表：rbd device list

檢視塊裝置對應的所有 objects ：rados -p ceph-demo ls|grep rbd_data.12e14e0cad6b

單個object物件對映的PG及OSD資訊/大小等：ceph osd map ceph-demo bd_data.12e14e0cad6b.000000000000042f

3.Ceph 基礎篇 - RBD 塊儲存使用

資料儲存原理

RDB 基礎

1. 使用 create 建立 pool 池（還有一種是通過init 的方式建立）

RBD 資料寫入流程

RBD 特性之一瘦分配

總結

資料儲存流程

基本使用

資訊檢視

3.Ceph 基礎篇 - RBD 塊儲存使用

7. Ceph 高階篇 - RBD塊裝置回收站、快照、克隆

ceph儲存之RBD塊儲存

1.Ceph 基礎篇 - 儲存基礎及架構介紹

4.Ceph 基礎篇 - 物件儲存使用

2.Ceph 基礎篇 - 叢集部署及故障排查

6.Ceph 基礎篇 - CephFS 檔案系統

5.Ceph 基礎篇 - 認證

10.Ceph 基礎篇 - RGW 高可用

06 雲原生 RBD 塊儲存（轉載）

前端開發系列046-基礎篇之資料儲存

Java基礎複習之旅(3)-執行緒篇

pygame實現俄羅斯方塊遊戲（基礎篇3）

PostgreSQL-儲存過程(一)基礎篇

訊息佇列（基礎篇）- 3 主題和佇列有什麼區別

Linux基礎篇（3）小白如何學習Linux？計算機組成部分以及RAID陣列卡概念

Python入門基礎篇 No.3 —— 變數的宣告_初始化_刪除變數_垃圾回收機制

Python入門基礎篇 No.27 —— 列表_二維列表_表格資料的儲存和讀取

重溫《資料庫系統概論》【第一篇基礎篇】【第3章關係資料庫標準語言SQL】

前端基礎篇3--css高階技巧

3.Ceph 基礎篇 - RBD 塊儲存使用

資料儲存原理

RDB 基礎

1. 使用 create 建立 pool 池（還有一種是通過init 的方式建立）

RBD 資料寫入流程

RBD 特性之一瘦分配

總結

資料儲存流程

基本使用

資訊檢視

相關推薦