01 CN66531EN92GLA0 One NDS Components PDF

One-NDS Components
One-NDS Components
Contents
One-NDS Components 1
1 The different components 3
1.1 Directory Server Agent (DSA) 4
1.2 One-NDS Administrator (ADM) 4
1.3 Installation Server (IS) 4
1.4 Provisioning Gateway (PGW) 5
1.5 Provisioning Gateway DSA (PGW-DSA) 5
1.6 One-NDS components 6
2 Relevant Directory Server Functions 7
2.1 DS Modes 8
2.2 One-NDS Key Processes 10
2.3 Hardware and Software of a Directory Server 26
2.4 Journaling 28
2.5 Startup and Shutdown 37
2.6 One-NDS and B&R 44
CN66531EN92GLA0
Copyright ©2014 Nokia Solutions and Networks. All rights reserved.
1
One-NDS Components
CN66531EN92GLA0
2 Copyright ©2014 Nokia Solutions and Networks. All rights reserved.
One-NDS Components
1 The different components
CN66531EN92GLA0
3
One-NDS Components
1.1 Directory Server Agent (DSA)

The Directory Server Agent (DSA) is the part of One-NDS which contains a directory
database, accessible via the LDAP protocol. Normally the subscriber database is
distributed over several DSAs in two logical layers. The two layers are the Index and
the actual Subscriber Profile.
For redundancy reasons each DSA consists of at least three Directory Servers (DSs)
which are physically located at different geographical sites.
1.1.1 Routing / FrontEnd DSA

The Routing or FrontEnd DSA stores access keys and references to the database
entries (subscriber data) for centralized access by the Application Clients. For
redundancy and load distribution the Index information is replicated (mirrored) to
several servers (minimum of three), depending on the size of the database and the
number of Application Clients.
The One-NDS has only one Routing / FrontEnd DSA.
1.1.2 BackEnd DSA

The BackEnd DSA is the part of the directory contains the actual data content
(subscriber data) of One-NDS and contains between 2 and 4 million profiles,
depending on the hardware used and the size of a single profile. If the subscriber
database needs to contain more profiles, then additional BackEnd DSAs can be
added.
One BackEnd DSA always consists of three Directory Servers (DSs) located on three
different geographical sites.
1.2 One-NDS Administrator (ADM)

The One-NDS Administrator (ADM) is an independent management system used for
the administration of the One-NDS Directory, PGW configuration, and Notification
Manager (NTF). Over the ADM, authenticated clients and authorized users can
perform tasks, for example, in the One-NDS Directory. The tasks include relocating
subscribers from one BE-DSA to another, monitoring subscriber data storage,
schema management, checking data consistency and administering new DSAs.
1.3 Installation Server (IS)

It is not possible to install One-NDS manually because of the amount of servers and
software packages. For installation and software update of a complete One-NDS,
three Install Servers (IS) are necessary, one on each site.
CN66531EN92GLA0
One-NDS Components
1.4 Provisioning Gateway (PGW)

For easier provisioning, a standardized XML based language; called SPML (Service
Provisioning Markup Language) is used.
The Provisioning Gateway is the access point for provisioning systems and converts
SPML into LDAP and back. To overcome all redundancy functions, offered by One-
NDS, three PGWs are available. These three PGWs are also located on the three
sites like a DSA.
1.5 Provisioning Gateway DSA (PGW-DSA)

1.5.1 Config DSA
The Config DSA is used to store the configuration data of the PGW. The
configuration data provides information about the topology of the One-NDS Directory:
number of DSs of the Routing and PGW-DSA, distribution of these DSAs over
geographical sites, number and IDs of BE-DSAs, IP addresses, presence of separate
application LAN, presence of PGWs, PGW IP addresses, distribution of PGW
geographical sites, and so on.
1.5.2 Notification Manager (NTF)

The Notification Manager (NTF) is a central component for distributing all
notifications from One-NDS components, that is, the NTF is responsible for the
distribution of SOAP trigger messages from the One-NDS Directory to both PGW and
Application Servers. The NTF stores the subscription information from different
applications in the One-NDS Directory.
TIP
A trigger interface is used to notify Application Servers (e.g. HLR, PCS, etc.) about
data changes in the One-NDS.
CN66531EN92GLA0
5
One-NDS Components
1.6 One-NDS components

Site 1 Site 2 Site 3
Appl. FE
B&R
IS
ADM
SM2
PGW
PGW-DSA
incl. NTF
R-DSA
BE-DSAs
Fig. 1 One-NDS components
CN66531EN92GLA0
One-NDS Components
2 Relevant Directory Server Functions
CN66531EN92GLA0
7
One-NDS Components
2.1 DS Modes
2.1.1 Primary
The responsibilities of the Primary Directory Server are:
 Processing of updates and queries SDF == DS
 Replicating updates to SSDFs

 Synchronization of SSDFs
 Inter-SDF Reconciliation
 Nomination of Primary Standby
2.1.2 Secondary Synchronized

The responsibilities of the Secondary Synchronized Directory Servers are:
 Processing of queries
 Processing of replication updates
 In case of Primary Standby: Detection of Primary failure and failover
2.1.3 Secondary Unsynchronized

The responsibilities of the Secondary Unsynchronized Directory Servers are:
 Transitory state
 Can be configured to contribute operationally
 Used to facilitate upgrades
