HPE Storage Users Group

Hi all,

did anybody establish a policy for regular unmaps on all VVs with the ESX admins?

It's one of thos fridays again: Taking an export from vcenter with all datastores (Names, Identifier, Cap and Free), preparing the same via 3PAR-CLI, throwing out all secondaries, native server etc, aligning SCSI-IDs, and calculating the delta between "Used Capacity ESX-View" versus "Used CApacity 3PAR-View". On most vvs, 3PAR sees lower usage. If there are vvs where 3PAR sees more usage (and there always are some), these are the data stores on which UNMAP makes sense.

This includes a lot manual steps, especially as our ESX and storage boxes live in separate LAN-segments and can't "see"each other. Nor could any script...

So the question is: Is it sensible or usefull to establish a policy for regular unmaps on all data stores? How? Hit every ds once a quarter?

Thank you,
apol

_________________
When all else fails, read the instructions.

This is a topic I'm very interested in as well. In my case I am the VM admin and the 3Par admin. We are in the beginning stages of moving our entire VMware workload over to some 7440's running peer persistence and TDVVs. I too am concerned about how I am going to manage space...how I'm going to reclaim it...and how best to automate it.

We currently have a VDI environment running TDVVs on 7450's. My concern with automating unmaps is that if I run an unmap on 3 different datastores by 3 different esxi hosts I can see my average latency across the whole array go from 1ms to 10ms. Granted this is not the end of the world speeds here but doing this across an array with a much greater workload may cause issues. So I guess you could script one at a time but doing this in off peak hours (we are 24/7 shop) across 300+ datastores may be difficult to schedule and might not be worth the effort.

At this time my plan is to monitor the datastores and make sure I do manual unmaps on datastores that show less usage than the 3par reports. This isn't by any means a long term solution but I think the silver lining in the clouds is that with vSphere 6 and the introduction of VVols, this will make unmaps almost unecessary...at least in the case of deleting a VM. The array will get those blocks back right away.

Now can I ask, do you schedule "compact CPG's" and other tasks like that right now? If so do you use the 3par to schedule it or do you have an enterprise scheduler/worload product?

Generally, you shouldn't need to schedule a regular compactcpg. This is a task that will be done in the background by the array periodically, and a compactcpg task just serves to make it happen right away.

As far as a regular thin reclaim, unless your doing thin on thin (thin VMDK on a 3par TPVV/TDVV), I can't honestly see the benefit. The reason is that a thick VMDK takes up a certain amount of space, and it'll never be included in a reclaim initiated from VMware.

There are bigger issues with doing regular reclaims in that they can

A) impact performance while they are running (which is why VMware removed the automatic UNMAP)
B) Cause a large amount of array fragmentation

For example, I have two 60TB 7200's, that run at about 75% capacity. Unless I have servers that I know for a fact are constantly deleting old files and writing new files, I rarely run reclaims unless I decommission and delete a large VMDK, and when I do I'll do a host based reclaim (sdelete in windows) versus the VMware based UNMAP. The reason is that if I nickel and dime the array for every last GiB, I'm just going to end up fragmenting the array horribly. It's better to leave it, and let the array take care of it's own business, and when I have 500GiB or more to be reclaimed, that's when I'll run the reclaim.

mitchellm3: yes, we scheduled a daily (monday through saturday) compactcpg, and a weekly tunesys on saturday morning.

Schmoog: Every "Best practice" document from HP regarding 3PAR (like 4AA4-4524ENW) says "Best practice: When using thin provisioning, schedule regular CPG compactions during low activity periods." I never saw a compactcpg occur without us starting it. There are a lot of other automatic activities of course - defragmentation, check slow disk, remove expired vvs, etc...

When build as "eager zeroed thick" as advised in the bp-guide, thick vmdk on tpvv makes A LOT of sense - and does only take up a very small amount of space.

Talking 'bout fragmentation - 3PAR stripes all data over all discs, so what do you mean with fragmentation?

Even with UNMAP, we have problems with reclaiming the space 3PAR-wise: We see "User Used" decline as soon as UNMAP starts, but on our well-filled and maxed out V400, it literally takes months until the not-user-steerable garbage collection reduces the "user reserved" space and returnes the GBs to the global or cpg free pool. And we're talking about approx 10TB!

_________________
When all else fails, read the instructions.

Compactcpg happens as part of AO so if you have AO scheduled there's no reason to schedule it separately.

that depends on how AO is run. if it runs default, yes, but you can also run it with e.g. -trimonly and then no full compactcpg will be run after ao is finished.

_________________
The goal is to achieve the best results by following the clients wishes. If they want to have a house build upside down standing on its chimney, it's up to you to figure out how do it, while still making it usable.

^^^ this. I run too close to our used limit thresholds to wait weeks/months for the free to be returned. For VMware, it is easier for us to just migrate the VMs to a new DS and remove the old.


I run a custom script each weekend that compacts each CPG one at a time (on each frame) because again I can have instances where I will have 1TB or more sitting free in a CPG and AO doesn't trigger a compact CPG.