This post is more than 5 years old
15 Posts
0
3662
VPLEX Local - Rebuild behavior issues
Hi All,
I'm working with a customer that has come across an issue doing local mobility of extents as part of a backed-end SAN hardware refresh.
Each virtual volume is a VPLEX Local RAID-1 device that has extents on two local Unity storage arrays.
The first round of migrations went as planned without any issues - the extents were being migrated, maintaining their 'thin' status.
On the second round of migrations there was an issue regarding the thin provisioning from the VPLEX point of view in that each extent that was migrated resulted in a fully allocated LUN on the Unity - I believe this was because the storage volume was not enabled for thin-rebuild therefore during the migration phase the 'new' extent became fully provisioned on the Unity back-end.
Not great, but what would be the best course of action to take next?
We have attempted to complete another 'third' migration, by taking the existing local extent and then migrating to another local 'thin-enabled' extent from the same storage array - this resulted in the operation completing without issue however there are now size discrepancies (if you look at the sizes of the LUNs on each backend system they aren't the same size) .
Even after a commit, there are still size discrepancies between LUN sizes on each Unity - is this a weird caching issue or a symptom that what we attempted to perform as a fix is not the correct approach.
Thanks,
Garth
galcomm
15 Posts
0
April 13th, 2018 13:00
Hi Romain,
Thanks for your message. We believed the issue only came about because one was an extent migration straight into a thin-enabled storage-volume and, the other was an extent migration into a thin-enabled storage-volume - of a previously migrated (but committed) extent migration into a thickly rebuild storage-volume.
Dell EMC so far have said that they believe that there is nothing wrong with what we have done and that the LUN size differences between each Unity system is nothing to be concerned about - however, I'm off to check the ETA list again!
Regards,
Garth
chrislogo
98 Posts
0
April 12th, 2018 05:00
Where both LUNs created at the same time ?
Was compression enabled on the LUNs at different times ?
I see these as pointers to size difference on the Unity LUNs if they are in cluster from the VPLEX.
rdauchy
4 Posts
1
April 12th, 2018 13:00
Hi,
I've seen the same issue on a migration i'm doing for a customer, i've local VV and put them into distributed VV.
I have 2 UNITY 300, source LUN is 2348 GB for exemple and new destination is 2346.5 GB (no compression, no thin enable VV on VPLEX) and i'm using thin rebui_ld to keep the thin state of my new LUN.
I've raised an SR about this issue because i've in mind the ETA where an inconsistancy apperead due to thin VV (but it was due to unmap...)
I will update this post with what EMC will tell me.
At this time, they confirmed for compressed volume the size and compression can be different because the compression was not done at the same time on the volume. That don't explain the small difference on "normal" LUN with no compression.
Regards,
Romain
galcomm
15 Posts
0
April 13th, 2018 13:00
Hi Chrislogo,
Thanks for your thoughts on the topic... my answers below:
Where both LUNs created at the same time ?
NO
Was compression enabled on the LUNs at different times ?
NO COMPRESSION/DEDUPE
I see these as pointers to size difference on the Unity LUNs if they are in cluster from the VPLEX.