CN66531EN92GLA0
One-NDS Components
Primary
initial
failover
Primary
Standby
Secondary
Synchronised
Secondary
Unsynchronised
Automatic Transition non-functioning

Automatic or Manual Transition
System Stop – Request or Failure
Fig. 2 Secondary Unsynchronized para maiores detalhes vide o curso: 02_CN65402EN90GLA0_key_processes

ITEM 2.8.2
CN66531EN92GLA0
9
One-NDS Components
2.2 One-NDS Key Processes

2.2.1 Initial Bind Operation
Incoming LDAP connections are initially processed by the LDAP controller process
(A16C) which nominates one of a number of LDAP worker processes (A16W) to
handle operations from that client.
When the LDAP client makes the initial connection, it does so to the LDAP controller
process (A16C). This decides which of the LDAP worker processes (A16W) are most
appropriate and passes the connection to the chosen worker which completes the
connection. All subsequent operations, including the bind, are handled by the LDAP
worker.
The LDAP controller is in constant communication with each of the LDAP worker
processes, using shared memory to exchange information. When a new connection
is received, the controller decides which worker process should handle the client
based upon the number of connections and the number of outstanding operations
each worker is currently processing.
The controller then passes the connection to the nominated worker which handles all
operation requests from that connection until it is terminated.
CN66531EN92GLA0
One-NDS Components
Initial Bind Operation
DS
A16C A16W A16W
LDAP Client 1 … 35
TCP Port
16611
Listen exchange
LDAP information
LDAP
Fig. 3 Initial Bind Operation
A16C - LDAP controller process

A16W - LDAP worker process
1 ©2013 Nokia Solutions and Networks. All rights reserved.
CN66531EN92GLA0
11
One-NDS Components
2.2.2 Local Search (intra DSA)

The worker communicates with the LDAP controller via shared memory so that the
controller has up-to-date knowledge of each worker’s workload, enabling it to make
informed decisions about which worker should handle new client connections (this is
true for all LDAP operations).
Search actions or so called queries can be received at any NDS (network directory
server), that is primary (P), primary standby (PS) and secondary synchronized (SS).
Procedure
First the receiving process starts a search action at the local database. If the query
processing was successful internally, a query response is generated and sent by the
receiving process.
TIP
NDS=DS
Local Query
SITE A SITE B SITE C
Application
Query NSR
(e.g. HLR-FE)
LDAPsearch
A16C A16W
R-DSA
RAM
P PS SS
BE-DSA
SS PS P

Fig. 4 Local Query
CN66531EN92GLA0
One-NDS Components
2.2.3 Remote Search (inter DSA)

The query operation is received by the LDAP worker process which performs any
attribute adaptation and adaptive naming required. It then determines that the target
of the operation is an entry held by a remote DSA and forwards the request to the
remote operations router (A32). This transfers the query to the remote operations
router on the appropriate DSA, which passes it to the remote request server (DAPC),
where the operation is performed and the result returned.
Procedure
First the receiving process starts a search action at the local database
If the search action does not find the starting object a chain query is created and
forwarded to A32 to contact the next DSA.
A32 generates a new message, a so call DSP Chained Query and sends it to the
remote DSAs A32 process. This process removes the DSP header and forwards the
DAP query to the DAPC process for processing.
The executing process is performing the search action and creating the response
message. The response is taking then the same way back
TIP
 Directory Access Protocol (DAP)
Directory Access Protocol (DAP) is the protocol defined in the X.500 standard for
external clients (DUAs) to access the directory.
 Directory System Protocol (DSP)
Directory System Protocol (DSP) is used for DSA to DSA communication when
chaining operations to other DSAs. When a DSA passes an operation (or part of
an operation, for example when a search operation spans a subtree distributed
across more than one DSA), the DSA is said to chain the operation. Chaining will
typically occur when the name resolution process determines that the target object
is not held locally and has at least one reference to another DSA that may hold the
object or be able to chain the operation on further. As noted, search operations
may sometimes result in a form of chaining when the search is a subtree search
and parts of the sub-tree are on different DSAs.
CN66531EN92GLA0
13
One-NDS Components
Remote Query
site A site B site C
PGW e.g.disp MSUB
LDAPsearch
A16C A16W
R-DSA
RAM
A32
P PS SS
BE-DSA A32
RAM
DAPC
PS SS P

Fig. 5 Remote Query
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CN66531EN92GLA0
14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
2.2.4 Local update and replication, primary receives the

request
The update operation is received by the LDAP worker (selected before by A16) which
performs the local update
A16W has to convert the LDAP request into a DAP message.
In the example below a new subscriber is created and the primary DS (P) of the R-
DSA has to update his memory. New pointers have to be created in the R-DSA to
localize the subscriber in the BE-DSA.
In the next step the primary has to update (replicate) the data of the P and SS in his
own DSA (see next page).
Local Update
Request Rcvd by Primary DS
PGW e.g.create NSR
LDAPadd
A16C A16W
R-DSA
RAM RAM RAM
A31
P A31 A31 PS SS
BE-DSA
P PS SS

Fig. 6 Request received by Primary DS
CN66531EN92GLA0
15
One-NDS Components
2.2.5 Local update and replication, other than primary receives

