Re: ASM diskgroup redundancy
Date: Sun, 18 Sep 2011 17:48:07 +0000 (UTC)
Message-ID: <pan.2011.09.18.17.48.07_at_gmail.com>
On Sun, 18 Sep 2011 03:38:56 -0700, Jörg Jost wrote:
> Hi,
>
> we use the mirroring feature delivered by ASM at two sites. And we do
> this most of all because of saving money :)
That's the best motive I know of. IT as such was introduced to save money in the first place. Before the IT, companies were working like in the opening scene of Monty Python's "Meaning of Life": an army of accountants, all with mechanical calculators, supervised by a "slave master". Now, 3 Dell boxes, clustered over NetApp are much cheaper than the army of accountants, even with Oracle RAC.
>
> Think about a two node RAC, each node sitting in a separate data center
> at
> the same building, but in different rooms because of security reasons.
> Fire or water
> will destroy normally only one site (hopefully)
>
> So, regarding this scenario, you will normally use two storages, one for
> each data center.
>
> Now you have the choice, use the ASM mirroring feature to make all
> mirroring over both
> storages or use some build in feature delivered by the storage
> manufacturer. Last one will
> often cause expensive investments, because this feature is not cost
> free.
>
> In this case we use ASM mirroring with two failure group, one on each
> storage. So we have
> no single point of failure.
>
> Bye
>
> Joerg
Now, this is a perfectly reasonable explanation: ASM does for free what the storage manufacturer charges for: replication between 2 different SAN devices. Makes perfect sense. How are you satisfied with the performance? That, of course, means that the server CPU cycles are used for disk mirroring. Is it a big burden? The companies that I worked for have usually used external redundancy, provided by the SAN itself plus a standby database, usually in maximum performance mode, to minimize the impact on the primary. In one case, the standby replication went over WAN from Louisville, KY to NYC, NY. It did consume very significant communication resources, completely devouring a T2 line.
-- http://mgogala.byethost5.comReceived on Sun Sep 18 2011 - 12:48:07 CDT