I'm looking to migrate from a single HTPC to a NAS with multiple clients (most likely Raspberry Pis on each TV). After poking around on a few forums (including this one), I'm pretty sure I've settle on a Synology NAS, and I'm planning to have a media rack in our basement to house everything. I'll have a gig ethernet switch down to connect the NAS and the clients. I'd like to migrate the mySQL database to the NAS as well and then connect to all the Raspberry Pi clients via NFS.
Given all that, I'm leaning towards the DS815+ (with 4 3TB drives), but I'm wondering if the DS815 would work as well. I'm mostly thinking about the 815+ to ensure I have enough processing power to deal with the mySQL database and then using the link aggregation (the switch supports it) to get the best throughput I can to the clients (probably never more than a couple at a time, but maybe three in some situations). I'm also going to have PVR machine recording stuff locally and then copying the stuff the the NAS (via SMB), so there could be four clients doing reads/writes of data simultaneously.
Thoughts?
A single gigabit link (1000Mbps) is enough to host over 20 devices streaming Blu Ray rips (~30Mbps). Each DVR stream shouldn't be more than ~15Mbps. Link aggregation will be useful if multiple computers are each saturating a gigabit connection (e.g. bulk file transfers, remote video editing).
I can't find the specification sheets for the Synology models you have selected, but both should work. Serving media requires negligible computing power. The performance bottlenecks are usually the CPU if you transcode files and the system throughput for parity calculations. MySQL is generally bottlenecked by storage device random read/write speed, so either install enough ram to keep the database entirely in memory and/or use an SSD.
If you anticipate your storage needs to grow significantly in the future, I'd buy the largest HDDs you can (personally, I'd wait for 10TB drives) and then stick with that drive model as you expand your array. Synology and other parity-protected JBOD systems (e.g. UnRAID, SnapRAID) can use different size disks, but disk rebuilds take longer.
This is an issue because drive sizes have expanded faster than their I/O speed, meaning the largest contemporary drives already have rebuild times >15 hours. Mix disk sizes and that time goes up, increasing the window of a second disk failing during rebuild. Mixing drives around the same size (e.g. 6TB, 8TB, 10TB) isn't that big of an issue, but wildly differing sizes (e.g. 2TB, 10TB) can really slow things down. Also note that parity needs to be your largest disk.
Again, if you anticipate your storage needs growing significantly, building your own NAS and using software like UnRAID will be much cheaper and more flexible over the long run. If you can get your antenna/cable feed to the server, you can also consolidate the PVR function into it via Docker or a virtual machine.
Thanks for the feedback ZwartePiet. I apparently did the math wrong somewhere on the bandwidth for streaming. Somehow I got that I could saturate a single link with a couple of clients. I clearing put a zero in the wrong place somewhere. I think the 9TB of space will hold me for quite some time, but when I get to building I'll look at larger ones. I've left space in the rack for one of their expansion devices for growth, but larger drives would move that down the road quite a bit.
I know folks really like unRAID, but everytime I start I get kind of overwhelmed. I'm comfortable trading money for a commercial solution in this case. Well, probably. I'll take another look at unRAID.
Again, thanks.
Using a commercial product works great, it's just that you pay a premium for it.
I still stand by my recommendation to buy the largest HDDs available, even though they are more expensive than smaller models. The reason is that the overall cost per gigabyte of your NAS is:
(Drive Cost x Number of Drives + NAS Cost) / Array Size
With 10TB drives, you could meet your storage needs with a much cheaper 2-bay model. Adding drive bays is expensive in both acquisition and running costs (i.e. electricity), so the fewer the better. Just some food for thought.