Server 2012 R2 Hardware Raid or Storage Spaces
We are migrating a SBS 2011 system to Server 2012 R2; we have about 800 GB of data; 15 users with 5 needing remote access. We decided on a Dell T430 with 4 x 1TB SATA drives configured in RAID 1.
Having got to the nitty gritty of building the new server (2012 R2 with Hyper-V and 2 VMs – 1 DC and 1 exchange) I have got myself into a debate on whether to use storage spaces or not.
So my questions is: Do I
1) break the Hardware RAID and set up mirrored storage space.
2) do a partial break – keep 2 drives in hardware RAID 1 to hold the Hyper-V OS (+ OS’s for the DC and Exchange servers ?) and configure the other 2 drives as Storage Space for data etc.
The install of Hyper-V uses a partition for the OS: I have a concern that this partition would not be included in the storage space so would have issues if that drive fails.
3) stick to the Hardware RAID (and don’t use storage spaces)
Thanks
Brian
Having got to the nitty gritty of building the new server (2012 R2 with Hyper-V and 2 VMs – 1 DC and 1 exchange) I have got myself into a debate on whether to use storage spaces or not.
So my questions is: Do I
1) break the Hardware RAID and set up mirrored storage space.
2) do a partial break – keep 2 drives in hardware RAID 1 to hold the Hyper-V OS (+ OS’s for the DC and Exchange servers ?) and configure the other 2 drives as Storage Space for data etc.
The install of Hyper-V uses a partition for the OS: I have a concern that this partition would not be included in the storage space so would have issues if that drive fails.
3) stick to the Hardware RAID (and don’t use storage spaces)
Thanks
Brian
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry for not getting back sooner.
Having researched this a little more and based on Cliff Galiher's outline implementation I would probably implement that. Apart from the quicker / easier recovery from a crashed disc it also appears that write speeds are quicker in a mirrored storage space compared to a hardware RAID.
However, my research suggests that the RAID on the DELL (a PERC H730 with 1GB cache) does not support JBOD and can only be setup in RAID 0 . Apparently Storage Spaces cannot fully handle discs in that state.
If that is true then I'm obliged to stay with a Hardware RAID 1
Having researched this a little more and based on Cliff Galiher's outline implementation I would probably implement that. Apart from the quicker / easier recovery from a crashed disc it also appears that write speeds are quicker in a mirrored storage space compared to a hardware RAID.
However, my research suggests that the RAID on the DELL (a PERC H730 with 1GB cache) does not support JBOD and can only be setup in RAID 0 . Apparently Storage Spaces cannot fully handle discs in that state.
If that is true then I'm obliged to stay with a Hardware RAID 1
Or buy an HBA.
Dell has a 12Gbps SAS HBA: (405-AAFB) SAS 12Gbps HBA External Controller, Low Profile
NOTE: Storage Spaces on a single server will _not_ perform anywhere near as well as a dedicated hardware RAID setup would. BTDT
Drive failure: Please research this. It is not a simple disk swap with Storage Spaces.
Drive failure: Note that one needs to keep at least ###GB + 50GB (Where ###GB = size of one drive in the JBOD) of space free in the Pool to allow Storage Spaces to rebuild a failed disk into that free space. We try to keep about 75% of a Pool's available storage free to allow for multiple disk failures. Once a failed disk is rebuilt into free Pool space the two disk resilience in a 3-Way mirror is back.
NOTE: 3-Way Mirror is the _only_ resilience model to use. That's 33% of total storage available for the VHDX files. 33%
We build Scale-Out File Server (SOFS) clusters that provide a storage backend for Hyper-V clusters via SMB (two 2 node clusters at the minimum). SOFS is based on Storage Spaces. We also build SMB/SME clusters built on clustered storage spaces.
NOTE: Storage Spaces on a single server will _not_ perform anywhere near as well as a dedicated hardware RAID setup would. BTDT
Drive failure: Please research this. It is not a simple disk swap with Storage Spaces.
Drive failure: Note that one needs to keep at least ###GB + 50GB (Where ###GB = size of one drive in the JBOD) of space free in the Pool to allow Storage Spaces to rebuild a failed disk into that free space. We try to keep about 75% of a Pool's available storage free to allow for multiple disk failures. Once a failed disk is rebuilt into free Pool space the two disk resilience in a 3-Way mirror is back.
NOTE: 3-Way Mirror is the _only_ resilience model to use. That's 33% of total storage available for the VHDX files. 33%
We build Scale-Out File Server (SOFS) clusters that provide a storage backend for Hyper-V clusters via SMB (two 2 node clusters at the minimum). SOFS is based on Storage Spaces. We also build SMB/SME clusters built on clustered storage spaces.
ASKER
Sorry for not replying sooner.
I decided to go with option 3 - use raid and no storage spaces.
The installation of server 2012 r2 went well as did the install of the DC and exchange except the migration from exchange 2010 was a disaster !!
So did fresh install of 2012 R2 and exchange 2013 and manually migrated exchange data.
All seems OK Now !
I decided to go with option 3 - use raid and no storage spaces.
The installation of server 2012 r2 went well as did the install of the DC and exchange except the migration from exchange 2010 was a disaster !!
So did fresh install of 2012 R2 and exchange 2013 and manually migrated exchange data.
All seems OK Now !
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Noted and thanks
For the rest, I definitely would go storage spaces. Place your VM VHD(x) files on the storage spaces and they get whatever protection you configure. Even with a few drives, you get much faster rebuilds than RAID, and get the benefit of portability. Should a whole server go kaput, you can pull the drives and pop them in a new server. Windows will recognize and use the pool immediately. Mich tougher to do with RAID, where getting the exact same controller and firmware can be tricky for older systems.
I don't even deal with the cost of Raid controllers anymore, but if you *really* need five nines of uptime on a single host (which is odd, as other hardware cab fail and a cluster would solve both issues) then RAID on the system drive nay be worth considering as said above.