Building Systems with OpenSAF Mario Angelic Expert Hans Feldt OpenSAF Technical Co-Chair

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

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

SCOPE Arhitecture

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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.)

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

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

Backing-up OpenSAF Figure Source: OpenSAF /etc/opensaf /repl_opensaf/imm.xml

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

Questions ?

Thank You! For more information: