Ceph storage mixed usage

[Bjorn Smith]

Hi,

I have my ceph cluster running, and so far I am happy - but I would love to decommission my NAS that is serving files to some nodes in my k8s cluster.

So my question is:

Even though I am storing primarily VM's and their data inside ceph - will it be okay to e.g. store 2TB worth of multimedia files?

Or is it better to create a new pool based on spinning rust, and then put the multimedia there?

My only concern is whether or not adding 2TB of data that is rarely used into ceph will add a too big burden onto ceph, when having to do scrubs etc - or if its not a problem.

Its not often I update the data and its also rarely used - and right now its on a zfs mirror pool, so if I had to make it into a new ceph pool I would need to buy another disk, so I can get my 3x replication to have the same resiliences as the rest of the ceph pool.

 

[ano]

not quite sure what you mean here? but if you have enough space to self heal etc, your media pool just chilling will work fine no worries, its all large blocks, much easier than k8s workload

not a problem imho

 

[iGene]

I usually create crush rule for different types of disks (NVMe/SATA SSD/HDD) and based on usage assign pools to different crush rule.
Different pools are created for certain applications.

 

[Bjorn Smith]

I usually create crush rule for different types of disks (NVMe/SATA SSD/HDD) and based on usage assign pools to different crush rule.
Different pools are created for certain applications.

Yes that was what I was thinking - create a pool on either the two disks from the NAS - create a rule to only allow my "multimedia" pool to be placed on that - and either accept a lower resilience (replicas=2, min_size=1) - or pony up for a 3rd disk and just have a normal pool with 3 replicas.

 

[Bjorn Smith]

not quite sure what you mean here?

My questions was more about whether or not its a good idea to mix "concerns" into the same pool, i.e. VM storage, k8s storage together with multimedia, which will primary be streaming of large blocks of data.