| HPE Storage Users Group https://www.3parug.com/ |
|
| 3Par and Appvolume Replication https://www.3parug.com/viewtopic.php?f=18&t=2725 |
Page 1 of 1 |
| Author: | AlexCS [ Thu Nov 23, 2017 7:18 am ] |
| Post subject: | 3Par and Appvolume Replication |
Hi guys, First off, I am a bit of a n00b when it comes to the 3Par as it was installed and configured by another company so go easy on me. I am having some seriously slow replication issues when replicating Appstacks from Appvolumes through ESXI 6 We have 6 datastores on two storage groups all on SSD storage as far as im aware. 3 on one called Standard and 3 on Performance. When an appstack is created it is put on one of the standard datastores. Once completed it will replicate across the other 5. When replicating it goes pretty quickly to the other 2 datastores on the same group, although not as quick as i would expect. The other 3 though take over an hour for 150GB. The templates on appvolumes are thin provisioned if that makes any difference. Hope that all makes sense? |
|
| Author: | Richard Siemers [ Thu Nov 23, 2017 2:21 pm ] |
| Post subject: | Re: 3Par and Appvolume Replication |
Doesn't entirely make sense yet... Are you sure your replication is storage based, meaning the 3PAR replication feature is being used? I am skeptical that the solution as described is using a VMware based replication like SRM or Zerto, or something. |
|
| Author: | AlexCS [ Fri Nov 24, 2017 4:13 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
Richard Siemers wrote: Doesn't entirely make sense yet... Are you sure your replication is storage based, meaning the 3PAR replication feature is being used? I am skeptical that the solution as described is using a VMware based replication like SRM or Zerto, or something. The replication is done through Vcenter requested by Appvolumes. All it is doing is replicating the appstack to the other datastores not a full datastore replication |
|
| Author: | MammaGutt [ Fri Nov 24, 2017 4:31 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
This can't be any type of 3PAR replication, so I would say with some certainty that this replicated with some form of host-based replication that either copy the data over the SAN infrastructure or the LAN infrastructure. What is your connection between the environments and what is the utilization on those? 150GB per hour is something like 400Mbps (~42MB per sec average). |
|
| Author: | AlexCS [ Fri Nov 24, 2017 5:28 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
MammaGutt wrote: This can't be any type of 3PAR replication, so I would say with some certainty that this replicated with some form of host-based replication that either copy the data over the SAN infrastructure or the LAN infrastructure. What is your connection between the environments and what is the utilization on those? 150GB per hour is something like 400Mbps (~42MB per sec average). No its not 3Par replication it is more like copying a VMDK to the other datastores. The 3PAR and the hosts are sitting right next to each on a 10gig network. Not sure on the utilization but i dont think it will be that high as there really isnt much going on there. |
|
| Author: | MammaGutt [ Fri Nov 24, 2017 5:56 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
So if you're getting 40MB/s doing copy from one datastore to another on a 3PAR that's right next to you, there is something very wrong. 40MB/s is what you would get from 1 NL drive or something. Since you mention 10Gbit I'm guessing you're using iSCSI.... That's always interesting to troubleshoot... Do you have a seperate infrastructure for that or are you using your standard switches? And which 3PAR hardware you got (model and drive type + number) and 3PAR OS version? From what I understand there has been iSCSI improvements in almost every version released the last 5 years. |
|
| Author: | Patrick [ Fri Nov 24, 2017 10:59 pm ] |
| Post subject: | Re: 3Par and Appvolume Replication |
Three things come to mind 1) Jumbo frames missing 2) IOPS policy is not 1 3) vDS in play and someone is playing with shaping, or someone needs to if another type of traffic is maxing the link. |
|
| Author: | AlexCS [ Mon Nov 27, 2017 6:23 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
We are using Fibre not iSCSI. We did a test moving a 10GB file from one datastore to another and it was very quick so the issues seems to be something between the 3Par/VCenter/Appvolumes |
|
| Author: | Patrick [ Mon Nov 27, 2017 9:27 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
Just playing devils advocate as this is an inherited environment but why would a given AppStack be replicated like that if the datastores supporting it are all flash? The point behind AppStacks (Appvolumes) is to reduce the number of copies of data. Generally when updating AppStacks, you'll technically 3 copies 1) Original version 2) in-progress version 3) New version in-progress dissolves itself at completion of the process and the original version goes away after everyone is off of it (possibly longer with retention periods). In any case, you just have one copy of a given version unless you are trying to spread the load across spinners or someone was trying to mix SAN storage with local datastores. |
|
| Author: | AlexCS [ Mon Nov 27, 2017 9:44 am ] |
| Post subject: | Re: 3Par and Appvolume Replication |
Patrick wrote: Just playing devils advocate as this is an inherited environment but why would a given AppStack be replicated like that if the datastores supporting it are all flash? The point behind AppStacks (Appvolumes) is to reduce the number of copies of data. Generally when updating AppStacks, you'll technically 3 copies 1) Original version 2) in-progress version 3) New version in-progress dissolves itself at completion of the process and the original version goes away after everyone is off of it (possibly longer with retention periods). In any case, you just have one copy of a given version unless you are trying to spread the load across spinners or someone was trying to mix SAN storage with local datastores. Well we have two VDI enviroments, one for CAD one for standard VM users. They both have a seperate data group Performance for CAD and Standard for normal VDI but they are both on SSD storage. Would we be better off having just one group with a single datastore for all of them? But it was setup but i very well respected guy from VMware a year ago, but i have found quite a few things that actually go against what VMware recommend in Appvolumes and other VDI systems he has been involved in so this could be another one to add to that list... |
|
| Page 1 of 1 | All times are UTC - 5 hours |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|