Re: asm on san

From: Michael Austin <maustin_at_firstdbasource.com>
Date: Sat, 13 Dec 2008 20:19:11 -0600
Message-ID: <P2_0l.9863$yr3.8943@nlpi068.nbdc.sbc.com>


Robert Klemme wrote:
> On 13.12.2008 23:28, hpuxrac wrote:
>
>> In this business you have got to be prepared for the fact that
>> warm-and-fuzzy only lasts 3-5 years. And if someone doesn't keep up
>> they fall by the wayside.
>
> Switching to the latest and greatest all the time is not an option for
> everyone. Especially in the area of storage that back 24x7 systems
> large volume data migration can be difficult to impossible. IMHO
> understanding of the underlying technologies and how they will scale in
> a few years from now is important. There are some fundamental issues
> with RAID 5 that a large cache can only mask.

Yes, that is true, however, with todays technology, they mask it very well. And as I stated, the virtualization and obfuscation at the array level, including the RAID settings within the array as well as stripping within ASM and potentially IBM's SVC front-end, the RAID level is *almost* a moot point.

>It may well be that you
> hit the IO bandwidth limit no sooner than two years from now by which
> time you face a necessary hardware upgrade and migration of a few TB
> which can be painful - and costly.

I would like to take this opportunity to share one of the biggest benefits I have ever seen in a piece of technology from Oracle. I was recently involved in the implementation and support of moving a huge multiTB database from one storage vendor to another. Using ASM, we were able to move the data ONLINE and without interruption to normal day-to-day operations. It took a few :) days, but was seamless in its implementation and extremely painless given the magnitude of the move. The fact that it was in a RAC cluster also helped.

I would provide more details but then I would have to .... [you know the rest :) ], I will say that our 3 smallest DISKGROUPS were just shy of 1TB and in parallel (used each ASM instance in the cluster), moved all 3 in < 2.5hrs.

Once the move was complete, the old vendors LUNS were removed from the system, the cluster rebooted and performance is well within SLA.

Suffice it to say, that just a few short years ago, this would have been a near impossibility... leaving most customer "stuck" with their previous choice of storage vendor. Received on Sat Dec 13 2008 - 20:19:11 CST

Original text of this message