1

I am soon installing a new pair of drives in one of our machines that exists as a VMWare host box (running VMWare Server at the moment). They are going to be used as a RAID0 array for a couple of specific VMs that will impose a high I/O load when they are actively in use. The machine hosts a number of reasonably large VMs that are used for testing purposes.

As there is little point (cost wise) getting drives smaller than 500G the resulting array would be 1000G in size which it far more than is needed for this purpose, so I am considering using a chunk of the disks as a RAID1 array for storing VM backups and reference copies (freeing some space on the existing RAID1 array).

Would there be any harm in:

  1. splitting the drives into, say, 5 partitions
  2. setting one pair of partitions as the initial RAID0 array
  3. creating an LVM group using this new physical volume
  4. setting one pair of partitions as the initial RAID1 array
  5. creating an LVM group using this new physical volume
  6. when either volume group needs to expand
    1. creating a new R0/R1 array in a free partition pair
    2. expanding the relevant LVM group to include this new physical volume

I suspect that all of the above will work perfectly fine, but I was wondering if there are any issues that I'm not aware of. For instance, would splitting the drive into multiple arrays affect the kernel's ability to cache I/O effectively at all?

I have considered instead rebuilding the machine with single RAID10 array over all the drives it will end up with, but taking the machine offline for as long as that will take is not an option and it would not allow the same separation of I/O load that having separate arrays does.

David Spillett
  • 22,754
  • 45
  • 67
  • Why do you think IO load will be separate if both RAID volumes are on the same disks? – Zoredache Nov 19 '09 at 17:47
  • Probably because the backups are scheduled during a maintenance window? – Oskar Duveborn Nov 19 '09 at 18:57
  • Not separate between the new R1 and R0 arrays, but separate between the new pair of drives and the existing pair so the new I/O heavy VMs on the new R0 don't interfere (much) with the existing ones on the existing R1. The stuff on the new R1 (same drives as the new R0) would be accessed so infrequently that general I/O contention from that data would not be an issue. – David Spillett Nov 19 '09 at 18:59

4 Answers4

0

I have set up RAID0 and RAID1 on the same disk with seperate partition and it works perfectly. I haven't measured the performance though. Don't know if this might cause any performance issue.

user435760
  • 1
0

For instance, would splitting the drive into multiple arrays affect the kernel's ability to cache I/O effectively at all?

As the cache is functioning at the block level, you'll effectively destroy any cache hits you're getting by the constant churn. I don't recommend using same-drive partitions for RAID-anything, unless you're just doing it to learn about how to set it up (i.e. it's for experimentation and learning, and is temporary). You'll regret doing this on a production machine.

I have considered instead rebuilding the machine with single RAID10 array over all the drives it will end up with...

The merits of RAID 10 are discussed elsewhere on SF.

...but taking the machine offline for as long as that will take is not an option and it would not allow the same separation of I/O load that having separate arrays does.

Sometimes, it's "no pain, no gain". Frankly, this is your best option. Make sure your RAID arrangement is bootable. But in a 4-drive setup (the minimum), you'll end up with decent protection and decent performance. Otherwise, if you have just 2 or 3 drives, just do RAID1 (mirror) only. If you have the 3-drive arrangement, look at making drive 3 a hot spare.

Avery Payne
  • 14,536
  • 1
  • 51
  • 88
  • Sage advice, though the pain for the gain (of a rebuild) would be in the form of unpaid overtime out-of-ours for me, and there is going to be more of that than I'd like over the next month or two anyway. I am aware of the relative performance metrics or RAIDs 0/1/5/6/10, I think, my question is more checking that if I try use the "spare" space this way am I in for complications I've not thought of further down the line. – David Spillett Nov 19 '09 at 19:04
0

I see no problem in doing this. It's cost-effective and it solves the issues you're having, as long as the RAID1 I/O load is only in effect during controlled maintenance windows.

However, a big RAID1 might provide you with a simpler and more efficient setup, depending on the type of load.

Oskar Duveborn
  • 10,760
  • 3
  • 33
  • 48
  • The load on the R1 space wouldn't be quite that predictable, but it would not be at times when it would compete with spindle time with the VMs that we want R0 to help the performance of. – David Spillett Nov 19 '09 at 22:16
-1

Why?

Raid is meant to be set up ACROSS DRIVES, not across partitions. Taking a single drive and making partitions and then raiding them provides zero benefit. If the drive goes, so does all your raid "protection".

Even playing with raid across 2 drives (unless you just parallel the two drives) is wasting time and energy for no real benefit.

Drives are cheap, so iF you really want/need raid, then buy more drives and raid them.

Cheers,

-R

Huntrods
  • 237
  • 2
  • 10
  • In addition, you're mixing different I\O types across the different RAID partitions on the same physical disk (Read, Write, Random, Sequential) which is probably going to introduce performance problems. – joeqwerty Nov 19 '09 at 18:22
  • With a mix of R1 and R0, only the R0 areas would be killed in a single drive failure? Unless I'm misunderstanding (which is why I asked the question, in case I am!) the data in the areas used for R1 would still be protected by the fact that there is a copy on both drives. – David Spillett Nov 19 '09 at 19:07
  • @Huntrods - most modern SANs implement their RAID at the block level, allowing an arbitrary number of RAID levels per disk. So while yes, historically, RAID implementations have been stuck at the disk level, that's not true today. Granted, SANs have very intelligent controllers that are able to (with aggressive read/write caching) mitigate many of the performance issues that could be caused by this. This level of caching and control is most likely not available on a "standard" server raid controller. – EEAA Nov 19 '09 at 19:15