TR Forums

Canuckle wrote:

slymaster:
"If the OS is not part of a raid array, and the drive dies, you are down, and need to restore from backup. This is not too great an ordeal if you use disk imaging, but why lose the OS because of a failed HD when you have raid capability ?"

States quite clearly that slymaster perferred using the mirror to restore the OS rather then a backup. Odd that you couldn't find it when I quoted it in one of my posts...

Actually, the intention of my statement is that if the OS drive is mirrored (or raid 5 protected), you would not be restoring at all - you would still be up and running and watching the array rebuild. It seems that in your previous posts, you recommend against including the OS in the raid array. If we are misinterpreting this, than please correct us. If the OS is not protected with raid, a single HD failure brings the whole system down.

If one has gone to the expense of purchasing a raid controller and extra drives, why not protect the entire system ?

As far as non-bootable raid controllers, I agree with Buub - I have never seen a non-bootable raid controller (unless you count a dead controller as non-bootable). The oldest raid controller I have worked with is about 8 years old (still running, but no longer system critical !) Even this controller was bootable.

As far as partitioning increasing access times, that is possible. Partioning can also be an overall performance booster, if the partioning scheme is appropriate for the system. The topic is complex enough that it deserves its own thread. To say that a performance reduction will always occur with partioning is not prudent.

Yahoolian wrote:

element, could you tell us brand the SCSI HD is?

element:
"I'll tell you my SCSI experience with a 36 gig IBM 10000rpm drive."

slymaster wrote:

Actually, the intention of my statement is that if the OS drive is mirrored (or raid 5 protected), you would not be restoring at all - you would still be up and running and watching the array rebuild. It seems that in your previous posts, you recommend against including the OS in the raid array. If we are misinterpreting this, than please correct us. If the OS is not protected with raid, a single HD failure brings the whole system down.

Mirroring does NOTHING for an OS - it does NOT protect from virus, rooted, file corruption/deletion. Mirroring an OS is pointless...

For these concerns, the OS should be separate from the data array - either on a single drive or in it's own raid 0 array. Because in such situations, you wouldn't loose JUST the OS - you loose whatever data hadn't been backed up (if any had at all).

slymaster wrote:

If one has gone to the expense of purchasing a raid controller and extra drives, why not protect the entire system ?

If you have the budget, then you'd be running the redundant power supplies, UPS that provides 48 hours minimum, definitely SCSI and not SATA...

Are you catching my drift yet?

slymaster wrote:

As far as non-bootable raid controllers, I agree with Buub - I have never seen a non-bootable raid controller (unless you count a dead controller as non-bootable). The oldest raid controller I have worked with is about 8 years old (still running, but no longer system critical !) Even this controller was bootable.

Does because you've never seen one mean they don't exist?

slymaster wrote:

As far as partitioning increasing access times, that is possible. Partioning can also be an overall performance booster, if the partioning scheme is appropriate for the system.

Partitioning means that the drive has to first find where on the drive the partition exists before it can start to find the information requested. This all happens on the drive itself I feel the need to point out...

slymaster wrote:

To say that a performance reduction will always occur with partioning is not prudent.

You don't like that I have squashed your arguement because you are uninformed on the subject you brought up.

Hoo, boy. Here we go...

Canuckle wrote:

slymaster wrote:

Actually, the intention of my statement is that if the OS drive is mirrored (or raid 5 protected), you would not be restoring at all - you would still be up and running and watching the array rebuild. It seems that in your previous posts, you recommend against including the OS in the raid array. If we are misinterpreting this, than please correct us. If the OS is not protected with raid, a single HD failure brings the whole system down.

Mirroring does NOTHING for an OS - it does NOT protect from virus, rooted, file corruption/deletion. Mirroring an OS is pointless...

But it does protect it from drive failure, which is the main reason to use RAID in the first place.

For these concerns, the OS should be separate from the data array - either on a single drive or in it's own raid 0 array. Because in such situations, you wouldn't loose JUST the OS - you loose whatever data hadn't been backed up (if any had at all).

