Presentation is loading. Please wait.

Presentation is loading. Please wait.

Migrating a Legacy Application to OpenSAF Experience and Findings Using OpenSAF Ana Sanz Merino SAPC System Architect Ericsson.

Similar presentations


Presentation on theme: "Migrating a Legacy Application to OpenSAF Experience and Findings Using OpenSAF Ana Sanz Merino SAPC System Architect Ericsson."— Presentation transcript:

1 Migrating a Legacy Application to OpenSAF Experience and Findings Using OpenSAF
Ana Sanz Merino SAPC System Architect Ericsson

2 Agenda SAPC Overview SAPC to openSAF Drivers
SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

3 Ericsson’s Service Aware Policy Controller
Convergent Policy and Charging Control in Fixed and Mobile Access Networks SERVICES / BACK OFFICE M-TV Server IMS Domain External DB Self-Service Web Portal Rx Mobile access network presence 60 Contracts 150M Subscribers Fixed access network presence 110 Contracts 120M Subscribers LDAP SQL SOAP LDAP SOAP SAPC CENTRALIZED POLICY CONTROL Gx Gx Gy Rx RADIUS CoA Access GGSN DPI TRANSPORT LEVEL Non- Accesses BRAS DPI

4 SAPC on Proprietary Platform
Advantages Platform provides everything O&M support SW management & availability Data storage Process model Inter-application environment communication mechanism Disadvantages No HW flexibility Not easy 3PP integration Feature lead time constraints SAPC Java SAPC C++ Middleware O.S. HW TSP

5 SAPC on OpenSAF Advantages Challenges Different HW alternatives
Standard technologies & alignment on middleware layer Possible to reuse software Easy 3PP integration Open interfaces Broader developer community Challenges Need to adapt application to the new interfaces openSAF services’ characteristics might be different from the equivalent legacy platform service Not all legacy platform services supported by openSAF: add components to cover the difference SAPC Java SAPC C++ Java EE AS Middleware O.S. Ericsson HW COTS

6 OpenSAF 4.0 Services Used by SAPC

7 Agenda SAPC Overview SAPC to openSAF Drivers
SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

8 SAPC Experience w/ IMM Service
openSAF IMM Frequent reads from every payload node Infrequent writes In-memory storage Optimized for read access Not high throughput writes Small number of objects Limited volume of data Required redundancy, but not persistency Data redundancy Optional persistent back-end Access synchronization IMM is good for SAPC configuration data

9 Node Management System
SAPC & IMM Object Manager API (OM-API) Create, access, and manage configuration objects/attributes Node Management System Adaption provided towards OAM interfaces OAM Java Logic C++ Logic SAPC Java IMM Conf Data Adapters SAPC C++ CM IMM Conf Data Adapters Access to configuration data during traffic processing Java EE AS Java Adaptation OM-API (create) OM-API (access) OM-API (access) Adaptation provided to access from Java openSAF IMM Config Data

10 IMM Conf Data Validator
SAPC & IMM Object Implementer API (OI-API) To deliver the operations requested by Object Managers to the appropriate Services or applications that implement these objects At object creation, IMM Service invokes any existing Object Implementer synchronously to validate the creation request WrongObjectX Conf Data ERROR OAM 1 4 SAPC C++ CM IMM Conf Data Validator OM-API (create) OI-API (validate) 2 3 Useful for validations or configuration data openSAF IMM Conf Data

11 Agenda SAPC Overview SAPC to openSAF Drivers
SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

12 SAPC Experience w/ AMF Service
Different redundancy models to adapt to application needs Just a few simple ones used 2N for redundancy N-way active for load balancing SCN 1 SCN 2 PL 1 PL 2 ImmValidatorSG: 2N TrafficLogicSG: N-way active ImmValidatorSU ImmValidatorSU TrafficLogicSU TrafficLogicSU IMM VALIDATOR IMM VALIDATOR TRAFFIC LOGIC TRAFFIC LOGIC active standby active active AMF provides simple, flexible and robust high availability support to SAPC

13 Agenda SAPC Overview SAPC to openSAF Drivers
SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

14 SAPC Experience w/ CKPT Service
openSAF CKPT Frequent reads and writes from every payload node Required redundancy, but not persistency In memory storage No persistent storage Local reads/writes depend on checkpoint type Data redundancy Expiration on inactivity Retention and expiration time Number of sessions in the order of millions Limit of 1000 replicas per node CKPT is a good to store session data Good performance while guaranteeing redundancy Automatic session clean-up

15 Collocated Checkpoint for SAPC Session
Session Establishment Session Modification 1 2 SC 1 SC 2 PL 1 PL 2 SAPC Java SAPC C++ SAPC C++ SAPC Java Java EE AS Java EE AS 1 2 CPSv CPSv CPSv CPSv Session X Session X openSAF openSAF openSAF openSAF With SAPC N-way active AMF model, collocated checkpoint redundancy not guaranteed

16 Non-Collocated Checkpoint for SAPC Session
Session Establishment Session Modification 1 2 SCN 1 SCN 2 PL 1 PL 1 SAPC C++ SAPC Java SAPC C++ SAPC Java Java EE AS Java EE AS 1 2 CPSv CPSv CPSv CPSv Session X Session X Session X 1 2 openSAF openSAF openSAF openSAF Thanks to the different CKPT types, CKPT redundancy can be guaranteed for SAPC: use non-collocated checkpoint Local read/writes with non-collocated CKPT can be guaranteed with distribution algorithm of requests so that same session always handled in same PL blade

17 SAPC Session Model in CKPT
CKPT_ID: SAPCSession#<Session Container ID> Multiple sessions per checkpoint Each session data in a section SECTION_ID: <Session ID> {"sessionData":<JSON string with all session attributes>} CKPT limit in number of objects not a problem

18 Agenda SAPC Overview SAPC to openSAF Drivers
SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

19 SAPC Conclusions on OpenSAF Services
IMM is good for SAPC configuration data CKPT is good to store session data AMF provides simple high availability support for SAPC OpenSAF services SW quite robust

20 OpenSAF advantages for SAPC
SAPC General Conclusions on OpenSAF More standard and open interfaces Broader developer community Possible to reuse software Easy 3PP integration Reuse ideas from open source community OAM and Java Adaptation modules reused from other products OpenSAF advantages for SAPC Software-Hardware decoupling Same SW deployed in different HW Ericsson Blade System and COTS (SUN Blades)


Download ppt "Migrating a Legacy Application to OpenSAF Experience and Findings Using OpenSAF Ana Sanz Merino SAPC System Architect Ericsson."

Similar presentations


Ads by Google