HPE EVA Storage
1845707 Members
4331 Online
110247 Solutions
New Discussion

Re: continuous access problem

 
SOLVED
Go to solution
hakam
Occasional Contributor

continuous access problem

Dear all

I have two EVA3000 storage, one in HQ site and the other in DR site.HQ and DR sites are connected by 2 links each is 2Mb/s using two MDS9216i fiber channel switch in each site(using FCIP). the firmware of EVA3000 is VCS3.028.

1- when I start data replication I see in command view interface only one connection instead of two where they should work together as load balancing.

2- while data replication is resumed in asynchronous mode and I start a copy process at the server it takes too long time. for example when I copy 180MB files it takes one second when data replication is suspended. but when data replication is resumed it takes 10 minutes.

I need to do data replication without affecting the server performance. at the same time improve the data replication speed using two connections.

thanks

 

 

P.S. This thread ahs been moevd from General to Storage Area Networks (SAN) (Enterprise). - Hp Forum Moderator

4 REPLIES 4
Jonathan Harris_3
Trusted Contributor
Solution

Re: continuous access problem

1. EVA 3000s only send their CA traffic out of a single port (Top controller, port 1, I believe). Therefore, you'll only find CA traffic flowing through one switch.

To use both pipes, you'd need to run both 2 x 2Mb/s out of that MDS9216i and then portchannel them to aggregate bandwidth (although this is a moot point - see below).

2. There are performance issues with CA in async mode, but your primary issue is one of design.

CA replication is continuous block-level replication. Every time you make a change to a file on a server, the block of data that it's residing on gets replicated. Uncompressed. You start copying 180MB and all the blocks have to be replicated to your remote site.

Now, your servers are probably connected with 2 x 2Gb/s connections. That gives you a maximum theoretical throughput of 2000Mb/s (v3.028 is active-passive) per server. But you've currently only got 2Mb/s to transport your replicated traffic. Can you spot the bottleneck?

Really simply, how fast can you send 180MB down a 2Mb pipe?

That's why you have problems and will continue to do so, even if you do aggregate your bandwidth to 4Mb.

hakam
Occasional Contributor

Re: continuous access problem

hi

is there a way of buffering data so that it will not affect server performance.

in XCS6.0 there is enhanced asynchronous mode but in VCS3.028 it is not found.

is there a new firmware version for EVA3000 that use enhanced asynchronous mode

thanks
Ricardo Rocha
Valued Contributor

Re: continuous access problem

Hi

Enhanced asynchronous mode is only available for EVA with XCS6.xxx. For EVA 3k/5k there are no fw with enhanced asynchronous replication. Even if you build a CA with a EVA3k and a EVA8k, you'll have to use simple asynchronous replication. The main difference between these modes are the location and space for the data buffers. XCS 6.0 puts these buffers on disks, while on the old EVA's they're located only on the cache (less space).

Best regards,

Ricardo
"there is this old man who spent so much of his life sleeping that he is able to keep awake for the rest of his years"
Jonathan Harris_3
Trusted Contributor

Re: continuous access problem

Buffering already takes place in async mode, but it's only capable of so much (about 32MB, off the top of my head). The issue is, that in order to retain data integrity, once about 30MB of that cache is full, CA will automatically switch to synchronous mode.

This cache copes with small peaks in traffic, but nothing sustained. So, as long as you don't overwhelm your replication pipe regularly, you'll be fine. Unfortunately, for you that means keeping your servers' I/O throughput really low - anything sustained over 4Mb/s will kill your local performance.

By the way, upgrading to EVA 4/6/8x00 with enhanced async is unlikely to help you that much. All that does is increase the buffer size by writing to disk rather than cache. If you've got any kind of throughput on your servers, that will just give you a bit more time before your buffer fills up. After that, you're back in exactly the same place.

If you're considering using CA over FCIP You really need to assess how much traffic you're going to be replicating and increase your bandwidth between sites accordingly.