Server 2012 R2 -- Using Storage spaces with hardware RAID?

anouri

I'm studying for MCSA using Server 2012 R2. I'm running a Dell r610 rack server with a perc6/i controller for hardware raid. Hardware raid is set up with a virtual array in a RAID 10 configuration.
For learning purposes, can I go ahead and play around with Storage Spaces (which I understand is Server 2012 R2's software RAID solution) on top of the hardware RAID or do I have to disable and wipe out the Perc/6i hardware RAID for this to work? Beyond educational purposes, can software and hardware RAID be combined in general and what is the advantage of doing so?
I appreciate any insight. Thanks.

OctalDump

Yeah, they are just layers of abstraction. So the hardware RAID can be set up to present logical 'disks' (or virtual disks or LUNs or other vendor terminology) to the OS, and the OS can use those 'disks' to create storage pools, which can be used to create volumes.

If you want to go in deep and tune for speed or redundancy, then you really need to understand the whole stack (from the physical disks up to the volume and filesystem). But for the goals of MCSA, it's safe to play around with what you have at the hardware RAID level, since as far as the OS is concerned these are just regular disks (well, sort of, but not in a way that matters for MCSA).

Actually, the deeper you go into storage, the more layers of abstraction you come across. For example the addressing that the OS uses to talk to the 'physical platters' isn't necessarily the address used, since blocks can be remapped if they go bad. This is one reason disks get slower as they get older. This matters a little bit for tuning, and a lot for data forensics, but for regular use, it doesn't matter.


EDIT: see below poolmanjim post
https://technet.microsoft.com/en-us/.../hh831739.aspx

anouri

Ah, I see. But won't Storage Spaces software RAID functionality conflict with hardware RAID functionality? Like if you're striping data at hardware layer and then mirroring at software. I understand storage pools might not be a problem, but I thought mixing software and hardware RAID would cause some issues. Thanks.

anouri

OctalDump wrote: »

Yeah, they are just layers of abstraction. So the hardware RAID can be set up to present logical 'disks' (or virtual disks or LUNs or other vendor terminology) to the OS, and the OS can use those 'disks' to create storage pools, which can be used to create volumes.

If you want to go in deep and tune for speed or redundancy, then you really need to understand the whole stack (from the physical disks up to the volume and filesystem). But for the goals of MCSA, it's safe to play around with what you have at the hardware RAID level, since as far as the OS is concerned these are just regular disks (well, sort of, but not in a way that matters for MCSA).

Actually, the deeper you go into storage, the more layers of abstraction you come across. For example the addressing that the OS uses to talk to the 'physical platters' isn't necessarily the address used, since blocks can be remapped if they go bad. This is one reason disks get slower as they get older. This matters a little bit for tuning, and a lot for data forensics, but for regular use, it doesn't matter.

Ah, I see. But won't Storage Spaces software RAID functionality conflict with hardware RAID functionality? Like if you're striping data at hardware layer and then mirroring at software. I understand storage pools might not be a problem, but I thought mixing software and hardware RAID would cause some issues. Thanks.

OctalDump

anouri wrote: »

Ah, I see. But won't Storage Spaces software RAID functionality conflict with hardware RAID functionality? Like if you're striping data at hardware layer and then mirroring at software. I understand storage pools might not be a problem, but I thought mixing software and hardware RAID would cause some issues. Thanks.

Yeah, it can cause performance issues, or more rarely might leave you less protected (redundant) than you think. But as far as lab situation for learning the concepts, it's nothing to worry about. In the real world, you tend to deploy based on the requirements of the job, and build from the bottom up.

The example you use, probably wouldn't be too bad. You use the hardware striping for speed, and the software mirroring for redundancy. The software mirroring can actually be useful for mirroring across two different storage types for example a directly attached RAID and a LUN on a SAN, or across two different SANs. It's also something that can be used for migration.

But if you had just an internal RAID, then normally you'd set it up as RAID 10 (speed and redundancy) or RAID-6 (redundancy and capacity), and create one big logical drive, then use the OS to carve it up. Occasionally you'd create more than one, if for example you had multiple parts that needed optimisation.

poolmanjim

If I am correct, Storage Spaces actually cannot work with a configured Hardware RAID.

From https://technet.microsoft.com/en-us/library/hh831739.aspx :
Serial ATA (SATA) or Serial Attached SCSI (SAS) connected disks, optionally in a just-a-bunch-of-disks (JBOD) enclosure
RAID adapters, if used, must have all RAID functionality disabled and must not obscure any attached devices, including enclosure services provided by an attached JBOD.

BornToBeMild

One approach for a lab would be to "hide" the hardware raid behind a virtualization layer. If you load a hypervisor on your Dell server, you can then install a 2012R2 VM, and give it as many virtual hard disks as you like. The VM won't see what's hosting the hard disk files, and you can configure Storage Spaces with the virtual hard disks.

OctalDump

poolmanjim wrote: »

If I am correct, Storage Spaces actually cannot work with a configured Hardware RAID.

From https://technet.microsoft.com/en-us/library/hh831739.aspx :
Serial ATA (SATA) or Serial Attached SCSI (SAS) connected disks, optionally in a just-a-bunch-of-disks (JBOD) enclosure
RAID adapters, if used, must have all RAID functionality disabled and must not obscure any attached devices, including enclosure services provided by an attached JBOD.

Yeah, you're right. I remember this now. So, yeah, I retract a good part of what I said, except that in theory there's no reason it should be a problem. LVM on Linux is a similar thing and has no requirement for JBOD.

Now I am curious about how hard that requirement is.

bohack

You are correct... SATA controllers work in two ways: one is JBOD mode and it passes the IOs to the hard drives. The other is RAID mode and this where the trouble is... Windows only supports JBOD mode for SATA and SAS drives. There are reasons beyond my understanding such as queue depth that RAID cards have and JBOD does not, since it's passed thru to the drive itself. I just went thru this with a Cisco UCS Chassis.