The ATABoy2F has TWO, count them TWO, ATA RAID controllers (for redundancy and performance). Just like the Xserve RAID. It has two ethernet ports (for redundancy) like the Xserve RAID. It has two fiber channel ports (for performance and redundancy) like the Xserve RAID. The ATABoy2F is almost a mirror image (bad pun) of the Xserve RAID, except for the SCSI controllers.
Oops. You made a mistake. Dual controller ATAboys have TWO host ports PER CONTROLLER. A model with dual controllers has FOUR host ports. Because the controllers are REDUNDANT IN HARDWARE. EACH controller can access ALL 14 DRIVES. So if one controller should fail, you can still run with NO DOWNTIME.
If your goal is to make a mirrored 7-drive array, then you're right. They'd function nearly identically. But if you want ANY OTHER configuration, they're far from the same. BECAUSE THE XSERVE RAID IS TWO 7-DRIVE RAIDS IN ONE CASE.
A true 14-drive RAID offers more flexibility. I feel that that's what Apple needs in an xServe upgrade. That's all. You can disagree if you like.
Ok Alexander. Answer me this: In what possible senario would the full bandwidth (~1GB/s) and capacity (2.5TB) of a 14 disk RAID be used?
If you can think up a senario, it will be a very limited one.
I can't think of a workstation or server senario where either backup or fallover is NOT important. Dual 7 disk RAIDs sound like good backup and fallover to me.
Ok Alexander. Answer me this: In what possible senario would the full bandwidth (~1GB/s) and capacity (2.5TB) of a 14 disk RAID be used?
If you can think up a senario, it will be a very limited one.
I can't think of a workstation or server senario where either backup or fallover is NOT important. Dual 7 disk RAIDs sound like good backup and fallover to me.
It's not bandwidth, I'm sure both have plenty of it.
It's capacity and flexibility for different configurations.
Say I want to put as much data as possible on an array and have some redundancy in case a drive fails. With a 14 drive controller, I can have 13 drives worth of data, and only lose 1 to RAID5 parity data. If I want a hot spare, I can get 12 drives worth of data. With the Xserve RAID, I could only get 12 drives worth of data with no hot spare. If I want hot spares, I could only use 10 drives worth of data.
It's also much easier to deal with one conceptual unit than two. This is the point of RAID - to combine many drives into a single conceptual unit.
Are you high, or just really, really stupid? The Xserve has no single point of failure because of its design. A single RAID controller device does. When an Xserve RAID controller falls over and you NEED 100% uptime in one unit, you can switch to the other 7 disk RAID. Trying to keep 100% uptime with zero redundancy is like pushing a boulder uphill. Also, it is probably cheaper to use dual RAID controllers, as a single 14-channel controller ASIC sounds really expensive. The decreased cost is passed to the end user eventually.
Actually, Alexander is right. It's two 7 drive RAIDs in one box and the 'redundant' claim is somewhat misleading since it's only redundant if you are mirroring across the two controllers. Apple can say that it has redundant controllers, but then you don't have a 2.5T RAID, you have a 1.25T RAID. Apple is very clear in this document that it runs a software RAID mirror across the two controllers to implement RAID 50. You can't run a 14 disk RAID 5 with the Xserve.
A perfectly valid use of the Xserve RAID would be to set up two RAID 5 sets for two uses. In that scenario, you don't have redundency in the controllers. My expectation of controller redundancy is that the box works the same with one controller as it does with two, regardless of how you intend to use it. PSU redundency works this way, controller should as well.
I agree that it's something for Apple to fix by replacing the two 7 drive controllers with two 14 drive controllers. I do think that we'll see a SATA Xserve RAID and thats when the full redundency will kick in. It's not broke, it's just not perfect.
I admit I was wrong about the ATABoy2. However, it's easy to treat many drives as a single unit in software, whether from the perspective of the server or the client. The Xserve RAID is not a hack, it's two RAIDs in one box. How is that a "hack"? I still think the senarios where a single 2.52TB hardware RAID are VERY limited, if they exist at all. In short, I think you're making a mountain out of a molehill.
And correct me if I'm wrong, but isn't RAID 5 distributed parity? That is, 1/3rd of the data on each disk is devoted to parity? Granted, you need one more hot spare in the Xserve if you are trying to keep 100% uptime in a single unit (which I think is a silly thing to try), however the Xserve shouldn't require any more drives for parity in RAID 5.
I admit I was wrong about the ATABoy2. However, it's easy to treat many drives as a single unit in software, whether from the perspective of the server or the client. The Xserve RAID is not a hack, it's two RAIDs in one box. How is that a "hack"? I still think the senarios where a single 2.52TB hardware RAID are VERY limited, if they exist at all. In short, I think you're making a mountain out of a molehill.
And correct me if I'm wrong, but isn't RAID 5 distributed parity? That is, 1/3rd of the data on each disk is devoted to parity? Granted, you need one more hot spare in the Xserve if you are trying to keep 100% uptime in a single unit (which I think is a silly thing to try), however the Xserve shouldn't require any more drives for parity in RAID 5.
Barto
It's not a hack, but when I first saw the specs for it I thought it was a fully redundent controller, and it really isn't. It surprised me is all.
It's not 1/3, rather 1/n where n=number of drives. The more drives, the less you lose. For 100% uptime, assuming that means you can lose a drive controller, then you have to do RAID 50 which means you can only store 6 drives worth of data.
(6 drives + 1 parity) x 2 for mirroring to cover the failed controller. You don't need a hot spare - you have 7 of them. That's a heavy reduction in storage.
I admit I was wrong about the ATABoy2. However, it's easy to treat many drives as a single unit in software, whether from the perspective of the server or the client. The Xserve RAID is not a hack, it's two RAIDs in one box. How is that a "hack"? I still think the senarios where a single 2.52TB hardware RAID are VERY limited, if they exist at all. In short, I think you're making a mountain out of a molehill.
Perhaps "hack" was a bit extreme, but the fact remains that I was RAID shopping at the time, was quite excited about the Xserve RAID, and then after I discovered how it works, was quite disappointed. When I see a 14-drive RAID unit, I don't expect it to be 2 half-size RAIDs. That's all. If you're aware of the Xserve RAID's architecture, I'm sure it can serve you well. I just feel that some people will be misled and disappointed, as I was.
Quote:
Originally posted by Barto
And correct me if I'm wrong, but isn't RAID 5 distributed parity? That is, 1/3rd of the data on each disk is devoted to parity? Granted, you need one more hot spare in the Xserve if you are trying to keep 100% uptime in a single unit (which I think is a silly thing to try), however the Xserve shouldn't require any more drives for parity in RAID 5.
RAID 5 uses 1/(number of drives) of each drive for parity data. A 3-drive RAID 5 set would use 1/3 of each drive for parity, a 4-drive set would use 1/4 of each drive, etc. It ends up to be the equivalent of one drive's worth of parity data no matter the size of the set. So if you have two sets instead of one, you'd need twice the parity data.
Hot spares are not just about potential increased uptime and data integrity, they're also about performance in the event of a drive failing. Performance on a degraded RAID5 set is very poor indeed until it's rebuilt. Having a hot spare in a server environment can therefore be quite beneficial if a drive fails. Instead of possibly waiting a day or more for a replacement drive, the set starts rebuilding immediately and is back to full performance in a matter of hours.
Comments
Originally posted by shawk
One xServe dual processor with 180G / 1x180GB and fiber card will cost $4,500. Two will cost $9,000
One xServe RAID with 1260G / 7x180GB Ultra ATA will cost $7,500. Two will cost $15,000.
Cost is the determining factor in a commercial installation but cost includes MIS overhead and potential loss of revenue due to downtime.
Yes, because two half filled xServe RAIDs are useful HOW?
The mind boggles...
Originally posted by Barto
The ATABoy2F has TWO, count them TWO, ATA RAID controllers (for redundancy and performance). Just like the Xserve RAID. It has two ethernet ports (for redundancy) like the Xserve RAID. It has two fiber channel ports (for performance and redundancy) like the Xserve RAID. The ATABoy2F is almost a mirror image (bad pun) of the Xserve RAID, except for the SCSI controllers.
Oops. You made a mistake. Dual controller ATAboys have TWO host ports PER CONTROLLER. A model with dual controllers has FOUR host ports. Because the controllers are REDUNDANT IN HARDWARE. EACH controller can access ALL 14 DRIVES. So if one controller should fail, you can still run with NO DOWNTIME.
If your goal is to make a mirrored 7-drive array, then you're right. They'd function nearly identically. But if you want ANY OTHER configuration, they're far from the same. BECAUSE THE XSERVE RAID IS TWO 7-DRIVE RAIDS IN ONE CASE.
A true 14-drive RAID offers more flexibility. I feel that that's what Apple needs in an xServe upgrade. That's all. You can disagree if you like.
If you can think up a senario, it will be a very limited one.
I can't think of a workstation or server senario where either backup or fallover is NOT important. Dual 7 disk RAIDs sound like good backup and fallover to me.
Barto
Originally posted by Barto
Ok Alexander. Answer me this: In what possible senario would the full bandwidth (~1GB/s) and capacity (2.5TB) of a 14 disk RAID be used?
If you can think up a senario, it will be a very limited one.
I can't think of a workstation or server senario where either backup or fallover is NOT important. Dual 7 disk RAIDs sound like good backup and fallover to me.
It's not bandwidth, I'm sure both have plenty of it.
It's capacity and flexibility for different configurations.
Say I want to put as much data as possible on an array and have some redundancy in case a drive fails. With a 14 drive controller, I can have 13 drives worth of data, and only lose 1 to RAID5 parity data. If I want a hot spare, I can get 12 drives worth of data. With the Xserve RAID, I could only get 12 drives worth of data with no hot spare. If I want hot spares, I could only use 10 drives worth of data.
It's also much easier to deal with one conceptual unit than two. This is the point of RAID - to combine many drives into a single conceptual unit.
Originally posted by Barto
Are you high, or just really, really stupid? The Xserve has no single point of failure because of its design. A single RAID controller device does. When an Xserve RAID controller falls over and you NEED 100% uptime in one unit, you can switch to the other 7 disk RAID. Trying to keep 100% uptime with zero redundancy is like pushing a boulder uphill. Also, it is probably cheaper to use dual RAID controllers, as a single 14-channel controller ASIC sounds really expensive. The decreased cost is passed to the end user eventually.
Actually, Alexander is right. It's two 7 drive RAIDs in one box and the 'redundant' claim is somewhat misleading since it's only redundant if you are mirroring across the two controllers. Apple can say that it has redundant controllers, but then you don't have a 2.5T RAID, you have a 1.25T RAID. Apple is very clear in this document that it runs a software RAID mirror across the two controllers to implement RAID 50. You can't run a 14 disk RAID 5 with the Xserve.
A perfectly valid use of the Xserve RAID would be to set up two RAID 5 sets for two uses. In that scenario, you don't have redundency in the controllers. My expectation of controller redundancy is that the box works the same with one controller as it does with two, regardless of how you intend to use it. PSU redundency works this way, controller should as well.
I agree that it's something for Apple to fix by replacing the two 7 drive controllers with two 14 drive controllers. I do think that we'll see a SATA Xserve RAID and thats when the full redundency will kick in. It's not broke, it's just not perfect.
And correct me if I'm wrong, but isn't RAID 5 distributed parity? That is, 1/3rd of the data on each disk is devoted to parity? Granted, you need one more hot spare in the Xserve if you are trying to keep 100% uptime in a single unit (which I think is a silly thing to try), however the Xserve shouldn't require any more drives for parity in RAID 5.
Barto
Originally posted by Barto
I admit I was wrong about the ATABoy2. However, it's easy to treat many drives as a single unit in software, whether from the perspective of the server or the client. The Xserve RAID is not a hack, it's two RAIDs in one box. How is that a "hack"? I still think the senarios where a single 2.52TB hardware RAID are VERY limited, if they exist at all. In short, I think you're making a mountain out of a molehill.
And correct me if I'm wrong, but isn't RAID 5 distributed parity? That is, 1/3rd of the data on each disk is devoted to parity? Granted, you need one more hot spare in the Xserve if you are trying to keep 100% uptime in a single unit (which I think is a silly thing to try), however the Xserve shouldn't require any more drives for parity in RAID 5.
Barto
It's not a hack, but when I first saw the specs for it I thought it was a fully redundent controller, and it really isn't. It surprised me is all.
It's not 1/3, rather 1/n where n=number of drives. The more drives, the less you lose. For 100% uptime, assuming that means you can lose a drive controller, then you have to do RAID 50 which means you can only store 6 drives worth of data.
(6 drives + 1 parity) x 2 for mirroring to cover the failed controller. You don't need a hot spare - you have 7 of them. That's a heavy reduction in storage.
Originally posted by Barto
I admit I was wrong about the ATABoy2. However, it's easy to treat many drives as a single unit in software, whether from the perspective of the server or the client. The Xserve RAID is not a hack, it's two RAIDs in one box. How is that a "hack"? I still think the senarios where a single 2.52TB hardware RAID are VERY limited, if they exist at all. In short, I think you're making a mountain out of a molehill.
Perhaps "hack" was a bit extreme, but the fact remains that I was RAID shopping at the time, was quite excited about the Xserve RAID, and then after I discovered how it works, was quite disappointed. When I see a 14-drive RAID unit, I don't expect it to be 2 half-size RAIDs. That's all. If you're aware of the Xserve RAID's architecture, I'm sure it can serve you well. I just feel that some people will be misled and disappointed, as I was.
Originally posted by Barto
And correct me if I'm wrong, but isn't RAID 5 distributed parity? That is, 1/3rd of the data on each disk is devoted to parity? Granted, you need one more hot spare in the Xserve if you are trying to keep 100% uptime in a single unit (which I think is a silly thing to try), however the Xserve shouldn't require any more drives for parity in RAID 5.
RAID 5 uses 1/(number of drives) of each drive for parity data. A 3-drive RAID 5 set would use 1/3 of each drive for parity, a 4-drive set would use 1/4 of each drive, etc. It ends up to be the equivalent of one drive's worth of parity data no matter the size of the set. So if you have two sets instead of one, you'd need twice the parity data.
Hot spares are not just about potential increased uptime and data integrity, they're also about performance in the event of a drive failing. Performance on a degraded RAID5 set is very poor indeed until it's rebuilt. Having a hot spare in a server environment can therefore be quite beneficial if a drive fails. Instead of possibly waiting a day or more for a replacement drive, the set starts rebuilding immediately and is back to full performance in a matter of hours.