|
So you all have probably heard the Netapp value proposition by now and why NFS, the technology that has been around for so long is now experiencing a resurgence.
While NetApp isnt the only NFS solution on the market, it sure is a compelling NFS solution and there are a myriad of blogs out there explaining why. From my perspective there are some interesting things that NFS does that really work well for VMware products. One of these is the whole thin provisioning thing.
I had a lengthy discussion with a number of people I know recently around thin provisioning and we came to the conclusion that "thin provisioning" on the storage level is fantastic and can add real value to a large scale deployment. Thin provisioning at the VMware level on NFS can cause quite a management nightmare. Let me explain why.
From a VMware perspective, when a new virtual machine is created on NFS the rule of thumb is that it is created as a "thin" disk. This in fact is not a VMware thing but a storage thing and is confirmed by this statement in the ESX 3.5 Configuration guide :
"NOTE The only disk formats you can use for NFS are thin, thick, zerodthick and 2gbsparse. Thick, zeroedthick and thin usually mean the same because the NFS server and not the ESX Server host decides the allocation policy. The default allocation policy on most NFS servers is thin."
Most people think that thin provisioning at that level is a good idea as well, and in theory it is. BUT lets not jump ahead so far.
It has been documented in numerous places, and here is another that when a virtual machine is migrated between storage (svmotion or cold migration) or deployed from a template it then loses it's thin provisioned disks.
If you wanted to keep it thin, you would then have to clone the disk back into a thin disk and reattach it to the virtual machine. I have heard of people scripting this but it does seem like quite a painful way to keep it thin. So from a management perspective, this can become quite a headache very fast.
Lets also take into consideration the management and the visibility of whether the virtual machine is thin or thick ? From a virtualcenter perspective it is always going to see the thin size on the datastore and if you have multiple end users deploying virtual machines that dont have visibility of the actual requirements for provisioning and the fact that the existing vm's have the ability to fill x amount of space that could also become a problem. Underprovisioning storage and over provisioning virtual machines - wow. But all of these management risks are mitigated with the right process and methodologies... Best laid plans :)
What about at the service console ? A LS command will show a thin disk up as its maximum allowable size and not the actual "thin" size, whereas a du command will show the thin size.
What about the latency involved with actually writing that first block and expanding the thin disk ? It's minimal but I guess for absolute performance die hards and mission critical environments it is also a consideration.
Lets assume you read all this and you agree with me that thin provisioning is good on a storage layer and maybe not such a good idea "at this time" on a VMware layer. Well how do we deploy thick by default on NFS ? Good question, and one I am still trying to get to the bottom of. When I do then I will share it, but if anyone has figured this out please let me know considering it is a NFS server setting.
|
