Re: asm on san
Date: Sun, 14 Dec 2008 11:13:00 +0100
On 14.12.2008 03:19, Michael Austin wrote:
> 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.
Yes, I agree. Unfortunately this is not too good news, because as the importance of RAID level decreases, new challenges and potential sources for issues arise: network topology, bandwidth, software issues in SAN etc. - the whole thing has become significantly more complex than in the old days(TM). :-)
>> 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.
Thanks for sharing! I haven't been exposed to ASM too much so far and will definitively keep this in the back of my head.
robert Received on Sun Dec 14 2008 - 04:13:00 CST