request
If the local A31 is not primary, it will forward the update request to the primary.
In the example below the primary standby (PS) receives the request on site B. The
PS sends the request to the primary on site A.
In the next step the primary (A31) has to update (replicate) the data of the P and SS
in his own DSA.
Local Update
Request Rcvd by Secondary DS
PGW e.g.create NSR
LDAPadd
A16C A16W
R-DSA
RAM RAM RAM
A31
A31 A31
P SS
PS
BE-DSA
P PS SS

Fig. 7 Request received by Secondary DS
CN66531EN92GLA0
One-NDS Components
2.2.6 Remote Update (same site)

A remote update operation is simply an extension of the remote query operation.
When the request is received by the remote request server (DAPC), it forwards it to
the update server (A31).
Procedure
If the target object or a part of it is stored or mastered by another DSA the receiving
one forwards the update to the primary DS of the next DSA.
The receiving DS will look if the request must be processed here. If not it is creating a
chained update and sending it to A32. A32 will create a DSP message and forward it
to the primary DS of the remote DSA. The remote DS will receive the message with
A32 and process it with A31.
The response will take the same way back and A31 of the starting primary DS will
create the update response message for the client.
Remote Update
Same Site
Application
(e.g. HLR-FE) LUP/VLRid
LDAPmodify
A16C A16W
R-DSA
A32
SS PS P
BE-DSA A32 DAPC
RAM RAM RAM
A31
A31 PS A31
P SS
Fig. 8 Remote Update (same site)
CN66531EN92GLA0
17
One-NDS Components
2.2.7 Remote Update (across WAN)

A remote update operation is simply an extension of the remote query operation.
When the request is received by the remote request server (DAPC), it processes the
operation, determines that it is an update and forwards it to the update server (A31),
as shown in the following figure.
First the query operation is received by the LDAP worker process .It then determines
that the target of the operation is an entry held by a remote DSA and forwards the
request to the remote operations router (A32). This transfers the query to the
remote operations router on the appropriate DSA, which passes it to the remote
request server (DAPC), where the operation is performed.
Remote Update
across WAN
Application
(e.g. HLR-FE) LUP/VLRid
LDAPmodify
A16C A16W
R-DSA
A32
P SS PS
BE-DSA A32 DAPC
RAM RAM RAM
A31
A31 PS A31
P SS
Fig. 9 Remote Update (across WAN)
CN66531EN92GLA0
One-NDS Components
2.2.8 Synchronization Process

Synchronization is the process by which a Directory Server node can join or rejoin a
live cluster. The Directory Server is started from a backup, and the Primary Directory
Server automatically supplies all update operations made since the backup was
taken. Once all historical updates have been applied the node is considered
synchronized and is available for service.
Synchronization is also used to recover from a temporary communication failure
between the Primary Directory Server and another of the Directory Servers in the
cluster. This operation is performed automatically as soon as the communication link
is restored.
The figure below shows an unsynchronized DS (cdb4be2)
With the help of the ADM or CLI command (synchronize_ds) the server must be
synchronized now if it happens not automatically.
Fig. 10 Unsynchronized DS
CN66531EN92GLA0
19
One-NDS Components
2.2.9 Synchronization Procedure

First the Secondary DS, which is unsynchronized, is started from a database backup
which is stored on the hard disk. Then synchronization must be started manually by a
certain command action (CLI command synchronize_ds) on the OS level.
The manual or automatic mode change from unsynchronized to synchronized is
handled by the process A22 of the Directory Server.
This Process is responsible for the whole mode control. It controls the local mode
and monitors/stores the mode of the remote DS in the same DSA and the referenced
DSA.
After initiating the synchronization A22 sends synchronization request to the local
A31 process. This process looks first to the local journal for the last transaction ID
(TID) and sends it to A31 of the primary DS within the synchronization request
message.
A31 of the primary sends now the missing journal updates to the A31 of the
secondary.
At the end the A31 of the primary sends the synchronization complete message over
the A31 of the secondary to A22 of the secondary.
After synchronization the mode change procedure is started. The A22 of the
secondary moves the local state to synchronized and sends a mode change
message to the A22 of the primary via the two A31 processes.
2.2.9.1 Mode Control Process
The mode control process is responsible to manage the mode of the DS. It can set
the states from Unsynchronized to Synchronized or from Secondary to Primary etc.
At the mode change from Unsynchronized to Synchronized the A22 process sends a
synchronization request to A31.
2.2.9.2 Synchronization Execution Process
The Synchronization is executed by the DS interconnection process A31. The
process from the primary DS gives the missing updates to the secondary
unsynchronized one.
CN66531EN92GLA0
One-NDS Components
DSA
site A site B
DS DS
SYCO A31 SYCO A31
Journal in-memory Journal in-memory
File Journal P File Journal SU
Unsynchronized
Synch. request
(current commit ID)
syco link 2 1
3 syco link update
5 syco link closed
SS

Fig. 11 Synchronization Process
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
CN66531EN92GLA0 . . . . . . . . . . . . . . . . . . . . .
. . ©2014
Copyright . Nokia
. .Solutions
. . and.Networks.
. . All.rights. reserved.
. . . . . . . . . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
2.2.10 Reconciliation Processing

