Re: Linux LVM software raid, and SAN question.

Kyle Schmitt <kyleaschmitt@xxxxxxxxx> wrote:
On Jan 23, 10:11?am, belpatCA <belpa...@xxxxxxxxx> wrote:
I don't want to suggest a bad architecture here (I'm sure there are
political/historical reasons), but I'm curious as to why you would
want software mirroring between two raid boxes in different SANs.
Aiming for 'massive redundancy' by relying on software on a server to
copy every byte to two different arrays isn't exactly common practice,
at least not in my world...
Just blindly mirroring between the two arrays only gives you some
redundancy against hardware failure (while introducing possibility of
software failure on your server), but doesn't help at all for logical
or user errors, which are much more common. And the most common
hardware failures (disk crash, controller crash, cable failure) are
presumably already taken care of by the arrays, unless you've got a
crappy one.

Something more common, as suggested by earlier posts, would be to have
one SAN with two separate fabrics, and every end-device (HBA and both
storage arrays) connected to both fabrics, switches only in one
fabric. Then use one array for primary storage, with dual redundant
everything from the HBA down to the array, and use the other array for
snapshots or clones.
You can have those snapshots generated by your apps or by volume
managers on the server if you like. Or some storage arrays support
creating 'remote' snapshots.

Each time I post I realize I forgot some piece of data or another :)
In my description of one hba hooking up to a switch, which has four
connections to the SAN, I failed to mention that the 4 connections
consist of two fabrics.
The consensus here has been that in the final setup, there will be two
habs to each switch (total of four on the box), for redundancy.

I'm not sure about remote snapshots, but it's possible that our SAN
supports it, or that the package/upgrade for that is available. I'll
have to look into it.

Historical-political issues abound, far too much to bring up in a
post. Suffice it to say, there are reasons we need and want two
physical sans hooked up here, and the majority are even legitimate.

The main objection you're hearing here is that a database server should be
also double as a SAN mirroring device.

Say the machine crashes. Which san even has the correct data anymore?

There are (costly) hardware devices which will present a a set of LUNs to
your host, the database machines that do the mirroring to the separate
SANs on the backend.

Assuming this is what you really want, you end up with a database server
doing only one thing, and that's being a database server, and you have
some extra hardware dedicated to mirroring your SANs.

Will all this extra stuff increate reliability? I really don't know.
.

Relevant Pages

  • SUMMARY: SAN Storage best practice
    ... fault tolerant SAN storage is overkill. ... other host side volume management requirements that might exceed what is ... If your storage array is setup to hand out fault tolerant LUN's then it ... --I've been in an organization where double mirroring was seriously ...
    (SunManagers)
  • Re: Do we need multiple REDOLOG member if it is already on SAN box?
    ... on SAN storage. ... redolog members, he told me we have already mirrored for u at the san ... consensus even from the Oakies is do not do mirroring twice. ...
    (comp.databases.oracle.server)
  • Re: Do we need multiple REDOLOG member if it is already on SAN box?
    ... on SAN storage. ... redolog members, he told me we have already mirrored for u at the san ... consensus even from the Oakies is do not do mirroring twice. ...
    (comp.databases.oracle.server)
  • Re: ASM Question - Best Practice
    ... The intention is to use ASM. ... So first question: The mirroring can be done ... or we can do it at the SAN level. ...
    (comp.databases.oracle.server)
  • Re: Linux LVM software raid, and SAN question.
    ... Aiming for 'massive redundancy' by relying on software on a server to ... Just blindly mirroring between the two arrays only gives you some ... one SAN with two separate fabrics, and every end-device (HBA and both ... You can have those snapshots generated by your apps or by volume ...
    (comp.arch.storage)