Ceph SSD Tiering

Pubblicato da Andrea il

Ho provato ad inserire un tier SSD in un cluster a 3 nodi ceph usato come block storage per verificarne l’incremento di performance.
Il landscape è composto da 6 VM CentOS, 1 admin, 1 monitor+dashboard, 3 osd e 1 rbd client utilizzato come nfs gateway con il modulo kernel, in un cluster vSphere 6 a 6 nodi.


Le performance in scrittura sul nostro Ceph con spinning disk su una copia file da ESXi è di circa 70/80 MB/s

Ho aggiunto un virtual disk SSD da 64GB a tutti e 3 i nodi OSD e poi ho verficato la lista di tutti i bus con il comando

sudo –i

ls /sys/class/scsi_host/

Eseguendo i comandi seguenti ho fatto il rescan dei bus trovati precedentemente

echo “- – -” > /sys/class/scsi_host/host0/scan
echo “- – -” > /sys/class/scsi_host/host1/scan
….
echo “- – -” > /sys/class/scsi_host/host31/scan
echo “- – -” > /sys/class/scsi_host/host32/scan

Ora ho un nuovo disco in ogni nodo e ho trovato il device associato con il comando

fdisk –l

L’output è questo

Disk /dev/sdd: 68.7 GB, 68719476736 bytes, 134217728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Ho preparato i dischi e li ho aggiunti al cluster

ceph-deploy disk zap rmosd1:/dev/sdd rmosd2:/dev/sdd rmosd3:/dev/sdd
ceph-deploy osd prepare rmosd1:/dev/sdd rmosd2:/dev/sdd rmosd3:/dev/sdd
ceph-deploy osd activate rmosd1:/dev/sdd1:/dev/sdd2 rmosd2:/dev/sdd1:/dev/sdd2 rmosd3:/dev/sdd1:/dev/sdd2

Ora alcuni dati verranno mossi sui nuovi dischi, ho fatto questo per testare lo scenario di un semplice aumento di capacità con l’aggiunta di dischi.

Dal monitor possiamo modificare la crush map per separare spinning disk da ssd, ho iniziato quindi facendo il download della mappa

cd /etc/ceph
ceph osd getcrushmap -o /etc/ceph/compiled-crushmap

Ho decompilato

crushtool -d /etc/ceph/compiled-crushmap -o /etc/ceph/decompiled-crushmap

L’ho aggiornata dalla versione Originale

sudo vi /etc/ceph/decompiled-crushmap

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable straw_calc_version 1
# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root
# buckets
host rmosd1 {
id -2 # do not change unnecessarily
# weight 0.557
alg straw
hash 0 # rjenkins1
item osd.0 weight 0.500
item osd.3 weight 0.058
}
host rmosd2 {
id -3 # do not change unnecessarily
# weight 0.557
alg straw
hash 0 # rjenkins1
item osd.1 weight 0.500
item osd.4 weight 0.058
}
host rmosd3 {
id -4 # do not change unnecessarily
# weight 0.557
alg straw
hash 0 # rjenkins1
item osd.2 weight 0.500
item osd.5 weight 0.058
}
root default {
id -1 # do not change unnecessarily
# weight 1.672
alg straw
hash 0 # rjenkins1
item rmosd1 weight 0.557
item rmosd2 weight 0.557
item rmosd3 weight 0.557
}
# rules
rule replicated_ruleset {
ruleset 0
type replicated
min_size 1
max_size 10
step take default
step chooseleaf firstn 0 type host
step emit
}
# end crush map

