LiquidObject

Diskeeper 12 & Space reclamation

After running with all of the features enabled on a VM for a week I noticed that Forefront started to pickup random viruses being written to the root of the C-drive. Every time the filename was BzEngineTempFile followed by some number and a .dk file extension. After some digging the Space Reclamation feature within Diskeeper is actually writing temporary files with all 0’s to the root of the volume where Space Reclamation is occurring. However antivirus products (Forefront & McAfee have been confirmed so far) trigger a random virus as the source.

, , ,
June 19, 2012 at 6:39 am Comments (0)

Diskeeper 2012 First Look

Diskeeper 12 (aka 2012) has been released to existing customers under active support contracts.
  
Upon first launch you’ll be greeted with a new splash screen which makes you wonder if this is really the “re-branding” version.
      

      
After the initial splash screen the normal What’s New dialog is present.
  

      
As you can tell things are starting to look a bit different. The home screen has been completely redesigned.
  

      
In general what is being present in the volume summary is similar to what it was before but it a simplified view. What you’ll also notice is the option to “Reclaim Space”, this will zero out any used blocked on the volume. Which in a virtual environment can be a really BIG DEAL!!! That being said you must being running thin provisioned VMDK’s on thin provisioned LUNs. This part is pretty straight forward the last piece to make your life is the availability of the SCSI UNMAP command being supported by your storage vendor otherwise you need to perform manual storage vmotion’s to LUNs of different block sizes to reclaim any inflated space.
  
In the time I’ve used it since install system resource usage has been about what is was with previous releases and so far has shown no performance issues as of yet. I’ll post a followup to this post after I have some time to test out the reclaim space functionality a bit more.

 

, , ,
June 4, 2012 at 1:14 pm Comments (0)

V-Locity 3 with Thin on Thin provisioning

Within vSphere 4.x and later (through the gui) thin provisioned VMFS volumes are an option. For those who have shared storage many storage providers also provide the option to provide Thinly provisioned LUNs. So it is foreseeable one could provision a 100GB VMDK thinly on a 1TB thinly provisioned LUN but then if the VMDK is only using 1GB then the LUN should be using close to 1GB of data assuming it is not blown out by data usage.

The Test

For testing purposes I’m using a 60GB thinly provisioned VMDK with approximately 50% fragmentation (10k files with 90k fragments) . With using vSphere 4.1 Update 1 and a HP Lefthand P4500 cluster running SAN I/Q 9.0.

Diskeeper has a product called V-Locity 3 which is suppose to offer great defragmentation options for the Thin on Thin world. The question is does the boat hold water?

Well after testing a number of LUNs there are some truth to it’s functionality and some dead weight. When looking back at the physical world with Windows Server installed on bare hardware Diskeeper Server Edition works at both preventing fragmentation to a point and defragmenting. When we look at VM’s instead Intelliwrite (http://www.diskeeper.com/blog/post/2009/11/20/Inside-IntelliWrite-technology.aspx) everything still works as expected. When looking at the automatic defrag feature, we then balloon out the volume and if left to run 24×7 would fully balloon the volume.

This is where V-Locity is suppose to step in where you take Diskeeper Server falls short for virtual servers. Be for-warned Diskeeper Administrator is required to gain full functionality of software to take advantage of (V-Aware and CogniSAN to prevent over utilization of the given VM Server or SAN). While there are some other features the one feature I was looking at in particular was the Automatic zeroing of free space

Automatic Zeroing of Free Space is an interesting feature basically offering their version of sDelete.exe at a file by file level. By design you are suppose to run the automatic defrag feature during a relatively idle period in the datacenter and the rest of the time the Automatic zeroing will reclaim the space used. If and only if a storage vMotion to a different block size occurs the space will really be reclaimed.

So as expected it does work but I would check your cost/benefit analysis before buying V-Locity for the entire enterprise. When looking at my every day production environment, I can only see three or four heavy usage systems actually benefiting significantly from this software. While the rest would run the regular version of Diskeeper Server purely for Intelliwrite.

vSphere 5.0

Now what about all the talk of vSphere 5 adding in a new version of Array Integration (VAAI) which takes care of the reclamation without a vMotion? Well, it’s there but as it currently stands there are two big issues with it:
1) VMWare has published KBs instructing everyone to disable it due to performance issues. (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007427)

2) Some SAN appliances don’t support the new feature – which is my current problem

As for number one, test and see how bad the performance hit is in a lab environment first before trying it in production. Technically I don’t see why the features is recommended to be just disabled, you could have the feature disabled except during some scheduled times enabling it for a few hours at a time allowing at least a partial benefit from the feature.

For number two, start leaning heavily on your SAN providers to provide the functionality. As of this writing SAN I/Q 9.5 doesn’t support disk space reclamation (sometimes referred to as UNMAP). Hopefully this feature it will be out in the next release in a production environment scripting out the creation of LUNs to perform a storage vMotion to then finally performance destroy the existing LUN requires heavy I/O load on the SAN and an ugly solution for automation.

Conclusion

For myself I find this the biggest deal-breaker with the software isn’t the software itself as it works as designed. Unless the entire stack supports reclamation as a whole the product is *nice* but not worth it in large deployments and time consuming in small deployments.

, , , , , , ,
December 27, 2011 at 11:44 pm Comments (0)