0

I'm designing a ceph cluster for mixing cephFS and rbd for my company( VM et file infrastructure).

In my set I need 32To raw storage by node. I start with 5 nodes.

The seller quotes propose me to choose beetween 16 ssd of 2 teras or 8 ssd of 4 teras by node.

I mean what is the impact on the IOPS managed by ceph in theses cases, the reconstruction delay etc. May question is highly related with CEPH, not general.

I've follow many guide to drive my choices in many aspects, including ceph documentation and books. But not sure to really have the answer of this question. The only clues I've found are things like 'bigger is better'...

Wich approach I need to follow to choose beetween theses 2 options ?

Here some details if needed : The network nics dedicated to cephs Vlans are 25Gb speed, redondants etc I've considered to multiply at least 4Gb Ram for 1 tera on OSD, so 128 by node to be large. SSD disks are enterprise fitted and read intensive.

Thanks for your help

Cheers

Ztevoz

Ztevoz Milloz
  • 3
  • 3
  • Thanks Nikita, but no. I've just realized that I've no specified Ceph in the title....I've just tagged my question with ceph keyword. So my question is highly related to ceph and about his optimization. I've read the link, interesitng by the way, but global. Ceph is a distributed storage application which is not easy to configure correctly, even you are already aware with all the concepts listed in the links. Cheerz, ZtevOz – Ztevoz Milloz Oct 05 '22 at 18:14

1 Answers1

0

If those two options are your only options and both SSD models are enterprise SSDs you should be fine with both. Points to consider are scalability, performance and failure domains. The more OSDs you have the more resilient you are to disk failure because less data has to be transferred during recovery. You would also benefit from more parallelization by having more disks which could increase performance. If you don't use all slots and have only 8 disks per node instead of 16 you can add more disks later if your capacity reaches its limit. Don't let your cluster become full, that will be very difficult to get out of. Also plan your capacity to sustain the loss of an entire host so your PGs can be recovered even if an OSD host goes down. And that host failure should also not fill up your cluster, of course.

eblock
  • 417
  • 2
  • 6
  • Hi, thanks eblock for your answer. Yes it's enterprise ssds. I totally agree the reasoning about the osds. For scalability I'll try to leave some shelves free (Dell R750) and add nodes of course. I've difficulties to understand how to compute the slack to sustain losses. Too, I need to undestrand failure domains...Ceph is attractive but can be a problem if I lack of knowledge. – Ztevoz Milloz Oct 12 '22 at 17:09
  • You need to plan how many hosts or OSDs can fail but still have service availability. For example, with a default replicated pool with size 3 and 5 hosts I would use a crush rule to spread all three replicas of a PG to three different hosts (failure domain). If one entire host goes down you still have 4 hosts left, and if your capacity allows it, ceph would recover the missing replicas on the remaining 4 hosts. You could lose another host and would still have all PGs available (with a respective crush rule), but depending on the capacity you'd have a degraded but functional cluster. – eblock Oct 13 '22 at 13:24