There are two types of reconciliation checks done; inter-NDS (intra-DSA) checks and
inter-DSA checks. Inter DSA reconciliation is used when multiple DSA are involved
with distributed data. The validity of all references and DSAs are checked by verifying
whether the other end on the reference exists. It is similar to inter NDS reconciliation
and is scheduled as a low priority activity. It can take hours/days to cycle through all
references.
If reconciliation problems are detected an alarm will be raised and forwarded to a
higher management system like @vantage commander, NetAct, Netcool etc. (see
figure below):
SDF:SDF 00005 0241 2

Inter-DSA reconciliation error
1 Fig. 12 Alarm ©2013 Nokia Solutions and Networks. All rights reserved.
CN66531EN92GLA0
One-NDS Components
2.2.11 Intra-DSA reconciliation

The primary DS within every DSA performs continuing database consistency checks
with the process A36. Checksums are produced which are packed together to a block
and are sent via A36 to A36 of the secondary DSs.
At the secondary DS the local database is rechecked and the result is given back to
the primary.
Intra-DSA (Inter SDF) Reconciliation
DSA
DS DS DS
A36 A36 A36

P PS SS
Checks Checks Checks
Check data block
Checks OK
Database consistency
checks -> checksum
A36 - Intra-DSA Reconciliation
Fig. 13 Intra-DSA reconciliation
CN66531EN92GLA0
23
One-NDS Components
2.2.12 Inter-DSA reconciliation

The A3C process of the primary DS of the BE-DSA reads a block of references from
the database. This block is sent over the inter-DSA process A32 to the primary DS of
the R-DSA.
At the primary of R-DSA the A3C process compares the references and sends back
the result to A3C of the calling DS in the same by.
R-DSA BE-DSA
site A site C
DS DS
A3C A32 A3C A32

P P
Reference Block
Ref. Blocks
Reference Check
Checks OK Checks OK
Checks OK
A3C - Inter-DSA Reconciliation
A32 - Remote Operations Router
Fig. 14 Inter-DSA reconciliation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 . . . . . . . . . . . . . . . . . . . .©2013
. .Nokia
. Solutions
. . . and. Networks.
. . .All rights
. . reserved.
. . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CN66531EN92GLA0
24 . . . . . . . . . . . . . . . . . . . . . Copyright
. . .©2014
. Nokia
. .Solutions
. .and.Networks.
. . All .rights. reserved.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
For consistency check the ADM offers a tool which handles the checking in 6 steps.
ADM -> Consistency Check
Fig. 15 Consistency check
TIP
In EP6 the Automatic Hierarchical Object Binding (HOB) Repair feature has
introduced new functionality to the management of HOBs:
©2013 Nokia Solutions and Networks. All rights reserved.
Broken HOBs that are detected by the inter-DSA reconciliation process will be
automatically handled by the fix_references utility.
The fix_references utility has been enhanced so that it first attempts to repair the
HOB by re-establishing it, in preference to simply removing the broken HOB.
If repair or removal is not possible, the broken HOB will remain.
All instances of broken HOBs are reported.
CN66531EN92GLA0
25
One-NDS Components
2.3 Hardware and Software of a Directory Server

The Directory Server offers a directory database which is accessed with LDAP from
the clients, like it was describer previously. This X.500 database is located in the
random access memory (RAM) of the computer during operation, but for a working
system, more components are needed.
Processes
The processes are executables which offer all the necessary functions.
Files located on the hard disk
The whole database and the logs are saved periodically on the hard disk. It includes
database backups, logs, schemas, journals and memory backups.
CN66531EN92GLA0
One-NDS Components
Directory Server components

in-memory-journal
RAM
LDAP- IMJ
Directory
HDD
backup journal
files schema logs files
Fig. 16 Directory Server Components
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
. . . . . . . . . . . . . . . . . . . ©2013
. Nokia
. .Solutions
. and. Networks.
. . All . rights
. reserved.
. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CN66531EN92GLA0
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
2.4 Journaling
2.4.1 Update Operation
The update operation is first recorded in the in-memory database and the in-memory
journal when it is accepted by the NDS node.
After operation processing, which may involve coordination between the primary
node and the secondary node(s), the update is committed (unless it is part of a
transaction, when it is not committed until the transaction is committed). The update
operation commit is recorded in the in-memory journal (regardless of success or
failure) and subsequently written to a journal file.
Primary DS
in- in-
memory memory JTASK journal File
journal DB
update
updates in-memory
journal
updates local
in-memory db
A31
replicates update
to other Sync DSs
in DSA
A31
rcv ACK from

other DSs
send COMMIT
send COMMIT
to other DSs
to JTASK write update
to Disk-Based
Journal file
Fig. 17 Update operation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CN66531EN92GLA0
. . . . .
28 . . . . . . . . . . . . . . . . . . . . . .Copyright
. .©2014
. Nokia
. .Solutions
. .and.Networks.
. . All .rights. reserved.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
2.4.2 In-Memory Journal

The in-memory journal is a shared memory area, implemented as a circular buffer,
which stores details about all update operations. The journaling task, JTASK,
processes this buffer, writing the updates to disk-based journal files. In periods of
high load, it is possible that updates will be added to the buffer faster than they are
written to disk, and the in-memory journal will begin to “fill”. The information in the in-
memory journal is used for two key functions:
 Replication and
 Synchronization.
