3

Just discussing a new Server with a client and they are insisting on using two 3Tb 7.2K SATA Driver in RAID 1. I wanted to get them 5 15K SAS Drives in RAID 5.

Can anyone tell me what the true speed difference will be between these two setups? Will they actually notice a huge improvement with 15K SAS drives over the 7.2K SATA's?

It will be a File Server holding around 1Tb of data for about 200 users across the UK.

  • 1
    If you are considering SATA then you might want to look at Nearline SAS drives. They are basically the lower spec cheaper drives but with SAS controllers so you have no voltage or overhead problems. – JamesRyan Sep 16 '14 at 9:38
  • Will this be HP hardware? – ewwhite Sep 16 '14 at 10:58
  • My Quote is HP, clients quote is Dell. Personally I'm not a fan of PERC controllers... – CharlesH Sep 16 '14 at 11:48
5
  1. They are not so error-prone. A 3-raid1 is a very redundant configuration, it practically means that all of the disks should be gone to a data loss. On the 5 disk-raid5 were already 2 enough to loss your data.
  2. It is faster. For reading, you can execute 4 parallel read task in a five-disk raid5. For write, you have to update 4 blocks to change a single one. But writing speed is not so important: first, because writing can happen delayed, from the write block cache, and second, because most of such systems are writing much fewer as reading. Next to these structural things there is the around 2-3 times greater speed of the SAS disks.
  3. It is much more efficient. The cost of the extrem big redundancy of the first setup was, that you had to use 3 disks instead of 1. 2 of the disks were only practically dead copies. In the new system, there is only 20% redundancy.

I must also mention:

  1. Some of the professional system administrators here are thinking, that using raid5 is actually not okay, because there is a too big chance of a simultaneous disk collapse (because the disks are coming probably from the same manufacturer, same serie, so there is a bigger chance of the same structural problem.) My opinion is not the same: I experienced a such stiuation 2 times in 15 years, so you need to have only good backups.
  2. And yes: raid is not backup! Raid doesn't protect against accidental deletion, against attacks, against software failures and such! Only backup can protect against them. I suggest to think a lot more on your backup solution, as on your raid solution - on my experience, the first is much more important.
  • Thanks Peter, I have also felt the pain of simultaneous disk failures in RAID 5 however do you not also believe this to be true for RAID 1, I mean the disks are still likely to be from the same batch correct? I should also mentioned we will be using DFS to a data center and then also the data will be backed up there so we have other systems in place in event of DR/restore. – CharlesH Sep 16 '14 at 9:04
  • for best experience you would not connect the same batch drives, but similiar ones (talk about a month or so in production date) Additionally you can calculate the theoretical risk of a drive getting damaged in some sort of % value, which you decide what you want to risk. Google did some research on this as far as i remember. Second you can monitor the smart values from beginning to end and have a nice picture of the degrading of the HDDs there aswell. – Dennis Nolte Sep 16 '14 at 9:31
  • @DennisNolte Although it seems a little bit mysticism for me (we are optimizing the probability of events happening around once in a decade), I admit such precaution can be fruitful. – peterh says reinstate Monica Sep 16 '14 at 9:39
  • Let me put more emphasis on the bit about having more redundancy. RAID5 and RAID1 with only two disks will fail in the most spectacular fashion if one disk is out and another disk has a single faulty sector. Obligatory anecdata: a friend of mine works for a data recovery company, and 90% of the work they get are RAID5 sets. – Simon Richter Sep 16 '14 at 9:43
  • @SimonRichter Imho, rescuing a raid member disk with some bad block, should be a trivial task even for a beginner system administrator. And this is the same for selecting/using raid solutions which don't prohibit that. – peterh says reinstate Monica Sep 16 '14 at 9:44
3

First of all: SATA vs SAS drives (not discussing RPM)

SAS drives do have better error-handling than SATA, so when you have the option, take SAS over SATA, so when you have a harddrive fail the chance of killing your raid will be reduce with SAS over SATA.

Read some other questions here on SF about people loosing their raid over 1 failed sata drive.

For the RAID : you have to decide what do you actually need, reliance, nearly no downtime, fast restore , access speed, etc.

There are some nice questions here on those specific needs.

For the speed difference: 15k RPM against 7.2K RPM make a lot of difference, though this depends on the server and your data.

Basically if you anticipate a lot of IOOps and cannot afford or want SSDs go for the 15K drives.

IF you really have only a handfull sequentiell access, and no further access 7.2K drives might be enough, but you have to measure that yourself.

Depending how important every bit of data is you might want to consider the drives based on the bit error rate aswell. Keep in mind that a rebuild of a larger Raid might already trigger that bit error rate on bad drives.

  • Do you have any experience of Dell PERC RAID controllers, my past experience with them was bad so I generally switched to HP however this was some time ago so they may have improved now. – CharlesH Sep 16 '14 at 9:11
  • sadly i don't, my experience is only on LSI megaraid and 3ware, so quite "old" in that regard. But you might want to bring this into the serverfault chat, i think there are a few people with more recent Raid controller knowledge. – Dennis Nolte Sep 16 '14 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.