EVA5k + SecurePath + VxVM + HP-UX11i - Anyone Using this Environment?

[Alzhy]

I know even before SecurePath 3.0D, VxVM works perfectly with SecurePath/EVA LUNs. Anyone out there happen to have this environment EVA5K Array with SecurePath and Using VxVM (instead of LVM) to carve/manage the LUNs?

I am acutally more interested to those sites that use VxVM mirroring (hostbased) to say - mirror a volumegroup accross 2 EVA's instead of using Business Copy VSNAPS or Continuous Access. With LVM .. you can only mirror an object one at a time.. but with VxVM, you can simultaneously have several mirror resynhcs going on. We are doing this apporach on Solaris + XP (HDS) environment and get very good results (we do 4 Volume synchs at a time and performance is not severely degraded).

We are thinking doing away with Business copy SnapClones (since it does not support snapclones accross 2 EVA and does affect performance during the snapclone process and the various "levelling" processes going on behid the scene).

[Nagarajan Balakrishnan_1 · Accepted solution]

Nelson,

We are using the same combination namely EVA5K, SecurePath, VxVM, HPUX 11i.

If you want to use the OS based mirroring, it would work perfectly well, except that if the storages are kept at different locations (physical) and connected through a WAN link.

Otherwise, it should be perfectly fine. We have done this before with good success. The only thing that you would miss is using the second copy for performing some operations like during specific upgrades or using the snaps for backups from an entirely different host, etc.

Cheers
Baalki
Cheers
Baalki

[Alzhy]

Nagarajan,

What I am planning to do in lieue of the easier but performance impacting BC Vsnapclones is just to use mirroring. Instead of VsnapCloning our TBsized DB's onto LUNs located within the same EVA - I will do hostbased VxVM mirroring so I mirror to another EVA.. The mirroring will be done during windows of light activity and with VxVM we can submit several mirror synchup processes -- which according to my estimates could be faster than VsnapClones. Once the VxVM Mirrors are attached, we halt the DB and split the mirrors. The LUNs comprising the Mirrors could then be "imported" on to another server where it can be backed up or use for testing, reporting or DSS processing.

This scheme will have the advantage of:

1. The only real impact on production (and on the production EVA) will be only during the mirror synch up process.

2. After the LUNs are presented on say the backup server, backup operations (or other processing done on the mirrors) will no longer have any impact on the production EVA and the servers attached to it.

3. No more background levelling, synching that will happen whenever Vsnaps are refreshed, etc..


The "Mirror LUNs from the Backup or Mirror EVA) can be prepped up beforehand and "multi-pathed or multi-hosted or multi-presented" to the production server and to the backup or test servers... This has the added advantage of just using VxVM's Volume Group export/import facilities to "float" the mirror LUNs around..

We are already using this approach on a Solaris/HDS (XP 99xx) environment with great success.