Note: larger HDDs have really low IOPS-per-TB; SSDs avoid that issue but cheap SSDs do not have PLP so write IOPS are much lower than read IOPS.
That is something I've seen mentioned a lot, so we've only got PLP drives on the shopping list. The tentative current shopping list is 24x 7.68TB Samsung PM893 or Kingston DC600M drives.
PLP is crucial, but there are other factors. If you have a choice, NVMe SSDs give a lot more bang for the buck than SATA. The Kingstons don't have IIRC stellar performance, but maybe you don't need it to be.
Whether the drive is SSD or HDD larger ones also usually mean large PGs which is not so good. With SSDs at least it is possible (and in some cases advisable) to split them into multiple OSDs though.
Could we just increase the number of PGs to avoid this?
With Quincy and later releases, the former advice to split became a wash. Splitting HDDs was never widely practiced or advised. With modern SSDs > 30 TB splitting might make sense. There are serializations both in OSD and PG code.
That is indeed a good suggestion: the fewer the drives per server the better. Ideally just one drive per server :-).
This might just be possible, since we've got a couple of racks of render nodes that I can probably make the case to retire from render duties. Would I actually see a major advantage going from 6 nodes to 8, from 8 to 12, or from 12 to 24? (Given 24 disks in each case.)
Those chassis can even only have their server trays partly populated too. Were you to have 8 chassis, you could make `chassis` your CRUSH failure domain, with however many drives per chassis/host.
Andrew
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io