VMWare block size for file server

[gshaw]

I'm moving our file server onto virtual soon as part of a shake-up of the folder structure generally but it poses some interesting questions on how best to store the VMDK files...

 

We're not on vSphere 5 yet, waiting for newer version of Veeam first (and potentially an update pack for VMWare) so that means I've got the block size of the VMDK file to think about. If I do 1MB then it's max 256GB for the VMDK file, which is a bit tight as one of the shared folders I'm moving is ~200GB at the moment (splitting up the 600GB physical server into 2-3 VMs to spread the load).

 

Then question is whether it's worth making a store with 4MB (or even 8MB) block size when vSphere 5 is so close that can use 1MB for any datastore size you want, although that relies on waiting for the releases above and a bit of work doing the vSphere 5 update.

 

Any thoughts from the VMWare users on here?

[CyberNerd]

smaller files use more space witha larger blocksize, so diskspace the only real disadvantage. I'd go for 2M if thats what you need.

[riffleman]

As the block size is set when you create the datastore, I would wait until you've implemented vSphere 5. You're only going to be duplicating the workload by moving before then.

[andrew-virtusolve]

Go for whatever you need in terms of single file size 2MB block files will allow you to create 512GB files, however be careful when creating your virtual disks - DO NOT use the maximum size available as you will not be able to snapshot (which Veeam will require to perform backups through the vStorage API)

 

Upgrading your VMFS datastores to version 5 (from version 3) when you update is VERY simple though (regardless of the current block size):

 

Upgrade_to_VMFS_5.swf

 

Note that the block size remains following the upgrade, to revert to a 1MB block size requires deleting and recreating the datastores

Edited November 7, 2011 by andrew-virtusolve

[gshaw]

Thanks for the input, for some bizarre reason 2MB didn't even register with me, was only thinking 1MB, 4MB or 8MB

 

Was either going to do 500GB thin or keep the size down lower at 250GB and extend if \ when required (chances are it won't need it but prefer to be able to expand up to ~512GB than have a low limit of 256GB that could get too tight)

 

As for the VMFS upgrade, main reason I'm holding back is Veeam as the patch for the current version seems to have a few side effects and would prefer to wait for the new version that's been designed for vSphere 5 rather than patched up to make it work.

[andrew-virtusolve]

Not too sure on the side effects, but we are running Veeam 5.0.2.230 on at least 5 clients who are running vSphere 5 with very few issues??

 

Extending the virtual disks on the fly works well on 2008 and above, not so well on 2003 because of contiguous space on disks, you may need to change the disk type to Dynamic other than basic and that will affect File Level Restores in virtual backup (certainly does on quest vranger, not tried with U-AIR on latest version of veeam yet)

[gshaw]

Only reason I felt a bit paranoid was this from Veeam on the email susbcription

 

 

There were couple of common issues reported by customers who had applied Veeam Backup & Replication vSphere 5 compatibility patch which can both result in reduced job performance, so I wanted to give you heads up.

 

Most customers choose to upgrade to vSphere 5 along with applying said B&R patch. However, it seems that certain strategies our customers employ to move VMs to vSphere 5 brake CBT data on some VMs. Veeam B&R detects CBT data inconsistency, and fails over to legacy "snap&scan" method of determining incremental changes, which is noticeably slower than CBT (as it requires whole VM image to be read). From user pespective, this translates into very slow incremental backups. To fix CBT on affected VM, use vSphere Client to edit advanced VM setting and set all parameters with CTK letters to false. This will reset CBT, and our job will then automatically enable it on each processed VM.

 

Also, under certain circumstances, the patched B&R data mover agent may exhibit increased CPU usage. In cases when B&R server lacks available CPU resources, this increase makes CPU to become a bottleneck, which in turn reduces the overall processing performance. We now have the new agent version available through our support addressing this problem. If you don't have unusually high CPU load on your B&R server after vSphere 5 patch (for example, hotadd mode is not affected by this), then you do not need to install the new agent, as it does not change anything else.

 

Good to hear it's working OK so gives a bit more confidence, has the vSphere 5 update been quite painless by and large?

 

Would be running on 2008 R2 but with thin disks I guess easier to just do it 500GB and avoid any extend issues

[andrew-virtusolve]

Good to hear it's working OK so gives a bit more confidence, has the vSphere 5 update been quite painless by and large?

 

Would be running on 2008 R2 but with thin disks I guess easier to just do it 500GB and avoid any extend issues

 

Has been mostly painless, there are some getting PSOD's when they have a certain patch level on the hosts and upgrade the vCenter first, but we generally have done the hosts individually and then upgraded vCenters afterwards for our clients. We have done approximately 300 hosts out of the 800 or so we actively look after for clients and no major issues yet!

[gshaw]

A quick update, created a new store on the VNXe expecting to blow it away in vCenter and re-create with a 2MB block size then found the SAN auto created with 8MB block. Not unsurprising in itself apart from the fact the VNXe used to create 1MB stores

 

Turns out the last software update changed the default block size from 1MB to 8MB... bit odd considering 1MB is the standard going forward so one to watch out for for VNXe owners going forward. Just deciding if to leave the 8MB block now or put it back to 2MB, which is enough for what we're doing then once upgraded to VMFS5 it won't matter anyway.

 

VMWare seem to suggest doing vCenter first from the docs I've seen, did you do the ESXi upgrade from local console (boot CD etc) or using Update Manager? Don't think I'll have that done before I need to make these new file server VMs hence the block size messing about now...

Edited November 14, 2011 by gshaw

[andrew-virtusolve]

VMWare seem to suggest doing vCenter first from the docs I've seen, did you do the ESXi upgrade from local console (boot CD etc) or using Update Manager? Don't think I'll have that done before I need to make these new file server VMs hence the block size messing about now...

 

Correct - 'best practice', for a large environments and where you need to maintain the cluster sizes is to upgrade vCenter in situe, however these have been the most troublesome upgrade routes - if you are non-clustered and have a small number of hosts (as I imagine is the case in many implementations of folk on edugeek) our recommendation is as described, it will avoid the known issues around PSOD when upgrading the vCenter agent when upgrading ESXi4.0 U2 specifically. See the following KB article:

 

VMware KB: ESXi 4.0 hosts may experience a purple screen after vCenter Server is upgraded to 5.0

 

Message is, if you cannot go the simple route - patch first, upgrade second