On 11/8/21 13:04, Boris Behrens wrote:
That does not seem like a lot. Having SSD based metadata pools might
reduce latency though.
So block.db and block.wal doesn't make sense? I would like to have a
consistent cluster.
I don't want to state that this would not make sense. All IOPS that
would not go to HDD would be be available for data IO. But there are
more things to take into consideration here. 1 SSD on 10 HDD is quite a
big blast radius. One failed SSD would take 10 HDD with them.
In either case I would need to remove or add SSDs, because we currently
have this mixed.
It does waste a lot of space. But might be worth it if performance
improves a lot. You might also be able to separate small objects from
large objects based on placement targets / storage classes [1]. This
would allow you to store small objects on SSD. Those might be more
latency sensitive than large objects anyway?
Gr. Stefan
[1]: https://docs.ceph.com/en/latest/radosgw/placement/
<https://docs.ceph.com/en/latest/radosgw/placement/>
Puh, large topic.
Would removing the smaller files from the spinning disks release enough
pressure from the flying heads to speed up large file uploads? Could be
a test, but I don't know if this would work as expected. I can imagine
that this leads to larger problems, when the SSD OSDs run out of space.
Then you would need to change the SSH/HDD ratio in the hosts. And add
more hosts to scale both small / large objects together in the proper ratio.
Also I would rather add more spinning disks because we also need a lot
of space.
Gr. Stefan
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
