<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Replication performance EVA 8000 in HPE EVA Storage</title>
    <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149973#M57004</link>
    <description>Mel,&lt;BR /&gt;&lt;BR /&gt;I am afraid this is not described in the product documentation.&lt;BR /&gt;&lt;BR /&gt;One of the problem is that people beleive that FATA disks are just 'slower drives with a FC interface' which can be used if a server 'is not deemed that important'. I've been discussing this a few times with customers now.&lt;BR /&gt;&lt;BR /&gt;Quite a number of years ago I've talked to an engineer who did disk drive qualification on the EVA. He told me that the FATA disks (at that time) were quite robust. It appears that the situation has changed.&lt;BR /&gt;&lt;BR /&gt;In the mean time, HP explicitly discourages the use of FATA disks for the CA-EVA Write History Log (WHL) - CV-EVA was recoded. And writes in the EVA specifications:&lt;BR /&gt;""FATA drives are designed for lower duty cycle applications such as near on-line data replication for back-up. These drives should not be used as a replacement for EVA high performance, standard duty cycle, Fibre Channel drives. Doing so could shorten the life of the drive.""&lt;BR /&gt;&lt;BR /&gt;&amp;gt; Is it OK to have a FC vdisk replicate to a FATA vdisk&lt;BR /&gt;&lt;BR /&gt;What is the argument to have FATA at the destination? No high I/O requirements? What is supposed to happen if the source goes down and you have to fail over?&lt;BR /&gt;&lt;BR /&gt;&amp;gt; The DR group I added to in the case above already had&lt;BR /&gt;&amp;gt; a FC vdisk replicating to a FATA vdisk.&lt;BR /&gt;&lt;BR /&gt;Did you ever check the timing on that configuration? Maybe it was operating just before 'falling over the edge'.</description>
    <pubDate>Tue, 13 Jan 2009 18:33:44 GMT</pubDate>
    <dc:creator>Uwe Zessin</dc:creator>
    <dc:date>2009-01-13T18:33:44Z</dc:date>
    <item>
      <title>Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149968#M56999</link>
      <description>We have 2 x EVA800 SAN with Continuous Access replication. Today I added a 1TB vdisk (part of a 500gb FATA disk group) to a replication group. This was replicating to a disk group with 1060 free GB.&lt;BR /&gt;&lt;BR /&gt;After it started I received 1 "Excessive Vdisk response time at the DR Destination has been detected". I also received some "Copy resources on the inter site link have been reduced" errors and a couple of messages about alarm level reached on the disk group. Apart from this things seemed to progress OK if slowly.&lt;BR /&gt;&lt;BR /&gt;A couple of hours later severe reduction in performance was reported on at least one system using the destination EVA as its primary disk. This was using another disk group on this EVA.&lt;BR /&gt;&lt;BR /&gt;As soon as I removed this member from the replication disk group (leaving the destination vdisk in place) the issues disappeared.&lt;BR /&gt;&lt;BR /&gt;Is this likely to be caused by &lt;BR /&gt;1) The disk group on the destination EVA was too full&lt;BR /&gt;2) The writes to this disk group were overwhelming the controller&lt;BR /&gt;3) something else&lt;BR /&gt;&lt;BR /&gt;Any help appreciated</description>
      <pubDate>Mon, 12 Jan 2009 16:01:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149968#M56999</guid>
      <dc:creator>Mel Nugent</dc:creator>
      <dc:date>2009-01-12T16:01:59Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149969#M57000</link>
      <description>1) FATA disks are slow&lt;BR /&gt;2) If the replication is synchronous, slowness on the target EVA can affect the source EVA too&lt;BR /&gt;3) Could be that after trying to replicate a the changes to a 1 TB vdisk you're over the capacity of the link&lt;BR /&gt;4) This can be analyzed if you capture some performance data with EVAperf</description>
      <pubDate>Mon, 12 Jan 2009 16:51:33 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149969#M57000</guid>
      <dc:creator>Víctor Cespón</dc:creator>
      <dc:date>2009-01-12T16:51:33Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149970#M57001</link>
      <description>OK FATA is slower than fibre channel, but its a large disk group with 40 disk and the reduced performance was noted on Fibre Channel disk group.&lt;BR /&gt;&lt;BR /&gt;It was synchronous replication, but the target EVA showed all the performace hit. Is this possibly as it was writing when the other EVA was just reading? It was just doing the initial copy at this stage, it only got to about 35% of the initial copy.&lt;BR /&gt;&lt;BR /&gt;The link was probably using a lot of bandwidth but the performance problems on our systems were unrelated to that. They were definitely disk related&lt;BR /&gt;&lt;BR /&gt;I might try and recreate and run evaperf.</description>
      <pubDate>Mon, 12 Jan 2009 17:21:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149970#M57001</guid>
      <dc:creator>Mel Nugent</dc:creator>
      <dc:date>2009-01-12T17:21:26Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149971#M57002</link>
      <description>A slow FATA(l) disk group can block valueable space in cache memory and kill the entire array performance - I guess that's another reason that FATA(l) disk drives are now discouraged for the Write History Log (WHL).&lt;BR /&gt;&lt;BR /&gt;If you put a virtual disk from FATA into a Data Replication Group (DRG) with FC, you can slow down the FC I/Os, because the write ordering is preserved in the DRG and thus limited by the FATA I/O capability.</description>
      <pubDate>Mon, 12 Jan 2009 19:52:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149971#M57002</guid>
      <dc:creator>Uwe Zessin</dc:creator>
      <dc:date>2009-01-12T19:52:55Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149972#M57003</link>
      <description>Thanks Uwe, I'm not sure I understand all that but I'll have another read in the morning. But another question or two then. &lt;BR /&gt;&lt;BR /&gt;Where should I start for a little more reading, the EVA best practices white papers maybe?&lt;BR /&gt;&lt;BR /&gt;Should FC and FATA be always separate in DR. Is it OK to have a FC vdisk replicate to a FATA vdisk, for example in a DR group with no other members.&lt;BR /&gt;&lt;BR /&gt;The DR group I added to in the case above already had a FC vdisk replicating to a FATA vdisk.&lt;BR /&gt;</description>
      <pubDate>Mon, 12 Jan 2009 20:39:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149972#M57003</guid>
      <dc:creator>Mel Nugent</dc:creator>
      <dc:date>2009-01-12T20:39:58Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149973#M57004</link>
      <description>Mel,&lt;BR /&gt;&lt;BR /&gt;I am afraid this is not described in the product documentation.&lt;BR /&gt;&lt;BR /&gt;One of the problem is that people beleive that FATA disks are just 'slower drives with a FC interface' which can be used if a server 'is not deemed that important'. I've been discussing this a few times with customers now.&lt;BR /&gt;&lt;BR /&gt;Quite a number of years ago I've talked to an engineer who did disk drive qualification on the EVA. He told me that the FATA disks (at that time) were quite robust. It appears that the situation has changed.&lt;BR /&gt;&lt;BR /&gt;In the mean time, HP explicitly discourages the use of FATA disks for the CA-EVA Write History Log (WHL) - CV-EVA was recoded. And writes in the EVA specifications:&lt;BR /&gt;""FATA drives are designed for lower duty cycle applications such as near on-line data replication for back-up. These drives should not be used as a replacement for EVA high performance, standard duty cycle, Fibre Channel drives. Doing so could shorten the life of the drive.""&lt;BR /&gt;&lt;BR /&gt;&amp;gt; Is it OK to have a FC vdisk replicate to a FATA vdisk&lt;BR /&gt;&lt;BR /&gt;What is the argument to have FATA at the destination? No high I/O requirements? What is supposed to happen if the source goes down and you have to fail over?&lt;BR /&gt;&lt;BR /&gt;&amp;gt; The DR group I added to in the case above already had&lt;BR /&gt;&amp;gt; a FC vdisk replicating to a FATA vdisk.&lt;BR /&gt;&lt;BR /&gt;Did you ever check the timing on that configuration? Maybe it was operating just before 'falling over the edge'.</description>
      <pubDate>Tue, 13 Jan 2009 18:33:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149973#M57004</guid>
      <dc:creator>Uwe Zessin</dc:creator>
      <dc:date>2009-01-13T18:33:44Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149974#M57005</link>
      <description>I am also experiencing extremely slow CA performance with FATA disks. We have a lot of experience with CA and have seen this behaviour.&lt;BR /&gt;1/ CA FC to FC - very good no degredation of EVA performance&lt;BR /&gt;2/ CA FC to FATA - reasonable rates some degredation of performance&lt;BR /&gt;2/ CA FATA to FATA - forget it (20MB/s)&lt;BR /&gt;&lt;BR /&gt;I am trying to migrate two disk groups on a 2c12d EVA8100 (FATA) to a single disk group on a 2C18D EVA8000 (FATA) and it manages 1TB in 16 hours. I have 78TB to copy !&lt;BR /&gt;&lt;BR /&gt;I am only using CA to migrate a CDR network data copy from FC to FATA in two stages.&lt;BR /&gt;&lt;BR /&gt;I have some spare 146GB FC disks which I could install in a new extra group for WHL - will this help - should I do it at source or destination or both, how many disks would I need to make it get used (8,16,24...)?&lt;BR /&gt;&lt;BR /&gt;I lost a disk on the destination EVA disk group(88x1TB FATA). I replaced it and levelling is taking 24hrs to do 4% (25 days to complete. I have the latest disk code (HP05) and using XCS6200.&lt;BR /&gt;&lt;BR /&gt;Any help appreciated.</description>
      <pubDate>Tue, 03 Mar 2009 10:56:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149974#M57005</guid>
      <dc:creator>BAASANTEAM</dc:creator>
      <dc:date>2009-03-03T10:56:23Z</dc:date>
    </item>
    <item>
      <title>Re: Replication performance EVA 8000</title>
      <link>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149975#M57006</link>
      <description>Thanks for all the help.&lt;BR /&gt;&lt;BR /&gt;I have put this down mainly to not enough spare capacity in disk group.</description>
      <pubDate>Mon, 26 Apr 2010 10:17:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/hpe-eva-storage/replication-performance-eva-8000/m-p/5149975#M57006</guid>
      <dc:creator>Mel Nugent</dc:creator>
      <dc:date>2010-04-26T10:17:16Z</dc:date>
    </item>
  </channel>
</rss>

