Re: IBM FastT vs. EMC Clarion

• Previous message: Jim Richard: "Re: IBM FastT vs. EMC Clarion"
• In reply to: Jim Richard: "Re: IBM FastT vs. EMC Clarion"
• Next in thread: Andrew Townsend: "Re: IBM FastT vs. EMC Clarion"
• Reply: Andrew Townsend: "Re: IBM FastT vs. EMC Clarion"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:         Fri, 25 Mar 2005 07:55:41 -0500
To: aix-l@Princeton.EDU

I have two CX500's and 5 CX300, not by my choice, I go with IBM. THe
big thing I found is that if you need to do a flare upgade (firmware)
any AIX servers attached to that unit will have to be shutdown. That
is as of today. I do know EMC has made some improvment to powerpath
to help but still not there yet. The trouble is something with the OS
and the disk, when they do a flare upgrade on the A side sometimes and
not all, the disk are gone from the OS and you have to reboot to get
them back. Again managment are the ones that whated EMC here and it
is a show stopper in rolling out a new product till it is fixed.

Here is a copy from EMC on this issue:

EMC Corporate Statement

The EMC CLARiiON CX family of arrays supports a Non-Disruptive Upgrade
process (NDU) for upgrading the software on the array without
interrupting host I/O access to the array. This process involves
upgrading the software on the array storage processors one at a time,
while allowing the other array storage processor to continue to
service I/O requests. EMC has successfully tested this process without
interrupting host I/O access to the array thousands of times with many
different types of hosts attached to the array. Unfortunately, we have
found that in a small percentage of cases upgrading the array software
will cause interruption in host I/O from AIX attached hosts.

Because even a small percentage of failures is unacceptable to
customers who depend on the non-disruptive nature of our array
software upgrades, EMC's current recommendation is to schedule
software upgrade for arrays with AIX attached hosts at a time when AIX
host I/O interruptions can be tolerated. EMC has a cross-functional
team including members from several EMC Engineering organizations and
EMC Customer Service, along with assistance from IBM to address the
failures. The problem is related to complex interactions between AIX
driver behavior, PowerPath behavior, and CX array behavior that have
been difficult to reproduce for root cause. Due to this complexity,
progress thus far has been slow. However, EMC is committed to the same
NDU feature for AIX attached hosts that is currently available for
other attached host environments.

EMC has equipment and staff dedicated full time to these efforts and
is committed to delivering reliable NDU for AIX as soon as possible.
Current Status

EMC has made tremendous progress in addressing the ability to
successfully and safely perform online NDUs in an AIX attached
environment through changes in PowerPath. We are constantly running
NDUs in our lab and we now have runs of as many as a 100 consecutive
successful NDUs under heavy host I/O load with hundreds of paths to
the array. However, we still have occasional failures.

We have reached agreement with IBM engineering on an approach to
addressing the problem that involves changes in array behavior
combined with changes in PowerPath behavior. We are in the process of
implementing and then testing the changes. We are optimistic that
these changes will enable reliable NDU for AIX. However, to assure the
changes enable successful NDU and do not introduce new problems,
extensive testing will be required. As we complete our implementation
and get some testing completed, we will have a better feel for the
success of this approach and will start to plan how to deliver the
updates to the field.

Additional information should be available in the next 30 days. We
remain committed to reliable NDU for AIX ASAP.

HTH
Vince

On Thu, 24 Mar 2005 23:25:50 -0500, Jim Richard <JRichard@sciquest.com> wrote:
> I have a fastt600 running for a year now flawlessly... My only gripe is that
> it was advertised as being raid 10 aka (1+0) capable... And technically it's
> not. To my mind raid 10 is Mirror the disks across pairs then stripe the
> data across the mirrors. IBM builds the stripe on half the disks then
> mirrors the entire stripe onto the other half of the physical disks.
>
> This has a number of negative reliability, and recovery ramifications :
>
> Reliability:
>
> In my idea of a raid 10 ( and most other vendors' that I've dealt
> with ) you would have to loose 2 individual disks that are directly
> paired together to loose the array.
> So say you have a disk array with 10 drives, this would be comprised
> of
> 5 pairs.
> You would have to loose both disks of any single pair for the array
> to fail. So I can actually have up to 5
> disks of the 10 units fail before the array fails (very best case),
> so long as no two failed disks were paired together.
>
> In IBM's idea of a raid 10 you have an array comprised of 5 drives
> striped ( raid 0) then the raid 0 is mirrored
> to another 5 drives (raid 0+1).
> In this case if you loose 1 drive on one stripe then any other drive
> on the other stripe the
> array is toast. The only way to lose 5 disks and have the array
> survive is if all 5 failed disks are in the
> same stripe. Of course the only likely scenario for this is if your
> stripes are in two separate disk enclosures, and
> you lose an enclosure. Which is a good idea in either case, in my
> idea of a raid 10 no paired disks would reside in
> the same enclosure.
>
> Recovery:
>
> In my idea of a raid 10 described above, if you loose a drive, when
> you replace it only the one drive has
> to be re-mirrored.
>
> In IBM's idea of a raid 10, the entire 5 drive stripe has to be
> re-mirrored...5x I/O, CPU, contention on the
> switch .... Etc.
>
> To be fair you can mitigate most of the reliability risk with proper use of
> hot spares and diligent monitoring, which should be the norm in any large
> disk deployment SAN, SCSI, or anything else. Unfortunately the recovery
> issue is still a problem for large arrays.
>
> Unfortunately for me the decision to purchase these units) was based on high
> level marketing material and discounts... I only found all this out after
> slogging through the technical docs ( and this little detail is buried way
> down in them) after the equipment was already on order. A typical case of
> buyer beware.
>
> Other then that the stuff is pretty nice. If you're not planning on running
> raid 10 (1+0) you should be fine. If you are going to run mirrored you'll be
> fine as long as you follow best practices and understand the issues.
>
> Jim
>
> -----Original Message-----
> From: glh@DAIRYNET.COM [mailto:glh@DAIRYNET.COM]
> Sent: Thursday, March 24, 2005 12:31 PM
> To: aix-l@Princeton.EDU
> Subject: IBM FastT vs. EMC Clarion
>
> We are in the process of selecting our first SAN for our environment -
> approximately 10 AIX servers and 3 Windows servers. We've narrowed our
> choices down to either an IBM DS4300 Turbo (old FastT) or the EMC CLARiion
> CX500. For those of you who may have worked with either (or both) of these
> products, what is your overall opinion of the product? Would you buy that
> product again? Any positive or negative comments would be greatly
> appreciated. Thanks.
>

• Previous message: Jim Richard: "Re: IBM FastT vs. EMC Clarion"
• In reply to: Jim Richard: "Re: IBM FastT vs. EMC Clarion"
• Next in thread: Andrew Townsend: "Re: IBM FastT vs. EMC Clarion"
• Reply: Andrew Townsend: "Re: IBM FastT vs. EMC Clarion"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]