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 BladeSystem Matrix Allocation Rules Engine for Multi-tenancy Solutions

Early this week I was in a couple of halo meeting sessions with folks in our Bangalore India location, taking about "the next big thing". It reminded me that the last thing we worked on - exposing an extensible rules engine into the allocation and placement - was part of the BladeSystem Matrix 6.0 release. I wanted to talk a little about that capability today and give an example of how it can be used in deployments involving multi-tenancy.


BladeSystem Matrix Allocation and Placement Rules











Allocation and placement has always been a key function of BladeSystem Matrix.


When multi-tier service designs (represented my templates) are submitted for instantiation, it is the allocation and placement function that looks at the requirements for the service in terms of individual element specifications, desired service topology and lease period and them binds these to the available resources in the environment based on their characteristics and capacity, availability calendar, and physical topology.


In BladeSystem Matrtix 6.0, this allocation process can be customized by an extensible rules engine. Overall there are 18 different allocation rule sets that can be extended as shown in figure 1. The policy.xml file specifies which of the rule sets should be used. These are further explained the in the Insight Orchestration User Guide on page 48.


 



 
Figure 1 Extensible Rules sets




 


Mutl-tenancy Example











A very common use case I hear from customers is the desire to have a common design for a service but to have some aspects of the resource binding to be determined by the identity of the service owner.


In this scenario, we consider a provider who is servicing two competitors like Marriott and Hilton hotels but wants to put offer a common service template in the catalog. The desire is that when Marriott deploy a new instance of the service, that service instance would connect to Marriott-Corporate network segment. However, if Hilton deploy the service, then their service instance would connect to the Hilton Corporate network segment.




Figure 2. Pre-configured networks for the two competing  corporations




Setting up your Service Template











Here we show a portion of a simple single server template as an illustrative example. This is a multi-homed server with



  • 1. a connection to the corporate network. The network is named "@corporate". Later on in the rule engine we will look for the "@" sign in the name to trigger special rules processing

  • 2. a connection to an internal network private to the service "net1".



 


Figure 3 Sample Multi-tenancy configuration




 Adding the processing Rule


The rules engine is based on Drools. The rules are written expressed in Java with a Drools rule semantic wrapper. I'll give you a boiler plate wrapper to get you started below. This rule and the Java function are appended to the SubnetCheck.drl file. I'm going to show a very simple example, but can imagine that the creative community will quickly come up with some more sophisticated implementations. In figure 4, I show a simple rule. The rules processing is invoked to refine the candidate networks for allocation to the new service instance. The rule runs for each network (LogicalNetwork) specified in the template, and for each candidate network in the environment. The purpose of the rule processing is to discard candidates that "don't fit".


This snippet basically extracts the information about the subnet specification in the template (the $logicalSubnet), the candidate list of networks ($subnet) from the context ($pVO). It invokes a function customerSpecificSubnetCriteriaCheck to perform the actual processing. 


rule "CustomerSpecificSubnetCriteria"
       when
               $pVO : PolicyExecutionVO( );
               $resLst : List();
               $logicalSubnet : LogicalSubnet();
               $subnet : Subnet() from $resLst;
              eval(customerSpecificSubnetCriteriaCheck($logicalSubnet, $subnet, $pVO)); 
       then
             
              // match processing is embedded in customerSpecificSubnetCriteriaCheck
              // $pVO.match($subnet, HPIOMessage.get(HPIOBundleKey.ALLOCATION_CRITERIA_CUSTOM, "CustomerSpecificSubnetCriteriaCheck succeeded"));
end


Figure 4. Boiler plate rule example


The function code is placed in the drl file after the rule statement. Here is the snippet


function boolean customerSpecificSubnetCriteriaCheck(
                                         LogicalSubnet logicalSubnet,
                                         Subnet subnet,
                                         PolicyExecutionVO pVO) {

       AllocationEntry ae = pVO.getAllocationEntry();
      
       InfrastructureService service = ae.getInfrastructureService();

       String serviceName = service.getName();
       String owner = service.getOwner().substring(owner.lastIndexOf("\\")+1); // strip domain
       String lsName = logicalSubnet.getName();
       String psName = subnet.getName();

       System.out.println("Service: " + serviceName + " Owner: " + owner);
       System.out.println("LogicalSubnet: " + lsName + "Physical Net: " + psName);
      
       boolean match;
      
       if (lsName.beginsWith("@")) {
              String key = lsName.substring(1); // strip off @
              // March @key to networks with Id "owner-key"
              match = psName.equalsIgnoreCase(owner+"-"+key);
       } else {
              // regular network. Could include additional security checks here.
              match = true;
       }
       if (match) {
              pVO.match(subnet, HPIOMessage.get(HPIOBundleKey.ALLOCATION_CRITERIA_CUSTOM,
                                                                                  "CustomerSpecificSubnetCriteriaCheck succeeded"));
       } else {
              pVO.doesNotMatch(subnet, HPIOMessage.get(HPIOBundleKey.ALLOCATION_CRITERIA_CUSTOM,
                                                                                                      "Could not find customer specific subnet"));
       }
       System.out.println("MATCH="+match);
       return match;
}


