Eye on Blades Blog: Trends in Infrastructure
Get HP BladeSystem news, upcoming event information, technology trends, and product information to stay up to date with what is happening in the world of blades.

Integrating BladeSystem Matrix into a Chargeback or Billing system

I got a call last week enquiring how the IaaS APIs of BladeSystem Matrix (Matrix) could be used to integrate with a chargeback or billing system at a customer site. its a snowy day in Boulder and being a fair weather skier I thought I would spend a few moments and put together some examples of how you could do this.


How Matrix calculates a service cost


Matrix service templates are listed in the template catalog, which shows their name, a description of the service template, and an associated service cost. This cost is calculated by adding the individual costs of each of the service elements in the template together. For example, in a service template the service designer specifies costs for each class of server, for each GB of a class of storage, and for each IP address consumed on a class of subnet. The cost of the service is calculated by combining these unit costs with the amount of each type of resource consumed to create a total. The template catalog shows the cost to deploy the template. However, once the service is deployed, the user can choose to add additional storage, or perhaps choose to temporarily release (suspend) a server. When the user adds additional storage, their service cost will increase based on the template unit cost per GB of storage. Similarly when the user chooses to temporarily suspend a server, their service costs reduces, reflecting that they have reduced their resource consumption. I'm showing an example of the cost breakout chart in the Matrix template designer tool.



Linking to a charge back or billing system


The ListServices web service call can be used by an administrative user to return summary information about the services deployed in Matrix. The Web service return includes information on the current resource consumption cost of that service. Let's assume the IaaS provider wants to chargeback to their customers based on a 15 minute usage increment. They could use a single CRON job on their billing system to fetch usage information every 15 minutes, as shown in figure 2 below.



The content of the CRON job is shown in figure 3. Matrix 6.0 includes a handy CLI wrapper which I am going use in this example. The wrapper is written in Java, so I can run it on any machine and use the underlying web services to connect the Matrix environment. In my example I copied the ioexec.jar file from the Program Files/HP/Insight Orchestration/cli directory to my linux machine. You could also use your favorite wsdl2{java,perl,python,c,.net} tool or the wsdl import feature in Operations Orchestration to create something similar.


Here is my outline of the bash script:


 # sample charge back cron job
# Cron runs script every 15 minutes
#
###################################################################
# charge_owner: used to apply incremental charge to owner's account
# Inputs: service_name owner cost cost_units
# Returns: !=0 if owner has no more credit
function charge_owner
{
echo service $1 owner "$2" cost $3 $4
# insert commands to charge customer here!
return 0
}
###################################################################
# credit_denied: called when owner has no more credit on service
# Inputs: service_name owner
function credit_denied
{
echo suspend service $1 of owner $2
# Insert commands to handle over drawn customers here
# ioexec deactive service -s "$1" -c chargeback.conf
return 0
}


####################################################################
# process_chargeback
# Inputs: processes listServices output invoking charge_owner &
#         credit_denied to perform chargeback processing
function process_chargeback
{
while read -r LINE
do
    FIELD=${LINE#*services*.}
    FIELD=${FIELD%%=*}
    ARG="${LINE#*=}"
  
    case "$FIELD"
    in
         name)  service="$ARG";;
         cost.value)    cost="$ARG";;
         cost.units)    units="$ARG";;
         ownerName)     owner="$ARG";
                        charge_owner "$service" "$owner" "$cost" "$units"
                        if
                        then
                            credit_denied "$service" "$owner"  
                        fi;;
    esac
    :
done


}


ioexec list services -o raw -c chargeback.conf | process_chargeback


The script uses the ioexec wrapper to invoke the list Services web service call. I then pipe the results to process_chargeback  to parse the results extracting the service name, current charge rate and charge units, and service owner. The information is passed to the chargeback system via two functions charge_owner and credit_denied. The sample code has a stubbed version of charge_owner, which takes the service name, charge rate, charge units and owner arguments and simply echos them. This routine could be extended to insert the usage information into a database or pass it directly to a charge back system. If the routine returns a non-zero result (indicating an error), then the credit_denied routine is called. This is another stub which, for now, just echos the name of owner and the associated service. This could be extended, as shown, to do other operations - such as invoke the deactivateService web service call to shut down the service when the user has no more credit.


More Complex Scenarios


The example I've given is very simple, but hopefully is enough to get people started on their own integrations. Matrix has additional integration points that can trigger workflows to perform additional actions. An example of one of these triggers is the "Approval" workflow that is used to gate requests for new resource allocation in Matrix. This trigger point could be used to do a credit check on a customer prior to proceeding with a resource deployment operation.


I'd love feedback about the charge back or billing tools people use today, and what kind of out-of-the-box integrations would be most useful.

Is Power Capping ready For Prime Time

 


Mike Manos responded to my post about power capping being
ready for prime time with a very well thought out and argued post that really
looks at this from a datacenter manager's perspective, rather than just my
technology focused perspective.


