Best Practices for Running Multiple Identity Manager 2 (formerly DirXML ® ) Drivers on Linux and Solaris Patrick J Cush Senior Technical Specialist Novell

Best Practices for Running Multiple Identity Manager 2 (formerly DirXML®) Drivers on Linux and Solaris

Patrick J CushSenior Technical SpecialistNovell

© December 30, 2003 Novell Inc.2

one Net: Information without boundaries…where the right people are connected with the right information at the right time to make the right decisions.

The one Net vision

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:


The one Net vision

Novell Ngage services provides real-world experience from consultants around the world. Novell's service professionals make sure every Novell solution you implement is based on best practices, customized to meet your needs, and capable of delivering the highest possible return on investment.

Novell NgageSM

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:


Planning a DirXML® Implementation

Things to review for solution:

Define purpose of solution

Define entry point of system data

Define connected systems and data to be shared between them

Define Governance of system


Define Purpose of Solution

Definition of new solution:• Does this solution just share identities?• Does the solution have special data sharing needs between

systems?• Are other applications going to reside on the server with

DirXML or be written to obtain data from it?• Is there a need for special handling of information – forcing

one system information over another?• Is there a need to share data between different countries or

regions?


Define Entry Point of System DataDefine the Entry Point of Information:

• Do we have a entry point for all existing and new users?• Do we have special considerations on updating the data we

obtain(update real time or update once a day)?• How to obtain data from authoritative system?• Other information we may need for other systems not in the

authoritative system data but needed for other systems to consume?

• Placement of information from authoritative source – need for regional design of eDirectory™?

• Define what is needed to create a user and how/who to notify on failure.


Define Connected Systems

Define the connected systems:• Who will consume data in eDirectory?• Do they have special needs for the information?• Does there need to be auditing when user created, modified

or deleted from system?• Is that system data being consumed by other applications

which might have special consideration based on security or format of data?

• How will the connected system use the data obtained by eDirectory?

• Does the timeframe match the authoritative timeframe for refreshing data?


Define Governance

Define how the new solution will be governed:• What policy is needed to maintain system?• Does the system have a central group responsible for

maintenance?• What is the needed as far as auditing for the system?• How do we handle change control and further development

of solution?


Define Structure of eDirectory

Definition of eDirectory design to meet need:• Number and location of connected systems?• Do we need to replicate to another Country/Region and is

the data mission critical?• Are other applications running on server with this solution?• Is there a need for redundancy of system?• Are the drivers sitting in an existing eDirectory server?• Setting partition one up on the driver set.


Define Driver Set

Define the driver set:• Number of drivers per driver set?• If split logical split of different drivers running in each driver

set?• If drivers split, required maintenance of the tao file

associated with each driver.• How will replication of information across a WAN effect the

solution?


Improving eDirectory Performance

Improving eDirectory Performance on Linux and Solaris:

Tuning the eDirectory Server

Optimizing Cache

Optimizing bukload data

Tuning OS for Novell eDirectory

Monitoring the system


Tuning the eDirectory Server

Tuning the thread pool:• Thread pool is the number of threads used when eDirectory

started(parameters in /etc/nds.conf file)• Parameters to Adjust when sudden load on system

– n4u.server.idle-threads– min number of threads regardless of activity

– n4u.server.max-threads– max number of threads

– n4u.server.start-threads– number of threads to start when eDirectory starts


Optimizing Cache

Allocate Fixed RAM on UNIX systems:Why

• UNIX normally does not return freed memory back to the OS.

Fix RAM by either:• Manually creating an ini File(_ndsdb.ini) located in /var/nds/dib

– Add the following parameters:– blockcachepercent=50

– % of cache allocated to caching database blocks

– cacheadjustinterval=15– Min. seconds for eDirectory to evaluate its utilization of free memory

and adjust overall cache

– cachecleanupinterval=15– Set seconds that eDirectory will write dirty cache blocks to disk


Optimizing Cache

Fix RAM Using iMonitor:• Click Agent Configuration• Click Database Cache

– blockcachepercent=#– set the default cache allocated to caching database blocks.– Set no greater then 40% if server is used for other applications.– Default is 50%

– cachecleanupinterval=#– time to write dirty cache to disk

– cacheadjustinterval=#– time to adjust overall cache size based on utilization


Optimizing Cache (cont.)

– cache=#– Set hard limit in bytes of memory for eDirectory Cache

– cache=leave:#– Set min bytes to leave

– min:value– Set min cache size in bytes

– max:value– Set max cache size in bytes


Optimizing Transaction Size

Increase Bulload performance:• increase LBURP transaction size

– The number of records sent from ICE to LDAP server during a single transaction

– default is 25 ( can be set between 1 and 1000)– Watch for adequate memory allocation

• Can set parameter in /etc/nds.conf– n4u.ldap.lburp

• Clean up LDIF files before loading • Load containers first using seperate LDIF


Tuning the OS

Solaris tuning for eDirectory:• Go to /etc/system

– set maxphys=1048576– set md_maxphys=1048576– set ufs:ufs_LW=1/128_of_available_memory– set ufs:ufs_HW=1/64_of_available_memory – ctcp:tcp_conn_hash_size=8192

Increasing JVM Heap Size:• set DHOST_JVM_INITIAL_HEAP• set DHOST_JVM_MAX_HEAP

Setting Memory in tomcat.sh file• go to tomcat.sh file add “-Xms512m -Xmx512m” to

TOMCAT_OPTS parameter• Make sure you have the RAM


Monitor the OS

Solaris/Linux monitoring:• Use prstat/top

– Watch system to see how it reacts to both bulk load and average load.

• Use iMonitor – Look at block cache and cache to see how it is reacting to loads


System Maintenance

Clean up of TAO file maintenance:• If splitting drivers between servers need to clean up old cache

events on tao file occasionally:– One way is to rotate which server runs which driver. At a

specified interval turn one off the other on.– The other is to replace the tao file with a new empty tao file

• Replacing the tao file with a new tao file – .tao file is located in the /var/nds directory on UNIX/Linux systems– The tao file contains 8 bytes of information– It is named after the driver objects entry id (EID) found by

dsbrowse or iMonitor, converted to a decimal.

For example:if the NDStoNDS driver had an EID of 00000832D

The tao file would be named: 33581.TAO

The tao file would contain: FF 44 58 02 00 00 00 00


Pitfalls

Pitfalls of Designing and Implementing a DirXML solution:

• Design:– Placing policy into drivers code instead of enforcing good

administrative practice.– Not defining authoritative source.– Not defining the governance of the solution.– Not having proper change control procedures.– Lacking a Development, Staging and Production envoirnment.


Pitfalls (cont.)

Tuning/implementation:• Not testing the system and adjusting for Average load of

use.• Running to many applications on same server.• Not having adequate RAM for tasks of system.• Not monitoring system with OS tools to see how system is

behaving both on Bulk load and average load.• Not maintaining system after rollout.• Too much interaction of drivers between each

other...”cache never goes down”


General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Novell, Inc., makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

Documents

Best Practices for Running Multiple Identity Manager 2 (formerly DirXML ® ) Drivers on Linux and Solaris Patrick J Cush Senior Technical Specialist Novell