March 1, 20197 yr Hello, We would like to ask you to help us in the following situation. We have just bought a new HP server with 3 SSD (same type, 500 GB capacity) and 3 HDD (same type, 4 TB capacity). We would like to install few virtual machines, Ubuntu and Windows 10 as well. We would like to create storage from SSD and HDD device for each VMs. And another neccessary thing is, that we should be able to move storage capacity from one VM to another in the future . If it is possible, how can we do this? Should we create only one big array (including all SSD and HDD devices) or we should create more, smaller arrays for each VMs? Which disk (or disks) can we mark as parity disk(s)? We think it is a basic problem, but we have just started to learn and use UnRAID virtualization software and that is why we need some help. Thank you for your help, Best regards, Gyorgy
March 1, 20197 yr @Gyorgy Welcome to Unraid I'll try to help you in your situation and maybe make the right decision for your usecase. First of all, the parity drive has to be minimum the same size as the biggest drive in the array. If you want dual parity for the array, both parity drives have to be at minimum the size of the biggest array drive each. The array is mainly used to store all your data on and is accessible on its own. Better described with an example. If you have lets say 3 drives in the array without a parity drive and one of the drives dies, only the data on that one specific drive is lost, everything on the other 2 drives are still available. This fact makes it easy to expand the array later with more drives. It's kinda an easy plug and play solutionn to add more drives later. If you have a parity drive and one drive dies, you can add a new drive in and let the parity rebuild the data on the drive you lost. Keep in mind, the read and write speeds aren't like in an RAID5 or Raid10 where the drives speeds add up. You only have the speed of one drive. Here comes the cache drive in place. You can define your network shares to use the cache drive first, if someone places data on the share, in case of an SSD you gain from the read and write performance of an SSD. Shares can be sitting all the time on the cache drive or can be automatical moved to the parity protected array at a defined cycle, for example every night. For VMs you wanna use an SSD storage. We all know these days thats a big difference having an OS sitting on an SSD vs. an HDD, right? You have 3 options here. 1. VMs always sitting on the cache drive as a virtual disk image (vdisk) 2. VMs sitting on an unassigned device as an vdisk 3. VMs with an physical passed through SSD only used by that specific VM (passthrough) The cache isn't protected by the parity of the array. You can use one single drive for the cache or 2 drives as RAID0 for performance and have a backup strategy in case the drive fails or you can have 2 drives in an mirror configuration like RAID1. Depending on how much storage is needed inside the VM for the OS and it's programs you have to decide where to place the VM. Does it fit on the cache drive besides all the cached shares you defined or do you completly separate it from the cache and have the VMs on non-cache non-array drives. Or if you want close to bare-metal performance the best choice is to have only one VM using that SSD via a passthrough solution. Keep in mind having 2-3 VMs running on the same SSD at the same time reduces the performance for all 3 VMs. In your situation I would specify the 3 4TB drives as the array with 1 parity drive. so you have a total of 8TB of storage to play with. The 3 SSD i guess you have two choices. For security reasons having a 2 drive cache configured as RAID1 would be the best choice. You can for example have one VM sitting on the cache the second VM on an unassigned device, both as vdisks or passthrough the 3rd SSD completly to one VM. Expanding the storage of these vdisks later on is kinda easy. Shutdown the VM, change the vdisk size, start the VM and expand the partition. For the cache drive you have to have an eye on it how much space is consumed by cached enabled shares and by the vdisks maybe sitting on the cache drives. It's hard to predict how your usecase will be. Inside the VMs you can mount your network shares sitting on the array as every other network share. If you have software that doesn't like accessing data on a network share you can have more vdisks attached to the VM and place them on the array or the cache, depending on the size and what performance you like. If you're new to Unraid you have a month to test the software without any limitations and check different configurations and look which one fits best for you. Limtech has a couple tutorials up which you can start with https://lime-technology.com/getting-started/ and also SpaceInvaderOne's Youtube channel is highly recommended to get an idea what you can do and how to configure stuff on Unraid. Edited March 1, 20197 yr by bastl
March 1, 20197 yr Community Expert A couple of points: SSD's are not officially supported as array data disks. In your case you should either use them to create a cache pool or use them as "Unassigned" disks outside of direct Unraid control. There is an Unassigned Devices plugin that can help with handling disks not directly under Unraid control. Unraid only supports a single array. If you have hardware RAID controllers then these can combine several disks into one logical drive for presenting to Unraid (which then sees such an array as it is was a single drive). However this is not the normal way one uses Unraid. If you are going to have a parity disk(s) then the only rule is that it needs to be a drive that is at least as large as the largest data drive. Another thing that is not clear from your description is whether you really want to dedicate real physical disks to VMs or you are going to use 'virtual disks' If going the virtual route then a disk is emulated as single file at the Unraid level even though the VM sees it as if it were a drive containing a full file system.
Archived
This topic is now archived and is closed to further replies.