During replication the information may be used to rollback a replicated update that
has failed. During synchronization it will be used to transmit the latest updates to the
synchronizing node.
The transactions are stored in a circular buffer, i.e. when full, the oldest transactions
are overwritten. Thus the in-memory journal holds only a limited number of the latest
updates in the database.
If a synchronizing node attempts to resynchronize from a starting transaction which is
no longer in the primaries in-memory journal, the synchronization will fail.
At this point the failed secondary node will need to be restarted using more up-to-
date backup and/or journal files to ensure it will attempt resynchronization from a
more recent transaction.
The behavior of the in-memory journal may be configured by changing values of
attributes in the dsJournalControl (dsControl=journal) object.
key attributes explanation

dsJournalFullBehavior This may be rejectUpdates which causes all
updates to be rejected with an LDAP “unwilling to
perform” error code 53” until the journal is no
longer full,
dsJournalBlockedThreshold The initial percentage full value at which the
alarm is raised (Journal Buffer Filling) .The alarm
will be raised at three regular intervals between
this value and 100% so, for example, if this is set
to 20 (the default), the alarm will be raised at
20%, 40%, 60% and 80%.
dsJournalSyncWindowThreshold The expected period of time, in seconds, that a
secondary node can be offline and still be re-
synchronized from the in-memory journal. The
default is 3600 (1 hour).
CN66531EN92GLA0
29
One-NDS Components
2.4.3 Journal Files

Journal files contain details of all update operations performed by NDS and are
created by the JTASK process which processes the in-memory journal and records
the operation details on disk. A new journal file is created each time:
 The node starts-up,
 At midnight,
or
 When the file reaches the maximum permitted size (currently up to 200 Mbytes in
size or a maximum of 500,000 entries whichever occurs first).
The files not only contain the actual update but also information about when the
transaction was performed and by whom. The journal files consist of ASN.1 encoded
binary information. Because they are not human readable, however, utilities are
provided to examine journal files and report on client transactions.
The information is recorded in ASN.1 format so is not directly readable, but may be
accessed using the jrep utility
Journal files are a key component when restoring a node after a planned outage or
node failure. When used in conjunction with a backup file, a node can be restored to
the last transaction successfully performed before a planned shutdown (or failure)
and thus minimize the number of transactions the primary will need to retransmit to
synchronize the node.
In-Memory Journal
Fig. 18 Journal files recorded
CN66531EN92GLA0
One-NDS Components
TIP
Journal files are located in /opt/sdf/backup/journal and are identified using the current
date and a sequence number as shown above.
cdb2be1$ jrep -j journal.01.08022011.1

•# entryIndex: 3034
•# parentIndex: 2787
•# entryUpdateCounter: -1
•dn: o=counter,o=DEFAULT,dc=C-NTDB
•changetype: transactionSubject
•objectClass: NSSCOUNTER
•# commitId: 18590 $ 1
•# transactionId: (1,351,1,1)
•# updateStatus: success
•# userInvokeId: 7401
•# updateId: 08/02/2011 15:29:50.084168000 $ $ 16
•# user: pgwAdminUser
•# originalUser: pgwAdminUser a new service
•# userTransactionId: 06000000 was assigned to
•# receiptId: 18754 $ 1
•# entryIndex: 3034
a subscriber
•# parentIndex: 2787
•# entryUpdateCounter: 133
•dn: o=counter,o=DEFAULT,dc=C-NTDB
•changetype: modify
•objectClass: NSSCOUNTER
•replace: SubRegInAC
•SubRegInAC: 66
•# SubRegInAC: 65
•-
•# commitId: 18591 $ 1
•# transactionId: (1,351,1,1)
•# updateStatus: success
•# userInvokeId: 0000
•# updateId: 08/02/2011 15:29:50.085625000 $ $ 17
•# user: pgwAdminUser
Fig. 19 Journal file
CN66531EN92GLA0
31
One-NDS Components
2.4.4 Daily Backup

Backups are automatically created once a day at a configurable number of seconds
past midnight. Backups can also be requested by an operator from the command line
at any time.
The backup process starts by walking the directory tree (process “MONKEY”) and
writing each object it finds to the backup file in ASN.1 format. To limit the impact of
the backup, the database will remain available for normal activities throughout the
backup process (including the journaling).
TIP
As a result of this, as the backup process walks the tree, updates could be occurring
to areas of the tree already backed-up introducing inconsistencies in the backup file.
However the majority of these inconsistencies are resolved at restore time by
replaying the updates that occurred during the period of the backup. Some of the
inconsistencies however cannot always be resolved by replaying transactions, in
particular object moves (modifyDN with new superior). To handle these potential
inconsistencies, once the main backup is completed, additional supplementary
backups are performed. The supplementary backups, will output the objects of any
subtree moved during the previous phase of the backup. This supplementary backup
Backup config file
is repeated until no moves occurred in the previous phase.
The time of backup is defined in the file:
/opt/sdf/conf/af07_system_param.txt
•cdb2be1$
•cdb2be1$ cat /opt/sdf/conf/af07_system_param.txt
•#
•#
•#
•#
•# Time of database backup as number of seconds after midnight
•# Must be in range 0 - 86399
•#
•7200
•#
•# backup at 02:00 a.m
•#
•cdb2be1$
Fig. 20 Backup information
CN66531EN92GLA0
One-NDS Components
Any file in /opt/sdf/backup whose name begins af09_dailybkup will be automatically

