HPE Storage Users Group
https://3parug.com/

Migrating to 3PAR 8440, Data reduction questions
https://3parug.com/viewtopic.php?f=18&t=2975		 Page 1 of 1
Author:  Dave338 [ Fri Sep 07, 2018 4:23 am ]
Post subject:  Migrating to 3PAR 8440, Data reduction questions
Hello, I'm migrating data from a EVA P6550 to a new 3PAR 8440 "all flash" (20x1,92TB SSD)

From scratch the array reserver about 4TB for itself... OK.

I've moved some VM (mixed) data to new LUNs in the 3PAR. About 55 VMs (vsphere), with file server, mail server, and other general use servers. All convertible data to 16kb block has been migrated with VMWare converter. Not file server yet, but the two DAG mailbox server of 1,5TB each yes, to 64kb block), and lots of other machines.

Capacity summary says that
Private base 4.201 GiB
Private snap 5 GiB
Shared 1.700 GiB
Free 43 GiB

Capacity efficiency says that
Compaction 1.8:1
Data reduction 1.5:1
Compression 1.2:1
Deduplication 1.3:1
Total 5.949 GiB

I ommit compaction, because I think it's related to thin provisioned luns, but data reduction is 1,5:1.. I asume that's the real benefit in disk with dedup+compresison (all LUNs with d+c in same CPG RAID6 8+2)

So my concern is that data reduction was 1,9:1 when I started moving general servers (several Windows versions, but majority of 2008R2 and 2012R2). ThenI started moving mailboxes and another SQL servers with bigger data, and I was expecting the dedup/compression ratio to increaseg (3TB of almost duplicated data in 64kb blocks), but it started to go down until the 1,5:1 you can see.

My first question: Is there any job related to scrubbing, garbaje or similar, that can reclaim space of unused blocks??? (if really there are many of them)

And second one: How can I get better ratios?? I converted mailboxes to 64kb because this is Microsoft recommendation for database disks (original machines where at 4kb), but maybe going to 16Kb is a better aproach.

bonus: If I convert again a mailbox from 64kb to 16kb inside the 3PAr, will this generate lots of dedup garbage if new blocks are different??? How can I clean old-unused blocks (like in 1st question :) )???

If any of this doesn't make sense, probably is my english skill, heheh

BR.
Author:  MammaGutt [ Fri Sep 07, 2018 7:43 am ]
Post subject:  Re: Migrating to 3PAR 8440, Data reduction questions
Not sure wherw to start... 4TB is most likely spare capacity + admin volume + srdata.

Changing from 64kB til 16kB will not make any difference as 64kB is a multiple of 16kB. The intention with 16kB is that you don't get an offset in the blocks.

Also remember that dedupe and compression ALWAYS depends on the data. If it is all unique data and it is alreasy stored in a compressed form you will get zero benefit.

Not sure which 3PAR OS version you are running, but there is a big change with CPGs created on 3.3.1 (and later) when it comes to reclaim.

Data reduction = dedupe + compression
Compaction = data reduction + thin provisoning.

How are your VMDKs and which VMFS version are you running?
Author:  Dave338 [ Fri Sep 07, 2018 7:56 am ]
Post subject:  Re: Migrating to 3PAR 8440, Data reduction questions
Sorry for the missing data, I thinked it, but I didn't write it :lol:

The OS is 3.3.1.410 (MU2)+P30,P32,P38, updated two weeks ago by the HP team.

Array was completely empty, I started deployment after upgrade.
My vsphere versión is 5.5 at the momento, migration to 6.5 is planned but not urgent at this moment, so all datastores are VMFS5

VMDKs are quite all thin provisioned (except one old Microsoft cluster that need thick eager zeroed shared disks tu run in virtual mode.

BR.
Author:  MammaGutt [ Fri Sep 07, 2018 9:47 am ]
Post subject:  Re: Migrating to 3PAR 8440, Data reduction questions
With VMFS5, all VMDKs should be eager zero thick.

Did you read the 3par vmware implementation guide? There is a SATP rule there which can make a huge difference performance wize.
Author:  markinnz [ Sun Sep 09, 2018 4:58 pm ]
Post subject:  Re: Migrating to 3PAR 8440, Data reduction questions
Dave338 wrote:

Array was completely empty, I started deployment after upgrade.
My vsphere versión is 5.5 at the momento, migration to 6.5 is planned but not urgent at this moment,

BR.


Don't forget vSphere 5.5 goes end of general support on the 19th of September :-)
And vsphere 6.5+ in combination with 3PAR OS 3.3.1 has lots of useful things to try and keep things thin.
Author:  Dave338 [ Mon Sep 10, 2018 2:26 am ]
Post subject:  Re: Migrating to 3PAR 8440, Data reduction questions
MammaGutt wrote:
With VMFS5, all VMDKs should be eager zero thick.

Did you read the 3par vmware implementation guide? There is a SATP rule there which can make a huge difference performance wize.


Do you mean Round Robin with IOPS=1?? It's already implemented.

markinnz wrote:
Dave338 wrote:

Array was completely empty, I started deployment after upgrade.
My vsphere versión is 5.5 at the momento, migration to 6.5 is planned but not urgent at this moment,

BR.


Don't forget vSphere 5.5 goes end of general support on the 19th of September :-)
And vsphere 6.5+ in combination with 3PAR OS 3.3.1 has lots of useful things to try and keep things thin.


I know, I'm going to 6.5 ASAP. So because I'll need to créate new Datastores and format then in VMFS6, then I should migrate VMDKs to thick eager zeroed?? I can do it with storage vmotion without interruption.

BR
Author:  MammaGutt [ Mon Sep 10, 2018 3:13 am ]
Post subject:  Re: Migrating to 3PAR 8440, Data reduction questions
VMFS5 = EZT
VMFS6 with unmap enabled = Thin
Page 1 of 1 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/