best practices: thick versus thin?

My google-fu must be incredibly weak, because I haven't found a good writeup on provisioning choice in terms of use case. For example;

Server 2008 domain controllers that primarily just domain-control - thick or thin?

thin is better if you're going to Storage vMotion it frequently, but seems to me that DCs that aren't doing a lot of other roles can just sit there and handle authentication/authorization traffic, so why shuffle them around a lot. So, provision it as One Big Disk, make it thick at the Windows minimum, and leave it alone?

Server 2008 file server - thin seems better, capacity consumption will grow slowly over time.

Linux server running BIND - I'm guessing thick, simply because it can be made quite small and appliance-like.

What are your views on thick versus thin?

Find more posts tagged with

Comments

dave330i

Should always be thin unless the app needs every last bit of performance. You'll want to thin at storage vs. hypervisor. If storage doesn't thin, then do it at hypervisor.

kj0

It really depends on your environment, Best practice is Thin, but it also depends on the application it is working for. They say Thin is slower, but with Todays SAN technology, most companies are pushing for Thin. 3Par storage has "getThin" (Check out some whitepapers)

Our SANs are due for replacement and for that reason we keep ours thick. Each Datastore is for each VM. (Small Environment).

I think you've given me my next blog post.

Thanks.

[edit] Or what Dave said

Essendon

Continuing what Dave's said - Thick provision the swap datastores and leave all else at thin. If you have a very busy SQL server or Exchange server, you may want to thick provision its disks. But these days with modern arrays the difference between performance of thin and thick isnt that great.

Why would you want to SvMotion any VM often? It's something you dont do everyday or even every other day. If your having to do it often, then you have problems.

File servers - consumption will grow based on use. As an example, my previous employer had it's file services growing by about 100GB everyday.

Here's a link to help look at this thing in a few different ways:

Thin Provisioning – What’s the scoop? | VMware vSphere Blog - VMware Blogs

JBrown

The following is my environment. Running Windows 2008R2 DataCenter.

DC is always THICK. Usually requires no more than 60GB of disk, we can increase the disk if there is a need in the future.
SQL OS, DB thick, extra junk goes to thin.
All other VMs thin.

offtopic
Btw, I really, really like Deduplication on Win2K12 (Not R2), did some tests with our ghost and wim images, and space savings are phenomenal.
WIll most definitely upgrade our Win 2003R2 file servers to Win2k12R2 as soon as its out.

QHalo

Thin at whichever layer has the best alerting on usa in your environment.

dave330i

Essendon wrote: »

Thick provision the swap datastores and leave all else at thin.

It is a VMware recommended best practice. I don't buy it.

1. Performance difference between thin & thick is minimal in modern storage.
2. Production environment should never use swap unless you have massive resource failure i.e. blade chassis fails.
3. Spliting out swap makes DR more complex.

QHalo

It's really only recommended for SRM so you're not replicating useless data that is recreated anyway on a failover. But I don't do it. I have amazing pipes between sites. The bandwidth use is minimal compared to the extra complexity.

sratakhin

I always use thin provisioning, but for something like heavy used SQL and Exchange servers thick is recommended.

dave330i

QHalo wrote: »

It's really only recommended for SRM so you're not replicating useless data that is recreated anyway on a failover. But I don't do it. I have amazing pipes between sites. The bandwidth use is minimal compared to the extra complexity.

VMware recommends swap file be thick provisioned due to concern that thin provisioned swap file may not inflate fast enough.

If you think about what swap file does, the amount of useless data (i.e. swap file) you initially replicate using SRM is extremely small and the swap file shouldn't be part of subsequent replication.

DirtySouth

Definitely going to be varying opinions on this. I can tell you from my experience, we would always thin provision the LUN and thick provision the VM. It gets too complicated to have both thin. If your back-end shared storage is managed properly, I would let them the storage admins worry about over-subscribing rather than at the vcenter level.

blargoe

I use thin on storage, lazy thick on hypervisor. I use Storage DRS with datastore clusters to pool like LUNs together and ensure thresholds are managed on the VMware side, and have a threshold on the SAN side that will alert me when I need to allocate space on the back end.

emerald_octane

Thin, IMO.

At a minimum follow the guidelines in the following order:

1. Storage array guidance (some arrays can interact with a host to provide benefits to each type of provisioning). Especially if you have the stronger arrays from NetApp or EMC.
1. OS Vendor Guidance (I.e. MSFT virtualization)
2. Application Vendor Guidance (i.e. virtualizing domain controllers. exchange servers).

Especially in 2013 there is alot of info out there and vendors are offering specific information for virtualization because their customers demand it.