removed by tidy_files process if it is older than 3 days.
TIP
tidy_files
Backup File isFormat
a shell script that is, by default, only accessible to the root user and is
configured by the NDS installation process, to run automatically every day at 5
minutes past midnight.
Header
Schema
Main Object Backup
Supplementary Backups
Fig. 21 Daily backup file
CN66531EN92GLA0
33
One-NDS Components
Main Backup Suppl. Backup 1 Suppl. Backup n
Daily backup file

Header
Schema
Main Object Backup
Supplementary Backups
Fig. 22 Main backup
Automatic backups are created in /opt/sdf/backup and named according to the

following pattern:
af09_dailybkup.ddmmyyyy
Backups requested by an operator are also created in /opt/sdf/backup, but are
explicitly named by the operator when the request is made.
When a backup is complete, the symbolic link,
/opt/sdf/backup/last_backup_file, is adjusted so that it references the most
recent backup.
Backup files can often be very large and manually requested backup files should
always be named using the af09_dailybkup prefix to ensure that they are deleted
(by tidy_files) when not required.
This can be critical as journal files are only deleted when all backup files made prior
to the journal file have been removed and if a backup file is not deleted, all
subsequent journal files will be kept, potentially impacting operation when the disk
becomes full.
The backup files, like the journal files, are also written in ASN.1 format and not
viewable directly, but may be viewed using the dsViewBackup utility. As they
CN66531EN92GLA0
One-NDS Components
contain all entries from the database, they may also be very large. To offset this, it is
possible to automatically compress backups as they are written using various
compression levels. By default, no compression is used, but the dsBkCompLevel
utility may be used to set a compression level for all automatic backups and any
manual backups where no compression level is explicitly requested.
TIP
dsViewBackup - display the contents of an NDS backup file.
dsViewBackup [-h] [-b filename] [-s] [-f]
Options
-h displays usage information
-b filename displays the contents of the named backup file.
-s displays the schema in addition to the header and the root DSE object.
-f displays the entire backup file contents (including the schema).
dsBkCompLevel
display actual level

•cdb2be1$
•cdb2be1$ dsBkCompLevel
•Backup default compression level: 0
•cdb2be1$
change actual level
•cdb2be1$ dsBkCompLevel -h
•Usage: dsBkCompLevel [-hy] [-z <0-9>]
•where options include:

• -h display usage information
• -y if setting the compression level then auto-confirm
• -z set the backup default compression level (0 to 9)
• default action is to output the current backup default compression level
•cdb2be1$
Fig. 23 dsBkCompLevel utility
CN66531EN92GLA0
35
One-NDS Components
Backups
•cdb2be1$ pwd backup time defined in

•/opt/sdf/backup
/opt/sdf/conf/af07_system_param.txt
•cdb2be1$
previous backup files
•cdb2be1$ ls -l
•total 4376
•-rw-rw---- 1 sdfrun sdf 1479274 2011-02-07 02:00 af09_dailybkup.07022011
•drwxr-xr-x 2 sdfrun sdf 4096 2011-02-08 11:39 journal
•lrwxrwxrwx 1 sdfrun sdf 23 2011-02-09 02:00 last_backup_file ->
af09_dailybkup.09022011
•drwx------ 2 root root 16384 2011-02-08 10:36 lost+found
•cdb2be1$
•cdb2be1$ dsViewBackup -b af09_dailybkup.09022011 -f

•……
Fig. 24 Backups
CN66531EN92GLA0
One-NDS Components
2.5 Startup and Shutdown
System Startup and Database Integry

Startup and Shutdown
©2013 Nokia Solutions and Networks. All rights reserved.
Fig. 25
CN66531EN92GLA0
37
One-NDS Components
2.5.1 Startup
NDS operation is controlled by a single daemon ndsd, which is started when the
operating system starts by /etc/init.d/nokiasiemensnetworks-ndsd.
The command-line utility, nds, performs a number of functions, including issuing start,
stop and restart requests to ndsd. The commands are:
 nds stop – This command requests that NDS be stopped in a controlled fashion.
Once complete, ndsd will wait for a start (or restart) request.
 nds start – If NDS is currently stopped, this command requests that ndsd starts
NDS.
 nds restart – This command requests that if NDS is running, it is stopped in a
controlled fashion and then immediately restarted. If NDS is not currently running,
it is started.
1. When ndsd is initially started, it will start NDS (Starting DS…).
2. The first step in this process is to cleanup from any previous NDS run. This
includes: renaming any core files it detects, killing off NDS processes that failed
to exit correctly, waiting for any outstanding backup requests to complete, tidying
up any temporary files and clearing inter-process communication queues
(Clearing old data).
3. The next stage in starting NDS is to ensure that the in-memory database is
loaded correctly. This part of the process is handled by dsRestore.(Restoring
database from backup/af09_dailybkup.12122011). If an in-memory database
is already loaded, it will be used, providing that the most recent backup taken
was from the loaded database, or, if no backup has been taken, the current
database was loaded from the most recent back-up. If this condition is not met,
the database will be loaded from the latest backup file.
4. Shared memory areas are created next
5. Start of all other NDS processes (Network Directory server starting
processes)
6. Journal updates are checked (A31) and applied to the in-memory database if
required.
CN66531EN92GLA0
One-NDS Components
Extract from initlog
1 [Mon Dec 12 16:56:14 CET 2011] Starting DS ...

