server hard disk configuration

wijcc · 22 Dec 2014 at 16:41

How would you guys setup your server's hard disk configuration... would you setup two sets of RAID partitions.. one for the OS and the other for DATA, if so what RAID level would you use for each?
Or would you just use a RAID partition for both both the OS and DATA?

#Chri5# · 22 Dec 2014 at 16:49

How many disks? What will the server be doing? Does the requirement suggest taking speed over capacity or resilience?

wijcc · 22 Dec 2014 at 16:52

The server would be running sql server, a few programs and act as network drive too. A mixtures of speed and resilience..

Armageus · 22 Dec 2014 at 17:00

RAID10 for the whole lot, given how little the OS uses in generally it is more of a waste of 2 disk slots if you go down the separate os (on raid 1).

RAID5 shouldn't be considered for anything these days.

Caged · 22 Dec 2014 at 17:02

RAID10 on 15k SAS, ideally on a SAN which auto-tiers onto flash.

Xez · 22 Dec 2014 at 18:00

Armageus said:
RAID10 for the whole lot, given how little the OS uses in generally it is more of a waste of 2 disk slots if you go down the separate os (on raid 1).

RAID5 shouldn't be considered for anything these days.

What? Raid 5 still has it's place admittedly it's not ideal for large databases but for people who need space for less money and the majority of operations are reads then a Raid 5 is more than adequate. Same with a back server Raid 10 is just wasting disks when it doesn't need to be as resilient as a Raid 10.

Armageus · 23 Dec 2014 at 08:45

Xez said:
What? Raid 5 still has it's place admittedly it's not ideal for large databases but for people who need space for less money and the majority of operations are reads then a Raid 5 is more than adequate.

I would go so far to say it's not ideal for anything where you value your data - yes it can tolerate a drive failure, but the stress a rebuild places on the rest of the disks can easily instigate another failure = data loss. For the sake of 1 more disk you could go for RAID6 which will at least tolerate another disk failing during a rebuild, but where disk slots are available RAID10 is a much better option.

Xez said:
Same with a back server Raid 10 is just wasting disks when it doesn't need to be as resilient as a Raid 10.

Depends on the individual circumstance - for home probably not, but for the 24/7 business where I work, I'd rather spend a little more and have resilience on my backup servers - I can then completely failover to my backup servers minimizing downtime.

Xez · 23 Dec 2014 at 15:36

Sorry I probably should have expanded a bit more, when I say backup server I don't mean DR/failover server. We backup to disk first and then duplicate to tape so the most amount of space is the most ideal for us as if that raid set was to complete fail then worst case we just backup straight to tape. In this case Raid 10 would simply be wasting space.

I guess it entirely depends on the environment, as much as I'd love for all our clients to have Raid 10 arrays with failover servers it more often doesn't happen due to cost and size.

Armageus · 23 Dec 2014 at 16:03

Xez said:
Sorry I probably should have expanded a bit more, when I say backup server I don't mean DR/failover server. We backup to disk first and then duplicate to tape so the most amount of space is the most ideal for us as if that raid set was to complete fail then worst case we just backup straight to tape. In this case Raid 10 would simply be wasting space.

No problem - that explains things

Xez said:
I guess it entirely depends on the environment, as much as I'd love for all our clients to have Raid 10 arrays with failover servers it more often doesn't happen due to cost and size.

100% correct, ultimately most of any disaster recovery strategy comes down to money (cost to implement vs loss to business).

High availability is of more importance to our business (because even a couple of hours downtime has an impact on a whole weeks work - beyond a couple of hours it makes little difference how long it takes to recover backups etc), whereas our actual backups are more low tech (e.g. batch files rather than backup software), so that's how our budget was split.