Mirror Accross 2 Arrays using LVM or VxVM - What Are My Performance Penalties?

[Alzhy]

Planning to have Full or Part-Time Mirrors at the host level (software based-LVM/VxVM) to protect agains whole array failures. I know for reads I will get the added benefit but what about writes? Do I suffer considerable penalties for such?

I know that for some HP-UX11i clustering solutions -- VxVM mirroring is sometime implemented. And the arrays involved are hundreds of KM away (dark fibre...) And if I recall right -- I thought one of the presenters at HP World '04 mentioned that the penalty is "negligible"..


Comments, experiences?

[Steven E. Protter]

If you've got a fast, reliable pipe, sounds like you do, then the performance penalties are not large.

We're talking Raid 1 mirrors here. That mirroring usually provides a performance benefit over a Raid 5 striping scenario.

You might wish to investigate implementing a SG Continental Cluster.

Did you get your Harley yet?

SEP

[Alzhy]

The 2 Arrays will be on a local SAN and same configuration/brand/SANabilities. For VxVM I can have more control on the configuration of my storage volumes.

Note though that the reason we are further RAIDing the already RAIDed LUNS from each array is to provide redundancy on these arrays -- specially that we've seen a string of whole array failures.

My testing so far (with IOZONE and BONNIE) does seem to indicate very little or no performance impacts at all -- using VxVM.

Yep I got the HD Sep! And they actually gave me the 2005 XL883 Custom! Nice bike but I will probably only be able to enjoy it in the next few days or so. I am in Michigan ya know... so..

[Prashant Zanwar_4]

I dont suggest that. Because replication cost would be really will not be a problem if you are working with two arrays already.
USe array technology rather than using Unix one.

If at all you are going for it, use a dedicated ethernet to address it. Have a FDDI ring which will let you do it best.
Do something such that the mirroring sync happens through some decicated NET.

hope above helps
Prashant

[Alzhy]

Prashant,

You don't seem to understand. I am not implementing a Cluster here. I am merely providing higher storage availability becuase we are faced with an undeniable fact that our storage arrays (whole arrays) can fail. And that storage array's "in-array" tools does not allow for mirroring to another array -- just within itself. So in the past, we have production, snapclone of production, snapshots or production on the SAME ARRAY - which if it goes down - guess what?

[Sridhar Bhaskarla]

Nelson,

You sure will get benifits from reads. But the penalties from the writes is dependent. In the mirroring setup, on important point to note - performance will be as good as the weakest link. So, if the latency of one array due to any component in between is not better than the the other array, then you can't expect good performance.

VxVM mirroring is generally preferred not because of the performance point of view but due to it's ability to support "striping" if you ever intended to do on the host.

I don't believe you see any performance benifits with VxVM except that you have better tools to debug performance problems like vxstat, vxtrace etc., that you lack on LVM.

I assume you will add seperate HBAs on the system for the other array and make sure the setup is the same if not better than the first array.

-Sri

[Alzhy]

Sridhar,

I don't know if you've monitored some of my posts vis a vis VxVM and EVA but the reason we are doing this is to give our EVA's Full Redundancy and Failoverability. I've done some extensive tests (iozone, bonnie and a custom written tool) and there is no difference in the write performance on a VxVM volume that has a single plex compared with one that has multiple plexes (to date I tested up to 3 plexes - with each plex on a LUN on a different EVA).

We will still be using SecurePath as the EVA is not a VxVM DMP supported system so all arrays will share however many HBA's we have -- which on our biggest server, we have 8x2GB FCs. Under SecurePath, each EVA LUN is accessible and active on however many HBA's.

I was thinking of striping accross LUNs from each EVA but we will still be vulnerable should one EVA go down. I also "toyed" with the idea of daoing a RAID5 (a 3+1P) from the 4 EVAs to protect agains whole EVA failures but settled to just do simple mirroring - whatever we have on one EVA is duplicated on another EVA - so on failure of one EVA, my servers and applications stay up.

Some were actually suggesting Continous Access/EVA but I think we've successfully demonstrated that for our needs, VxVM's benefits of increasing EVA availability and our needs of continous large DB Refresh environments and split mirror backups far outweight Continous Access/EVA's. Besides, VxVM will not bind us to any array vendor as whatever processes we establish today - will still work on any array that might come our door in the future. And migrating data from one array to another (heterogenous platforms) will be a whole lot easier.

[Ted Buis]

Many years ago, I was told that told that the read benefit was typically 30% and that the write penalty was typically 10% if you had separate interface cards using MirrorDisk/UX. However, I am checking in "HP-UX 11i tuning and performance" by Robert F. Sauers, and he is say up to 100% improvement on reads and up to a 50% decrease in performance on writes (p.274 "twice as many writes"). He definitely isn't sticking his neck out as I read this as just state the obvious extremes. If one of the arrays is much farther away your latency will grow, but reads will still be faster since it goes to the device with the shortest queue. I would be surprised if there is much performance differnce between VxVM mirroring and MirrorDisk.