Y'know, I'm just not following your reasoning here. Keeping the OS seperate from the data is a good thing, but how is it any different with the data on a seperate drive rather than another partition? If the virus can get the other partition, it can get another drive. And using RAID 0 in anything remotely mission critical is downright stupid.

slymaster wrote:

If one has gone to the expense of purchasing a raid controller and extra drives, why not protect the entire system ?

If you have the budget, then you'd be running the redundant power supplies, UPS that provides 48 hours minimum, definitely SCSI and not SATA...

Are you catching my drift yet?

Um, not really. What he says makes a lot of sense.

slymaster wrote:

As far as non-bootable raid controllers, I agree with Buub - I have never seen a non-bootable raid controller (unless you count a dead controller as non-bootable). The oldest raid controller I have worked with is about 8 years old (still running, but no longer system critical !) Even this controller was bootable.

Does because you've never seen one mean they don't exist?

They may exist but they're sure not common.

slymaster wrote:

As far as partitioning increasing access times, that is possible. Partioning can also be an overall performance booster, if the partioning scheme is appropriate for the system.

Partitioning means that the drive has to first find where on the drive the partition exists before it can start to find the information requested. This all happens on the drive itself I feel the need to point out...

It's been proven that "short stroking" a drive can improve performance quite a bit. So can an appropriate partition scheme.

slymaster wrote:

To say that a performance reduction will always occur with partioning is not prudent.

You don't like that I have squashed your arguement because you are uninformed on the subject you brought up.

Maybe you should "get informed":
http://www.storagereview.com/articles/2 ... troke.html

Steel wrote:

But it does protect it from drive failure, which is the main reason to use RAID in the first place.

How blatant do I have to present this:

Criteria 1: OS on RAID 1 with no backup policy.
Criteria 2: OS with backup policy.

Scenario: hacked/rooted/etc
Result: Criteria 2 wins - or are you really that stupid to trust a mirror?

If the virus can get the other partition, it can get another drive.

That's assumption talking...

And using RAID 0 in anything remotely mission critical is downright stupid.

No - relying entirely on RAID for your redundancy is.

Steel wrote:

Um, not really. What he says makes a lot of sense.

Are you really that stupid?

Steel wrote:

They may exist but they're sure not common.

For a time, bootable SCSI RAID 0 controllers were not common.

Maybe you should "get informed":
http://www.storagereview.com/articles/2 ... troke.html

Thank you for the link - I'm now informed and apologize Sly.

The SCSI improvements of ~15% are interesting; I wasn't impressed by the ~7% average for the IDE drive. Too bad only one was done

I still prefer the OS to reside on a separate drive (or array) however.

Canuckle wrote:

Partitioning means that the drive has to first find where on the drive the partition exists before it can start to find the information requested. This all happens on the drive itself I feel the need to point out...

The partition table is RAM-resident. There is no extra disk access required to locate the partition.

Partitioning can help or hurt performance, it depends on the situation. Situations where partitioning can be used to improve performance:

- Keep files that are typically accessed together physically closer to each other on the disk, thereby reducing head movement.

- Keep most frequently accessed files (e.g. your swap file) close to the outer edge of the disk, where transfer rates are the highest.

- Physically segregate large sequentially accessed files from smaller files. This can improve performance by reducing fragmentation of the large files.

Canuckle wrote:

Thank you for the link - I'm now informed and apologize Sly.

Apology accepted - I am the first to admit that I am often uninformed - I come to TR seeking knowledge.

I would just like to clarify one thing - nobody recommends using raid for the OS without a backup strategy, they are recommending using raid for the OS with a backup strategy. If you read my first post on page 1, I believe I was the first in this thread to mention backup - I consider backup more important than raid (and I am a BIG fan of raid).

I would not be so quick to attack Steel - he has a lot of good posts on many subjects. Example: three times now in this thread he has linked to Storage Review. I have enjoyed storage review for a long time now, nobody (that I have seen) provides analysis and testing of storage issues so well. I had not seen the 'short stroking' article, but my reasons for partioning and performance increase were based on the same principles. I enjoyed the read, and learned something new.

Canuckle wrote:

Steel wrote:

But it does protect it from drive failure, which is the main reason to use RAID in the first place.

How blatant do I have to present this:

