1. OpenSAF Architecture & Status
Hans Feldt
Ericsson
OpenSAF TCC

2. Outline Project and tools architecture Architectural decisions
Logical architecture
Modular architecture
Deployment architecture
Management architecture
Status & improvements in release 4.1
Assume audience if familiar with SAF Services
Two parts, arch and status
Different aspects of architecture
4/11/11

3. Project and Tools Users Technical Leadership Council - TLC Developers
Maintainers
Release
Manager
Technical Leadership
Council - TLC
TLC: roadmap, maintaining the arch,
Release manager: branch management, tags, monitoring patches, change contror, announcements
Different roles, direct users, commercial users,
Policies and procedures
IPCA – Individual Participation and Contribution License Agreement
Source Code Management – Mercurial, distributed version control similar to git (used by the Linux kernel)
Project management and defect tracking – Trac
Processes & Methods
Servers (virtual), buildbots, Fedora yum FTP repository

4. 4.0 Architectural Decisions
“The Architecture Release”
IMM used to store configuration data
Close major functional gaps
Use of POSIX APIs
Managed as specified by SAF
Public/external APIs – SAF specified
Modularity
To understand the architecture
No porting layer (LEAP), reduced scope
Gaps: SMF, PLM, IMM Transactional Transparency (PBE)
Managed using IMM, LOG & NTF
Legacy services removed

5. Modular architecture
When building OpenSAF, SAF services can be selected/deselected
Services packaged individually (rpm)
When installing OpenSAF, packages can be selectively installed
OpenSAF’s IMM configuration created based on installed services with OpenSAF provided tools
GNU build system /autotools
Tools to create an IMM configuration based on selected services.
4/11/11

6. Logical Architecture SA-Forum picture from SAI-Overview doc
Missing services in OpenSAF:
- Security
- Naming
Timer
Compliance report in each service description
Roadmap presentation...

7. Management Architecture
Management Systems
SNMP / Netconf / SOAP / HTTP / RPC / CLI …
CM, FM
Optional,
Modular,
Pluggable
Management Daemons
IMM “CLI”
NTF
IMM
LOG
CLM
AMF
SMF
Fault Management - AMF (anf other services) use NTF to send alarms and notifications
Configuration Management – AMF uses IMM to read configuration, validate config changes and receive config changes, admin ops, reflect current AMF state in IMM
AMF uses LOG to log important AMF events
OpenSAF Infrastructure Services
RDE, FM
MDS
MBC
Log&Trace
OpenSAF Core
Optional

8. Deployment Architecture
Controller Node (Active)
Controller Node (Standby)
Director
Node
State replication
Server 2N
Also a process architecture
Node types
Directors/servers have cluster wide view
Directors work in conjunction with node directors
OpenSAF configuration is stored here
Node directors process all events that can be managed at node scope and offloads the director
Server and directors check point state between active/standby
Payload Node 1
Payload Node N
Lib
App

9. 4.1 Status
4/11/11

10. OpenSAF 4.1 Released March 2011 4.1.1 released May 2011?
4.0 released July 2010 => ~8 months development
Major features:
IMM Improvements
SMF Rollback & API
Alternative transport protocol for internal messaging
AM4J/AMF Agent

11. Information Model Management - Overview
A configuration database for both system services as well as applications
Supports runtime objects whose purpose is to reflect the current state
Supports execution of operations on objects, kind of Remote Procedure Calls …
Classes define the schema for objects
AMF model objects such as components, LOG streams, CLM nodes etc
Runtime objects: checkpoint, log streams, AMF assignments, Message queues, Event channels etc
Examples of admin ops, lock node etc

12. IMM Service Interfaces
Configuration
Object
Runtime objects added
Tree of objects, LDAP like names, hierarchical
Runtime
Object
SA-Forum picture from the IMM specification
4/11/11

13. IMM Implementation Overview
A.02 API
RAM based “database” replicated to all nodes
Initially loaded from an XML file
Nodes joining the cluster are “synced”
By default no transactional persistency, dump state to an XML file after configuration changes
Full transactional persistency implemented by the “persistent backend” – PBE (disabled by default)
Dumping state is done outside IMM
Improvements pending…
4/11/11

14. Information Model Management – Improvements in 4.1
Data capacity
400K objects average size 300 bytes
Sync improvements
Model iteration improvements
Schema upgrade – changing class definition
Update of runtime objects concurrently with sync
PBE hardening and adaption to large model, now production ready
Schema upgrade - non standard but uses standard API.
New class definition a superset of the old
A few changes to existing attributes allowed. E.g. change of default value
More relaxation changes possible and defined

15. Software Management Framework - Overview
SMF orchestrates a cluster wide upgrade from one configuration to another
SMF co-operates with AMF to maintain service availability
Operates on AMF entities
Concepts: upgrade campaign, software bundle, software repository, software catalog, …
Campaign, instructions written in xml
4/11/11

16. Software Management Framework - API
Enables upgrade-aware processes
Use cases:
Backup
Process can stop/suspend the upgrade campaign
Functional overview
A process registers a “campaign callback“
A process registers “scope of interest” using a set of filters
Labels are specified in the campaign
When SMF finds a label during campaign execution that matches a registered filter, it calls the callback
Typically management processes or manager processes within applications
Campaign ”debugger”, step wise execution

17. Software Management Framework - Rollback
Rollback is a recovery operation to gracefully restore system state effective at the beginning of a campaign
The upgrade history is used to execute actions in reverse order to undo them
Use cases:
Rollback a successfully executed or suspended campaign while providing service
Rollback a failed campaign not possible to repair
If campaign takes too long time, suspend and rollback
The system was working ”better” before the upgrade

18. Java - AM4J/AMF Agent
JSR Availability Management for Java (AM4J)
New in 4.1 is Java code that implements the JSR319 specified interfaces …
and map them to the Java mapping for AMF
This means that AMF can be used to control availability for Java entities
Sailfin is one Java Application server that supports JSR319
JSR enable external availability management frameworks to supervise and to control Java runtime entities in a standardized way in order to achieve
high availability.

19. AM4J/AMF Agent – JSR 319 Picture from JSR319
Container/contained support missing in AMF
4/11/11

20. MDS Alternate transport protocol - TCP
MDS is an internal communication service that by default uses TIPC as transport protocol
MDS/TCP support added in 4.1
Opens for use on systems not supporting TIPC or when TIPC is not preferred
Solaris, <net|free|open>BSD, Windows, RTOS, …
Characteristics:
A bit “slower” than TIPC (<1500B), improving with larger packets
Error detection uses tuned TCP keep alive messages – defaults 2s, instant detection of process death – roughly the same as TIPC
TIPC is a beta feature in the kernel source tree and not even built by some distributions
Linux includes TIPC but many distributions does not enable it in the standard kernel (e.g. RedHat/Fedora)
Other OSes does not even support TIPC

21. General Hardening IMM Persistent Back End, now production ready
Object implementer related
Startup
Restart …
4.1.1 focused on hardening PBE
IMM improvements pending

22. Questions?
4/11/11