Figure 5. Rule processing example


The function starts by getting the information on the InfrastructureService being provisioned.  This contains details of the entire template being provisioned and can be used for additional context aware processing. From this object we extract the service owner name (stripping off the windows domain), as well as the name of the service. It is also possible to extract information such as the "notes" that are specified for the service where additional information may also be encoded by the requestor.  From the LogicalNetwork object we extract the name (ie "@Corporate" or "net1") in lsName. Similarly we extract the physical network name into psName.


I've included some debug lines using System.out.println . These show up in C:\Program Files\HP\Insight Orchestration\logs\hpio.log.


The purpose of this code is to return "FALSE" if the physical network is not a match candidate for the LogicalNetwork specified in the template, otherwise return "TRUE". The rules processing logic requires that if the rule allows an element to be a selection candidate, then the function pVO.match must be invoked for that element. If the element is to be eliminated from consideration, then pVO.doesNotMatch() needs to be invoked listing a reason for the exclusion. As a matter of coding style, you can either include the calls to both these routines in your custom function, OR you can just include the pVO.doesNotMatch() code in the function, and put the pVO.match() innocation in the body of the rule.


For logical networks not beginning with a "@" we just want to return TRUE and let the normal selection rules apply. For networks beginning with "@" we will be more selective, excluding candidates unless they match a specific pattern. For a logical network specified in the template with name of the form "@key" we want it to match against physical networks named "owner-key", where owner is the id of the requesting user. The logic looks for a lsName beginning with "@" and then strips off the "@" to create the key. We then test the physical server name to see if it matches the owner-key pattern.


Configuring the Code


To configure the use of the rules processing, edit C:\Program Files\HP\Insight Orchestration\conf\policy\policy.xml As shown in Figure 6. Once you have updated the policy.xml file you will need to restart the Insight Orchestration service.


<policy enabled="true" name="SubnetPolicyCheck.applyFitting">
    <policy-rule-file>SubnetCheck.drl</policy-rule-file>
    <policy-class-name>policy-class-name</policy-class-name>
</policy>


 Figure 6. Configuring rules processing


Provisioning the Service











Now we are ready to deploy the service. Logging on as user Marriott, I create the service using the template shown earlier in Figure 2. Once the provisioning completes, I can look at the service details page for more information about the service. Select the network named "@Corporate" and then click on the resource details tab. From there I see that the network has indeed been mapped to the Marriott-Corporate network by the customer allocation rules processing.



 


Figure 3 Provisioned Service details




Conclusion


The rules based processing capabilities in BladeSystem Matrix enables simple realization of customized resource allocation processing that can be used to simplify and extend Matrix template deployment. I hope this example helps others to quickly understand the capabilities enabled through this powerful engine and gives a "Quick Start" to writing your own custom rules. If you have cool examples of rule extensions you have implemented, I'd be interested in hearing about them.


Thanks to Manjunatha Chinnaswamynaika for helping me to create this example.


Happy coding :smileyhappy:


 

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.

Tips to Reduce Processor Latency


For some of financial and data-acquisition applications, it's more important to finish one calculation super-fast than a bunch of calculations slightly slower.  There's a group of HPC apps with a similar requirement:  two identical instructions need to have precisely the same latency, every time they're executed.


Real-Time Operating Systems (RTOS) can help address these two scenarios.  These OSes address latency in a number of ways; for example, by ditching device-polling and background cleanup tasks that that standard OS's normally do.


However, some features of modern industry-standard servers can hurt low- and consistant-latency computing.  For example, low-power processor modes might save power, but any such processor throttling can increase latency.  Another example would be management routines that consume CPU cycles, such as routines built into the BIOS of ProLiant server blades that occasionally use CPU cycles to track resource utilization and monitor correctable memory errors in the memory controller.


If you face these situations and have already gone with an RTOS, HP's got some settings in our RBSU (ROM BIOS Setup Utility) that can offer additional help.


Load up RBSU (accessed by pressing F9 while the system is booting), and change the following settings:
1) Set "ProLiant Power Regulator Mode" to "Static High Mode".
2) Disable processor c-state support. 
3) If you are running an application that is single-threaded, set "Processor Core Disable" to "One Core Enabled".
4) On Intel Xeon 5500-based servers (like the BL460c G6), disable "QPI Power Management", and ensure "Intel Turbo Boost Technology" is set to "Enabled".