2 [Mon Dec 12 16:56:15 CET 2011] Clearing old data
[Mon Dec 12 16:56:15 CET 2011] Restoring database from backup/af09_dailybkup.12122011
3
dsRestore: Created shared memory segment schema with huge pages size=4.00 MB
dsRestore: Created shared memory segment bkqueue with huge pages size=66.00 MB
4 dsRestore: Created shared memory segment emergency with huge pages size=2.00 MB
dsRestore: Created shared memory segment DB_00 with huge pages size=5.00 GB
dsRestore: Successfully built. Total database size 9.07 GB
dsRestore: Database restored (80717568 bytes, 2794 entries [0 duplicates])

[16:56:15] dsRestore : Reconciliation Successful.
[16:56:15] dsRestore : Backup file backup/af09_dailybkup.12122011 successfully restored.
Backup start and end commitId equal: no journal updates applied during restore.
dsRestore: Backup file backup/af09_dailybkup.12122011 successfully restored. No updates applied during
restore.
5 [Mon Dec 12 [16:56:22] CET 2011] Network Directory Server starting processes ...
Heap used 8% [864392 / 10000000]

EMF Management Registered NDS_A13 DSA 2 Node 2
6 [16:56:22] A31 : Journal replay: initiated
[16:56:22] A31 : No entries found for playback
Heap used 8% [864392 / 10000000]]
[2011-12-12 16:56:22.735+0100] Network Directory Server running
Fig. 26 Extract from initlog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CN66531EN92GLA0
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
Administration
You can start the NDS via ADM.
Procedure:
DSA Management -> DSA Administration -> (select a DSA ID) -> Details -> (select
DS-ID) -> Details -> Start DS
Fig. 27Start DS procedure
CN66531EN92GLA0
One-NDS Components
2.5.2 NDS Restart from Backup

1. When ndsd is initially started, it will start NDS (Starting DS…).
2. The first step in this process is to cleanup from any previous NDS run. This
includes: renaming any core files it detects, killing off NDS processes that failed
to exit correctly, waiting for any outstanding backup requests to complete, tidying
up any temporary files and clearing inter-process communication queues
(Clearing old data).
3. automatically load information from the backup file referenced by
/opt/sdf/backup/last_backup_file if it exists, otherwise it will load the
default database. Once the in-memory database is populated from the backup (or
default database) any update operations in the journal files whose commit id is
greater than the most recent commit id in the backup file are replayed, bringing
the node as close to the current state as possible. If the node is part of a multi-
node system, once all journal updates have been replayed, it will ask the primary
to re-synchronize it i.e. replay more recent updates that the primary node has in
its in-memory journal. A check is made that the primary’s in-memory journal has
not wrapped since the most recent update at the secondary i.e. still contains the
most recent update that the secondary has performed. If it does not, it is not
possible to ensure that the secondary has all updates and it will not synchronize
successfully. In this case, it will be necessary to take a backup on the primary or
another synchronized node and copy it and all journal files to the unsynchronized
node and restart from the new backup (removing any journal files that previously
existed on the unsynchronized node).
4. Shared memory areas are created next
5. Start of all other NDS processes (Network Directory server starting
processes)
6. Journal updates are checked (A31) and applied to the in-memory database if
required.
CN66531EN92GLA0
41
One-NDS Components
Extract from initlog
1 [Tue Dec 13 10:18:11 CET 2011] Starting DS ...

2 [Tue Dec 13 10:18:11 CET 2011] Clearing old data primary
[Tue Dec 13 10:18:11 CET 2011] Restoring database from
3 backup/af09_dailybkup.backup_1323767883626_by_DBM_of_SDF_3
[10:18:11] dsRestore : Backup Restoration Initiated. Backup file:
backup/af09_dailybkup.backup_1323767883626_by_DBM_of_SDF_3
[10:18:11] dsRestore : Restore backup file
backup/af09_dailybkup.backup_1323767883626_by_DBM_of_SDF_3
dsRestore: Created shared memory segment schema with huge pages size=4.00 MB
4 dsRestore: Created shared memory segment bkqueue with huge pages size=66.00 MB
dsRestore: Created shared memory segment emergency with huge pages size=2.00 MB
dsRestore: Successfully built. Total database size 9.07 GB
dsRestore: Database restored (80921632 bytes, 2546 entries [0 duplicates])

[10:18:11] dsRestore : Reconciliation Successful
[10:18:11] dsRestore : Backup file backup/af09_dailybkup.backup_1323767883626_by_DBM_of_SDF_3
successfully restored
[10:18:11] dsRestore : Backup start and end commitId equal: no journal updates applied during restore
5 [Mon Dec 12 [16:56:22] CET 2011] Network Directory Server starting processes ...
Heap used 8% [864392 / 10000000]

