EVA to EVA migration - Continous Access

[Frank Andrews]

All,

I may be migrating a client from an older EVA to an 8100 in the future, I was told that downloading the free trial of CA can accomplish this. I was wondering if anyone could give me an overview/hint of how this is deployed? I am guessing that the product would be installed on the management workstation where Command View is installed? I also assume it can do a 'mirror' of one EVA's volume to another EVA's volume?

When the mirror is first started is there a big impact on the FC traffic? Can it be throttled?

The client is concerned that if we begin a mirror using CA that initially a lot of traffic will swamp there FC network and they already have performance issues due to heavy usage through some databases.

Basically can anyone give me an overview of how CA is deployed and its concept, I'd appreciate it.

Thanks

[T Downing · Accepted solution]

I can't comment on a trial of CA, but what you download and install is RSM (Replication Solutions Manager), as IIRC CA is activated on the EVA via a license key. I use a mix of RSM and Command View for CA depending on what I am doing, most task can be done in either.

Based on my experience in setting up CA (8100 to 8100) I have noticed some impact on traffic when I create DR groups (starting the mirror) and they are going through their initial full copy. This has mostly effected our VMware servers and our Database latency on the redo logs. What I do to minimize this is to only create one group at a time on any EVA pair. Once a group is finished and I move on to the next on the same pair I usually don't see an effect on the previously created groups, with the exception of Vmware, tend to see SCSI wait errors, but they are not constant and have not caused the VM's themselves to error out. I have had no issues with Windows/Linux physical boxes, I may see some paging errors right when I create the group but nothing big. We also have some VMS and have not seen issues there either.

When creating groups of Vmware or Database groups I go as far as adding members one at a time waiting for each member to full copy, and in doing so I add the redo log luns/vdisks last so they are exposed to this increased traffic the least. It may sound like overkill but by doing it this way I have been able to reduce the impact on our DB i/o which they are pretty sensitive about here. Once the groups are finished I have not had any issues with i/o due to them being in Synchronous mode when everything is connected up locally, which I assume is what you would be doing. So between that and creating these trouble groups off hours I have not gotten any complaints from our DBA's/Web admins.

As for the throttling I have not seen a way to do this manually. I have seen excessive i/o messages from the EVA and I believe it gives priority to non CA traffic and will throttle it if needed. I may be wrong on that, but that is my perception of how it is operating.

If you do this I would treat the groups as if I were doing real CA and keep things application specific, thus creating smaller groups, vs just creating on group of all vdisks, which you may not be able to do anyways based on what ever software version is on the older EVA's and the total size of you vdisks.

Hope that helps.

[Frank Andrews]

The EVA we are wanting to migrate from is an EVA 5000 running "SR0025vcsp-3110"

The client claims this was a very early model which was updated to this revision. The Cache is listed on CV EVA as:

Control cache: 256 MB
Read cache: 512 MB
Write cache: 256 MB
Mirror cache: 256 MB
Total cache: 1280 MB

Similarly to your configuration, they have Windows Servers, two or more ESX servers and I believe Unix hosted databases (I can clarify all this). The EVA is running at 2GB/s and they already 'feel' it to be performing slowly, partly due to the general loads on it and partly due to a very poorly thought out switch upgrade which means some hosts are bunched together on one switch with traffic going through a single ISL to the switch connected to the EVA (bottleneck!).

I was told by another user of this forum that Continuous Access was available as a evaluation download and lasts long enough to be able to migrate EVAs?

Anyway, you were talking about 'groups' on RSM. I'm not experienced with RSM at all, is a group basically 1 or more LUNS in a group that are being synchronised from one EVA to another one?

[T Downing]

Yes a group is one or more Luns placed in a group that are replicating to another EVA.

To use CA use create data replication groups, this can be done in Command View or RSM. If you are used to CV I would just use that. When you create a group you basically select the lun(s) you wish to replicate, the destination EVA, the destination disk group, what Vraid/redundancy the replicated luns will be (default is the same as the source), source log disk group and destination log disk group. The nice thing about doing this in RSM vs CV is that you can add multiple Vdisks to a group at a time, in CV you create the group and add on Vdisk, then you have to go to each Vdisk you want to add, click on the Data replication tab, then click the add member button.

Just FYI Per the software compatibility guide you can CA between the 5000 on vcs 3.1x to a 4x00/6x00/8x00 on XCS 6.X (what the 8100 will most likly be) on in Synchronous mode. But that should be fine for what you are doing.

