Planning for Identity Manager
Novell Cool Solutions: Tip
Digg This -
Posted: 16 Dec 2004
If you're new to the world of Identity Manager, know that there are others in your shoes (with fresh socks, of course ...). Here's a recent conversation about getting into the Identity Manager world, from scratch.
"The company I work for is about to delve into the world of Identity Manager, and having read the documentation on the web, I have a few questions regarding installation recommendations.
The environment where we are going to set up Identity manager is brand spanking new, with no legacy version of IDM, DirXML, or eDirectory in place. We will be setting up a brand new eDirectory server and IDM v 2.0 (or perhaps 2.0.1), that will interoperate with an IBM LDAP server, DB/2, MS SQL Server, and various Access databases.
Initially, the product will be used to synchronize 1,000 (at any given time) user accounts with the systems listed above. User accounts will be disabled at the same rate they join, so 1,000 users is a stable figure. Eventually, it is envisioned that the environment will grow so that 10,000 accounts are active at any given time.
Based on the information above, what recommendations would you make in terms of separating the components (IM Driver Shim, Remote loader, IM Engine, eDirectory, etc.) onto separate servers? What can we run together, and what should we separate? Which component has turned out to be the most resource hungry in terms of RAM, CPU, Disk space etc.?"
And here's the response from a few of our Forum experts ...
Identity Manager is generally event-driven, so it's not so much a matter of the number of "live" users as the frequency that they are added, or their dataset changes. It is common practice to keep objects associated with each other, even when the account is disabled - unless the associated application object is deleted completely. So the number of associated objects would rise over time. But there is little overhead for an unchanging associated object, so that is unlikely to have a tangible impact. Adding users is a relatively expensive operation, so the question there is how frequently you are pushing new users into the system and what sort of delay in processing is acceptable when you do so.
Remember that every change to the directory counts as an event. Login and logout traffic alone will give you more than 1000 events per day. When you add in the backround DS threads, you'll have plenty more. But that's not really a problem, because the DirXML Engine is pretty efficient and quick about processing events.
I have about 80K users here at our university, with three eDir trees and a MAD tree, all linked via DirXML. These are mostly students, and are mostly people who are not physically here. We create 100 or so accounts per day. I see around 180K login/logout events, and around 700 password changes per day. If I counted account changes and group membership updates, I'm sure I could get make it over 200K events per day.
The hardware recommendations: go for more memory, and maybe more CPUs if you can get them. Get fast disks, too.
I'm running a single sync server to maintain my flat identity vault tree (eDir 18.104.22.168). This server also runs the DirXML engine and 15 drivers (13 eDir-to-eDir, 1 eDir-to-MAD, 1 NAM3). The server also functions as a Win2K MAD domain controller, and it runs NAM3 (password sync only). It has 4GB of RAM and 4x800MHz Xeon CPUs but is often "bored." eDirectory alone can take over 2GB of RAM on this server, though.