1. Building Systems with OpenSAF Mario Angelic Expert mario.angelic@ericsson.com Hans Feldt OpenSAF Technical Co-Chair hans.feldt@ericsson.com

2. Presentation Outline What is meant with “OpenSAF Based System”? How does OpenSAF fit into the “system” ? Integration aspects? Commonly used system building blocks Conclusion

3. OpenSAF Based System What is meant with OpenSAF Based System? –A system where Availability (HA and Clustering) and Manageability (Configuration, Fault, Software Management) are handled using OpenSAF services What is meant with OpenSAF Based System? –An complete system consisting of necessary functional components to deliver total system functionality Examples of systems: –Base Station Controller (BSC), Media Gateway (MGW), Call Session Control Function (CSCF), SIP Application Server. –Social Network Systems, Search Engine systems, On-line web stores

4. SCOPE Arhitecture

5. Availability Integration Using Availability Management Framework support –wrapper approach –Proxy-proxied approach –Non-SA-aware, non-proxied approach Managebility Integration Configuration Management (IMM) Fault Management (NTF) Software Management (SMF) Log

6. Visualizing Wrapper Approach Node A Node B 3PP WrapP SAF MW Component A Component B AIS State replication Service Unit A Service Unit B Service Group AIS SI CSI activestandby Proprietary API

7. Visualizing Proxy-Proxied support SAF MW Node 3 Node 4 3PP Component L1 Component L2 SU L1 SU L2 SG ”Proxied” (N-way active) Node 5 3PP Component L3 SU L3 Node 1Node 2 Component P1 AIS SU P1 Component P2 AIS SU P2 SG ”Proxy” (2N) Proxy SI Mediation CSI mediation SI CSI active standby

8. Components typically needed when building OpenSAF based system Components required by OpenSAF itself Additional Components to build System

9. Components Required By OpenSAF Some obvious: –HW (redundant for HA requirements) –Operating System (typically Linux) Some less-obvious: –Shared file system accessible to controllers

10. HW for HA Deployment Node n (PL-n) Linux OpenS AF Node director Agent Node 3 (PL-3) Linux OpenS AF Node director Agent Node 1 (SC-1) Linux OpenSAF Node director Server AgentDirector Node 2 (SC-2) Linux OpenSAF Node director Server AgentDirector Two Controllers + zero or more Payloads –NOTE: OpenSAF can run on single-node cluster as well Redundant communication network –NOTE: OpenSAF can run on non-redundant network as well

11. Operating System OpenSAF is most commonly deployed on Linux Using subset of Linux Standard Base interfaces –LSB - core –LSB - C++ –LSB - Runtime Languages Additional OS functionality required –TIPC (if MDS configured to use TIPC, which is default config) –SQLite, If IMM Persistent Backend feature enabled

12. Shared File System File system that is accessible from active controller Examples could be using –Shared-disk architecture SAN, NAS solution Clustered file system (OCFS2, GFS, etc.) –Shared-nothing HW architecture For example using DRBD to get “shared-disk” solution Using GNBD to export block devices to file servers

13. Shared File System and Middleware Shared/Cluster File Systems typically benefit to be controlled by common cluster management used in OpenSAF “As clustering has become more popular, so have the demands for a common cluster stack. One of the developments projects underway is to allow OCFS2 to work with user-space cluster stacks.” Source: OCFS2 User Guide

14. Shared File System and OpenSAF Today OpenSAF requires access to shared file system –Especially when IMM Persistent Backend is enabled –OpenSAF is decoupled from technology used to provide shared file system Shared File System benefits with integration with common system middleware

15. Way forward: OpenSAF and shared file systems Discussions in OpenSAF Project to remove OpenSAF dependency to shared file system –IMM (with PBE): would write to 2 instances of local file system For example writing to local file system on each controller –LOG Service –DTSv service (is deprecated and will be removed) Will enable more elegant usage of OpenSAF to control and implement shared/clustered file system.

16. Remote Management Access Man-Machine interface –Commercial CLI Agents –OpenSAF shell CLI commands: imm*, amf*, smf*, ntf* commands –OpenSAF Python based IMM OM Agent Machine-Machine Interface: –Examples: Based on HTTP, SOAP, SNMP, Netconf, XML- RPC, etc. OpenSAF Based System Configuration Management Fault Management Management Systems Management Daemons Optional, Modular, Pluggable IMM “CLI” IMMNTF

17. IP Load Balancing For applications that need that need to distribute workload across nodes of distributed system Can be achieved by entity external to the system –Examples Using Domain Name Server Application Protocol based balancing IP Load Balancers –Examples LVS

18. ”Load Balancing Clusters” Load Balancing tier Server tier Internet Storage tier

19. OpenSAF in Load Balancing Clusters ? Question: In which tiers can OpenSAF be used? –Server Tier (Workload logic typically modeled with N-way active redundancy model) –Load Balancing (Workload logic typically modeled with 2N redundancy model) –Storage tier (N-way active for shared-storage, N-way for shared-nothing architectures) Load Balancing tier Server tier Internet Storage tier

20. Database For applications that need to store large amount of persistent data Examples: –HLR/HSS node in Telco networks holding subscriber data –Web 2.0: Social sites (MySpace, Facebook) Components that could be used: –SQL: Raima, PostgreSQL, MySQL (Cluster) –“NoSQL”: Key-value stores (Cassandra, Hypertable, etc.)

21. Integration Example: Shared-storage DBMS Architecture Node WNode X Node 1 Node 2 DBMS SAF MW Component proprietary SU SG AIS Node 3 DBMS Component SU AIS Wrap P Apps DB API (Connector) DBMS Load Balancing DB API (Connector) AIS Shared Storage proprietary N-way active redundancy model used for DBMS Server processes DBMS Server process ”hooked- in” to AMF via Wrapper Process DBA API (like Connector) is transparently load-balancing Application requests

22. Backup Needs to be able to save important data to be able to restore system to backed-up state (for whatever reasons) Integrating OpenSAF in different backup solutions is simple –Persist IMM state to imm.xml file ( immdump ) Not needed when PBE enabled (PBE fdb file part of backup) –Save /etc/opensaf content –Plus other no-OpenSAF controlled data if needed Example of open-source backup solutions –Bacula –Amanda

23. Backing-up OpenSAF Figure Source: http://www.zmanda.com OpenSAF /etc/opensaf /repl_opensaf/imm.xml

24. Conclusion OpenSAF is an important component for building systems with Service Availability in mind –within Linux (& Unix, POSIX,...) ecosystem of components It is important to exercise deployment cases where OpenSAF is used with different components complementing its functionality Growing OpenSAF ecosystem of the components; (components whose availability and manageability is integrated with OpenSAF) will ease building of OpenSAF based systems

25. Questions ?

26. Thank You! For more information: http://devel.opensaf.org