SSD for Docker and VM's

[Jurre]

I'm setting up my new unraid server and I was wondering how I can best setup my drive pool.

 

I have currently setup my array with 4, 8TB WD Red drives with no parity disk.

 

I want to add a 256GB SATA SSD for the VM's and Dockers, what is the best way to add this? Add it as an additional drive in the array, or adding it as a cache drive? and would adding it as a cahce drive even make sense with 196GB of ram?

[trurl]

2 minutes ago, Jurre said:

would adding it as a cahce drive even make sense with 196GB of ram?

Don't understand this question. Cache is persistent storage that is used for a number of purposes, including a place to have VMs and dockers so they will perform better.

 

SSDs are not recommended in the array and can't be trimmed in the array. Assigning it as cache and using it for VMs and dockers is the usual method. If you assign it as cache Unraid will manage it. If you don't assign it to Unraid, you will have to use the Unassigned Devices plugin to manage it. Also, if you put it in a btrfs cache pool you can use some of the raid modes to get redundancy for that storage.

 

Why no parity?

[Jurre]

12 minutes ago, trurl said:

Why no parity?

I have an nightly cloud copy of all the files, and In the worst case it would take me 4 days to download all data back from the cloud. 

 

So I assumed that this would be quicker then the time rebuilding the array would cost?

 

Also I read that the having a parity disk will effect the performance. I don't know how true this is though.

[bonienl]

Parity has only impact on write speed, but it depends on your disks how much the actual impact will be.

My main server has all new 10TB disks and dual parity, still it can write to the array in excess of 100MB/s, actually my gigabit ethernet connection is the limiting factor. My backup server which has "older" 4TB disks and single parity can write between 50MB/s and 60MB/s.

 

Read speeds are limited by what a single disk can deliver, which is usually much higher than the network connection speed.

 

Edited September 20, 2018 by bonienl

[trurl]

Just now, Jurre said:

I have an nightly cloud copy of all the files, and In the worst case it would take me 4 days to download all data back from the cloud. 

 

So I assumed that this would be quicker then the time rebuilding the array would cost?

 

Also I read that the having a parity disk will effect the performance. I don't know how true this is though.

Are you sure you could get 32TB down from cloud in only 4 days?

 

Backups are a good thing and we recommend everyone have another copy of any important and irreplaceable data whether they have parity or not. Unraid parity or indeed any traditional RAID isn't and never has been a substitute for backups.

 

Rebuilding a disk from 8TB parity should take only a day +/- a few hours but that is perhaps not a fair comparison since you were claiming you could download ALL data in 4 days.

 

But as mentioned, the purpose of parity isn't to serve as a backup anyway. Redundancy allows you to keep going even when a disk is missing and while the disk is rebuilding. There is some write performance penalty with parity but there are 2 modes for that. One mode is slower but allows all disks except the disk to be written and parity to be spun down, and the other mode is somewhat faster but requires all disks to spin.

 

And of course, if you were actually rebuilding a disk, while you would still be able to access all your files (including those from the missing disk) and continue to use the array, performance would also be impacted during the rebuild.

[trurl]

And overcoming the write performance penalty of parity is another (and the original) purpose of cache. Files are written to cache at full speed and later moved to the parity protected array.

[TheBenga]

It's been a looong time since original poster was here but thought i might make a comment in case anyone else comes along here.

 

OP likely has not taken account of egress charges from cloud. All the major platforms do not charge for ingest but DO charge for egress e.g. pulling your data back out. This is a per-MB model. If he were to pull his data back it would cost him nearly $3,000. I very much doubt he'd taken this into account!!

 

Lesson, make sure you really understand the ramifications of your choices by learning about the tech you are employing.

[JonathanM]

9 minutes ago, TheBenga said:

All the major platforms do not charge for ingest but DO charge for egress e.g. pulling your data back out. This is a per-MB model. If he were to pull his data back it would cost him nearly $3,000.

Which platforms charge and which don't? Can you provide links to their policies where it specifically states their rates?

 

Many people here are using google drive, which as far as I know doesn't charge to give you your data back.