I'm going to try and summarize some of the key issues that
he brings up and try to respond as best I can.


Critical Mass


This one spans a number points that Mike brings up,  but I think the key thing here is that you
must have a critical mass of devices in the datacenter that support power
capping otherwise there is no compelling value. 
I don't believe it is necessary, however, to have 100% of devices in the
datacenter that support power capping.  There
are two reasons why:


1.     
In most Enterprise datacenters the vast majority
of the power for the IT load is going to the servers.  I've seen numbers around 66% servers, 22%
storage and 12% networking.  This is a
limited sample so if you have other numbers let me know I would be interested.


2.     
Most of the power variation comes from the
server load. A server at full load can use 2x - 3x the power of a server at
idle.  Network switch load variation is
minimal based on some quick Web research (see Extreme Networks power consumption test or Miercom power consumption testing). Storage power consumption variation also seems to
fairly light at no more than 30% more than idle. See Power Provisioning for a
Warehouse-sized Computer
by Google 


So if our Datacenter manager, Howard, can power cap the
servers then he's got control of the largest and most variable chunk of IT
power.  Would he like to have control of
everything, absolutely yes, but being able to control the servers is more than
half of the problem.


Been there done that,
got the T-Shirt


The other thing that we get told by the many Howards that
are out there is that they're stuck. 
They've been round and round the loop Mike describes and they've hit the
wall.  They don't dare decrease the
budgeted power per server any more as they have to allow for the fact the
servers could spike up in load, and if that blows a breaker taking down a rack
then all hell is going to break lose. 
With a server power cap in place Howard can safely drop the budgeted
power per server and fit more into his existing datacenter.  Will this cost him, sure, both time to
install and configure and money for the licenses to enable the feature. But I
guarantee you that when you compare this to cost of new datacenter facilities
or leasing space in another DC this will be trivial.


The heterogeneous
datacenter


I agree most datacenters are in fact heterogeneous at the
server level either; they will have a mix of server generations and
manufacturers.  This again comes down to
critical mass, so what we did was enable this feature on the two of the best
selling servers of the previous generation, DL360 G5 and DL380 G5 and pretty
much all of the BladeSystem blades to help create that critical mass of servers
that are already out there, then add on with the new G6 servers.  We would of course love for everyone with
other manufacturer's product to upgrade immediately to HP G6 ProLiant Servers
and Blades, but it's probably not going to happen.  This will delay the point at which power
capping can be enabled and for those customers that use other vendors systems
they may not be able to enable power capping until those vendors support it.


Power Cap Management


