Setting Up UNRAID for Plex Sharing - 6.5.3

[sannitig]

Hello,

 

Hopefully this is posted in correct place as it's more of a unraid/plex hybrid post.

 

I've been a light Unraid user for a couple years now and am looking to offer my Plex content to family and friends but I know I will need to do a complete overhaul on my server and am looking to the community for a little assistance in terms of bottleneck discussion, CPU/GPU, migrating data and how to optimize performance/longevity. The server currently acts as a media server and network share for family pictures/training videos/documents etc.

 

My current build is:

Parity - 2TB WD RED

Disk 1 - 2TB WD RED

Disk 2 - 1.5TB  WD Something or other

Disk 3 - 2TB WD RED

COLD SPARE - 2TB WD RED

 

Motherboard:Gigabyte Technology Co., Ltd. - GA-MA785GM-US2H

Processor:AMD Athlon™ II X2 245 @ 2.9 GHz

Memory:4 GB (max. installable capacity 16 GB)

            A0 = 2048 MB, 800 MT/s

            A1 = 2048 MB, 800 MT/s

Graphics Card: Onboard

 

Is there a general "walk-through" I should be looking at that has server build, tips, tricks and gotchas?

 

Pardon my ignorance but bare with me here. I'm looking for advice on the more obscure things like:

"remember to get a cache drive and set it up to copy at night" 

"when setting up your drives make sure all your plex media is one drive that way you can implement 'spin down' to help save power" 

"put the most used drive at the top of the array or the bottom or the middle (or wtvr) for thermal reasons" 

"make sure you run automatic smart scans and are sending email alerts if either it fails the smart scan or straight up if a drive fails at anytime" 

"is it wise to get a meh CPU and a great GPU and sign up for a plex pass to perform hardware transcoding (i've never owned a gpu in my life - always had onboard on all PCs ever built)" 

"where's the bottleneck? ie if 5 people tried to stream the same file, could a standard 5400rpm hard drive keep up?"

"when you upgrade your parity and first drive to 8TB drives, migrate all your data to the 8TB drive and pool your 4x2TB drives into one pool and add that as a '6TB drive w parity' to the main array (so the 2TB drives don't go to waste) - would this make sense?"

"I've read when migrating data, do not migrate from disk-to-disk, it should be migrated using the user folder instead - this seems like an important gotcha"

 

These sorts of things, I would think, should be part of an in-depth walk-through to get unraid/plex up and running.

 

I appreciate any assistance that can be given here or perhaps lead me in the right direction - my wife is ripping on me to get off the computer so I'm outta here

[sannitig]

Bueller? 

[trurl]

Cache drive will be a useful addition, but maybe not in the way you are thinking. If you setup your dockers and VMs so they stay on cache (not moved at night), then they will perform better and won't keep array disks spinning. The shares appdata (working storage for dockers), domains (VM OS storage), and system (libvirt and docker image, where the docker executables live), should be setup to stay on cache.

 

A possible bottleneck you haven't mentioned, and may be the most important, is the upspeed of your internet service. If people not on your LAN are going to stream from your server, do you have enough up bandwidth?

 

No reason to keep all plex media on one drive. Drives will spin up as needed and spin down when no longer needed.

 

You really should have your cooling good enough so that all drives are kept within reasonable temps.

 

Unraid already monitors SMART for all array and cache pool disks and other problems. You just need to be sure to setup Notifications so you get those alerts.

 

You don't necessarily have to have a separate GPU. My intel CPU has that builtin and I use it for hardware transcoding. Maybe with AMD you would have to if you want hardware transcoding.

 

I've never tried more than 2 streams, plus DVR, but I do have users from many states away. Probably a lot of factors besides just disk speed. Maybe someone else will have more on that.

 

On 4/27/2020 at 11:10 PM, sannitig said:

"when you upgrade your parity and first drive to 8TB drives, migrate all your data to the 8TB drive and pool your 4x2TB drives into one pool and add that as a '6TB drive w parity' to the main array (so the 2TB drives don't go to waste) - would this make sense?"

Not only would this not make sense, but I would say it doesn't make any sense at all, as in, you can't even do it. There is only a single parity array, which can have up to 2 parity disks. There is no way to have another "pool" with separate parity.

 

