1. DVTDS
Christian Hollstein, TeraCortex
www.teracortex.com

2. Presentation of DVTDS
Distributed Virtual Transaction Directory Server
By TeraCortex
●
Background
●
Architecture
●
Virtualization
●
Performance

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

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

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

6. New Solution Coming Up:
DVTDS

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

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

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

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

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

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

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

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

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

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

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

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

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

20. Throughput Scaling

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

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

23. Roadmap 2014
●
Automatic replica reconciliation after mirror network faults
●
Free configurable indices
●
User level documentation
●
Free demo version download

24. Thank you for your attention!
www.teracortex.com