Criteria 1: OS on RAID 1 with no backup policy.
Criteria 2: OS with backup policy.

Scenario: hacked/rooted/etc
Result: Criteria 2 wins - or are you really that stupid to trust a mirror?

Again, I trust a mirror to do one thing and one thing only, to protect against a drive failure. That's it.

If the virus can get the other partition, it can get another drive.

That's assumption talking...

No, that's experience talking. We've had viruses here that attacked files on mapped network drives, not even on the same machine. If the computer had a second hard drive with data files on it, the virus would've got those too.

And using RAID 0 in anything remotely mission critical is downright stupid.

No - relying entirely on RAID for your redundancy is.

Again, like slymaster said, nobody's suggesting that.

Steel wrote:

Um, not really. What he says makes a lot of sense.

Are you really that stupid?

Yeah sure, I'm so stupid having set up 30+ servers over the years all with RAID and the OS as part of the RAID set. And there have been drive failures where if the OS wasn't protected we would have had hundreds of pissed off and annoyed users unable to work while we spent hours rebuilding the server.

Steel wrote:

They may exist but they're sure not common.

For a time, bootable SCSI RAID 0 controllers were not common.

But still, that's ancient history. You'd be hard pressed to find a modern RAID controller that can't boot a computer.

Maybe you should "get informed":
http://www.storagereview.com/articles/2 ... troke.html

Thank you for the link - I'm now informed and apologize Sly.

The SCSI improvements of ~15% are interesting; I wasn't impressed by the ~7% average for the IDE drive. Too bad only one was done

Yeah, I suppose it would've been nice but since ATA is rarely used in an enterprise setting, it's understandable.

I still prefer the OS to reside on a separate drive (or array) however.

Yeah, but sometimes it's not economically feasable. In order for drenaud to do that while maintaining redundancy for everything, he'd have to buy a minimum of 4 hard drives and it would only be a minor benefit at best.

I found an interesting link on raid arrays and probability of failure - if you are interested in a hard-core probability analysis of different raid types, check out raid failure analysis. It might be advisable to grap a cup of coffee before before reading, however.

Unfortunately, all the examples are with 14 drives - the reliability would likely be better with smaller numbers. You can always put your own numbers in and see how they work out. My most important server by coincidence has 14 drives, on 3 separate channels. I would have guessed my reliability over 3 years to close to 99%, but I am probably in the low 90's at best. Backups are everything !

The conclusion of the article is that mirroring provides the most reliability.

By the way, Drenaud - if you have not given up on this thread, post what hardware you already have (if any) and how much space you think you really need. I am worried that we may be proposing enterprise solutions to a less than enterprise budget.

Canuckle wrote:

Steel wrote:

But it does protect it from drive failure, which is the main reason to use RAID in the first place.

How blatant do I have to present this:

Criteria 1: OS on RAID 1 with no backup policy.
Criteria 2: OS with backup policy.

Scenario: hacked/rooted/etc
Result: Criteria 2 wins - or are you really that stupid to trust a mirror?

Ugh. How blatant do I have to present this? Please try to read completely and comprehend before replying.

Let me repeat: Nobody here has said that you should stop backing up your OS after you put it on a RAID partition. Got that?

Criteria 3: OS on RAID WITH a backup policy.

Wins hands-down every time.

I agree with you element, I have the same IBM SCSI drive and I have RMAed it twice already. The drive has had nothing but trouble since I first got it several years ago, and it again is in need of an RMA again. I bought IBM at the time as they made good drives, and now it is a paperweight and not worth the money or trouble I put into it.

Starfalcon wrote:

I agree with you element, I have the same IBM SCSI drive and I have RMAed it twice already. The drive has had nothing but trouble since I first got it several years ago, and it again is in need of an RMA again. I bought IBM at the time as they made good drives, and now it is a paperweight and not worth the money or trouble I put into it.

I wonder if these IBM SCSI drives you're talking about were based on a design similar to that of the GXP "Deathstar" IDE drives? The timeframe is about right, and it would explain a lot...

A sample size of one is not a very good indicator of anything.