There's a bunch of issues around power cap management that definitely
do need to get sorted out.  The HP
products do come from an IT perspective and they are not the same tools that facilities
managers typically use.  Clearly there
needs to be some kind convergence between these two toolsets even if it's just
the ability to transfer data between them. 
Wouldn't it be great if something like the Systems Insight Manager/Insight
Power Manager combination that collects power and server data could feed into something
like say Aperture (http://www.aperture.com/)
then you'd have the same information in both sets of tools.


The other question that we have had from customers is who
owns and therefore can change the power cap on the server, the
facility/datacenter team or IT Server Admin team.  This is more of a political question than
anything else, and I don't have a simple answer, but if you are really using
power caps to their full potential changing the power cap on a server is
something that both teams will need to be involved in.


I would like to know what are the other barriers you see to
implementing power capping - let me know in the comments and be assured that
your feedback is going into the development teams.


SNMP Access.


Just to make Mike happy I thought I'd let you know that we
do have SNMP access to the enclosure power consumption.


If you collect all six SNMP MIB power supply current output
power values and add them together, you will have calculated the Enclosure
Present Power.


In the CPQRACK.MIB file, which you can get from here http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?swItem=MTX-a7f532d82b3847188d6a7fc60b&lang=en&cc=us&mode=3&


There are some values


cpqRackPowerSupplyCurPwrOutput which is MIB item:
enterprises.232.22.2.5.1.1.1.10.1 through enterprises.232.22.2.5.1.1.1.10.6
gives you the Input Power of each Power Supply, I know the MIB name says output
but it's actually input - sum these together then you have the Enclosure Input Power.


Power supplies placed in standby for Dynamic Power Savings
will be reporting 0 watts.


And for enclosure ambient temp - read:


CPQRACKCOMMONENCLOSURETEMPCURRENT


Tony

Designing infrastructure the way IT wants to work

We've been on the Adaptive Infrastructure journey at HP for several years now.  This week we are announcing an important milestone: BladeSystem Matrix.  We've been really thinking a lot about how customers use IT and ways we can optimize IT infrastructure to make it work better for them.  We recognize that infrastructure exists for applications, which exist for the business.  So we've taken a business and application perspective on how an infrastructure ought to operate.


Deploying an application typically requires an IT architect or team of architects to carefully design the entire infrastructure - servers, storage, network, virtual machines - and then hand off the design to a team of people to deploy, which typically takes several weeks.  This length of time is mostly an artifact of the way IT infrastructure is designed.  So we decided to change this with BladeSystem Matrix.  Now an architectural design is saved out as a template - servers, storage, virtual machines, network, server software image.  Then when it is time to provision an application, it's as easy as saying "make it so" - and in a matter of minutes, the Matrix's converged virtualized infrastructure is automatically configured and the application is ready to run.  In other words, the way it ought to be.


BladeSystem Matrix is the culmination of several years work at HP - creating an Adaptive Infrastructure that is simpler to buy, deploy and keep running optimally.  Applications are easier to provision, maintain, and migrate.  We've spent years proving out this architecture, not just in our labs but in real-world environments, with BladeSystem, Virtual Connect, and Insight Software - so we could learn how IT really operates - and more importantly - how it ought to operate.


Some people tell me Matrix's virtualization sounds sort of like a mainframe.  Others say that the portal interface reminds them of cloud IT.  I guess in a way they are all correct.  But unlike those environments, Matrix will run off-the-shelf x86 applications.  So I guess I've decided that Matrix is it's own thing.

Builder versus Plumber

Rob Enderle recently added some great insight into a question we posed a couple of weeks ago, "What If a Plumber Built Your House".  When thinking about the question if you wanted a plubmer to build your house, he answered with "maybe".  Here are some of Rob's excellent points from his post, "Cisco, EMC and VMware: Cloud Computing Could Bring Strange Bedfellows".




  • Most builders learn the ropes in a specific trade like plumbing.


  • Plumbers can learn and partner.


  • Other experts may be useful if you were building with non-traditional materials in non-traditional places; like a cliff

Can a plumber learn new skills and partner with others to fill in the gaps?  Certainly.  Could a world-class builder do the same thing?  That is, continuously learn and partner to expand innovation in new areas based on a proven foundation.  Absolutely.


But when the example of the cloud came up, Rob inferred the cloud is primarily a network thing. Or at least a network, storage, virtual thing.  That's one point where we disagree.


The point between our builder versus plumber analogy is this: the only frame of reference when building a house is from the family and the people that make it up.  In the case of the next generation data center, that means the business and the applications and services it relies upon.  If everything isn't aligned, unified and integrated with those needs in mind for both today and the unknown tomorrow, it's a non-starter. 


Whether you are building a cloud, a data center, a or a tiny IT room, it's about about the business and delivering the application services the business needs - faster, cheaper and easier.  In our opinion, taking any kind of technology-centric view; network, server or storage is just the wrong approach.


This really just comes down to a simple difference in our points of view .  We view the big picture from the business and the application perspective across the data center, others see these as appendages hanging on to either side of a network cable.  


Rob ended with this.



"But the key to all of this is a general contractor that understands networking, storage and virtualization deeply, because those are likely the three critical skills in this new world order. By the way, this clearly suggests other partnerships, as well."


We agree it takes a lot to bring all the skills together to build in the world of the next generation data center.  Our team features EDS, who may be the world's greatest general contractor, HP software for the best home automation, and ProCurve might be your best bet for a plumber.  VMware, Microsoft, Citrix, Oracle and more are some of our most talented sub contractors too.  But without a builder, how do all the necessary parts of your data center work together and stay optimized; and who's accountable if they don't?


A big thanks to Rob for adding a lot of great ideas to consider in the "builder versus plumber" discussion.  What do you think?

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us


About the Author(s)
  • More than 25 years in the IT industry developing and managing marketing programs. Focused in emerging technologies like Virtualization, cloud and big data.
  • I work within EMEA HP Servers Central Team as a launch manager for new products and general communications manager for EMEA HP Server specific information. I also tweet @ServerSavvyElla
  • Hello! I am a social media manager for servers, so my posts will be geared towards HP server-related news & info.
  • HP Servers, Converged Infrastructure, Converged Systems and ExpertOne
  • WW responsibility for development of ROI and TCO tools for the entire ISS portfolio. Technical expertise with a financial spin to help IT show the business value of their projects.
  • I am a member of the HP BladeSystem Portfolio Marketing team, so my posts will focus on all things blades and blade infrastructure. Enjoy!
  • Luke Oda is a member of the HP's BCS Marketing team. With a primary focus on marketing programs that support HP's BCS portfolio. His interests include all things mission-critical and the continuing innovation that HP demonstrates across the globe.
  • Global Marketing Manager with 15 years experience in the high-tech industry.
  • Network industry experience for more than 20 years - Data Center, Voice over IP, security, remote access, routing, switching and wireless, with companies such as HP, Cisco, Juniper Networks and Novell.
  • 20 years of marketing experience in semiconductors, networking and servers. Focused on HP BladeSystem networking supporting Virtual Connect, interconnects and network adapters.
  • Greetings! I am on the HP Enterprise Group marketing team. Topics I am interested in include Converged Infrastructure, Converged Systems and Management, and HP BladeSystem.
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation