how-to block ads
|
AntiFUD
@dell.com
| Benchmarking? I think not.
Perhaps when you attempt benchmarking with an operating system that is test with and validated to work with the unit, the results will be more accurate. When the management software for a unit has to be hacked up (yes, hacked up, you even said you were out of your element there!) it cannot be depended upon to produce the same output that it did when run as intended.
As well, was any kernel tuning performed to focus on I/O? You didn't include any in the brief write up of the steps you did perform. So far, the evidence you present in this 'benchmarking' run is flimsy at best, cobbled together sewage at best. Best of luck spreading FUD. | |
justin
Australian
join:1999-05-28
Brooklyn, NY
Host:
IPv6
Business Connectiv..
Home/Office setup ..
Console/Handheld g..
Console Tech
edit:
September 10th, @03:05PM
| said by AntiFUD :
Perhaps when you attempt benchmarking with an operating system that is test with and validated to work with the unit, the results will be more accurate. I'm using SuSE x64 10.1, here is the certification matrix from the Dell manual:
Am I missing something?
When the management software for a unit has to be hacked up (yes, hacked up, you even said you were out of your element there!) it cannot be depended upon to produce the same output that it did when run as intended. I'm out of my element where it comes to talking about the history of kernel patches to support rdac on device mapper, but actually my SuSE is vanilla 10.1, and the management software isn't changed one jot. Nothing was "hacked up". I got the same performance on CentOS 5 (which is RHEL, also on the certified list) and the RDAC driver .. As one would hope, as the RDAC driver is nothing to do with performance, it handles failover only.
As well, was any kernel tuning performed to focus on I/O? No kernel tuning is required in order to benchmark external enclosures with IOZone or dd or Orion or Bonnie++. The kernel is hardly involved, the work is done by the HBA and the enclosure. During benchmarks the cpu is nearly 100% idle. If there is "kernel tuning" required in order to extract more performance where is this tuning documented in the MD-3000 install guide? There is actually some minor tuning dicussed in the IBM redbook manual for the DS4100, it involves being careful that the sum of all nr_requests (scsi queues) does not exceed the capabilities of the MD-3000 for if they do, data loss can result.
You didn't include any in the brief write up of the steps you did perform. So far, the evidence you present in this 'benchmarking' run is flimsy at best, cobbled together sewage at best. Best of luck spreading FUD.
The performance I got is duplicated by the other write-up out there: all.thingsit.com benchmark md-3000. Actually he got slightly lower performance.
It is interesting that an @dell.com address is attempting to undermine this write-up  now you couldn't have any vested interests, could you?
But I welcome comments from Dell privately or public so fire away..
Can you point to a Dell or Dell authorized benchmark that shows the unit doing better? Do you maintain that the MD-3000 does not have the guts from an IBM DS4100 which has openly advertised total through-put that matches the results above? Stuff like this I'd like to hear from Dell. | |
fcisler
Premium
join:2004-06-14
Riverhead, NY
| Anonymous did bring up one point, which doesn't affect you - but I have seen firsthand.
When we had an oracle cluster setup under linux (RHEL ES, but a CX300), I did a kernel upgrade. Instantly - performance went down the tubes. Couldn't figure out why, so I downgraded the kernel - performance was back to normal.
One weekend when I had some time, I upgraded to the newest kernel and did some testing. While transferring files back and fourth to two different LUN's (one R10 and one R5), the CPU's would peg at 100%!
What the hell is this? A call to dell support, after getting transfered between "gold support" at least 5 different times, resulted in a "please do not update until dell tells you to do so". Uhh...ok? A kernel revision BUMP can degrade the performance THAT MUCH? wow!
One of the many reasons we dumped that setup. Neither Dell (who was also our support for RHEL, we could not contact them directly) or Oracle was of any use WHATSOEVER! Seriously...we had dell setup the thing...but once performance started degrading, neither one was of any help whatsoever. Both companies were not ready to support this setup.
Anyway, back on topic....
We are actually paying for an installation of this whole shebang. I've never setup a SAS array, and for "warranty purposes" - dell must do an installation of the MD3000, two nodes of the cluster, and software. Fine by me....I'll get to learn how Dell does it (hopefully) right.
Interesting you say R5 works better than R10. This was just creating a single LUN on the array...all hardware? No software raid involved? For everything lately, except a couple multi TB arrays strictly used for a "storage repository", I've been going R10.
I haven't read through those manuals yet...but do you know off the top of your head if any of the disks also hold the "OS" for the array itself (ala emc)?
The price we got for this while cluster is completely absurd (in a good way, I wish I could post what we paid for the array alone), and it will only be doing Exchange 2007...so I 'm hoping that performance on the MD3000 isn't going to be an issue with it.
On the other hand, though, we were looking at setting up a new oracle cluster possibly with the MD....but if this is the performance - I'd be better loading up a 2950 with 4 SAS drives, doing R10 across them, and setting up two standalone units. The price difference between the new CX3-* series and MD3000 was a big issue...and I guess this is another instance of "you get what you pay for".... | |
justin
Australian
join:1999-05-28
Brooklyn, NY
Host:
IPv6
Business Connectiv..
Home/Office setup ..
Console/Handheld g..
Console Tech
| Yeah I know there are instances of upgrades killing features that optimize for speed. Happens all the more often when there are layers involved for instance for a while LVM killed performance that you got out of the underlying devices. I tend not to automatically upgrade critical production stuff that works unless I need a new feature, for that very reason.
Not concerned here because the dots are all joined up. The spec published by IBM (but not Dell) matches the throughput test I've done, which matches the benchmarks done on the all.thingsit blog, give or take 20%. lower level benchmarks match higher level ones. Stuff like that.
As for RAID5 I've not tested it yet but that is very clearly what the IBM manual says vs RAID10. Something about the firmware in the controllers optimized for RAID5 LUNs  It may not really be worth it because if the whole shabang is capped at around 400mb/sec or so then there isn't a lot of point increasing sequential read throughput from 200mb/sec to perhaps 300mb/sec with the potential to slightly decrease write speed unless you really need the extra space RAID5 provides. There is also the issue that if all the drives are the same age they may start failing in batches and in that case you probably want RAID10 not RAID5 as it can suffer more drive failures!
The MD3000 stores the firmware on the pluggable controllers (I think). Anyway, it stores nothing on the drives thats for sure. The firmware isn't very large, or complex. It does support some basic performance collection so you can check if you have drive hot spots but the management interface does not give you any tools to review this info - you're on your own sucking that data out and plotting it or whatever. There are also those two "unlockable" features at ridiculous cost to look at (LUN copy and LUN snapshot). I'm not bothering with them because LVM2 gives the same thing for free. | |
|
