Bill Blundell is founder of Blundell Consulting, an IT technology and training consultancy based in Nuremberg, Germany. Here he looks at the Intelligent Platform Management Interface

Ask any CIO what the common denominator between all the servers for which he or she is responsible is and the answer will usually be something to do with Intel based  x86 architecture, perhaps application portability or the software. IPMI is unlikely to figure highly in the answers but that belittles its importance in general server management: Intelligent Platform Management Interface is a hardware management standard that defines a set of management facilities built into most of those servers based on an Intel or AMD x86 architecture.

What is IPMI and why is it so important these days?
Thinking about the English behind the acronym will help you to understand what IPMI is about: IPMI is a specification that defines an ”interface” to a set of “intelligence” that “monitors and manages” the “hardware platform”.

The intelligence is embodied in a service processor that must be separate from the main server CPU. Often referred to as the Baseboard Management Controller, this service processor is programmed to monitor and control the lowest hardware levels of the main server: such things as peripheral or server CPU temperatures or power, presence or absence of  field replacement units or logic levels inside the server processor. In the IPMI specification, the list of entities which can be managed or monitored is some 15 pages long and very detailed. Important to remember is that this intelligence is totally independent from the server processor; a BMC has its own 32bit micro that’s programmed to scan the hardware and raise a flag whenever one of those sensor values moves outside a predetermined range or changes its state. Additional power circuitry ensures the BMC is alive when the main server CPU is powered down, either by accident or design, and lights out management is often used to describe IPMI capabilities.

The IPMI specification was defined back in the 1990s and the current version 2.0 was released in 2004. The original architects, Intel, NEC, DELL and HP, produced a document that has been expanded and enhanced by the IT industry in general and some 180+ companies today claim IPMI conformance in their products.

The IPMI Interface
Conformance to what? The answer is conformance to the IPMI “interface”.  The specification defines not only what should be managed, sometimes referred to as managed entities, but also the interface to those entities and how the various parameters can be set and interrogated remotely. The easiest example to understand is temperature. Thresholds can be set for a temperature sensor, and actions pre-defined which must be carried out when the temperature moves outside that threshold.  Such events can be logged conditionally to a System Event Log on the BMC and the SEL can be interrogated, again remotely.
Today’s servers, especially blade servers, are modular by design, with the power supply, networking and storage components, etc.,  designed as field replaceable units  (FRUs). IPMI was developed with the management of FRUs in mind and it defines, for example, how sensors can be linked to monitor the resilience status of a field replaceable unit such as a power unit with three power supplies. If one supply fails, then the BMC just signals that degraded status but if two fail together then it also signals that resilience is totally compromised. Based on that information, service dispatchers can immediately allocate the correct urgency level to the support call, together with the number of spare PSUs the service technician must take on site.

The dials and levers which mirror the sensors and power switches managed and monitored by the BMC will be displayed via a graphical user interface (GUI) on the systems management console (SMC) – the schematic to the left illustrates the management hierarchy under which IPMI sits.  Two management scenarios were envisaged by the IPMI architects. In the “In-band” scenario the systems management console software runs on the associated server processor and interfaces to the BMC directly via a processor to processor link.  “Out of band” requires the systems management console to be run on a remote, management server which interfaces to the BMC via a separate serial interface or LAN. Obviously the “In-band” scenario will only work while the server is running, hence it is aimed at smaller, less critical configurations. The more powerful “out-of-band” covers the full lights out scenario: the remote SMC has access to all the BMC facilities via the out-of band LAN, even while the main server CPU is down. It’s important to note, however, that the commands for either scenario are the same and this simplifies the SMC code immensely.  What about LAN and security? IPMI defines not only the security levels for limiting access to the BMC but also the protocols and techniques to be used for moving information via the interface – encryption figures high in version 2.0.
 
Heterogeneous Systems Management
That brief overview of IPMI omits one very important item – if all IPMI implementations are based on the same specification, all hardware, regardless of brand, should be manageable from the same management console. In today’s world where companies may have grown via mergers and acquisitions, the IT departments are inevitably a collation of different hardware. Providing that all that hardware incorporates IPMI then all platform management can be centralised and unified. This is one of the major strengths of IPMI, compared to proprietary solutions and explains the wide adoption of the standard.

OEM Extensions for Manufacturer Specific Enhancements
The lack of commands to operate ”switches” down at the hardware level may be deemed a drawback and yes, the specification only defines mechanisms for powering the server on and off but more importantly it does include room for the BMC designer to incorporate sophistication at the “on/off” level. Using OEM extensions the designer is free to incorporate extensions to the standard IPMI command set that can do – well what ever the designer feels necessary. In this way IPMI can be extended to cover the more stringent requirements of hot-swap and dynamic hardware reconfiguration. Naturally the SMC must be aware of these extensions and naturally such extensions will only be supported by that manufacturer’s BMC, limiting the use in multi manufacturer configurations. Even here, though, the specification is far sighted – version details and command support can all be interrogated remotely by the SMC and hence the SMC can chose the command set suitable for a particular BMC: vanilla subset for the masses and hot-swap superset for those machines with the correct support.

The Future for IPMI
IPMI has been around for over ten years now, it is a well rounded specification with numerous capabilities which will help today’s cost and environmentally conscious CIOs to monitor and mange the lowest levels of their server hardware. Due to its stability and sound architecture its future is certain and the specification is being extended. Use of IPMI has expanded to outside the classical commercial IT space and it forms the heart of the systems management infrastructure defined by AdvancedTCA, a standard that defines the layout of servers used in telecommunications and other environments. IPMI is here to stay!