Today I thought I'd address a topic I've had many questions about in the past. The mystery behind VMware View's Linked Clones. The technology is based upon their snapshot technology and is quite ingenious! It is very storage efficient, creates clones fast and is easy to manage. Unfortunately we started to see problems in the field when a large number of Linked Clones were deployed. The controller would be getting slammed and as a result the customer's desktops would suffer.
The first I heard of the problem I was new to VDI and was told Linked Clones are misaligned, so I created a bunch, logged into a Windows 7 clone and ran an "msinfo32". Nope, divisible by 4096, not misaligned! I was told it's not the master image that's misaligned, but the "delta" disk. What's a "delta" disk?! The delta disk is where all of the changes a user makes to their desktop get stored. Since the master image is read-only, writes get written to the delta disk. Now this is the part that didn't make sense to me. The delta disk is NOT misaligned, what happens is it can write data as small as 512 bytes. Now this wouldn't be a problem if every write Windows did was 512 bytes, but it's not. You get a mix of 512, 4K, 16K, 32K, etc.
Data ONTAP WAFL blocks have 4K boundaries and if Windows wrote everything in 512 bytes, everything would be cool!(8 512 bytes make up 1 4K). Here in lies the problem. Say I'm writing to the disk, I write 512 bytes of data, that data is aligned, no problem! Okay, but the next chunk of data I write is 4K. Ugh oh! It won't fit because I only have 3584 bytes left, so I need to carry over the last 512 bytes from the 4K write to another 4K block which requires additional I/O. Now I go and read that 4K of data and instead of being able to read just one block, I now have to read from two because the data was split over two NetApp 4K blocks. You got it, more I/O! Take a look at the picture, it should help.
What I've drawn is 512 bytes of data being written. Next 4K of data and you can see that last 512 bytes gets written to a brand new NetApp block. And last I write 1K of data. If I access that 512 bytes of data or that 1K of data, no problem. The problem is larger chunks of data that can get truncated and placed onto multiple blocks which will increase I/O when it's written AND when it's read. Is this behavior unique to NetApp? Nope, it will effect any storage vendor that doesn't use 512 bytes as their block size.
So what can be done about this? In vSphere 5.1 , VMware introduced a new filesystem format called SESparse. VMware View 5.2 is the first VMware product that uses the new SESparse disk type. SESparse has a couple of functions, it can clean up unused space in clones, but what really excites me is the smallest chunk of data it can write to disk is 4K enabling the delta disk to stay block aligned!
Here I have another 512 byte chunk of data being written to disk, and than it jumps to the next 4K boundary and is ready to write the next chunk of data, which I've drawn as 4K. This does use a little more space, but this will help immensely if you're having performance issues due to the partial reads and writes. If you're okay with traditional Linked Clones, you don't need to use SESparse, you can stick with VMFSSparse. There are also some caveats to look out for, so check the VMware site for best practices.
I hope this helped clear up some of the confusion around Linked Clones and why I'm excited about the new version of View!
Until Next Time!
No comments:
Post a Comment