Alla nuova versione con un nuovo layer disktype:

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable straw_calc_version 1
# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root
type 11 disktype
# buckets
disktype rmosd1_ssd {
id -5 # do not change unnecessarily
# weight 0.058
alg straw
hash 0 # rjenkins1
item osd.3 weight 0.058
}
disktype rmosd1_spinning {
id -6 # do not change unnecessarily
# weight 0.500
alg straw
hash 0 # rjenkins1
item osd.0 weight 0.500
}
host rmosd1 {
id -2 # do not change unnecessarily
# weight 0.557
alg straw
hash 0 # rjenkins1
item rmosd1_ssd weight 0.500
item rmosd1_spinning weight 0.058
}
disktype rmosd2_ssd {
id -7 # do not change unnecessarily
# weight 0.058
alg straw
hash 0 # rjenkins1
item osd.4 weight 0.058
}
disktype rmosd2_spinning {
id -8 # do not change unnecessarily
# weight 0.500
alg straw
hash 0 # rjenkins1
item osd.1 weight 0.500
}
host rmosd2 {
id -3 # do not change unnecessarily
# weight 0.557
alg straw
hash 0 # rjenkins1
item rmosd2_ssd weight 0.500
item rmosd2_spinning weight 0.058
}
disktype rmosd3_ssd {
id -9 # do not change unnecessarily
# weight 0.058
alg straw
hash 0 # rjenkins1
item osd.5 weight 0.058
}
disktype rmosd3_spinning {
id -10 # do not change unnecessarily
# weight 0.500
alg straw
hash 0 # rjenkins1
item osd.2 weight 0.500
}
host rmosd3 {
id -4 # do not change unnecessarily
# weight 0.557
alg straw
hash 0 # rjenkins1
item rmosd3_ssd weight 0.500
item rmosd3_spinning weight 0.058
}
root default {
id -1 # do not change unnecessarily
# weight 1.672
alg straw
hash 0 # rjenkins1
item rmosd1 weight 0.557
item rmosd2 weight 0.557
item rmosd3 weight 0.557
}
root spinning {
id -11 # do not change unnecessarily
# weight 1.500
alg straw
hash 0 # rjenkins1
item rmosd1_spinning weight 0.500
item rmosd2_spinning weight 0.500
item rmosd3_spinning weight 0.500
}
root ssd {
id -12 # do not change unnecessarily
# weight 0.174
alg straw
hash 0 # rjenkins1
item rmosd1_ssd weight 0.058
item rmosd2_ssd weight 0.058
item rmosd3_ssd weight 0.058
}
# rules
rule replicated_ruleset {
ruleset 0
type replicated
min_size 1
max_size 10
step take spinning
step chooseleaf firstn 0 type disktype
step emit
}
rule spinning {
ruleset 1
type erasure
min_size 3
max_size 20
step set_chooseleaf_tries 5
step take spinning
step chooseleaf indep 0 type osd
step emit
}
rule ssd {
ruleset 2
type replicated
min_size 1
max_size 10
step take ssd
step chooseleaf firstn 0 type disktype
step emit
}
# end crush map

Ho compilato la nuova mappa
crushtool –c /etc/ceph/decompiled-crushmap –o /etc/ceph/new-compiled-crushmap
E aggiornato la crush map nel cluster
ceph osd setcrushmap -i /etc/ceph/new-compiled-crushmap
Ora i dati del Default pool verranno rimossi dagli SSD

Ho creato due pool, uno ssd (hot) e uno spindle (cold)
ceph osd pool create hot-storage 100 100 replicated replicated_ruleset
ceph osd pool create cold-storage 100 100 replicated replicated_ruleset
ceph osd pool set hot-storage crush_ruleset 2

Ho aggiunto l’hot-storage come tiering del pool cold-storage
ceph osd tier add cold-storage hot-storage

Ho impostato la cache in writeback e rediretto il traffico client al pool hot con l’algoritmo cache bloom
ceph osd tier cache-mode hot-storage writeback
ceph osd tier set-overlay cold-storage hot-storage
ceph osd pool set hot-storage hit_set_type bloom

Successivamente dal client ho creato una nuova immagine di 100GB sul cold-storage pool
sudo mkdir -p /cephfs-cache
sudo rbd create cold-storage/nfsdata-cache –size 100G
sudo rbd feature disable cold-storage/nfsdata-cache fast-diff object-map deep-flatten exclusive-lock
sudo rbd map cold-storage/nfsdata-cache
rbd showmapped
sudo mkfs.xfs /dev/rbd0
sudo mount /dev/rbd0 /cephfs-cache
Ho testato il mount del disco
Df –hT
Ho aggiunto un export NFS del nuovo folder e aggiunto un nuovo datastore sul cluster VMware.
Ho lanciato la stessa copia e, dal server monitor, ho verificato che la cache stesse lavorando correttamente con il comando
Sudo ceph osd pool stats
Lo spazio viene consumato dall’Hot-Storage pool invece che dal pool Cold-Storage
Sudo rados df
Dalla dashboard ho verificato le performance

La copia ora impiega 18:17 invece di 25:15 dell’utilizzo di soli dischi spinning con quasi il doppio delle performance di prima.
Dopo ho provato a riconfigurare i dischi SSD come journaling degli spinning e sembra che le performance siano simili al tiering.


0 commenti

Leave a Reply

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.