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

© 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 Ngage SM : : : :

© December 30, 2003 Novell Inc. 3 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 Ngage SM Novell exteNd ™ Novell Nsure ™ Novell Nterprise ™ Novell Ngage SM : : : :

© December 30, 2003 Novell Inc. 4 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

© December 30, 2003 Novell Inc. 5 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?

© December 30, 2003 Novell Inc. 6 Define Entry Point of System Data Define 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.

© December 30, 2003 Novell Inc. 7 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?

© December 30, 2003 Novell Inc. 8 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?

© December 30, 2003 Novell Inc. 9 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.

© December 30, 2003 Novell Inc. 10 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?

© December 30, 2003 Novell Inc. 11 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

© December 30, 2003 Novell Inc. 12 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

© December 30, 2003 Novell Inc. 13 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

© December 30, 2003 Novell Inc. 14 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

© December 30, 2003 Novell Inc. 15 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

© December 30, 2003 Novell Inc. 16 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

© December 30, 2003 Novell Inc. 17 Tuning the OS Solaris tuning for eDirectory: Go to /etc/system – set maxphys= – set md_maxphys= – 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

© December 30, 2003 Novell Inc. 18 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

© December 30, 2003 Novell Inc. 19 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 D The tao file would be named: TAO The tao file would contain: FF

© December 30, 2003 Novell Inc. 20 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.

© December 30, 2003 Novell Inc. 21 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”

© December 30, 2003 Novell Inc. 23 General Disclaimer This 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.