この記事はRookだらけの Advent Calendar 2019 3日目の記事です。
Rook-CephでSSDとHDDの使い分けの例を説明します。
SSDにOSDメタデータを分けて置く
Cephをご存知の方だと、『OSDのユーザーデータとメタデータ領域は分けたほうがいい』というプラクティスを知っていると思います。
メタデータはsmall I/Oがバンバン来るのでFlashデバイスの方がいいということです。そのとおりで、特にsmall I/Oに強くないHDDにとっては性能的に望ましくないです。
CephではユーザーデータはHDDへ、メタデータだけSSDやNVMeへと分けることができるので、Rook-Cephでやってみます。
3台のworkerにそれぞれ5つのデバイスをぶら下げます。
[utubo@tutsunom ceph]$ ssh xxxxxx.compute-1.amazonaws.com lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 128G 0 disk ├─xvda1 202:1 0 1007.5K 0 part └─xvda2 202:2 0 128G 0 part / xvdf 202:80 0 5G 0 disk ← ssd(metadata用) xvdg 202:96 0 10G 0 disk ← ssd(osd用) xvdh 202:112 0 10G 0 disk ← ssd(osd用) xvdi 202:128 0 20G 0 disk ← hdd(osd用) xvdj 202:144 0 20G 0 disk ← hdd(osd用)
何も考えずにkubectl create -f cluster.yamlをやってしまうと、
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph osd df tree
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME
-1 0.19061 - 195 GiB 15 GiB 15 MiB 0 B 15 GiB 180 GiB 7.70 1.00 - root default
-5 0.19061 - 195 GiB 15 GiB 15 MiB 0 B 15 GiB 180 GiB 7.70 1.00 - region us-east-1
-4 0.06354 - 65 GiB 5.0 GiB 4.8 MiB 0 B 5 GiB 60 GiB 7.70 1.00 - zone us-east-1a
-3 0.06354 - 65 GiB 5.0 GiB 4.8 MiB 0 B 5 GiB 60 GiB 7.70 1.00 - host ip-172-20-42-193-ec2-internal
0 ssd 0.01859 1.00000 19 GiB 1.0 GiB 992 KiB 0 B 1 GiB 18 GiB 5.27 0.68 0 up osd.0
3 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.3
6 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.6
9 ssd 0.01859 1.00000 19 GiB 1.0 GiB 992 KiB 0 B 1 GiB 18 GiB 5.27 0.68 0 up osd.9
12 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.12
-14 0.06354 - 65 GiB 5.0 GiB 4.8 MiB 0 B 5 GiB 60 GiB 7.70 1.00 - zone us-east-1b
-13 0.06354 - 65 GiB 5.0 GiB 4.8 MiB 0 B 5 GiB 60 GiB 7.70 1.00 - host ip-172-20-93-28-ec2-internal
1 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.1
4 ssd 0.01859 1.00000 19 GiB 1.0 GiB 992 KiB 0 B 1 GiB 18 GiB 5.27 0.68 0 up osd.4
7 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.7
11 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.11
14 ssd 0.01859 1.00000 19 GiB 1.0 GiB 992 KiB 0 B 1 GiB 18 GiB 5.27 0.68 0 up osd.14
-10 0.06354 - 65 GiB 5.0 GiB 4.8 MiB 0 B 5 GiB 60 GiB 7.70 1.00 - zone us-east-1c
-9 0.06354 - 65 GiB 5.0 GiB 4.8 MiB 0 B 5 GiB 60 GiB 7.70 1.00 - host ip-172-20-102-19-ec2-internal
2 ssd 0.01859 1.00000 19 GiB 1.0 GiB 992 KiB 0 B 1 GiB 18 GiB 5.27 0.68 0 up osd.2
5 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.5
8 ssd 0.01859 1.00000 19 GiB 1.0 GiB 992 KiB 0 B 1 GiB 18 GiB 5.27 0.68 0 up osd.8
10 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.10
13 ssd 0.00879 1.00000 9 GiB 1.0 GiB 992 KiB 0 B 1 GiB 8.0 GiB 11.12 1.44 0 up osd.13
という風に全部のデバイスがosdとなってしまいました。あー。ノードではこんな感じでLVが作られる。
[utubo@tutsunom ceph]$ ssh xxxxxx.compute-1.amazonaws.com lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 128G 0 disk ├─xvda1 202:1 0 1007.5K 0 part └─xvda2 202:2 0 128G 0 part / xvdf 202:80 0 10G 0 disk └─ceph--8e673497--53a0--457f--9b7a--b48ea1f6e6d8-osd--data--e7021f4d--29f2--4c49--ba75--d242b0288181 254:2 0 9G 0 lvm xvdg 202:96 0 10G 0 disk └─ceph--0698a316--b2c8--4301--b076--0ed7c854649a-osd--data--a4f8a81f--1b17--483f--8ed6--7c3c299cc394 254:4 0 9G 0 lvm xvdh 202:112 0 10G 0 disk └─ceph--77603f3c--1bf5--4a22--8e98--4e90a06863af-osd--data--91c9407d--4b7f--4975--b1ae--2a2fffd8330e 254:1 0 9G 0 lvm xvdi 202:128 0 20G 0 disk └─ceph--0d73aa24--76db--4993--a455--07de990a7032-osd--data--67b5ef67--40d4--486e--a7f4--a92a974c19a4 254:3 0 19G 0 lvm xvdj 202:144 0 20G 0 disk └─ceph--e33ac0e4--633c--4af7--8fbf--f65a125bb1a3-osd--data--e952dada--1dea--4f24--8efd--2a4884914ea1 254:0 0 19G 0 lvm
各デバイスのLVでユーザー領域とメタデータ領域が同居することになってしまってます。
メタデータ専用のデバイスを指定できればできればいいですね。cluster.yamlファイルのstorageのセクションで、
storage: # cluster level storage configuration and selection
useAllNodes: true
useAllDevices: true
topologyAware: true
deviceFilter:
location:
config:
storeType: bluestore
metadataDevice: "xvdf"
databaseSizeMB: "1024" # uncomment if the disks are smaller than 100 GB
みたいな感じにconfig:以下を指定してあげましょう。
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph osd df tree
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME
-1 0.17569 - 180 GiB 24 GiB 10 MiB 0 B 12 GiB 156 GiB 13.34 1.00 - root default
-5 0.17569 - 180 GiB 24 GiB 10 MiB 0 B 12 GiB 156 GiB 13.34 1.00 - region us-east-1
-4 0.05856 - 60 GiB 8.0 GiB 3.5 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - zone us-east-1a
-3 0.05856 - 60 GiB 8.0 GiB 3.5 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - host ip-172-20-42-193-ec2-internal
0 ssd 0.01949 1.00000 20 GiB 2.0 GiB 896 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.0
3 ssd 0.00980 1.00000 10 GiB 2.0 GiB 896 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.3
6 ssd 0.01949 1.00000 20 GiB 2.0 GiB 896 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.6
9 ssd 0.00980 1.00000 10 GiB 2.0 GiB 896 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.9
-14 0.05856 - 60 GiB 8.0 GiB 3.5 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - zone us-east-1b
-13 0.05856 - 60 GiB 8.0 GiB 3.5 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - host ip-172-20-93-28-ec2-internal
2 ssd 0.01949 1.00000 20 GiB 2.0 GiB 896 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.2
5 ssd 0.00980 1.00000 10 GiB 2.0 GiB 896 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.5
8 ssd 0.01949 1.00000 20 GiB 2.0 GiB 896 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.8
11 ssd 0.00980 1.00000 10 GiB 2.0 GiB 896 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.11
-10 0.05856 - 60 GiB 8.0 GiB 3.5 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - zone us-east-1c
-9 0.05856 - 60 GiB 8.0 GiB 3.5 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - host ip-172-20-102-19-ec2-internal
1 ssd 0.01949 1.00000 20 GiB 2.0 GiB 896 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.1
4 ssd 0.00980 1.00000 10 GiB 2.0 GiB 896 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.4
7 ssd 0.01949 1.00000 20 GiB 2.0 GiB 896 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.7
10 ssd 0.00980 1.00000 10 GiB 2.0 GiB 896 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.10
TOTAL 180 GiB 24 GiB 10 MiB 0 B 12 GiB 156 GiB 13.34
MIN/MAX VAR: 0.75/1.50 STDDEV: 5.27
ノードではこうなってます。希望通り/dev/xvdfにメタデータ(dbs; rocksDB)領域のLVがまとまっています。
[utubo@tutsunom ceph]$ ssh xxxxxx.compute-1.amazonaws.com lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 128G 0 disk ├─xvda1 202:1 0 1007.5K 0 part └─xvda2 202:2 0 128G 0 part / xvdf 202:80 0 10G 0 disk ├─ceph--block--dbs--3d572391--5d90--4499--9777--1882fdb2d032-osd--block--db--0a9417fd--1f1e--4847--901b--abc1bc7a6f76 254:1 0 1G 0 lvm ├─ceph--block--dbs--3d572391--5d90--4499--9777--1882fdb2d032-osd--block--db--209b10e9--9712--462a--a354--e1e74321252c 254:3 0 1G 0 lvm ├─ceph--block--dbs--3d572391--5d90--4499--9777--1882fdb2d032-osd--block--db--5743ece9--2e47--4a80--bd65--85a5e8ded997 254:5 0 1G 0 lvm └─ceph--block--dbs--3d572391--5d90--4499--9777--1882fdb2d032-osd--block--db--69a7ef92--0c0f--4921--9276--754b1eb0aade 254:7 0 1G 0 lvm xvdg 202:96 0 10G 0 disk └─ceph--block--690c01e5--5df9--4f76--a0b7--5cda604029f3-osd--block--438cc4b8--acc4--4bc2--844f--4169f7d15eb4 254:6 0 9G 0 lvm xvdh 202:112 0 10G 0 disk └─ceph--block--63789610--ea4f--4c4d--b7d3--3a9cc61aab7b-osd--block--f00ca520--0ce4--4458--b2ca--8836ec16719f 254:2 0 9G 0 lvm xvdi 202:128 0 20G 0 disk └─ceph--block--2df2e114--9da7--44e6--ab0b--971511841130-osd--block--fad745f3--d7f6--4734--a0ab--081456857402 254:4 0 19G 0 lvm xvdj 202:144 0 20G 0 disk └─ceph--block--071efb65--60b2--4a97--94b4--da0a60fc2022-osd--block--fc1da0af--0c9a--4f12--b31b--6ac9438d9e1c 254:0 0 19G 0 lvm
Device Classを指定してPoolを作る
この状態で素直にPoolを作ってしまうと、SSDとHDDがごちゃまぜになったPoolになってしまって、SSDの性能がHDDに引っ張られてしまってもったいないことになります。だからSSDとHDDは分けて使いましょう。
それはそうと、SSDとHDDが混在する環境なのにCLASSのカラムが全部ssdってのはいただけません。クラウドではありがちな感じでしょうね。github見てると近いうちにデバイス毎にdeviceClassが指定できるようになるでしょう。いまのところは手で変更しときます。CRUSH mapをいじくってもいいです。
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph osd crush rm-device-class 0 1 2 6 7 8
done removing class of osd(s): 0,1,2,6,7,8
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph osd crush set-device-class hdd 0 1 2 6 7 8
set osd(s) 0,1,2,6,7,8 to class 'hdd'
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph osd df tree
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME
-1 0.17569 - 180 GiB 24 GiB 11 MiB 0 B 12 GiB 156 GiB 13.34 1.00 - root default
-5 0.17569 - 180 GiB 24 GiB 11 MiB 0 B 12 GiB 156 GiB 13.34 1.00 - region us-east-1
-4 0.05856 - 60 GiB 8.0 GiB 3.8 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - zone us-east-1a
-3 0.05856 - 60 GiB 8.0 GiB 3.8 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - host ip-172-20-42-193-ec2-internal
0 hdd 0.01949 1.00000 20 GiB 2.0 GiB 960 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.0
6 hdd 0.01949 1.00000 20 GiB 2.0 GiB 960 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.6
3 ssd 0.00980 1.00000 10 GiB 2.0 GiB 960 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.3
9 ssd 0.00980 1.00000 10 GiB 2.0 GiB 960 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.9
-14 0.05856 - 60 GiB 8.0 GiB 3.8 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - zone us-east-1b
-13 0.05856 - 60 GiB 8.0 GiB 3.8 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - host ip-172-20-93-28-ec2-internal
2 hdd 0.01949 1.00000 20 GiB 2.0 GiB 960 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.2
8 hdd 0.01949 1.00000 20 GiB 2.0 GiB 960 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.8
5 ssd 0.00980 1.00000 10 GiB 2.0 GiB 960 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.5
11 ssd 0.00980 1.00000 10 GiB 2.0 GiB 960 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.11
-10 0.05856 - 60 GiB 8.0 GiB 3.8 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - zone us-east-1c
-9 0.05856 - 60 GiB 8.0 GiB 3.8 MiB 0 B 4 GiB 52 GiB 13.34 1.00 - host ip-172-20-102-19-ec2-internal
1 hdd 0.01949 1.00000 20 GiB 2.0 GiB 960 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.1
7 hdd 0.01949 1.00000 20 GiB 2.0 GiB 960 KiB 0 B 1 GiB 18 GiB 10.00 0.75 0 up osd.7
4 ssd 0.00980 1.00000 10 GiB 2.0 GiB 960 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.4
10 ssd 0.00980 1.00000 10 GiB 2.0 GiB 960 KiB 0 B 1 GiB 8.0 GiB 20.01 1.50 0 up osd.10
TOTAL 180 GiB 24 GiB 11 MiB 0 B 12 GiB 156 GiB 13.34
MIN/MAX VAR: 0.75/1.50 STDDEV: 5.27
それではDeviceClassを指定してPoolを作りましょう。
[utubo@tutsunom ceph]$ cat pool-ssd-hdd.yaml
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
name: ssd-pool
namespace: rook-ceph
spec:
failureDomain: host
replicated:
size: 3
deviceClass: ssd
---
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
name: hdd-pool
namespace: rook-ceph
spec:
failureDomain: host
replicated:
size: 3
deviceClass: hdd
[utubo@tutsunom ceph]$ kubectl create -f pool-ssd-hdd.yaml
cephblockpool.ceph.rook.io/ssd-pool created
cephblockpool.ceph.rook.io/hdd-pool created
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph df
RAW STORAGE:
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 120 GiB 108 GiB 6.0 GiB 12 GiB 10.01
ssd 60 GiB 48 GiB 6.0 GiB 12 GiB 20.01
TOTAL 180 GiB 156 GiB 12 GiB 24 GiB 13.34
POOLS:
POOL ID STORED OBJECTS USED %USED MAX AVAIL
ssd-pool 1 0 B 0 0 B 0 15 GiB
hdd-pool 2 0 B 0 0 B 0 34 GiB
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph pg ls-by-pool ssd-pool
PG OBJECTS DEGRADED MISPLACED UNFOUND BYTES OMAP_BYTES* OMAP_KEYS* LOG STATE SINCE VERSION REPORTED UP ACTING SCRUB_STAMP DEEP_SCRUB_STAMP
1.0 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [11,9,10]p11 [11,9,10]p11 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.1 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [3,5,10]p3 [3,5,10]p3 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.2 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [9,4,11]p9 [9,4,11]p9 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.3 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [11,10,3]p11 [11,10,3]p11 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.4 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [3,5,10]p3 [3,5,10]p3 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.5 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [3,11,4]p3 [3,11,4]p3 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.6 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [3,10,11]p3 [3,10,11]p3 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
1.7 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:14 [5,4,9]p5 [5,4,9]p5 2019-12-02 03:55:47.245350 2019-12-02 03:55:47.245350
* NOTE: Omap statistics are gathered during deep scrub and may be inaccurate soon afterwards depending on utilisation. See http://docs.ceph.com/docs/master/dev/placement-group/#omap-statistics for further details.
[utubo@tutsunom ceph]$ kubectl exec -it `kubectl get pod -l app=rook-ceph-tools -o 'jsonpath={.items[].metadata.name}'` ceph pg ls-by-pool hdd-pool
PG OBJECTS DEGRADED MISPLACED UNFOUND BYTES OMAP_BYTES* OMAP_KEYS* LOG STATE SINCE VERSION REPORTED UP ACTING SCRUB_STAMP DEEP_SCRUB_STAMP
2.0 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [7,8,0]p7 [7,8,0]p7 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.1 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [7,8,0]p7 [7,8,0]p7 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.2 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [8,1,0]p8 [8,1,0]p8 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.3 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [8,0,1]p8 [8,0,1]p8 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.4 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [6,2,1]p6 [6,2,1]p6 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.5 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [7,0,8]p7 [7,0,8]p7 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.6 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [6,8,1]p6 [6,8,1]p6 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
2.7 0 0 0 0 0 0 0 0 active+clean 26m 0'0 36:10 [6,7,8]p6 [6,7,8]p6 2019-12-02 03:55:51.450649 2019-12-02 03:55:51.450649
* NOTE: Omap statistics are gathered during deep scrub and may be inaccurate soon afterwards depending on utilisation. See http://docs.ceph.com/docs/master/dev/placement-group/#omap-statistics for further details.
ssd-poolのPG割り当てられているのはDevice ClassがssdのOSDで、hdd-poolのそれはDevice Classがhddのものと確認できますね。
あとはStorageClassを別々に作って使い分けていくことができます。
まとめ
Cephはいろんなデバイスをクラスタにごった煮に入れて使えるので、有効な使い方ができるように多少の設計は必要ですが、最初のうちはそんなに細かく考えなくていいと思います。
まずはこれだけ留意しておきましょう。
