• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Distributed Virtual Transaction Directory Server

Distributed Virtual Transaction Directory Server






Total Views
Views on SlideShare
Embed Views



1 Embed 95

http://lanyrd.com 95



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Distributed Virtual Transaction Directory Server Distributed Virtual Transaction Directory Server Presentation Transcript

    • DVTDS Christian Hollstein, TeraCortex www.teracortex.com
    • Presentation of DVTDS Distributed Virtual Transaction Directory Server By TeraCortex ● Background ● Architecture ● Virtualization ● Performance
    • Background: LDAP in Mobile Networks 4G network IMS domain HSS MME IMSAS LDAP CSCF LDAP 3Com CoreBuilder 5000TM Switching Hub LDAP Transactions mgt fb fb fb fb tpl6 tpl6 fb Media Server fb fb fb 5302m SDM Directory LDAP Provisioning System 3G HLR network GGSN MSC SGSN
    • LDAP based Subscriber Data Management ● 3GPP standard rules LDAP as central repository ● Several hundred mobile operators / deployments worldwide ● Major vendors: Ericsson, Huawei, NSN, ZTE, Alcatel ● NSN alone serves 3.2 billion subscriber records ● Several dozen entries per subscriber record ● Probably largest directories worldwide
    • Consequences for Directory Products ● Millions of subscriber records → billions of entries ● Data federation / distribution ● High availability → geo -redundant deployment / replication ● Consistent provisioning → transaction safeness ● Update signaling to applications → triggers ● Multi application environments → data model virtualization ● High volume traffic → near real time behavior
    • New Solution Coming Up: DVTDS
    • DVTDS Distributed Architecture Client Client Client LDAP Possible session path DVTDS 1000 million keys on 64 GB (mirrored) machine ... Client … > 1000 • LDAP protocol for chaining • Multi level hierarchy • Leaves may be any LDAP server • Sessions span over several servers • Servers may be replicated • Distributed transactions LDAP Chaining DVTDS ... (chained) (chained, mirrord) ... LDAP Chaining
    • Client Session path Data Replication • Symmetrical Multi Master Replication • No single point of failure LDAP connection to • Logical DSA concept • Compatible with LDAP chaining any of the • Priority based conflict resolving, real time mirrors • LDAP protocol • Up to eight servers per DSA, fully meshed • Transaction safe (Mirror 1) (Mirror 0) LDAP Mirror (Mirror 2) (Mirror 3) Logical DSA
    • Replication and Conflict Resolving • Conflicts recognized and handled in real time • Based on request, user and server priority • Keeps to ACID paradigm • Data consistent across sites under attack • Winner gets “Success”. Looser gets “Busy” User Prio 7 LDAP Delete Prio 0 Session path User Prio 4 LDAP Modify Prio 1 Session path Object Object Resolver Resolver Object Object Resolver Resolver DVTDS Site A Prio 2 LDAP Mirror DVTDS Site B Prio 5
    • System Integration and External Interfaces Applications / Provisioning LDAP Client Port ... SOAP/ HTTP LDIF Binary ASN.1 Capture Port ... Trigger Log File ... ... LDAP CSV Backup / Data Migration LDIF Admin Port ... CSV LDIF CSV Reports ... Restore / Data Migration ... Data Federation LDAP ... Data ... Replication LDAP LDAP CSV LDIF OAM System
    • Internal Architecture Client Ports Session ... Capture Ports Session, queue control ... DVTDS Protocol Stack Protocol Stack Protocol Stack Object Resolver Object Resolver Object Resolver Execution Unit Execution Unit Execution Unit Interlocking sub system Directory Information Tree Central Data Area Hard disk sub system Configuration Schema Backup/Restore Traffic control Tuning DNS Licenses Logging/Audits ... Interfaces: Trigger Backup Restore Migration Reports Admin Log files Chaining Replication
    • Architectural Features ● Free configurable client ports ● Each client port serves a number of sessions ● Each session lives inside its own worker thread ● Object level locking system ● Direct data allocation on memory mapped hard disk volumes ● Volumes maybe cooked or raw file space
    • LDAP Data Model Virtualization Data access via application views HSS HLR MMS Physical data access (No views) AAA IMS Application Data M2M View Layer PCRF Core Data MNP FixedNet Provisioning System Social Networks
    • Supported LDAP View Mechanisms ● Transparent aliases ● Rule based bidirectional DN conversion ● Virtual objects ● Virtual and real attributes can be mixed in any object ● Soon: Rule based bidirectional attribute/value conversion ● Integrated in the DVTDS kernel → little overhead ● Online configurable → no service interruption
    • Data Aggregation by Virtualization: Physical Telco Model dc=Enterprise dc=IMSI oc: dcObject dc=EMAIL dc=IMSI oc: dcObject dc=MSISDN dc=IMSI oc: dcObject o=<BusinessUnit> dc=IMSI dc=ACCOUNT dc=IMSI oc: organization oc: dcObject oc: dcObject ou=subscriberData mail=me@teracortex.com IMSI=777888000000001 oc: imsiUidAlias mailAlias IMSI=777888000000001 MSISDN=4916096220958 oc: imsiUidAlias msisdnAlias IMSI=262011100000001 IMSI=777888000000001 oc: imsiUidAlias imsiAlias account=1234abcd IMSI=777888000000001 oc: imsiUidAlias accountlAlias oc: organizationalUnitt UID=777888000000001 oc: inetOrgPerson Access Path ... dc=configurableViews dc=IMSI oc: dcObject ou=MOBILE ou=EMAIL ou=FiXED ou=IDENTITY dc=IDENTITY Mobile Data Email Data Fixed net data Subscriber Identities dc=FIXED dc=EMAIL dc=MOBILE oc: mobileData param0: real value param1: real value ... Mobile: reference oc: eMailData param2: real value param3: real value ... Email: reference oc: fixedNetData param4: real value param5: real value ... Fixed Net: reference oc: identityData param6: real value param7: real value ... Identy: reference
    • View Mechanism Properties ● Each subscriber has individual data below uid=... ● Accessed via transparent aliases ● Application view data outside of subscriber data ● Found by two stage resolving algorithm ● Different applications can share physical data
    • Example: Server – Side DN Conversion DN as sent by the client: ou=mobile,impi=sip:262000000000000@ims.telekom.de,dc=IMPI Server Side Conversion Rule: clientDn: *,impi=(sip):([0-9]+)@(ims.telekom.de),dc=IMPI serverDn: imsi=#3(2),dc=IMSI DN as used by the server: ou=mobile,imsi=262000000000000,dc=IMSI
    • 1000000 Throughput in absolute numbers 900000 DVTDS Intel I7 4960X 6 Cores @4.6 GHz 32 GB RAM 7 x SATA 7200 RPM 28 Million entries Operations / s 800000 700000 600000 Oracle OID Sparc T5-2 32 cores @3.6 GHz 512 GB RAM Flash disk array 50 million entries 500000 400000 300000 200000 100000 Entry load LDAP Add LDAP Search LDAP Modify LDAP Compare
    • Throughput per GHz CPU speed 27000 DVTDS Intel I7 4960X 6 Cores @4.6 GHz = 27.6 GHz Operations / s 24000 21000 18000 Oracle OID Sparc T5-2 32 cores @3.6 GHz = 115.2 GHz 15000 12000 9000 6000 3000 Entry load LDAP Add LDAP Search LDAP Modify LDAP Compare
    • Throughput Scaling
    • Notes on 3D Server Throughput Diagram ● 2 Variables: queue length and number of clients ● Throughput increases with bigger queue length ● Throughput scales by number of cores and clients ● Saturation on 6 core machine at 6 clients ● Degradation when operated beyond saturation ● Linear scaling if not bottle - necked by memory bandwidth
    • Scaling the Data 540 Million entries inetOrgPerson 22 Attributes LDIF size: 532 bytes ine L rs a c ing al • 540 million entries in less than 2 hours • Naming attribute was indexed • Indexing time included, no setup time • Multi threaded object loader • LDAP protocol / BER object format • 30 GB RAM, 366 GB data base size 114 Minutes load time
    • Roadmap 2014 ● Automatic replica reconciliation after mirror network faults ● Free configurable indices ● User level documentation ● Free demo version download
    • Thank you for your attention! www.teracortex.com