Currently our storage to server costs are allocated via the CPU count however we would like them to be allocated with a combination of CPU, Memory and Storage. Has anyone done this previously or has any knowledge of this being possible.

Using combinations of CPU/Mem for allocations from IT Towers to Physical Servers can make sense, but not from Storage to Servers.  The amount of CPU and Memory resources in a server has little to do with the amount of Storage being used.  For example, a file server could consume many terabytes of storage, but have few cpu/mem resources; while an application server would have much more cpu/mem resources, but consume far less storage. 

The best approach would be to identify how much storage is being “used” or “allocated” to each server, and weight by that. 

Thanks Joshua that's very helpful

That's how we have ours done now, but after talking with the storage team, we're thinking about changing it to push storage to applications. Only so on the app reports we send the app owner can see the actual storage cost separate from servers. That way they can see the impact of storage and maybe we can use it to change behaviors.

We are also charging for total space allocated and not used. Granted, we're likely over-charging based on over-subscription, but so many times what the storage team allocates per app owner request is not used and rarely does anyone step up to give any storage back. That causes us to have to buy new arrays and drives up our costs.

So need to figure out a way to send storage to app. Guessing a use map table and checking for app/server matches. Only want storage dollars sent to apps that have a server match. 

And likely not all storage will hit a server tied to an app, so that'll cause storage costs to be stranded. Will need to figure out what to do with that because we don't necessarily want to overburden apps that are getting their rightful share either.

Off to the drawing board!

@Jenny Franklin

This is good stuff! This changes the game when you have a "bill" for any unused storage. It certainly drives the owner to be proactive to only request what they need.

Have you ran into costing for "burst" storage? In the case that the storage required exceeds amount allotted?

Have not run into that one - are you guys doing it?  How do you handle that within Apptio?  Typically folks ask for too much storage and never hit the threshold.  That's our problem..   @Richard Coronado

@Jenny Franklin

We have the same problem here. There is so much storage out there because they need it "just in case." What I was thinking is helping develop a model where owners get what they need plus 2-3% (something marginal) as wiggle space, not 10-15% that some owners request. In the case of an event when they need added capacity immediately then a burst of storage would kick in, somewhat of the services that AWS provides. I've talked to other companies and it is pretty common to have people with excess of 10-15% storage. That's crazy!

Totally late to the party on this one, but...

If an app owner or other person desires a larger amount of wiggle space, they should commit to it via a different level of service committed to. For example, standard storage service could come with 2-3% of wiggle room accounted for while a gold (or higher service level) of storage could come with 10-15%. Then, allocations could be weighted by the level of service.

Thank you for this response!  We have a similar issue where people do not like to give storage back (I guess people just love their storage)

It is definitely possible to do - you just need to define how you'd like to create the allocation %.  e.g. 40% CPU 30% Mem 30% Storage.  I would recommend doing this is a new custom column and then normalize the weight across the population i.e. You are allocating 100% object to object. You can use Sum functions and you can break out the calculation steps in multiple columns if you prefer or don't have a lot of experience and find it easier to view step by step.

As for storage utilization, based on my knowledge somewhere in the 70-80% utilization is considered a gold standard.  However, you need to be careful about which numbers you are considering.  Software Storage Management is generally behind the scenes so to speak optimizing your overall storage environment (auto tiering by usage, thin provisioning Thin provisioning - Wikipedia, the free encyclopedia  - and many other technologies may be deployed).  These are highly relevant because if you add up your total subscribed GB's you may see that it exceeds the physical capacity of your arrays.  For example you may have 50 TB's of capacity, but have 55 TB's of subscribed e.g. 110% of your storage is in use - huh?  So any data presented to the user is generally not what you would want to use - I kind of see that as the bs layer.   You need some overhead capacity for backup operations (snaps, and clones) otherwise your environment may be extremely slow.

The SW Management makes it more difficult to get the data you want because it is a moving piece.  There are likely parameters in that SW that can be adjusted (such as the 110% in the example above) but the storage technical team is likely responsible for that.   So don't necessarily take the data at face value.  I work with our tech folks on that and when we consider analysis or use case we often have to discuss.

Very helpful for a non-techie, thanks

We are currently pushing storage to applications as it spreads wildly among the application for already above mentioned reasons. Technically I think it should be possible with a weighting column but I think I would only do this if I don't have any data on storage and its use.

We allocation our Storage to Servers, this way we can identify what Storage does not match a server.

I sent the unallocated details to our Storage man and he is looking at the data with a view to reducing our Storage.

These are great pieces of experience and advice, thank you all so much