On 4/27/2020 at 11:10 PM, sannitig said:

"I've read when migrating data, do not migrate from disk-to-disk, it should be migrated using the user folder instead - this seems like an important gotcha"

Not entirely clear what you mean here. "Migrating" seems a pretty broad concept. What exactly are you migrating, and what are you trying to accomplish.

 

You should not mix user shares and disks in the array or cache pool when moving or copying files. Sometimes it makes sense to move from disk to disk, sometimes it makes sense to move from user share to user share. Depends on why you are moving.

 

Posting your diagnostics will probably go a long way to answering some of our questions about how you have things currently setup so we can make better recommendations and maybe guide you through making some changes.

 

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

 

[sannitig]

Thanks for the reply and I will take into consideration everything you've mentioned. I've attached the ZIP. The following may seem long but I think the answers will be pretty straight forward for most.

 

I'll start with the "migration" topic as I should have been clearer. I plan to upgrade to 8TB drives. I was going to put in an 8TB drive and assign it as parity, then pull the 2TB parity out. Next I would put my first 8TB data drive in, but I want to migrate a lot of my data off one of my full 2TB drives and then pull that 2TB out - this is what I am referring to in terms of migration. But from my understanding one does not simply cut/paste from the 2TB to the 8TB drive. I've been told to always add media into the /usr folder and never the /disk1, /disk2 or /disk3 folders - not sure how this would be accomplished here, only way I can think of is disk-to-disk

 

For the pool within a pool - the reason I was asking about that was I don't want to have too many disks in my array - the more disks the greater the risk of catastrophic failure. If I pooled the four remaining 2TB drives as one 8TB pool (minus the parity) I would a bit more redundancy built in compared to just letting those four drives be part of this larger array I'm building.

 

Spreading data across drives - any ideas on how to optimize this? Like if half a dozen people will be watching streams, perhaps TV on one 8TB and movies on another? Training videos on another? I originally was trying to conserve power by inquiring about placing all servable media on one drive but now I'm thinking that ain't to great for performance - but then again, that goes back to the question can a drive be a bottleneck, if not then putting it all on one drive should be a-ok.

 

Upload speed - a lot of my concerns are actually stemming around this. This is because I have terrible upload speeds and will be physically bringing this server to my in-laws' 1 hour away from my house, place it in their basement with ethernet connection to 1-gbps up/down  yee haw. So as you can see, I'm thinking about power conservation, redundancy and alerting since I will be an hour away at minimum at any given time

 

