Host based mirroring with an XP and an EVA

[Rick vonR]

I want to do host based LVM mirroring using two different types of storage. The LUNs would come from an XP12000 and an EVA8400. The XP has 2x16 port 2Gb cards, and 146GB 10K FC drives. The EVA8400 has 4Gb connections, 300GB 15K FC drives, and 22GB cache. The SAN is 4Gb.
This is for a DRLite (Disaster Recovery Lite) scenario. I.e. The XP is in one building on the campus and the EVA is in another building. There is one pair of HP-UX servers and one pair of AIX servers using VCS. The server pairs are split between the two buildings. A set of XP LUNs are given to the HP-UX servers and LVM mirrored to a set of EVA LUNs. Same with the AIX servers using a different set of LUNs.
What I want to know is if this is a workable solution? Are there any compatibility or performance issues that I need to be concerned about? Are there any documents or white papers for this type of setup? I was thinking about having the LUNs from each type of storage come into different HBAs on the servers.

[Steven E. Protter · Accepted solution]

Shalom,

Partial commentary:

What I want to know is if this is a workable solution?

No. DR on two buildings on the same campus is only a solution for lost of the disk array. It is not a real DR solution.

Are there any compatibility or performance issues that I need to be concerned about?

No issues there with enough band width to handle data replication.

Are there any documents or white papers for this type of setup?

http://forums11.itrc.hp.com/service/forums/categoryhome.do?categoryId=207

There are a number of DR white papers.

I recommend the following google search.

Disaster Recovery white papers site:docs.hp.com

SEP

[Olivier Masse]

I couldn't tell for AIX but under ServiceGuard, this is known as an "Extended Distance Cluster" and it is officially documented and supported, although you should check since you have two different arrays involved.

Unless performance is an absolute requirement for you, it's actually simpler with what you're doing than having to bridge your cluster technology with the replication of your SAN arrays; you're also totally hardware vendor independent as far as your SAN is concerned.

Look in the Serviceguard docs for more info.

[Rick vonR]

Thank you Steven and Olivier.

Steven, you are correct that this is not a true DR solution. This is why we have coined the phrase DRLite. We already have a true DR solution set up with another city in the US. This true DR solution is for an entire site disaster where we would have to fail over to the other city.
However, a more common situation is within a single site (power or data to a building gets cut, server goes down, storage goes down, storage/server maint, etc...) This is what we are planning for which we call DRLite. We don't want to fail over to another city if we have redundant systems in another building on the same site. We are using Veritas Cluster Server (VCS). It also allows us to remain running if the facilities folks need to work on a single building's power or we need to work on one set of servers (patching, upgrades, etc...). We can just fail over to the other servers in the other building. Iâ m glad there are no compatibility issues. Thank you for the white papers link.

Olivier, I'm not totally familiar with ServiceGuard, but isn't the Extended Distance Cluster where you have a cluster over routers. I mean, you have to extend your SAN or network over a set of routers that would change SAN into TCP-IP and then back again? In our case the SAN and LAN are all contiguous, connected via switches. So, there are no routes/bridges to contend with. It is just one large SAN connected to all the buildings.

After writing this I came up with another issue. If I lost a building (i.e. loss of the primary cluster node and loss of a storage array) and I had to fail over to the other secondary node, wouldn't the OS complain when I tried to import the VG without half of it's mirrors? I could probably disable quorum but is there anything else I'm forgetting?
I don't have the EVA8400 on-site yet so I can't test with it. But, I do have an EVA8100 that I could test with.

As far a compatibility goes, I say storage is stupid. It only responds to the hosts connected to it. So it shouldn't matter where the LUNs are coming from because the host will dictate all of the reads/writes and mirror synch.
For performance, I realize that in any host based mirroring there will be a small performance hit on the server. What I have to be concerned with is my choice of storage for the mirrors. I should pick storage devices that have almost the same performance characteristics (IOPS, latency, etc...). If both storage devices respond in the same time to write requests then they will not induce an additional latency on the server.
From everything Iâ ve seen or read about, the EVA8400 with 22GB of cache can keep up with an XP12000. I should qualify that it should keep up with MY XP12000 that is not a fully loaded XP.