Applying OpenHPI to xtca Platforms

Transcription

1 Applying OpenHPI to xtca Platforms MVACEC 2008, March 12, 2008 Mark Overgaard Updated March 11, accelerating the future.

2 Agenda Background on Pigeon Point Systems Introduction to HPI and OpenHPI, including: Key role of the HPI-to-ATCA mapping specification Positions of the SCOPE Alliance regarding HPI topics Architecture and usage considerations for OpenHPI Key frontier topic for xtca + OpenHPI integration Integrating HPI s Firmware Upgrade Management Instruments (FUMIs) w/ PICMG s HPM.1 Firmware Upgrades Content updated for today; a copy will be posted here: Conclusion Note: Presentation examples use Pigeon Point management components

3 Background on Pigeon Point Systems Delivering world-class management components for open modular platforms Focused on delivering outstanding PICMG management controllers Dependable for specification compliance, interoperability and responsive support Proven in dozens of companies and with years of interoperability experience Founded in 1997, headquartered in Scotts Valley, California Visit for more details Please visit us in the exhibits area! A PICMG hardware platform management tutorial covering both ATCA and µtca is posted at

4 What Interface of ATCA Shelf Managers Should Be Used for System Managers? Most ATCA Shelf Managers support multiple System Manager interfaces IPMI LAN Interface (RMCP) the only ATCA-required interface Typical ShMCs have at least SNMP & command line, also Problem: only RMCP has specdefined framework and semantics RMCP is quite low level SNMP is widely interesting, but: Management Info Base (MIB) is necessarily Shelf-Managerspecific 4 This presentation focuses on ATCA; utca situation is similar

5 SA Forum s Hardware Platform Interface (HPI) Provides a Solution HPI, layered above RMCP, can provide specification-defined: Platform management API SNMP MIB interface Portable System Manager uses RMCP or either HPI interface Preserves System Manager investments SAF s HPI-to-ATCA Mapping specification (w/ 184 pages) provides crucial compatibility assurance SAF website (saforum.org) provides specs & tutorials covering HPI and ATCA mapping 5

6 Why is Mapping Spec So Crucial? Many Ways to Diverge! Active/Standby Shelf Manager Sensor AMC Power On Sequence Commit Control AMC Power On Sequence Commit Status Sensor AMC Power On Sequence Control Assigned Power Sensor Chassis Status Control Desired Power Control E-Keying Link State Sensor Failed Resource Extract Control Fan Control FRU Activation Control FRU IPM Controller Reset Control FRU Power On Sequence Commit Status Sensor/Control FRU Reset and Diagnostics Control IPMB-0 Sensor IPMB-0 State Control LED Control Maximum Power Capability Sensor Shelf Address Control Shelf FRU Information Valid Sensor Shelf Manager IP Address Control Shelf Manager Failover Control Slot State Sensor Virtual Shelf Manager Redundancy Sensor Controls/Sensors Defined by Mapping Spec

7 What is the Position of the SCOPE Alliance on HPI Topics? Reminder: SCOPE is an industry alliance committed to accelerating the deployment of carrier grade base platforms for service provider applications. Visit for more SCOPE: ATCA/µTCA Shelf Managers must be compatible with usage by HPI implementations SCOPE: ATCA/µTCA IPM Controllers must be upgradeable via HPI s Firmware Upgrade Management Instruments (FUMIs), possibly mapped to PICMG HPM.1 Emphasis on FUMI, with HPM.1 a desirable realization mechanism below FUMI interface Gap in HPI (SCOPE): Inability to connect to multiple different types of hardware from the same HPI library user Example h/w: ATCA shelves & rack-mounted servers

8 OpenHPI: an Effective HPI Enabler 8 Provides highly adaptable foundation with plug-ins for particular platform types has details & source Supports wide range of platforms, including ATCA & IBM BladeCenter RPC in OpenHPI library enables HPI clients remote from OpenHPI daemon Pigeon Point OpenHPI & plug-in delivers SAF mapping spec compliance w/ Pigeon Point Shelf Manager Shelf Manager connection via RMCP Allows HPI service to be co-located with or remote from Shelf Manager OpenHPI allows multiple concurrent plugins, addressing SCOPE-identified gap

9 OpenHPI SNMP Operates as OpenHPI Client SAF-defined MIB provides standardized access from SNMP management clients OpenHPI assumes a Net-SNMP-based SNMP agent, supporting AgentX subagents OpenHPI (AgentX-compliant) subagent communicates with the OpenHPI service just like any other HPI client application All 4 elements involved w/ OpenHPI SNMP (clients, agent, subagent and daemon): Communicate via IP Can be co-located or remote from each other and Shelf Manager Note: SAF has not updated the MIB for the B specification; only B MIB is available

10 Redundancy Considerations with OpenHPI Current OpenHPI daemon has no awareness of / provision for any redundant instance; OpenHPI users can: Run two instances of OpenHPI daemon Implement client application(s) so that only one OpenHPI daemon gets state-changing direction ATCA Shelf Managers (including Pigeon Point) support a pair of redundant instances Includes transparent support for moving RMCP sessions to the backup Shelf Manager (ShM) on switchover Transparency applies to remote OpenHPI service For co-located OpenHPI configuration, typical setup has: Backup OpenHPI service communicates w/ active ShM Backup service goes active with ShM switchover OpenHPI redundancy issues need careful handling

