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.

Customizing the Matrix Self Service Portal

I was playing around with the BladeSystem Matrix creating some new demo videos, and I thought why not dig into the portal skinning features to create a custom look for my system.


The skinning feature is intended to let companies personalize the portal with their logos and product names, replacing the standard HP skin that ships with the product. In this example, my customer is the fictitious Acme Corporation.


Here are the steps I went through:



  1. Copy C:\Program Files\HP\Insight Orchestration\webapps\hpio-portal.war to my desktop

  2. Rename to hpio-portal.zip

  3. Copy hpio-portal.zip to hpio-portal.orig.zip

  4. Unzip hpio-portal.zip

  5. Browse to the hpio-portal/skins directory, and create a new folder "acme". You should see the following:


  6. Copy your new images into the acme directory. The image names, format, and recommended sizes are shown in the table below. I found there is minor flexibility in the sizes of images you create, but in general things look a little nicer if you stick to the sizes shown in the table.































    Filename



    Format



    Recommended Size in pixels
    (w x h)



    LoginScreenLogo.png



    PNG



    90 x 72



    LoginScreenImage.jpg



    JPEG



    408 x 287



    TitlebarLogo.gif



    GIF



    42 x 26



    TitlebarImage.png



    PNG



    300 x 40





  7. Edit the skinConfig.xml file in the skins directory. Here's my updated content:


    <properties>
         <property><key> personalizeMode                 </key><value>insight</value></property>
         <property><key> skinName                        </key><value>acme</value></property>
         <property><key> brandName                       </key><value>Acme Corporation</value></property>
         <property><key> portalName                      </key><value>Developer Self Service</value></property>
         <property><key> bsaURL                               </key><value></value></property>
    </properties>




  8. rezip hpio-portal directory
    Once you have re-zipped hpio-portal, you might want to open it and check that the top component of the zip file is the contents of the hpio-portal folder, and not a folder called "hpio-portal". Windows XP zip default behavior is to create that top level folder in the zip archive. Compare with the contents of hpio-portal.orig.zip to make sure you get this correct. Otherwise your portal won't restart correctly in the later steps.




  9. rename hpio-portal.zip to myportal.war file




  10. Stop the Insight Orchestration service




  11. Rename C:\Program Files\HP\Insight Orchestration\webapps\hpio-portal.war to hpio-portal.war.orig




  12. Copy myportal.war to C:\Program Files\HP\Insight Orchestration\webapps\hpio-portal.war




  13. Delete the folder in the C:\Program Files\HP\Insight Orchestration\work directory with a name starting with Jetty and containing the name hpio.portal.war




  14. Start the Insight Orchestration service




 Updated Portal


Here's my updated login screen to the self service portal, and a zoom in on the updated window bar after login is complete.



 


ioconfig Command


The ioconfig command in the C:\Program Files\HP\Insight Orchestration\bin folder is a useful utility that lets you switch between skins, for example: ioconfig --skin insight will change back to original skin. See ioconfig --help for more information on this command and options.


Send your examples


I hope this quick overview is helpful to getting you started. Send me examples of your self-service portal customizations!

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.

First post this year!

Well it is February already and I am just now fulfilling one of my New Year’s resolutions – to start blogging more often.  So here I go.


 


Last week, I had the opportunity to spend a few minutes chatting with Steve Kaplan, a vice president at INX, a Cisco reseller.  Steve is also the author of the blog “By the Bell” where late last year he compared Cisco UCS to HP BladeSystem Matrix.  He and I had the chance to compare our points of view on the applicability of blades.  Needless to say, our point of view here at HP is quite different from Steve’s support of UCS.


 


Here is a summary of a couple of areas that perhaps Steve and I do not yet see eye to eye.


1.      We at HP do not see UCS as comparable in functionality to BladeSystem Matrix, which we believe is in a category by itself.  Why is this?  Unlike other offerings that manage servers or VMs one at a time, Matrix uniquely allows customers to provision and manage the infrastructure of an entire application all at once – all the servers, VMs, storage, networks, and server images – through a service catalog based provisioning portal.  Further, Matrix also has built-in capacity planning tools and disaster recovery tools that are not found in UCS.


2.      We believe that data center power and cooling are substantial costs and challenges for customers and warrant significant attention.  It appears to me that Cisco has largely ignored this in their UCS design.  Not mentioned in Steve’s analysis is the ability for BladeSystem to throttle the power consumption of most chassis components that consume power including CPUs, memory, fans and power supplies to keep infrastructure running efficiently all the time.  Also not mentioned is that UCS requires up to double the amount of data center power allocated per server compared to BladeSystem.


 


While Steve’s analysis is very detailed, he omits general descriptions of the very capabilities of BladeSystem and BladeSystem Matrix that have made BladeSystem the most popular blades platform on the planet – with over 1.6 million blades sold.  (These can be found at www.hp.com/go/bladesystem and www.hp.com/go/matrix).  Anyone interested in hearing more of what I have to say about converged infrastructure and BladeSystem can check out this Information Week article.


 


I appreciate Steve taking the time to write on blades, one of my favorite topics!  I hope the dialogue over what customers find important for their IT infrastructure continues, as this is an important topic for our industry.  Our many years in the blades business has taught us a lot, and we always look forward to the opportunity to share with customers the technologies we can bring to help them save time, reduce power and cut costs associated with managing IT infrastructure, all while becoming more efficient.

"If something doesn't exist, we'll make it"

Over the holidays, I took my daughter to see a movie about a Cajun frog.  I admit to a pang of jealousy as I passed crowds lined up for screenings of "Avatar". However, given my situation -- namely a 5-year-old clamoring for popcorn and a Princess movie -- I made the best choice for my needs.


It turns out those Avatar-watching throngs got to see the result of another best choice; one made by a group of IT experts in Miramar, New Zealand


Weta is an Academy Award-winning studio that did the digital effects for Avatar.  The imaginations at Weta Digital have created some incredible virtual realities. Jim Ericson from Information Management quotes Weta's Paul Gunn as explaining that 'if it's something that doesn't exist, we'll make it.'  Pretty amazing innovations coming from a relatively small place on the other side of the world from Hollywood and Silicon Valley.


In an article and blog, Jim sketches for us the 4000-server facility Weta used to render the VFX of the blockbuster.  One eye-opener: the final output from this behemoth server farm fits on a single hard drive.


Weta's space- and power-constrained facility uses advanced techniques like blades and water cooling.  Performance is a paramount need –so much so that their server clusters comprise seven of the world's 500 largest supercomputers.  But their workloads didn't just need massive scalability, they also required high bandwidth between individual server nodes, and relatively local storage.  


As Jim points out, they chose to build their infrastructure with HP BladeSystem, using the double-dense BL2x220c  server blade.  This very innovative, compact server (shown in the video below) let them achieve, in their words, 'greater processing density than anything else found on the market'. 


Actually, any engineer could stick 64 Intel® Xeon® processors into a 17-inch-high box and get it to run.   However, very few computer companies have the expertise -- and resources -- to make such a thing affordable and efficient, and to be able to warranty  that it will run without pause for 3+ years. 


Even more important: Weta possessed something relatively rare when they chose HP BladeSystem. They were already experts in bladed architectures.  Their prior infrastructure was based on IBM blade servers, so they already expected the space- and power-saving benefits of blades.   Weta was seeking  the best bladed architecture.  And Weta determined that, for them, HP BladeSystem was the best choice.

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

Search
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 ISS Central team and a launch manager for new products and general communications manager for EMEA ISS specific information.
  • 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