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.

1. OpenSAF Architecture & Roadmap
Jonas Arndt
Telecom Architect
Hewlett Packard

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. 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. Project and Tools
Users
Technical Leadership
Council - TLC
Developers
Release
Manager Maintainers

5. Community Roles Project Infrastructure
• User
• Web: http://devel.opensaf.org
– 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 – devel@list.opensaf.org
– Developer that has development
leadership of a certain module. – users@list.opensaf.org
• 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. 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 C
Trunk
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. 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. 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. 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. 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
Director
Lib Node Lib Node
Director Director
Director Director

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. 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. 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. 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. 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. 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. Architecture Change: From 2.0 till 4.2
AMF MSG EVT
CLM CKPT LCK
RDE, FM MDS MBCSv PSSv SRMSv
Logtrace MASv SNMP OpenSAF
Subagent CLI
AvMv IFSv HiSv

18. Architecture Change: From 2.0 till 4.2
IMM PLM SMF
NTF AMF MSG EVT
LOG CLM CKPT LCK
RDE, FM MDS MBCSv
Logtrace

19. Architecture Change: From 2.0 till 4.2
Python Java
Bindings Bindings
IMM “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. Project Focus Areas
Architecture
• Streamlined
• Modularity
• Functionality
t
Usability ―Solve simple problems
in simple way‖
• Documentation
• Tools
• Migration Support
t
Ecosystem
• 3PP Plugins
• Distros (visibility)
t
4.0

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. Project Focus Areas
Architecture
• Streamlined
• Modularity
• Functionality
t
Usability ―Solve simple problems
in simple way‖
• Documentation
• Tools
• Migration Support
t
Ecosystem
• 3PP Plugins
• Distros (visibility)
t
4.1

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. Project Focus Areas
Architecture
• Streamlined
• Modularity
• Functionality
t
Usability ―Solve simple problems
in simple way‖
• Documentation
• Tools
• Migration Support
t
Ecosystem
• 3PP Plugins
• Distros (visibility)
t
4.2 / Today

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. OpenSAF 4.2 Architecture
Management Systems
SNMP / Netconf / SOAP / HTTP / RPC / …
CM, FM
Optional,
Modular,
Management Daemons Pluggable
IMM “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. Project Focus Areas
Architecture
• Streamlined
• Modularity
• Functionality
t
Usability ―Solve simple problems
in simple way‖
• Documentation
• Tools
• Migration Support
t
Ecosystem
• 3PP Plugins
• Distros (visibility)
t
4.3

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. 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 TLC
Release 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