[ale] lvconvert adding mirror speed considerations

[Jim Kinney]

Nice work on a complicated project.

On March 3, 2017 11:44:18 AM EST, "Lightner, Jeffrey" <JLightner at dsservices.com> wrote:
>Just a quick follow up on this thread.
>
>We ultimately did the LVM mirroring for most of our Linux servers.  We
>use LVM for most things - we did have some Oracle ASM volumes that
>required separate Oracle procedures.    We also did migrations on
>various Microsoft Windows (mostly 2012) servers running Hyper-V
>clusters (with Windows and Linux guest VMs) and a couple of SharePoint
>cluster servers.
>
>Over we moved ~147 TB on multiple servers for our Hitachi VSP to about
>a quarter of that space on Pure Flasharray.   The latter uses a
>combination of compression and various deduplication methods to store
>the data.   Performance on the new array is noticeably faster even for
>the our main Production DB which previously used SSDs on the Hitachi.  
>
>
>Other than the fact that lvconvert ran slowly (up to 23 hours for ~7 
>TB where source had 48 PVs and target had just 7 x 1 TB PVs) this
>worked well for us and we had no downtime caused by the migrations.   I
>did notice that on a similar sized DB that was alone on its server this
>only took about 15 hours.     I also saw that if I kicked off 2 of the
>~7 TB copies on the same Test/Dev server the combined operation would
>take about 33 hours which means combining them made each take longer
>individually but combined saved about 13 hours.
>
>A couple of minor issues we did see were related to the fact we were
>doing Hitachi disk copies (Shadow Image - this is the equivalent of EMC
>BCV wherein the array itself syncs mirrors which are then split off and
>mounted on other servers). 
>1) When the nightly shadow image kicked in while LVM mirroring was
>still running it did cause performance degradation which made sense in
>retrospect given the number of commits this caused.
>2) The shadow image disks after split refused to mount on the alternate
>servers because the split PVs included information about the LVM
>mirrors that was true for the source but not for the target servers.   
>This was easy enough to rectify but did mean I had to be up in the
>middle of the night.
>Neither of those caused us much pain but are things to keep in mind
>when planning this kind of activity.
>
>The Pure Flasharray does snapshotting rather than full copies like EMC
>BCV and Hitachi Shadow Image.   Even though we're using snapshots now
>we see no performance impact because there is almost no read penalty
>from flash like there is for spinning disks.   (In the past we'd stayed
>away from EMC and Hitachi snapshots for our main Production copies
>because of this read penalty as pointers from the separately mounted
>disks would still be reading from the live Production.   In one past
>job they'd implemented EMC snapshots and one of my first tasks on being
>hired was to replace that with BCV because of the performance hits
>seen.)
>
>
>-----Original Message-----
>From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
>Phil Turmel
>Sent: Friday, December 02, 2016 9:48 AM
>To: ale at ale.org
>Subject: Re: [ale] lvconvert adding mirror speed considerations
>
>On 12/01/2016 06:16 PM, Lightner, Jeffrey wrote:
>> pvmove had been my first thought but we got a vendor recommendation
>to 
>> do mirroring instead because if something bad happens in the middle
>of 
>> the mirroring (e.g. a reboot) one can resume the mirror but might
>lose 
>> data if it were a pvmove.
>
>Crashes or reboots shouldn't be a problem.  pvmove thoroughly
>checkpoints its actions stripe by stripe.
>_______________________________________________
>Ale mailing list
>Ale at ale.org
>http://mail.ale.org/mailman/listinfo/ale
>See JOBS, ANNOUNCE and SCHOOLS lists at
>http://mail.ale.org/mailman/listinfo
>
>_______________________________________________
>Ale mailing list
>Ale at ale.org
>http://mail.ale.org/mailman/listinfo/ale
>See JOBS, ANNOUNCE and SCHOOLS lists at
>http://mail.ale.org/mailman/listinfo

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.