Based on what little I know I would agree that the slowness is at least partly due to the switch layout then the EVA itself. The EVA should really be on the same switch as the majority of host using it, but you know that already.

What I would do is pick one of the windows physical boxes to do this first. Pick one that has a smaller lun or set of luns and create a group for that. Your biggest I/O hit like I said will be when the full copy is going on. The speed of the full copy depends on the size of the lun and how full it is. Once it is done, stop the I/O on the Windows box, delete the DR group (this will keep the Lun that was created on the 8100, then set up that Lun on the 8100 to be fed the Windows box. If you do them in small groups, one at a time, you should minimize the extra traffic vs waiting to switch till all the data was replicated. Does that make sense.

[McCready]

The short answer is that you only load a license to enable CA, and of course, the EVA's must be zoned to see each other via your switch.

If you are concerned with performance, I would only add one disk at a time to a DR group, and wait until it finishes the full-copy, so you can better control how long each "full-copy" period is. You can also try to use the EVAPerf performance tool to view various response-time stats, and do if off-hours.

The license is at least 30 days, if not 60. Hopefully, that would be enough time.

[Clint Placette_2]

There are some good resposense and there are some that are not correct.

CA migration is a complicated process. If there are custers it gets more complicated. You will need more then an overview because there can be many gotchas.

If you are running CV 7.x which you should get with a EVA 8100 you will get a CA, CV and BC temp 180 day lic.

You can watch the CA tunnels performance through Evaperf.

The only way to throtle CA is to suspend a dr_group or limit the amount of disk in a group.

For every single host I/O a CA will write 2 I/O's.

Since your target EVA is a 8100 you bottleneck will not be the target but mostly the the intersite link.


After you migrate you will need to add all the migrating host into the new EVA and eventually present the vdisk.

[Del_3]

Fist of all please assign points to these execelent responses.

I agree with T Dowling and Mr. Placette. I would just use the CV 180 day license for CA, but you can buy CA migration licenses ~7000.00 if you want.

One thing to add. Since you are not doing a DR failover the target vdisks (mirrors) are flagged read only. So when you break the DR group (Remove Member) and keep the remote vdisk the remote disk should be un-flagged as read only when you present it to the host.

Dont forget to unpresent the original vdisk first of course.

[Frank Andrews]

All, thanks for the great replies so far.

I guess I should be clear to explain, this migration is not going ahead yet, but we need to provide a migration plan to the client and this is why I was investigating CA.

Just to clarify an earlier point I made, the ISL is an inter switch link, not an inter site link, the EVAs will be in the same room. The bottle neck is on the EVA 5000 side, each of its two fabrics contain two switches that have a single link between them, meaning hosts on one switch are communicating through the single link to the other switch with the EVA ports on.

It may be possible that we can alter this set up prior to the migration, so there is no ISL bottle necking the fabric.

Can someone be explicit and confirm about CA/RSM please? Is it correct that its RSM that I would need to download and install and this contains CA? Also Mr Downing could you expand on your comments about log disks, do these need to be created on the EVAs as new LUNs?

To answer Clint, I don't believe any Windows clusters are used on this EVA, just Windows, Vmware, and some Unix.

Del, I always assign points when possible, I just didn't get any access to this forum until today.

[T Downing]

I got that the setup was an inner switch link, would definitely redo that whether you go forward with the EVA8100 or not.

CA is just a license like was said. You already have Command View so only RSM is a separate install, it will work if the CA license is activated as will the CA portions of CV, there is no extra CV components to install if you are using CA.

When you create a CA DR group a log, called a write-history log is created, this is part of the group creation process, you just have option of selecting what disk group is resides on if you have more then one disk group. You don't have to create vdisks for it, the process does that. They do not show up in your vdisk folder, they are shown on the log tab when you click on a DR group object. This log is used in Synchronous/Normal Asynchronous mode if the replication is suspended to store data (changes post suspend). It works a little differently if you are running Enhanced Async, but you won't be due to the 5000 controller software version.

[Uwe Zessin]

RSM (Replication Solutions Manager) is just a framework for automating CA and BC work through scripts. If your EVA is licensed for CA or BC, you are allowed to use RSM.

Honestly, for a one-time migration I would not invest a second into RSM. CV-EVA and maybe SSSU (the Storage System Scripting Utility) are sufficient for the task.