EMF Management Registered NDS_A13 DSA 2 Node 2
6 [10:18:48] A31 : Journal replay: initiated
[10:18:48] A31 : No entries found for playback
Heap used 8% [864392 / 10000000]
[2011-12-13 10:18:49.212+0100] Network Directory Server running
Fig. 28 Extract from initlog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CN66531EN92GLA0
42 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One-NDS Components
Administration
You can restart the NDS via ADM.
Procedure:
DSA Management -> DSA Administration -> (select a DSA ID) -> Details -> (select
DS-ID) -> Details -> Restart from Backup
Fig. 29 Restart from Backup procedure

CN66531EN92GLA0
43
One-NDS Components
2.6 One-NDS and B&R

In the database, each directory server (DS) of the routing-, BE-, and PGW-DSAs are
involved in the backup process. In this backup process, the actual roles of the DSs,
primary or secondary, play an important role in certain situations (see below). The
main characteristics of the backup process are:
 Each DS generates daily full backup files on the DS’s local hard disk. The time of
day at which this takes place is configurable, and preferably chosen to coincide
with a low traffic period.
 Each DS permanently generates journals (one entry for each DB change), that are
stored on the local DS’s hard disk. A new journal file is created each time the
server starts-up, at midnight and when the file reaches the maximum permitted
size. Journal files are identified using the current date and a sequence number.
 The automatically generated backup files and journals are kept on the local DS’s
hard disk for about five days. This duration can be configured in relation to the
available disk space. Ensure that no other files than the automatically generated
DS backup files and journals are stored in the opt/sdf/backup directory.
 The backup file plus on-disk journals are used during a server startup to seed the
database.
 In addition, each DS server has an in-memory journal. The in-memory journal is a
shared memory area storing details about all transactions. The information in the
in-memory journal is used during two key functions, namely replication and
synchronization. During synchronization, it is used to transmit the latest updates to
the synchronizing node. The transactions are stored in a circular buffer, i.e. when
full, the oldest transactions are overwritten. Thus, the in-memory journal stores
only a limited number of the latest updates in the database. The synchronization of
a restarted DS with the primary DS is performed automatically.
 If a synchronizing node attempts to begin resynchronizing from a transaction that
is no longer in the primaries in-memory journal, the synchronization will fail. The
failed secondary node will then need to be restarted using more up-to-date backup
and/or journal files. This ensures that it will attempt the resynchronization again
from a more recent transaction.
 The B&R concept for the three types of DS servers (Routing, BackEnd, and PGW)
is relatively the same.
CN66531EN92GLA0
One-NDS Components
Interconnection between network elements and B&R server
Site 1 Site 2 Site 3
Appl. FE
B&R
IS
ADM
SM2
WAN for WAN for
Inter- Inter-
PGW Site- Site-
Restore Restore
PGW-DSA
incl. NTF
R-DSA
BE-DSAs
Fig. 30 Interconnection between B&R and One-NDS
CN66531EN92GLA0
45
One-NDS Components
CN66531EN92GLA0

01 CN66531EN92GLA0 One NDS Components PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01 CN66531EN92GLA0 One NDS Components PDF

Uploaded by

Copyright:

Available Formats

One-NDS Components

1 The different components

1.1 Directory Server Agent (DSA)

1.1.1 Routing / FrontEnd DSA

1.1.2 BackEnd DSA

1.2 One-NDS Administrator (ADM)

1.3 Installation Server (IS)

1.4 Provisioning Gateway (PGW)

1.5 Provisioning Gateway DSA (PGW-DSA)

1.5.2 Notification Manager (NTF)

1.6 One-NDS components

Fig. 1 One-NDS components

2 Relevant Directory Server Functions

 Replicating updates to SSDFs

2.1.2 Secondary Synchronized

2.1.3 Secondary Unsynchronized

Automatic Transition non-functioning

Fig. 2 Secondary Unsynchronized para maiores detalhes vide o curso: 02_CN65402EN90GLA0_key_processes

2.2 One-NDS Key Processes

Initial Bind Operation

A16C A16W A16W

Fig. 3 Initial Bind Operation

A16C - LDAP controller process

2.2.2 Local Search (intra DSA)

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.3 Remote Search (inter DSA)

PGW e.g.disp MSUB

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.4 Local update and replication, primary receives the

PGW e.g.create NSR

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.5 Local update and replication, other than primary receives

PGW e.g.create NSR

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.6 Remote Update (same site)

BE-DSA A32 DAPC

RAM RAM RAM

2.2.7 Remote Update (across WAN)

BE-DSA A32 DAPC

RAM RAM RAM

2.2.8 Synchronization Process

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.9 Synchronization Procedure

3 syco link update

5 syco link closed

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.10 Reconciliation Processing

SDF:SDF 00005 0241 2

2.2.11 Intra-DSA reconciliation

Intra-DSA (Inter SDF) Reconciliation

A36 A36 A36

Checks Checks Checks

Check data block

A36 - Intra-DSA Reconciliation

Fig. 13 Intra-DSA reconciliation

1 ©2013 Nokia Solutions and Networks. All rights reserved.

2.2.12 Inter-DSA reconciliation

A3C A32 A3C A32

Fig. 14 Inter-DSA reconciliation

ADM -> Consistency Check

Fig. 15 Consistency check

2.3 Hardware and Software of a Directory Server

Directory Server components