[ale] lvconvert adding mirror speed considerations

[Lightner, Jeffrey]

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