Most large organizations that I have worked in utilized a system of chargebacks. Each company department established...
their own IT budget, and every month IT sent each one a bill for their portion of the organization's overall IT expenses. And it's not just about charging for ongoing or recurring resources -- departments are also on the hook for new server, service and application deployments.
The idea is simple enough, but managing chargeback is another matter. Every organization using an IT chargeback plan handles it differently, and the value of computing resources can vary radically from one organization to another. But things can really get thrown out of whack when an organization virtualizes their servers. After all, multiple departments may end up sharing server hardware, so how do you charge them for those resources fairly and objectively? Every organization's needs are unique, and I have several different ideas for handling IT chargeback in a virtual data center.
IT chargeback based on the virtual server count
One of the more popular models for implementing chargebacks in a virtual data center involves charging the individual departments based on the number of virtual servers (virtual machines or VMs) they have on a particular host server. For example, if a host machine contains ten virtual servers and two of them belong to the marketing department, then you would charge marketing 20% of the server's overall operating costs (plus any applicable software licenses).
Like all of the models here, this method isn't perfect. One of the biggest problems here is that it is difficult for the individual departments to stay on budget because their monthly IT chargebacks will fluctuate. For example, suppose that the finance department adds a virtual server to the abovementioned host. Now, instead of using 20% of the server's overall resources, marketing is only using 18%, so their monthly chargeback will go down. Likewise, if the finance department was to decommission a few virtual servers, then marketing could find their monthly chargebacks suddenly skyrocketing as they are now occupying a greater percentage of the total number of VMs hosted on the physical server.
IT chargeback based on resource consumption
Another disadvantage to the first method is that it isn't completely fair --not all VMs consume equal hardware resources. For example, one department may operate a virtual Web server which consumes sparse resources, while another department operates a SQL server that consumes nearly all of the host machine's available CPU and memory resources. In this type of situation, is it really fair to charge the department with the Web server the same amount of money as the one that operates the SQL server?
Being that some VMs consume more hardware resources than others, some organizations have begun basing their IT chargeback on the number of virtual CPUs that are allocated to each particular virtual server. That way, departments are charged based on the resources actually used.
Personally, I don't like this chargeback model -- it is labor-intensive for IT. Keeping track of virtual server configurations is a big enough job without linking the virtual machine configuration to the chargeback system. However, management tools like Vizioncore's vFoglight, VMware's vCenter Chargeback, Itheon's Utility Chargeback and others can automate at least some of the mundane work.
Charging departments for hardware
A third popular IT chargeback model involves adapting the chargeback techniques that have been used for decades by requiring departments to pay for their own hardware. For example, an organization's marketing department needs to deploy a SharePoint server. The department would purchase a physical server, but the server would be configured as a virtualization host. SharePoint would be installed within a virtual machine running on the server.
In this type of situation, the marketing department would own the server, and would be free to deploy additional VMs without incurring any additional hardware-related chargebacks until the server has been filled to capacity.
If you decide to use this chargeback model, then there are a couple of things that you will need to think about. First, you will have to establish clear guidelines as to what can be installed on a host server. For example, some organizations have security policies prohibiting Internet-facing VMs from being installed on the same host server as backend virtual servers. If your organization has such a policy, then you may have to explain why a department has to purchase additional server hardware when they barely used the hardware already present.
Another disadvantage to this method is that if fault tolerance is required, then the initial acquisition costs for server hardware can be considerable. You may find that some departments are reluctant to blow their IT budgets on redundant hardware. Instead, they try to find a way to share the costs with other departments. This puts you right back with trying to figure out how to allocate chargebacks.
IT chargeback at a flat rate
A final IT chargeback model that I think works the best in a virtual data center is to charge a flat rate for each server. Because some VMs consume more hardware resources than others, you could establish two different rates – basic and high capacity. That way, those who use a greater percentage of a server's resources pay more.
What I like about this model is that it does not force IT to use complex and time-consuming methods for determining each department's monthly bill. Best of all, using a flat rate makes it easy for the individual departments to stay on budget because they know exactly how much they are going to spend on IT resources each month.
Every organization is different -- an IT chargeback model that works for one organization may not work for another. Hopefully, one of the chargeback models described will be a good fit for your organization, but if not, you can always use a combination of these techniques in developing your own.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at email@example.com.