11 IPM Controller Firmware Upgrades Via HPI FUMI and PICMG HPM.1 PICMG HPM.1: IPM Controller Firmware Upgrade spec Adopted May, 2007, rapidly gaining traction; defines Format for firmware upgrade images IPMI-based protocol between upgrade agents and the management controllers being upgraded IPMC can have 1-8 upgradeable components, rich set of properties Each component can have backup copy of firmware SAF Firmware Upgrade Management Instrument Included in B.02 HPI revision, adopted December, 2006 Defines information and control APIs, plus source reference mechanism, for firmware upgrade process Each resource (e.g. board) can have multiple FUMIs for distinct upgradeable entities (IPMC, FPGA, BIOS, ) Each such upgradeable entity can have multiple banks for firmware storage

12 HPI-based Upgrade Agent Can Drive HPM.1-based IPMC Upgrades 12 Component firmware, along w/ upgrade actions, encoded in image, w/ upgrade data opaque to agent, understood by IPMC IPMCs with connections to in-shelf Ethernet can potentially get images directly from Upgrade Agent

13 HPI-driven Upgrades Managed Via APIs Acting on FUMIs R E S O U R C E IPMC: µc Firmware bank #1 bank #2 IPMC: PLD Data bank #1 bank #2 Firmware Upgrade Management Instruments (Source: SAF) Each FUMI uniquely numbered within a resource Each FUMI associated with one or a set of firmware storage banks Each bank associated with a distinct firmware source file Firmware upgrade targets explicit bank # or implicit active bank (#0) Boot preference order among banks is define-able APIs provide ways to: set/validate/install source firmware verify/activate/rollback upgraded firmware image

14 Key Opportunities When Mapping FUMIdriven Upgrades to HPM.1 Framework Generic mapping of HPI FUMI framework to arbitrary HPM.1- compliant shelves & intelligent FRUs HPI, purposely limited to API definition, doesn t define how the APIs are realized HPM.1 allows such a realization that is still applicable across arbitrary HPM.1-compliant product components Challenge remains for FUMI-described firmware that is outside the scope of HPM.1 HPM.1-aware HPI service that provides the core of an HPM.1 Upgrade Agent IPMC firmware upgrade management can be integrated with other functions of an HPI-based System Manager Emphasizing the single firmware bank model in FUMI, which fits better with HPM.1 than the multi-bank model Single bank model (focusing on active bank #0) is a fully mainstream usage of FUMI

15 Key Opportunities Mapping FUMI-driven Upgrades to HPM.1 Framework (Cont.) URIs as an implementation-independent representation for references to HPM.1 upgrade image repositories IPMCs that connect to in-shelf Ethernet fabrics potentially getting firmware images via Ethernet, vs. IPMB May be very attractive for large images and for MMCs that don t have connections to in-shelf Ethernet

16 Key Challenges in Mapping HPI-driven Upgrades to HPM.1 Framework HPM.1 IPMCs & components thereof provide considerable standardized attribute info & controls not visible via FUMIs Example attribute info: This component requires IPMC cold reset for upgrade to take effect Max times on this IPMC for long duration upgrade commands, plus rollback & self-test operations Approach to challenge: supplementary, FUMI-linked HPI controls / sensors make additional features visible FUMI architecture assumes detailed upgrade steps (such as separate upgrade actions for distinct FUMIs in the same resource) are driven by HPI user In contrast, for HPM.1, detailed upgrade steps are encoded in upgrade image file Approach: defer to HPM.1 image file for detailed steps, with overall orchestration by HPI user

17 Overall FUMI to HPM.1 Mapping as Proposed HPM.1 R E S Upgrade O U R C Image E Header B Upgrade Data µc PLD Resource HPM.1 FUMI One Bank ATCA Board µc IPMC PLD A single FUMI in a resource represents all the HPM.1-upgradeable components A FUMI is automatically created by the HPI implementation when a resource s HPM.1-capable IPMC is discovered HPI user: Assigns HPM.1 upgrade image as FUMI source and validates source Starts asynchronous FUMI install Starts asynchronous FUMI activate (proposed addition to current synch variant) Can do target verify to confirm active firmware matches source Tracks progress of asynch activities via HPI events

18 Status of HPI FUMI to HPM.1 Mapping Activities for OpenHPI OpenHPI release includes basic FUMI framework Pigeon Point actions leveraging that base: Fleshing out framework, including in OpenHPI core and in clients such as hpi_shell Released in Pigeon Point OpenHPI based on Plug-in-independent changes provided to OpenHPI maintainers, now in OpenHPI Doing test implementation of FUMI mapping in Pigeon Point plug-in Leading a push in SAF s HPI Working Group to augment HPI-to-ATCA mapping to encompass FUMI-to-HPM.1

19 Conclusions OpenHPI is gaining broad traction in xtca management One key benefit: potential for also managing non-xtca platforms, such as IBM BladeCenter, in a unified way HPI-to-ATCA mapping specification compliance is crucial to providing a consistent HPI view of xtca platforms Augmented mapping of HPI s FUMI facility to PICMG s HPM.1 architecture could add substantial additional value Recommendation: where applicable, consider adopting an OpenHPI distribution, e.g., Pigeon Point OpenHPI, that is: Intensively tested by TEMs and TEM suppliers (such as with widely used Pigeon Point ATCA Shelf Manager) Fully compliant with the existing mapping spec Gaining a FUMI-to-HPM.1 mapping implementation

20 Thank you!! Mark Overgaard 20