I don't think any IBM SCSI drives were based off the 75GXP. In fact I know they weren't, because the very principles that guide SCSI server drive design are not met by the 75GXP or other IDE drives. One of the problems was they were just pushing the density a little bit too far. Conservative density utilization is one part of making reliable server drives.

IBM SCSI drives are excellent quality. But let's not forget that EVERY hard drive is a mechanical device with moving parts. Every hard drive, no matter how well made, will fail if given enough time. The difference is how quickly, predictably (i.e. you can see it coming), and in what quantities they fail.

My personal experience (I stopped counting drives because it's been a lot over a long time) I have had three or four failed SCSI drives. Fortunately, they all lasted years before failure. And at the same time I have had at least twice as many failed IDE drives, if not more. And some of those failed very shortly after entering service.

Finally, as an example, back when 10K RPM SCSI drives were so new you couldn't hardly buy one, Maxtor came out with their version. Lots of people burned up many of them. Why? They ran too hot and burned out the motor bearings. These were very expensive drives. But yes, failure can happen even in really expensive server drives. It's just not the common case.

Buub wrote:

A sample size of one is not a very good indicator of anything.

Umm... where do you get a sample size of 1? I count a total of 5 dead IBM SCSI drives over the past 2-3 years, from two of the people posting to this thread.

The drives do use the same glass platters as the deathstar drives do, so that is a common thread between them. The drive also does run extremely hot, and I actually burned myself on it once, and that is with a large case fan blowing directly on it.

slymaster wrote:

Apology accepted - I am the first to admit that I am often uninformed - I come to TR seeking knowledge.

Thanks - nice to see the forum climate is quite friendly and forgiving

Buub - why do you bother? Seriously...

Buub wrote:

Ugh. How blatant do I have to present this? Please try to read completely and comprehend before replying.

My point is a backup policy is more necessary then RAID with regards to the OS. Rather, RAIDing the OS is unnecessary unless you have the budget for it.

Now will you formulate an arguement that holds relatively some water,or will you continue to waste time and bandwidth?

Steel wrote:

Yeah, but sometimes it's not economically feasable. In order for drenaud to do that while maintaining redundancy for everything, he'd have to buy a minimum of 4 hard drives and it would only be a minor benefit at best.

What I've been saying is that mirroring is not a wise decision for the OS - no need for it when a backup policy would be both cheaper and cover more possibly encountered problems.

Canuckle wrote:

What I've been saying is that mirroring is not a wise decision for the OS - no need for it when a backup policy would be both cheaper and cover more possibly encountered problems.

...and I think what others have been saying is that -- assuming you've already got a decent backup policy -- mirroring can improve your uptime.

Backups protect you from outside attacks, disk failures, and operator incompetence. Mirroring cuts your time to recover from disk failures to essentially zero... but doesn't help at all with the other scenarios.

It seems we will never agree on the raid and OS issue. Perhaps a different perspective will shed some light on the situation.

Conversation between sysadmin and CEO :

CEO - how much did that SCSI raid controller cost ?

sysadmin - $1,000 sir.

CEO - what benefit do we get from this RAID thingamajig ?

sysadmin - if a hard drive dies on the server, we can continure running, and replace the drive - once the new drive rebuilds, we are back to a redundant state - the odds of downtime are greatly reduced.

CEO - so why are we down now ?

sysadmin - a hard drive failed, sir. I am restoring from backup now.

CEO - Is that not what the F#$#C! raid controller is supposed to protect us from ?

sysadmin - only the data sir, the OS is not protected.

CEO - Why not ?

sysadmin - I choose not to protect it.

CEO - If we did not purchase this raid controller, and the same 'OS' hard drive failed, what would we be doing right now ?

sysadmin - exactly what I am doing now, sir, restoring from tape !

CEO - So we would still be in the same situation, but with $1000 extra in the bank ? I think I am still unclear as to the value of this raid thingamjig ....


EDIT : The above converstation is fictitious. The choice of whether to protect the OS (with raid) is certainly up to the sysadmin. I choose to protect it - whatever benefit I get by not protecting the OS is not worth the peace of mind I have by knowing I will never undergo a similar conversation. That is just my personal opinion, which depending on the mood of the customer, can be worth anywhere from good solid money, to nothing at all !

Cheers !