Hello,

Multiple customers have asked how to allocate our OS-specific subtowers (e.g. Wintel, Linux, Unix) to individual hypervisors if those hypervisors host mixed OS's?

For example, an individual hypervisor may host VM's that are running wintel, linux, and unix OS's; in such a case, from which sub-tower should this lone hypervisor receive costs?

Customers have used several methods to handle this, which one is best practice? Examples of approaches include:
1. Break Hypervisors apart per the OS's they host, and prorate the allocation of sub-tower by OS count

2. Bypass the Hypervisors object, and allocate directly to Servers object

I'm curious what is the ATUM accepted best practice. Any help is appreciated, thanks!

nmulnick
khaniu

ehayman

dahn

pngudup

One approach is to use the VM and Host relationship to return all the VM OS's running on the Host. This can be achieved via LookupEx, amongst other ways. However, it is important to make ensure that the Host's CPU, Cores, RAM and other information is normalized correctly after the LookupEx.

Even though there are various ways of doing it and the data is what usually drives the final implementation/approach. It would be great to have a recommended approach,

Thank you!

Great question Mark!

Option 2: allocate direct to the Logical servers (physcial or virtual) is the correct answer, the only costs for the Hypervisors would be the physical costs and if you have granularity into the VMWare (or related Hypervisor engine) costs those as well. Technically the boxes are likely running some sort of Linux underneath VMWare which *could* be sent to the physical servers first, but it's likely a lot of work for minimal change in outcome.

Option 2 will get you the right costs at the logical server layer, however the consequence of bypassing the Physical Server and Hypervisor objects is that certain standard reports will not function as designed.

If we think about the design of the 3 objects installed by the CT Apps - Servers component, there's an expectation that costs flow to Physical Server first. From there, the standalone server costs go straight up to Servers, while the hypervisor costs are directed to the Hypervisor object. The catch is that you don't know the guest OSes hosted by the hypervisors yet, so you don't know which subtower costs go to which physical servers.

If you have a file that represents the relationship between the hypervisors and their guests, you should be able to use that to back the Physical Server object, and that will allow you to allocate the Compute costs from IT Resource Towers to Physical Server without commingling the subtower costs. From there, all hypervisor costs could be allocated to the Hypervisor object, backed with the same level of OS detail, and finally those costs could be directed up to the Servers object where standalone servers and virtual servers come back together again.

While this results in more granularity in Physical Server and Hypervisor than the names imply, it does seem to achieve the goal of getting the right Compute subtower costs to the right logical servers. Any gotchas?

Excellent idea, Ken!

In terms of gotchas, we have to ensure that our identifier is at a level of granularity that will be compatible with the key relationship.  So, for hosts, we will have to affect the value that gets mapped into the identifier as well as all numeric values being used against that hypervisor.

For example:

• Server ID: HypervisorA – VM1, OS Windows, Actual units .33
• Server ID: HypervisorA – VM2, OS Linux, Actual units .33
• Server ID: HypervisorA – VM3, OS Windows, Actual units .33
• Server ID: HypervisorB – VM1, OS Windows, Actual units .5
• Server ID: HypervisorB – VM2, OS Linux, Actual units .5

If you appended a file to the dataset, I assume the numeric values (Memory, Cores, etc.) are aligned to the amounts assigned to each VM.  If you used a lookupex to a mapping table and don't have those values broken out by individual VM, you will likely want to utilize a sumif() function and basic arithmetic to spread that amount equally back across each VM aligned to that hypervisor.

David

@Ken Haniu, thank you for this very interesting idea.  Could you please help me by backing up a step in the model?  What thought process does the spend owner need to apply to properly allocate cost to the OS-specific sub-towers, so that the method they use to assign cost to the sub-towers works with the method you described to allocate cost up the model from sub-towers? 

I have a department manager who is responsible for a mixture of Windows standalone servers, Cisco UCS converged infrastructure that is running VMWare ESX, and other machines running ESX.  We are having trouble mapping their costs to subtowers.  Is OS the determining factor?  As they try various converged and hyperconverged platforms, should we also take that into account, as well as the OS?  Did your solution say that the guest OS does not matter at the point of mapping to subtowers?  Any advice that you or anyone else can provide on this topic would be much appreciated.  

(We have other departments responsible for Unix, Linux, and other servers.)

Wow, I'll take a shot at this but it's been a while so I'll invite anybody with more recent experience to chime in.

Looking at TBM Taxonomy V3.0 (PDF) , I see a distinction at the sub-tower level for Servers vs Converged Infrastructure, but not down to the OS. This assumes you're not using the Optional Level 3 detail, and also assumes that you are able to differentiate Unix servers at the asset level. Once you have the costs segmented at the sub-tower level, the method described above should apply.

I can see how implementing Optional Level 3 (OSes) would be challenging, and I recommend thinking hard about whether you can achieve a level of defensibility and value in doing so, relative to the complexity you'd be introducing into the model.

We are using the Optional Level 3 detail because a different department manages and buys Linux stand-alone servers (we'll call them dept B) than the one that manages and buys Windows stand-alones and hypervisors that run ESX or Windows (we'll call them dept A).  We initially mapped everything for Department A to Windows Level 3 under the Servers subtower and everything for Dept B to Linux Level 3 under the Servers subtower.  (There is also a Dept C that has converged infrastructure that we placed to the CI subtower.  At the time, I did not understand that Dept A also had some converged and hyperconverged infrastructure.)  So now, we are trying to figure out for Dept A whether we need ESX as a Level 3 option under Servers and whether to map any of Department A's cost in the Linux Level 3 because some of the guests run Linux.  (It is also possible that they need their own level 3 under the converged infrastructure tower, for the sake of allocating their costs separately from Dept C's because it is different hardware from Dept C's.)

With department A's data, it is easier for us to identify the OS that the physical server is running (Windows, ESX, etc.) than it is to identify whether the physical server is running on a converged infrastructure platform or not.  We also have visibility to the OS that the guests are running (thanks to the relationships between physical servers, hypervisors, and servers in the Apptio model).  Can you offer further advice or "@mention" anyone who might be able to?

The most ATUM-aligned thing to do would be to carve off Dept A's Converged Infra costs and allocate them to the Converged Infrastructure sub-tower. I'm just not sure if that is a decision you can make if you've aligned those sub-towers to specific departments.

It's hard to get the OS-level detail right at the level of the IT Resource Towers object. The hope is that you have enough information at the Fixed Assets level to drive the right costs to the sub-tower level. You might be able to figure out an OS for a physical unvirtualized server but that doesn't work as soon as you introduce virtualization, and if you try to do it right you end up re-creating the physical/hypervisor/server triangle "below" the IT Resource Towers object. Where we can be more sure about the OS is "above" the IT Resource Towers object, after we get through all the hardware and virtualization decisions and can look at the Platform column of the Servers object.

@Rhonda Keller, is there anybody in your vast network that might be able to weigh in with ideas for Angela?

Thank you for this additional explanation and input.  @Rhonda Keller, I would very much appreciate any additional perspectives that anyone in your network could provide.