• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Expanding storage

akode

n00b
Joined
Apr 4, 2012
Messages
41
Right now I have OI running with 2x2tb drives in a mirror. This is used a a file share and nfs storage for ESXI.
I am down to about 500gb free and when im running 5+ windows vms sometimes I have slow response which i think is being caused by only having 2 disks in my array.
So im looking to expand and wondering what my best option is. Would like to spend less then 500 bucks total, which leaves me open to purchasing 3-4 more 2tb drives or 3x3tb drives.

Taking my current 2x2tb drives into account plus another 3-4x2 tb or 3x3tb drives what is my best course of action in regards to raid config.

Thanks in advance.
 
How much data do you project to grow in the near future? If not too much, I'd do this way
1. buy 2 more 2T disks
2. add mirror vdev to existing zpool
3. create a new datastore
4. svmotion VMs to new datastore to re-balance between vdevs.
 
How much data do you project to grow in the near future? If not too much, I'd do this way
1. buy 2 more 2T disks
2. add mirror vdev to existing zpool
3. create a new datastore
4. svmotion VMs to new datastore to re-balance between vdevs.

I actually do project to grow more then that over the next year as I plan on expanding my media catalog, thinking minimum 6tb usable
 
Then buy 4 more 2T disks, backup your VM and recreate a raidz2 zpool with 6 disks. This should give you close to 8T space and even at 6T used it will not degrade performance, at the same time, higher resistance to disk failure.

I personally will not go raidz with bigger than 2T disks and mixing different sized disk and vdev in same zpool is also bad.
 
While this is probably WAY more in depth than you need to go, I figure that I'd write up a small guide to calculate what would be best for your environment:

You mentioned that you are mirroring the 2 disks (RAID 1). RAID 1 has a heavy penalty when it comes to performance as you can only go as fast as the fastest disk in the RAID group. I would highly recommend that you use RAID 5. When creating the RAID group, try to have the same type of disks in it as mixing disks can cause problems. You will need at least 4 disks to do RAID 5 (3+1), however the most common RAID 5 setup in the corporate world is 4+1 (4 disks plus 1 for parity).

You will also need to consider the IOPS being sent to the RAID group. I work frequently with EMC Storage arrays and ESXi hosts for my job and it's quite a large task to get everything working properly (performance wise on RAID group). By far the number one issue that will cause slowdowns is that you are overloading (sending too much IO to the disks) the disks. In the corporate world, there are tools that we use to measure the average IO to the RG. We can then figure out how many disks will be required to meet and exceed the IO requirements. On average, 7200 RPM drives can handle a sustained load of about 80 IOPS. 10k drives can handle up to 130 IOPS, and 15k Fiber drives can handle up to 180 IOPS. (yes I know I'm going into too much detail, but it's still good to know). :) Then, you have the write penalty for various types of RAID:

393180-330-141.jpg


So, for RAID 5, for every single write there are 4 IO’s needed. Here's an equation stating how to calculate IOPS:

(TOTAL IOps × % READ)+ ((TOTAL IOps × % WRITE) ×RAID Penalty)

So for RAID-5 and for instance a VM which produces 1000 IOps and has 40% reads and 60% writes:

(1000 x 0.4) + ((1000 x 0.6) x 4) = 400 + 2400 = 2800 IO’s

The 1000 IOps this VM produces actually results in 2800 IO’s on the backend of the array. Crazy huh?

Lastly, if your system has the ability to turn on write cache, I would highly recommend that feature to be enabled as it will allow for the writes to be written to RAM then to disk. This will significantly decrease response times, but you may run the risk of having data loss if there is a power outage and the info in the RAM was not written to disk.

Hopefully this helps a smidge. :eek:
 
Back
Top