What will happen with our thin provisioned LUN when it grows over 2tb?

[ginolard2010]

Long story short, I've been tasked with sorting out the mess that is our storage.  Every volume is a FlexVol, every LUN within each volume is thin-provisioned and those LUNs that are presented to our Hyper-V cluster have dynamically expanding VHDs on them.  This is a recipe for disaster already but my most immediate concern is one LUN in particular.

This LUN has a Size of 2198888778240 bytes (2047 GB) and SizeUsed of 2202995609600 (2051 GB).  It is presented an MBR Cluster Shared Volume.  What will happen to the CSV if that LUN grows again (say to 2.5TB).  How will the CSV react?

[columbus_admin]

I cannot see how it would be different than a LUN on a standard Windows server.  The system simply cannot allocate more usable storage to that volume, but Disk Manager should see the full size.  I did this mistakenly on an MBR partition to my backup server.  Diskpart and Disk Manager both saw 2.5TB, but only allocated 2TB to the volume.  The LUN should only grow in response to data requested to be placed in the LUN and as Windows simply won't know that more than 2TB is available, I would expect to see an "insufficient disk space message".

- Scott

[ginolard2010]

OK thanks.  I am trying to get my head around how to start managing this environment given that it's just been left to its own devices for a year.  I'm not a huge advocate of blanket thin-provisioning for every LUN but that's what I'm stuck with and now we have LUNs that have grown and grown.

Hell, we even have one aggregate of 8.7TB and the combined size of the volumes in it is 9.5 TB!!!  Madness.

[keitha]

Thats actaull not Madness but a good thing. It's actually very common in Virtual environments that are getting very good dedupe. It looks like the environemnt was configured correctly. You didn't mention but are the FlexVols reserved or are they Thin provisioned as well? If they are reserved then all you have to watch and manage is making sure the FlexVols have suffcient free space in them. If they too are thin provisioned then you have to watch the aggr and insure there is free space there as well. In virtual environments such as Hyper-V is is not uncommon to have a LUN that is twice as big as the FlexVol containing it, for example a 2TB LUN in a 1TB FlexVol, since Dedupe usually yeilds 60-70% savings.

What sort of Dedupe are you getting on these LUNs? How full is the FlexVol containing the LUN? How full is the AGGR?

Keith

[ginolard2010]

We are not using DeDuplication.  No, I don't know why not.

All FlexVols are Thin Provisioned.  This particular FlexVol is 88% full and the associated aggr is 66% full

[keitha]

OK, that is starting to edge on madness 😉 Why no dedupe? If everything is thin provisioned and you are on DOT 7.3 or newer you should be deduping those VMs. You would get gobs of space back. Any snapshots on the volumes?

Keith

[ginolard2010]

When the NetApp filers were first introduced here the knowledge within the team was practically zilch.  It's somewhat better now but it's been a "learn it as we go along" thing.  Now that we've started having problems (LUNS filling up and going offline etc) and I've been the most vocal critic of how it's (not been) monitored, I have been given the unenviable task of figuring out how to fix it.  I'm no NetApp expert and really only have a semi-decent understanding of how it works.

I've no idea why they didn't enable dedupe from the start but I can guarantee the reason they'll baulk at doing it NOW is the whole "ARRRGHH!  It deletes data?!?!? NO!" mentality. 

Looks like I have a hard sell to make.

[keitha]

I understand but the good news is you are not blazing any trails here. We have had Deduplication for primary storage available for 3 years now (ages in IT years) and thousands of customers are using it in production with now loss or corruption of data. The technology is as solid as they come.

If you like, direct message me with the details of your company or the system name of your NetApp, I can look at the autosupport and come up with a list of things you can/should do to maximize the performance and efficiency of it. Dedupe will definitly be one of them which sould net you back 60-70%

Keith

[adamgross]

Something to keep in mind.  2TB is the maximum size for an MBR partition, so you can't just grow it when you run out of space.  Even more dangerous than that in this particular case is that LUNs go offline when 100% full.  So...  your 2TB MBR partition fills to 100% and goes offline -- and you can't extend it to bring it back online.  That's all she wrote.  Roll back to a snapshot where the LUN wasn't full and hope that the data lost in the process wasn't important.

If for some reason this data has to remain on one LUN it's time to start migrating data.  Present a new LUN and partition as GPT to go above the limitations you're currently facing.

Resizing a cluster volume is the same painless operation of extending a single host LUN.  No downtime or IO interruption, just extend from the active node.

[columbus_admin · Accepted solution]

The LUN itself is not restricted to 2TB in size.  I had mistakenly created a backup LUN as 2.5TB and formatted it as MBR.  The only thing that occurred was the file system filled up, the server was sending out insufficient space reports, and the LUN remained online.  Diskpart and Disk Management both saw 2.5TB of space, but would only allocated 2TB of usable space, so the LUN can be expanded and brought back online, but Windows won't see any additional free space.

- Scott

[ginolard2010]

That's very kind but really not necessary.  We actually had someone come in this week to take a look at it and suggest improvements.  Dedupe is going to be one of them I think along with Thick Provisioning the volumes that are near full and migrating data off to bigger 3 & 4TB LUNS so that we can use GPT disks.

[ginolard2010]

Heh, did the exact same thing here.  We just created a 4TB LUN and presented it as a GPT disk, copied the data across and then deleted the old 2.5 LUN