The vCenter Inventory Service

The vCenter Inventory Service is used for 2 main things. First of all it's the place that stores all of the custom tags used within the vCenter Web Client. But what's not as well known is that the vCenter Inventory Service is also proxy (or cache) for the Web Client. If you're using the traditional vSphere Client, the Inventory Service is not used, it's simply bypassed... hence no tags in the older client. Prior to vSphere 5.1, while the service did exist, it wasn't separated out as an individual component. From vSphere 5.1 onwards this is a separate installable component that can co-exist on the same, or be split out onto a separate, windows server. Currently, separating out components on the linux based vCenter Server Appliance is not possible (unless you like to hack things like William does)

Why we need the Inventory Service

As I stated before, the Inventory Service is designed to reduce load on the vCenter server itself (VPXD). Traditionally only 10% of traffic to a vCenter Server consists of writes, and obviously the other 90% are reads. So if you can cache those reads closer to the Web Client and don't have to ask vCenter to retrieve from its database each time, you can see a significant improvement in response times; while also reducing the load on the more critical vCenter Server itself.

So how much improvement in terms? Well if you look at the #vBrownBag from earlier in the year Justin King (VMware's resident vCenter guru) outlines the numbers.

As you can see from the table, if you have a large environment with many administrators the Inventory Service can really be of benefit. The thing to keep in mind here is, if you have a large scale environment where should I deploy this service to see the benefit?

 

Client	# Sessions	vCenter CPU
VI Client	100	50%
Web Client	180	25%

 

Where the Inventory Service should be installed

While it makes sense to use the vCenter Web Client when scaling out to a large environment, you need to ensure that the Inventory Service is installed in the right location to be of most benefit.

I was recently onsite with a customer who were planning to install the Inventory Service on the same VM as their vCenter Server, but there were splitting out the Web Client to a separate server. I advised them that although this will reduce the load on the vCenter Server, the best place for this service is not on the vCenter Server itself, but to locate the Inventory Service on either its own server, or alongside the vSphere Web Client.

Wrapping Up

Remember the KISS principle, you do not need to split out your components unless you have specific requirements and/or need to scale your environment. Always keep in mind the hardware requirements for each component and how those change if you co-locate services on the same server (see here). If you do split out the components, think about what the component is, and where it best fits. Along with storing tags, the idea of the Inventory Service is to reduce the number of queries to the vCenter Server... place it accordingly!

If you're running your vCenter Server components as a VM (if not, why not?) think about your options. What about configuring DRS affinity rules to keep the Web Client and the Inventory Service VMs together, but your vCenter server separate? Everything depends on your specific requirements, but understanding the architecture and how different components work will ensure you can scale your environment effectively.

Source:-
http://nickmarshall.com.au/blog/2013/6/24/the-vcenter-inventory-service