Cache Drives - I think I have a couple of 500GB drives lying around (eventually I'll also have those 2TB drives). I don't think I fully understand this concept though. I don't have any VMs and the only Docker I have really is Plex. Do you mean as the data (movies) is served to users it will be copied on the cache drive and prevent array disks from spinning up? That's kinda cool.

 

What CPU do you have - notice how old mine is? Also, I've just realized I can't control what ppl use on their end to transcode - for example I tried to cast a 4k H265 movie (50GB) locally to my chromecast and my server started screaming via the hardware temperature alarm, not good. If I had someone attempt what I did, I would never know my cpu is melting since the server will be an hour away in someone else's basement - so I want to make sure I have a decent CPU or even a GPU that can do the work. Which leads to another question - if you have GPU transcode set, does that mean the CPU basically does nothing anymore and the GPU is doing all the work, or is there a shared load? I'm thinking if the CPU is left alone, might as well use the CPU I have with a kickass GPU

tower-diagnostics-20200430-2145.zip

[trurl]

It sounds like what you really have in mind as far as the actual data isn't really a migration, but simply upsizing some of your data disks.

 

The usual way to "upsize" a data drive is to simply replace the drive with a larger drive and let it rebuild. No need to copy anything at all. The only time you might want to do something a little different than just rebuilding a disk to a larger disk is if you intend to finish with fewer disks at the end of this "migration". Then you might do some copying from some of the disks you want to remove to some of the already upsized disks before removing them.

 

12 minutes ago, sannitig said:

I don't want to have too many disks in my array - the more disks the greater the risk of catastrophic failure.

I always say each additional disk is an additional point of failure. And more drives requires more hardware to support them. And larger disks perform better than smaller disks and are less expensive per TB. So I always encourage upsizing disks instead of adding disks. Maybe with the increased capacity from upsizing you don't really need any of those original 2TB disks.

 

17 minutes ago, sannitig said:

always add media into the /usr folder and never the /disk1, /disk2 or /disk3 folders

/usr is actually an operating system folder on RAM. The user shares are in the user folder under /mnt (and the disks are also under /mnt).

 

There are some reasons for that advice that don't apply in all cases. One reason is so you don't mix user shares and disks when moving / copying, which can result in data loss. Another reason is because it is simpler to let Unraid decide which disk to put something in accordance with user share settings, so folders can span disks, such as when you have more movies than will fit on a single disk, they can all still be in the same user share.

 

But if all you are really trying to do is upsize data disks then much of that is probably moot. And if you do intend to remove some disks after upsizing others, then moving from those disks to the upsized disks makes perfect sense because your purpose is all about which disks are used.

 

25 minutes ago, sannitig said:

Spreading data across drives - any ideas on how to optimize this?

If you can have different people streaming from different disks then you could expect that to perform better. For example, if you had kids movies and movies for everyone else, then maybe you could have separate user shares for those, and set the shares to include different disks. Just depends on your specific needs. If everything were on one disk then there would definitely be some number of streams that would strain the capabilities. Not sure where that line is, but a few might be OK depending on other factors.

 

32 minutes ago, sannitig said:

I will be an hour away at minimum at any given time

You will definitely want to setup the builtin WireGuard VPN so you can manage it remotely.

 

34 minutes ago, sannitig said:

I don't have any VMs and the only Docker I have really is Plex. Do you mean as the data (movies) is served to users it will be copied on the cache drive and prevent array disks from spinning up? That's kinda cool.

No, that's not how it works. Your media will typically be served from the array disks. Cache can be used to improve performance of the plex docker though, since its library will be on the appdata user share and its executable code will be in the system share. Those shares can be setup to stay on cache where they will not be impacted by the slower parity writes, and where they won't keep array disks spinning.

 

But there is no mechanism to move your media to cache as needed for playback.

 

I do my Plex DVR to cache (SSD pool) since there is some performance benefit when trying to record and/or playback multiple DVR programs at the same time. I may delete the recording after watching it, or if I want to keep it gets move to other user shares on the array.

 

My CPU is several years old now also. It is a 4th generation i5 (Haswell). But it has builtin iGPU so I can transcode with that. My specs are probably a little weak compared to many on the forum, but it is working for me. Often only 1 stream, seldom more than 2.

 

Even if you have GPU transcoding there is still definitely some work for the CPU. I think GPU usage varies depending on the specific codecs for example.

 

And there is more to performance than just CPU/GPU of course. Newer motherboards, RAM, even disks can all contribute to greater performance.

[trurl]

I took a quick look at your diagnostics. Cache is something we already discussed. Another thing that can help is more RAM. You can setup your plex docker to transcode to RAM, which is obviously faster than even SSD cache.

[sannitig]

Regarding copying data from one disk to another, is it ok to simply plop an 8TB into the array, take all the data from 2TB and copy it over then just remove the 2TB from the array?

 

I know the easiest way is to pull the 2TB out first and replace it with the 8TB drive and let unraid rebuild the array but I'm trying to avoid being in a degraded state.

[trurl]

3 hours ago, sannitig said:

Regarding copying data from one disk to another, is it ok to simply plop an 8TB into the array, take all the data from 2TB and copy it over then just remove the 2TB from the array?

 

I know the easiest way is to pull the 2TB out first and replace it with the 8TB drive and let unraid rebuild the array but I'm trying to avoid being in a degraded state.

If you do what you are suggesting, you will have to rebuild parity after you remove the 2TB, so might as well just do the "easiest way" and rebuild the data disk.

[sannitig]

thanks trurl - easier is better sometimes.

 

Out of curiosity what speed of drives do you use? I see many threads on this (5400rpm vs 7200rpm), slow lasts longer etc....

 

But if you were to buy drives, full knowing that you plan to have 20-30 different streams at a time, would it still be ok to be running the cheaper 5400rpm drives? The server will be at the in laws with 100mbps upload and each drive is 112mBps read speed so I should be way more than fine using the 5400rpm drives no? Does multiple reads at once matter here?