If you want to go even further, there's a way to disable some of those periodic BIOS checks on processor utilization and correctable errors. For most G5 and G6 server blades, HP has a tool called conrep (provided with the Smart Start Scripting Tool Kit) that let you control these settings.


In the BL280c G6, BL460c G6, and BL490c G6, you can also disable those things straight from RBSU.  Hit "Control-A" within the RBSU, and some additional options will appear in the
"Service Options" menu.


Question: What does “receive path validation” do and what could be the reason for the failure?

This one of the methods used to provide fail over for network traffic. 


 


From our BladeSystem support staff


 

"This is just a “redundancy mechanism” that is part of the HP Teaming driver.Not trying to over simply things but here it goes. NIC A and NIC B are teamed together. NIC A is receiving frames okay, NIC B has not received any frames.Teaming driver sends “Test Frame” out NIC A, sets timers and waits for NIC B to receive it. This is repeated a few times.If NIC B still has not received a frame after a few intervals, it is determined the RX (Receive) Path to this NIC is broken, thus NIC is marked as “Receive Path Validation” and is removed as an Active member of the team. This is a good thing because we don’t want a NIC in the team that can’t hear… So…either there is a problem with that NIC receiving frames (fix it) or there is a problem in the Teaming driver detecting “false” RX Path failures.Either way the recommendation is never to disable it as a solution to the problem.

 

How to order three-phase power module stand-alone for c7000!

Seems that we get a lot of questions on how to convert single phase power modules to 3-phase modules. Our technical staff tries to sum up the process.


 The problem:


"I have a partner who ordered a few enclosures with single-phase power per customer's suggestions.  Turns out customer now wants three-phase power.  The partner is looking to simply order the $175 three-phase power module stand-alone: 413380-B21.  They are unable to do so as it is an option to purchase only as an FIO orderable option with an enclosure on the HP site.  I know you can get the single-phase modules sent seperately and they've ordered those before.  Is there any way to do this for the three-phase module or a spare parts # to avoid a full return for a $175 part?"


 


Answer:


Converting a Single Phase c7000 Enclosure to 3-Phase Enclosure and a 3-Phase Enclosure to a Single Phase Enclosure.

 

To do a conversion the appropriate Spare Part number must be ordered through spares. In North America, Service Spares can be ordered through the HP Parts Store at http://h20141.www2.hp.com/hpparts/default.asp?EE=InvChr

 

Local spare parts stores and spares distributors for other regions can be found at http://h20141.www2.hp.com/hpparts/country_choice.asp

 

Use the table below to order the correct spare part to replace the original module.

 

Spare Part  Description                                                          Plug Type


413495-001  3-Phase North America/Japan Input Module       L15-30P


413496-001  3-Phase International Input Module                    IEC309, Red, 5-Pin, 16A


413494-001  Single-Phase Power Input Module                     C19 - C20 Cord

 

It is the responsibility of the user to ensure that the correct receptacles and/or PDU Infrastructure are available prior to the conversion.  For more information on powering c-Class enclosures please consult the c-Class Site Planning Guide available at http://h71028.www7.hp.com/enterprise/cache/499697-0-0-0-121.html


 


A brief overview of the steps required is below but consult the c7000 Maintenance and Service guide for detailed removal and replacement instructions, this is available at http://h71028.www7.hp.com/enterprise/cache/316682-0-0-0-121.html

 

1. Power Down the Enclosure


2. Disconnect all power cables to the enclosure


3. Remove the hot-plug Power Supplies from the front of the enclosure


    NOTE: The input module is difficult to remove if the power supplies are inserted in the enclosure.


4. Undo the 3 screws on the input power module at the rear of the enclosure


5. Remove the Input Power Module


6. Replace with the new Input Power Module


7. Tighten the 3 screws to lock the module in place


8. Replace the hot-plug power supplies


9. Add additional hot-plug power supplies if required


   Note: The 3-Phase Module requires 3 or 6 Power Supplies to operate, extra power supplies should be ordered if necessary.


10. Reconnect the power cables


11. Power the enclosure on

 

The user then needs to connect to the Onboard Administrator via Telnet or SSH and login to the command line interface as an administrator.


The following command should then be run to set the appropriate input module type.

 

Set enclosure pdu_type x


      x = 1 = Single phase


      x = 2 = Three phase North America/Japan


      x = 3 = Three phase, International


      x = 4 = DC Power

 

More details on the Onboard Administrator Command Line Interface are available at http://h71028.www7.hp.com/enterprise/cache/316682-0-0-0-121.html in the


1. HP BladeSystem Onboard Administrator User Guide


2. HP BladeSystem Onboard Administrator User Guide Command Line Interface User Guide


 


As the Input Power Module is a Field Replaceable Part there are no warranty or support issues with replacing this item.


 


Hope this helps all you power hungry BladeSystem people out there.


 

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
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