RBD至FileStore之所見（原理篇）
前言
我們知道，FileStore是目前Ceph版本的預設儲存方式（後續社群準備採用BlueStore）。
RDB是我們虛擬機器使用Ceph的常用方式，Ceph是一個基於物件儲存的分散式檔案系統，在Ceph中，所有的檔案都是物件，本文探討在Ceph中的RDB在Ceph的實現原理和對映方式。
瞭解RBD的對映原理以後，對我們運維管理，資料恢復會有很大的幫助。
操作過程
1.建立pool
1. [root@centos7 ceph]# ceph osd pool create test 64 64 2. pool 'test' created 3. [root@centos7 ceph]# rados ls -p test 4. none
建立好test pool後，通過rados檢視pool中的物件，因為沒有儲存任何東西，所以沒發現物件。
2.建立image
1. [root@centos7 ceph]# rbd create test/test --size 1024
2. [root@centos7 ceph]# rados ls -p test
3. rbd_directory
4. test.rbd在test pool中，建立了rbd的test image，此時通過rados檢視，發現了兩個物件：rbd_directory和test.rbd。
3.Object2PG
在Ceph中，每一個物件（Object）都會首先對映到一個pg上，然後pg再對映到一組osd上。
1. [root@centos7 ceph]# ceph osd map test rbd_directory
2. osdmap e163 pool 'test' (5) object 'rbd_directory' -> pg 5.30a98c1c (5.
1c) -> up [2,3] acting [2,3]通過ceph osd map [pool] [object_name] 直接可以檢視到object到pg的對映關係，本例中rbd_directory 對映到了pg=5.1c.前面的5是pool_id，30a98c1c這串數值其實就是通過Ceph的Hash函式將rbd_directory對映的結果，我們把他成為object_id，因為本例的pool中pg_num=64,對映過來的pg_id=0x30a98c1c%64=0x1c, 從上面可以看出，Ceph的object_id到pg的對映就是簡單的取模處理。一旦Ceph的pg資料發生變化，pg的對映也會發生變化，從原理上來看，當一個Ceph的生產叢集，最好不要調整pg數。
4.PG2OSD
每個pg都會通過Crush演算法，對映到一組osd上，Crush演算法是Ceph資料高可用性的保障。
Crush演算法其實一個能夠根據伺服器部署情況而產生不同對映結果的一致性雜湊演算法。
1. [root@centos7 ceph]# ceph osd tree
2. # id weight type name up/down reweight
3. -1 4 root default
4. -3 4 rack rack01
5. -2 4 host node01
6. 0 1 osd.0 up 1
7. 1 1 osd.1 up 1
8. 2 1 osd.2 up 1
9. 3 1 osd.3 up 1
10.
11. [root@centos7 ceph]# ceph pg map 5.1c
12. osdmap e163 pg 5.1c (5.1c) -> up [2,3] acting [2,3]本例中有4個osd, 通過ceph pg map 可以找到對應的object對映到了那個osd,本例中對映到了2和3，2是主osd(本例配置的副本數為2)。
5.檔案落地
1. [root@centos7 ceph]# cd osd/ceph-2/current/
2. [root@centos7 ceph]# cd 5.1c_head/
3. [root@centos7 5.1c_head]# ls
4. rbdudirectory__head_30A98C1C__5
5. [root@centos7 5.1c_head]# hexdump -C rbd\udirectory__head_30A98C1C__5
6. 00000000 00 00 00 00 01 00 00 00 04 00 00 00 74 65 73 74 |............test|
7. 00000010 00 00 00 00 |....|
8. 00000014從上面尋找的過程中，通過osd的目錄，進入到pg所在的目錄，因為一個osd會承載多個pg，同時一個pg會對映到至少一個以上的osd上。本例中順藤摸瓜，進入osd/ceph-2/current,由於pg是5.1c,進入5.1c的目錄，找到了檔案rbdudirectory__head_30A98C1C__5，命名規則也很簡單{object_name}head{object_id}_{pool_Id}，通過hexdump發現，裡面儲存了test，猜想他應該是儲存了image的名字。再檢視另外一個檔案test.rbd，如下，通過hexdump檢視，發現裡面儲存了一些RBD的描述資訊。
1. [root@centos7 osd]# ceph osd map test test.rbd
2. osdmap e163 pool 'test' (5) object 'test.rbd' -> pg 5.a2fa4514 (5.14) -
> up [3,1] acting [3,1]
3. [root@centos7 osd]# cd ceph-3/current/5.14_head/
4. [root@centos7 5.14_head]# ls
5. test.rbd__head_A2FA4514__5
6. [root@centos7 5.14_head]# hexdump -C test.rbd__head_A2FA4514__5
7. 00000000 3c 3c 3c 20 52 61 64 6f 73 20 42 6c 6f 63 6b 20 |<<< Rados
Block |
8. 00000010 44 65 76 69 63 65 20 49 6d 61 67 65 20 3e 3e 3e |Device Ima
ge >>>|
9. 00000020 0a 00 00 00 00 00 00 00 72 62 2e 30 2e 31 36 64 |........rb
.0.16d|
10. 00000030 30 2e 36 62 38 62 34 35 36 37 00 00 00 00 00 00 |0.6b8b4567......|
11. 00000040 52 42 44 00 30 30 31 2e 30 30 35 00 16 00 00 00 |RBD.001.00
5.....|
12. 00000050 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@......
......|
13. 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........
......|
14. 00000070|通過rbd info 檢視rbd的資訊，發現果然有幾分似曾相識，比如rb.0.16d0.6b8b4567，從這裡我們可以發現，rbd info 其實就是讀取了test.rbd中的資料，也就是說rbd的描述資訊存放在test.rbd中。
1. [root@centos7 5.14_head]# rbd info test/test
2. rbd image'test':
3. size 1024 MB in 256 objects4. order 22 (4096 kB objects)
5. block_name_prefix: rb.0.16d0.6b8b4567
6. format: 16.RBD檔案組織
6.1map到dev
1. [root@centos7 osd]# rbd map test/test
2. [root@centos7 osd]# rbd showmapped
3. id pool image snap device
4. 0 test test - /dev/rbd06.2格式化檔案系統
1. [root@centos7 osd]# mkfs.ext4 /dev/rbd0
2. mke2fs 1.42.9 (28-Dec-2013)
3. Discardingdevice blocks: done
4. Filesystemlabel=
5. OS type: Linux
6. Block size=4096 (log=2)
7. Fragmentsize=4096 (log=2)
8. Stride=1024 blocks, Stripe width=1024 blocks
9. 65536 inodes, 262144 blocks
10. 13107 blocks (5.00%) reserved for the super user
11. First data block=0
12. Maximum filesystem blocks=268435456
13. 8 block groups
14. 32768 blocks per group, 32768 fragments per group
15. 8192 inodes per group
16. Superblockbackups stored on blocks:
17. 32768, 98304, 163840, 229376
18.
19. Allocatinggroup tables: done
20. Writinginode tables: done
21. Creatingjournal (8192 blocks): done
22. Writing superblocks and filesystem accounting information: done6.3掛載檔案系統
1. [root@centos7 osd]# mount /dev/rbd0 /mnt6.4建立檔案（128M）
1. [root@centos7 osd]# cd /mnt/
2. [root@centos7 mnt]# dd if=/dev/zero of=./data bs=1M count=128
3. 128+0 records in
4. 128+0 records out
5. 134217728 bytes (134 MB) copied, 0.130102 s, 1.0 GB/s6.5檢視檔案
1. [root@centos7 ~]# rados ls -p test
2. rb.0.16d0.6b8b4567.000000000000
3. rb.0.16d0.6b8b4567.000000000004
4. rb.0.16d0.6b8b4567.000000000020
5. rb.0.16d0.6b8b4567.000000000021
6. rb.0.16d0.6b8b4567.000000000022
7. rb.0.16d0.6b8b4567.000000000023
8. ...
9. rb.0.16d0.6b8b4567.00000000003e
10. rb.0.16d0.6b8b4567.00000000003f
11. rb.0.16d0.6b8b4567.000000000040
12. rb.0.16d0.6b8b4567.000000000041
13. rb.0.16d0.6b8b4567.000000000060
14. rb.0.16d0.6b8b4567.000000000080
15. rb.0.16d0.6b8b4567.000000000081
16. rb.0.16d0.6b8b4567.000000000082
17. rb.0.16d0.6b8b4567.000000000083
18. rb.0.16d0.6b8b4567.000000000084
19. rb.0.16d0.6b8b4567.000000000085
20. rb.0.16d0.6b8b4567.000000000086
21. rb.0.16d0.6b8b4567.000000000087
22. rb.0.16d0.6b8b4567.0000000000a0
23. rb.0.16d0.6b8b4567.0000000000e0
24. rb.0.16d0.6b8b4567.000000000032
25. rb.0.16d0.6b8b4567.0000000000ff
26. rbd_directory
27. test.rbd
28. rb.0.16d0.6b8b4567.000000000025在格式化了檔案系統，同時建立了128M的檔案以後，通過rados檢視，出現了很多以
rb.0.16d0.6b8b4567的檔案，同時出現了連續的檔案命令，從rb.0.16d0.6b8b4567.000000000020到rb.0.16d0.6b8b4567.000000000041，共32個，加上ceph的物件大小為4M，共128M，和測試檔案大小吻合。其他的一些檔案這是ext4檔案系統的一些描述資訊。
因此，我們可以推測，rbd檔案組織是一個{image_name}.rdb 和 若干rbd_prefix.{num}，每個塊大小為4M，整個rbd的檔案數=size/4M+1。
總結
Ceph是一個非常優秀的分散式檔案系統，物件首先通過object_name計算出object_id，然後取模，對映到pg上，然後pg通過crush演算法對映到一組osd上，其中一個為主osd。
rbd則是ceph的一種訪問方式，在rados的基礎上的另外一層封裝，實現簡單，僅添加了一個描述檔案，其他的檔案通過順序方式組織起來，通過librbd提供給其他應用訪問。