Continous Access versus VxVM as EVA to EVA Redundancy, Failover & Mirroring Solution

[Alzhy]

Due to a string of unfortunate and near-catastrophic but nevertheless business-disruptive (over 24 hours) events on our EVA 5K + HP-UX 11i Environments - we are looking for solutions to give us protection in case of whole EVA failures. Not only that, we want to be able to have copies of our multi-TB sized Databases to be on different EVA's instead of the current problem plagued Business-Copy SnapClones that we do.


I am for implementing Full VxVM to address both redundancy/failover requirements as well as the ability to have copies of production DB on other EVA's. But someone from our teams is suggesting Continous Access/EVA.

Will Continous Access/EVA work to address the issues we're trying to address? Could this even be a solution? Note that our infrastructure is now simply Windows based but HP-UX 11i large systems.

[Zygmunt Krawczyk]

Hi Nelson,

the Continuous Access EVA (CA EVA) is the best solution for protection in case of whole array failure. CA EVA is controller based software, no OS software, so it doesn't add OS load.

Regards,
Zygmunt

[Alzhy]

As I understand it, CA is a replication solution (for DR/BC) and is not really intended for the use we are thinking of -- which is to provide high availability to the EVA platform. We've suffered catastrophic single EVA failures lately .. if we've say some mirroring/failover between 2 EVAs like VxVM can only provide, there would have been no downtime.

In a CA environment, how does a failover happen? Is it manual? With VxVM, we don't have to do anything since the filesystems hang off the 2 EVA's -- the server/apps just go on functioning.

Also, what about our other important requirement to have copies of production onto other EVA's (or other arrays) on a periodic basis? With CA will it be possible? LVM can'nt do this becuase you cannot safely split VolumeGroups after a mirror (MirrorDisk/UX based). And EVA software (BusinessCopy) does not allow for mirroring between 2 EVAs..

[chris huys_4 · Accepted solution]

Hi Nelson,

a/ VxVM mirroring with EVA

HP-UXserver vxvm-volume -- vola
| |
| +---------------------+
| EVA1 | EVA2
| +--------+ | +-------+
+----------+ vola-1 | +---+ vola-2|
| luna1 | | luna2 |
+--------+ +-------+

VxVM volume vola has 2 mirrored plexes, vola-1 and vola-2. vola-1 receives its data from luna1, vola-2 receives its data from luna2.

The VxVM software, is responsible for replicating the data between the 2 luns.

If 1 of the luns would fail, luna1 or luna2, one of the plexes would be disabled, vola-1 or vola-2, but the volume on itself would remain available.
There is no application downtime.


b/ Continuous Access with EVA

HP-UXserver vxvm volume vola
| |
| +-----------------+
| EVA1 | EVA2
| +-------+ | +-----+
+----------+ vola-1| +---+ |
| luna1 | |luna2|
+-+-----+ +---+-+
| |
+----------------+

VxVM volume vola has only 1 plex, vola-1 on EVA1.

plex vola-1 receives its data from lun luna1.
luna1 is hardware replicated, to luna2 on EVA2.

If luna2 would fail, volume vola is not implicated, so the volume vola remains active.
No application impact.

If luna1 would fail, plex vola-1 of volume vola, would be disabled, and as result vola will become unavailable.
As a consequence the diskgroup where vola is part of, will need to be failed over from accessing his luns via EVA1 to accessing his luns via EVA2.

This will cause application unavailability.

With MC/SG software you could automate the failing over of diskgroups from 1 EVA to another EVA, but the metrocluster script, that would give you this automation in MC/SG, and immediatel also support, will not be out for EVA CA, before Dec2004.

[Alzhy]

Chris,

Brilliant comparison sir! So with VxVM, no cluserting software required and you get higher storage uptime from 2 EVAs while addressing issues such as backups and database refreshes. One is also not locked into a particular array's technologies and makes migrating from one array to another painless.