It is useful to think of IPMI and SMASH going hand-in-hand. Even though IPMI offers a standardized message interface outside of the server to various applications/consoles, the separate server command line interface can vary from vendor to vendor. Think of SMASH then as the primary command line interface (CLI) available out of the box, accessing the IPMI hardware health management features in the box. This command consistency across different vendor's servers or blades is important to understand, not just for reducing the learning curve for managing new systems, but especially when considering the investment in scripts that many IT shops have made. Adopting SMASH will aid in ensuring consistent server scripts moving forward.
Bottom Line: IPMI + SMASH = Lower Server Management Costs
Overall, by using servers with IPMI and SMASH, IT can lower ongoing operational costs by:
- Offering a consistent command line that changes little over time - reducing training requirements which reduce mistakes
- Using fewer scripts that now perform management tasks across multiple server vendors
- Buying fewer management tools - which lowers purchase and training costs
- Predicting hardware failures to schedule downtime during non-peak hours
- Arriving at the remote site with the right parts by diagnosing the issue before dispatching service personnel
- Reducing the Mean Time to Repair (MTTR)
How it works
In 2003, a roundtable of financial customers identified the need for a standard command line interface (CLI) across servers. The Distributed Management Task Force (DMTF) took on this challenge to deliver an open standard by creating a new working group - the Server Management Working Group (SMWG). The overall goal implements a model that is consistent across multiple vendor products.
This was divided into various specifications. However, the focus for the initial delivery was the command line interface - the System Management Architecture for Server Hardware (SMASH) Command Line Protocol (CLP). SMASH v1.0 was released in June 2005 as a preliminary specification for public review and comment. It is expected to be supported in various products by the end of this year.
In emergency and/or ad/hoc situations, system administrators often need to interactively manage various systems. Servers that have support for the SMASH CLP offer administrators to directly use generic telnet and/or SSH software clients to open interactive sessions. Once logged in (using the server's native security features) they can use SMASH CLP "SHOW" commands to list the system resources that can be managed.
CLP has a specific architecture. The diagram shows the major components. The administrator at the CLP client uses Telnet or SSH2 to send CLP commands to the Manageability Access Point (MAP). The MAP can exist in a dedicated or shared processor or as a process or service elsewhere in the system or network. This flexibility accommodates many different management designs - such as a MAP as part of firmware residing at the server, or in a dedicated plug-in card, or even in a mediation device (such as an external appliance).
The MAP provides authentication and authorization, processing commands and responses, resolving addresses, discovery and managing the sessions between the client and the managed systems and elements. A MAP typically needs to support multiple concurrent sessions for managed elements.
Typically, the hardware vendor describes these managed elements although 3rd party vendors can do this. CLP conforms to the object model described by the Common Information Model (CIM), v2.9. The object model definition that describes the details of these managed element details are stored as profiles. Profiles can also contain sub-profiles. Associations between objects are also described. As an example, a storage subsystem has associations with boot options and power state control - described in sub-profiles.
The CLP Syntax breaks down as follows: ‹verb› ‹options› ‹target› ‹properties›
‹verb› is the command verb i.e SHOW - which retrieves system information
‹options› affect the action, behavior, or output of the verb i.e. '-l all' - lists all levels
‹target› is the implicitly- or explicitly-identified managed element the command is directed to i.e. log1/record* - which is the address of the target server IPMI system event log (SEL), and retrieves all stored records.
‹properties› are attributes of the target relative to the command execution
Once logged in (using the server's native security features) they can use the SMASH "SHOW" command to list the system resources that can be managed by the SMASH "START" and "STOP" commands. Some examples follow:
stop /system1 - power down server discovered as system1
show /system1 - display all the managed elements for system1
start alarm1 - switch on the front led on the current/default server
show log1/record*- display all the system event log records (from IPMI SEL)
start textredirectsap1 - view the system/OS console (can be provided by IPMI Serial Over LAN, or SOL, function)
SMASH CLP support is an optional feature of Avocent firmware and card solutions.