January 5, 20179 yr I have been tasked by work to create a new storage solution for our needs. Our current setup consists of 5 servers with ~10 Tb each. As per requirements, we have a backup of our storage servers in another room, as well as a 3 rotating backup servers that live in a cave that get synced every quarter. All of our drives are reaching their lifespan limits, so there are multiple reason whey we are upgrading. The current working drive spaces are simple 4-8 drives in raid 10, with a raid controller and NTFS. The reason we split them between machines was to split workloads of I/O. What I am proposing to do is to consolidate to a single server (per room) using unRAID. I am probably going to get schooled on setup or feasibility, but that's why I'm here, and posting. Storage Server: 24 slot Rack Mount Case with 24x8TB drives in BTRFS raid 10 1151 socket Mobo with 2x M.2 (samsung 960 evo pro 1TB) slots used as cache 64 gigs ram 3xController Cards (mini-SAS) to connect HDDs existing dual 10 Gb fiber NICs Some questions I have are: Does unRAID work offline, ie not connected to the internet. Our whole setup is never connected to the internet, or outside world, ever. That cant change. Would an intel 6700k cpu be enough for that large of an array in BTRFS? (having used raid controllers and NTFS for so long our cpus are never taxed). What throughput would be feasible with 2 M.2 drives as cache for a BTRFS in raid 10? NVME drives, do they work as cache in unRAID for BTRFS? Long term storage? i've seen NTFS just decide every single file is now corrupt without a single drive failure. With no way of recovery. Luckily we have backup solutions. Using a pcie 3.0 x8 controller cards, would it be better for a single 6xmini-SAS or multiple pcie 2xmini-SAS cards? (this is a current argument im having with a coworker) Requirements we need for storage: Fast - We deal with 8k footage (8192x8192 pixels) on a daily basis. Editing/Compositing that is, rather plainly put, taxing. We also have a render farm, but that's not really fast I/O for storing frames, only pulling across assets, textures, etc to each node for rendering needs a good throughput. So for ~100 machines pulling assets at different times. Reasons why we done with our current solution: We need more space. I am also tired of dealing with X and Y controllers with different software, and different failures and issues. I also want to consolidate to save space for new render nodes. Any and all help with welcomed. I am new to linux for storage, however I have used linux with ssh plenty and am not afraid of it. I also really like the web interface unRAID provides.
January 5, 20179 yr Hate to say it but I don't think unRAID will do the job, at least not as you have defined it currently. unRAID is not RAID. The main parity array doesn't support any RAID configuration at all, just the unRAID method of independent data disks of various sizes with parity protection. The user shares will allow these disks to be "pooled", but each disk is an independent filesystem and any file is completely contained on a single disk. It is possible to use a hardware raid controller and present multiple disks to the unRAID array as if they were a single disk, and some have done that, but that seems like it would only complicate things rather than simplify them. unRAID doesn't do fast, but it has the advantage of allowing mixed disk sizes, and in the event that you have more failures than parity can recover from, only the failed disks are affected, and often data can be recovered from them even then as long as the disk is readable. You can do several different btrfs raid configurations in the cache pool. I think raid10 will require more than 2 disks though. See this wiki: UnRAID 6/Overview
January 5, 20179 yr Yeah Trurl is right, unRAID is not the solution for this, you need a fast hardware raid controller with 1 to 2GB NVcache and either fast 15K SAS drives or solid state. You could standardize on RAID controllers if you buy more then one of the same configured server from Dell, HP or Lenovo.
Archived
This topic is now archived and is closed to further replies.