OpenSAF Symposium_Architecture_and_Roadmap_Update9.19.11


Published on

OpenSAF is a mature platform that has undergone a series of architectural improvements and changes, making it the leading solution in the commercial-off-the-shelf (COTS) HA middleware industry. In particular, Release 4.0, released in mid 2010, is the biggest step to date in the direction of implementing a full suite of SA Forum services. This session will provide an overview of the OpenSAF architecture and specifically shed light on a series of improvements for Release 4.1 and the upcoming Release 4.2 that make OpenSAF the most scalable, robust and comprehensive implementation of the SA Forum standards. Lastly, this session will survey the OpenSAF roadmap and discuss the key priorities for OpenSAF over the next year.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OpenSAF Symposium_Architecture_and_Roadmap_Update9.19.11

  1. 1. OpenSAF Architecture & Roadmap Jonas Arndt Telecom Architect Hewlett Packard
  2. 2. Presentation Layout• What is OpenSAF• Project Tools & Roles• Release Cycle / Process• OpenSAF Concept and Architecture• Services Descriptions• OpenSAF Releases & Roadmap• Features/Improvements in 4.1 & 4.2• Looking Ahead
  3. 3. What is OpenSAF Standards Body• Base platform middleware SA Forum developed by OpenSAF AIS HPI Project• Provides availability, manageability, utility and platform services needed to develop highly available OpenSAF OpenHPI distributed applications• LGPLv2 license Open Source Projects• Implements SA Forums AIS Specification• Supported by OpenSAF Foundation
  4. 4. Project and Tools UsersTechnical LeadershipCouncil - TLC Developers Release Manager Maintainers
  5. 5. Community Roles Project Infrastructure• User • Web: – suggest new features, report bugs, participate on user mailing list • Trac: for wiki, ticket system• Developer (enhancements, bugs) – user who contributes to OpenSAF (code, • Mercurial: for DSCM docs., etc.) • Mailing lists:• Maintainer – – Developer that has development leadership of a certain module. –• Release Manager • Buildbot: for autobuild – Manages OpenSAF releases, decides • For OpenSAF developers: when development release has needed quality to be announced as Generally – User Mode Linux support Available • Example to build UML environment $ cd tools/cluster_sim_uml• Technical Leadership Council – Architecture reviews of major contrib. $ ./build_uml – Release Strategy, Development process • To start 4 node UML cluster $ ./opensaf start 4
  6. 6. Timeline & Release Process • ~ mid 2007: Initial code contribution by Motorola ECC • February 2008: Infrastructure finalized, Foundation launched • August 2008: OpenSAF 2.0 • June 2009: OpenSAF 3.0 • July 2010: OpenSAF 4.0 • March 2011: OpenSAF 4.1 • September 2011: OpenSAF 4.2 (planned) 6 – Months Release Cycle Feature A Feature B Feature CTrunk Ms Beta Ms Beta Ms FC RC1 RC2 GA 0 1 1 2 2 Stable Open (Allowed to commit enhancements and defect fixes to repository) Release Stabilization Period (Only defect fixes allowed to be committed to repository) Change Control Process applied (Only fixes to major, critical, blocker defects allowed)
  7. 7. OpenSAF Concepts• Defines two types of nodes – System Controller Node – Payload node• System Controller Node – Management Access Point for Entire Cluster – Hosts Centralized Functions of OpenSAF Services – 2N Redundancy• Payload Node – Contains Node-Scoped functions of OpenSAF Services – Hosts target OpenSAF Applications
  8. 8. OpenSAF 2-tier Architecture• Server on Controller Controller Payload• Only library on Payload, used to talk directly to the Server Client Server• Examples Library – PLM – LOG – NTF – EVT
  9. 9. OpenSAF 3-tier Architecture• Director on Controller Controller Payload• Node Director on Client Payload, handles node- Library scoped activities and communicates with Node Director Director Director• Examples – AMF – CKPT – CLM – IMM – SMF
  10. 10. Deployment Architecture Controller Node (Active) Controller Node (Standby) Director Director Director Director Director State replication Director Server 2N Server Server Server Server Server Payload Node 1 Payload Node N App Node App Node Node Director Node DirectorLib Node Lib Node Director Director Director Director
  11. 11. OpenSAF Core services AMF Application• AMF - Availability Management Framework – Manages redundant service providers for each Service Group Protects service • instantiate, terminate and monitor service providers Hosted On Service Assigned to Service Unit Instance • Dynamically (re)assing services to service providers AMF Node • Model driven Hosted On Component Assigned to Component Service Instance (CSI)• IMM - Information Model Management Service OM 1 OM 2 IMM Object – Manages the Information Model Object IMM Service Management API – Allows objects of the Information Model to be IMM Object Implementer created, accessed, and managed by system OI 1 OI 2 API management applications Node U Node V Node W• LOG - Log Service Notificati on Log lib App 1 Log lib App Log 2 – Enable application to express and forward log lib records through well-known log streams that lead to Log particular output destinations such as named files Alarm Notification System Application
  12. 12. OpenSAF Core services• CLM - Cluster Membership Service – Deciding which nodes are part of the specific cluster Application Application Application Alarm Mgr Producer Subscriber Subscriber Reader• NTF - Notification Service Notification Library Notification Library Notification Library Notification Library – Notification producers generate notifications – Notification consumers consume Transport Service notifications generated by producers, and can be either of subscriber or reader type Forwarding – Support for Notification filters Notification Server Logging Log Service Notification Log File
  13. 13. OpenSAF Optional services• CKPT - Checkpoint Service Node A Service Node B Group – Manages checkpoints that a process uses Service Unit A Active Service Unit B Standby Active to save its state to minimize the impact of Compon ent Compon ent failure – A checkpoint is a cluster-wide entity, with a Checkpoint C Checkpoint C CKPT Section abc unique name, that is structured into areas Section abc called sections Section xyz Section xyz – A copy of the data that are stored in a checkpoint is called a checkpoint replica.• PLM - Platform Management Framework – Service providing management of hardware (via HPI) and low-level software.
  14. 14. OpenSAF Optional services• EVT - Event Service – Publish/subscribe multipoint-to-multipoint communication mechanism based on cluster-wide event channels• LCK - Lock Service – The Lock Service is a distributed lock service that allows different application processes on the same or different nodes in the cluster to compete for access to a shared resource in the cluster• MSG - Message Service – Buffered message passing system, for processes on the same or different nodes, that is based on the concept of a message queue.
  15. 15. OpenSAF Optional services• SMF - Software Management Framework Software repository – Software Upgrade: Support for migrating a Campaign.xml IMM target system in operation from one deployment configuration to another is -Admin operations Install/remove software -Read config realized following an upgrade campaign on target nodes -Modify config specification SMF Adaptation commands SMF
  16. 16. 2008 2009 OpenSAF Roadmap 2010 2011 2012 Initial Release from Motorola 1.0 64-Bit support AIS – LOG Service 2.0 HP HW Integration C7000 PLM, SMF CKPT Stepped to B.02.02 Retired HiSV, MASV, PSSv, 3.0 MSG B.03.01 SRMSv, IFSv, SNMP subag Partial Java Mapping OpenSAF CLI IMM Overhaul of CLM Architecture Modularized Architecture Streamlined Architecture 4.0 Major overhaul of build system IMM Improvements Performance enhancements SMF Rollback & API 4.1 Alternative transport protocol for internal messaging IMM Improvements AM4J/AMF Agent Python Mapping NTF Reader API improvement AMF B04 API 4.2 Non-Root User Retired DTSv Hot-Standby Support for AMF 16
  17. 17. Architecture Change: From 2.0 till 4.2 AMF MSG EVT CLM CKPT LCKRDE, FM MDS MBCSv PSSv SRMSv Logtrace MASv SNMP OpenSAF Subagent CLI AvMv IFSv HiSv
  18. 18. Architecture Change: From 2.0 till 4.2 IMM PLM SMF NTF AMF MSG EVT LOG CLM CKPT LCKRDE, FM MDS MBCSv Logtrace
  19. 19. Architecture Change: From 2.0 till 4.2 Python Java Bindings BindingsIMM “CLI” PLM SMF IMM NTF MSG EVT AMF Runtime LOG Dependency CKPT LCK CLM RDE, FM MDS MBCSv OpenSAF Optional Services Logtrace OpenSAF Core • AMF – Availability Management Framework • LCK – Lock Service • CKPT – Checkpoint Service • LOG – Log Service • CLM – Cluster Membership Service • MSG – Message Service • EVT – Event Service • PLM – Platform Management Service • IMM – Information Model Management Service • SMF – Software Management Framework
  20. 20. Project Focus AreasArchitecture • Streamlined • Modularity • Functionality tUsability ―Solve simple problems in simple way‖ • Documentation • Tools • Migration Support tEcosystem • 3PP Plugins • Distros (visibility) t 4.0
  21. 21. OpenSAF 4.0 Released July 2010  Services Introduced Major Design  SMF changes  PLM Redesign and break-  Services Retired out of CLM  MASv Streamlined  HISv Architecture  PSSv  SRMSv Modular Architecture  IFSv
  22. 22. Project Focus AreasArchitecture • Streamlined • Modularity • Functionality tUsability ―Solve simple problems in simple way‖ • Documentation • Tools • Migration Support tEcosystem • 3PP Plugins • Distros (visibility) t 4.1
  23. 23. OpenSAF 4.1 Released March 2011 Major features: ‒ IMM Improvements (read performance) ‒ SMF Rollback & API ‒ Alternate transport protocol for internal messaging ‒ No hard dependency on TIPC ‒ Stretched Cluster Support ‒ AM4J/AMF Agent
  24. 24. Project Focus AreasArchitecture • Streamlined • Modularity • Functionality tUsability ―Solve simple problems in simple way‖ • Documentation • Tools • Migration Support tEcosystem • 3PP Plugins • Distros (visibility) t 4.2 / Today
  25. 25. OpenSAF 4.2 Release Planned September 2011 Major features: — IMM Improvements Multiple Appliers (enables e.g. Hot-Standby for AMF)  Model Mediation (OI CCB Augmentation) – Python Mapping – AMF Improvements • B.04 APIs (subset of) • Support for Application Dependency Modeling. • Hot-Standby Support – Non-Root User – Retired DTSv
  26. 26. OpenSAF 4.2 Architecture Management Systems SNMP / Netconf / SOAP / HTTP / RPC / …CM, FM Optional, Modular, Management Daemons PluggableIMM “CLI” Python Java IMM NTF LOG Bindings Bindings SMF PLM AMF CLM OpenSAF Infrastructure Services CKPT EVT Runtime RDE, FM MDS MBC Logtrace Dependency MSG LCK Optional OpenSAF Core OpenSAF Optional Services
  27. 27. Project Focus AreasArchitecture • Streamlined • Modularity • Functionality tUsability ―Solve simple problems in simple way‖ • Documentation • Tools • Migration Support tEcosystem • 3PP Plugins • Distros (visibility) t 4.3
  28. 28. OpenSAF 4.3 and Beyond Release Planned Spring - 2012 Planned Features:  Reduce complexity of integrating legacy applications  Enhanced Virtualization support  Security Improvements  No dependency on shared file systems  Java mappings for EVT and AMF (B.04)
  29. 29. I need Feat. A Feature Lifecycle I’ll implement Feat. Feat. Feat. A A A ”Wish-list” User Developer Feat. A + Time Feat A Major Estimate Feat B OpenSAF Feat C Roadmap Minor TLCRelease Manager Betas I have Feat. A ! Feat. Milestones Feat. B Feat. A C FC Detailed RC Plan for M M General Release N Availability User Dev Release N OpenSAF Release N Trunk Stable Trunk