Just a brief question about Unity and VPlex regarding thin-provisioning/rebuilds.
When adding the storage array into VPLEX it shows and thin-capable: false and by default claimed storage devices are thin-rebuild: false (although you can change this setting) - does this sounds correct??
The hardware is VS2 running GeoSynchrony 5.5.2.02.00.03 in a MetroCluster configuration with locally connected Unity 400 (126.96.36.19957522) arrays at each end. Being that the Unity platform uses thin provisioning by default I would have though that the storage devices should be thin-capable: true? and fully support thin-rebuilds?
The VIAS support for Unity is (afaik) only fully supported in the 6.x code therefore I'm not sure if this would help or not? and for the VS2 platform the 5.5.2.02.00.03 was still the target code release so am hesitant to try-and-see on this production system.
The use case for this system is to be part of a vSphere Storage Metro Cluster therefore obtained maximum storage efficiency is important.
Thanks in advance for any suggestions/advice,
> When adding the storage array into VPLEX it shows and thin-capable: false and by default claimed storage devices are thin-rebuild: false (although you can change this setting) - does this sounds correct??
Yes, this sounds correct because thin support for Unity volumes were added as of 6.0 SP1 release, and so because you're on a 5.5 version support doesn't exist there.
VIAS and thin-capable (UNMAP support) should be thought of two independent features or product sub-areas, one isn't necessarily required for the other, or tied to each other in any way.
I would suggest 6.0.1 Patch 4, which includes a lot of stability fixes. You might want to wait until it reaches target code since it was released just last month (Aug 2017).
Many thanks for your reply and suggested versions.
Just to clarify, if we stayed at the revision level we are currently using until a 6.x was a target code release for the VS2 hardware - would my understanding of the following behaviour be correct ???
Scenario: Assuming a new 50GB thin LUN on Unity and presented to a VMware Metro cluster via VPLEX Distributed Device (finally then formatted as single datatore using VMFS):
1) Fill Datastore with 50GB thickly provisioned VM and then delete the VM - would still show as consuming 50GB on each Unity even after VM is deleted. This is because VMFS now states Datastore empty, Unity says LUN space has been fully allocated from pool for that LUN and wont be returned to the pool.
2) After point 1 above - I take it that even though the Unity boxes now believes the LUN is fully allocated as long as the Datastore VMFS filesystem believes it is empty then I could immediately then create another 50GB VM in the now empty (but allocated) disk space.
In other words, so long as you always have enough pool space to fully allocate the LUNs - although not ideal - you shouldnt run into any issues and just treat each presented thin LUN as if it were thick. I've not included VPLEX logic in any of my scenario as I believe it will just treat it all as thick and just pass through the requests.
Thank for any further advice and feedback,
how is unity zoned to the VPLEX?
While Zoning VNX to VPLEX , we reduce the number of paths seen by VPLEX by unchecking few initiator paths in engineering mode.
how do we do the same in Unity?