Welcome!

Identity Management Tips, Thoughts and Opinions

Matthew Pollicove

Subscribe to Matthew Pollicove : eMailAlertsEmail Alerts
Get Matthew Pollicove via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Ubuntu Linux Journal, Microsoft Developer, CIO/CTO Update, Exploring SAP and SAP Mobile

Blog Feed Post

Calling all Dispatchers


There are two items of general NetWeaver Identity Managementmaintenance that I get asked about frequently.
  • How do you prevent deadlocks    
  • What is the best way to configure my dispatchersin IDM?
All too often these issues are actually related asinefficient dispatcher setup can cause database deadlocks. In this blog entryI’d like to recommend some possible architecture scenarios that will help outwith this. For the purposes of this discussion, we’ll be talking about aNetWeaver IDM 7.1 installation on Microsoft SQL Server 2008 R2. According to Microsoft:
A deadlock occurs when two or more tasks permanently blockeach other by each task having a lock on a resource which the other tasks aretrying to lock. The following graph presents a high level view of a deadlockstate where:
·        Task T1 has a lock on resource R1 and hasrequested a lock on resource R2.
·        Task T2 has a lock on resource R2 and has requesteda lock on resource R1.
·        Because neither task can continue until aresource is available and neither resource can be released until a taskcontinues, a deadlock state exists.

Attaching multiple dispatchers to the same task would thenseem to create the potential for deadlocks to occur in the database,particularly if they are all trying to access the same rows in the various IDMtables. But wait, we’re supposed to be able to do this to encourage HighAvailability, Load balancing and failover, so what gives?

Well the secret lies in the architecture, of course. If therequests come from separate physical hosts, it is much easier for the both IDMand the database to manage the threads and requests. Let’s look at a couple ofexamples. First here is a basic dispatcher setup assuming one server with acouple of dispatchers on it.

This setup is OK since each dispatcher (D) is connected to adistinct Job (J) or set of jobs. Sometimes there is a need to have aconfiguration like this, which usually something like one dispatcher for provisioningjobs, one for housekeeping(HK) and one that provides some sort of elevatedaccess for Directory Services(DS) access.

Based on this there might be a temptation to set up thedispatcher/job relationship to look something like this to provide additionalfail over and support for some specific jobs. Consider the following examplewhere I outline a scenario with a crossover between multiple dispatcherspointing to jobs in a many to one relationship:
This scenario is exactly what we do not want to have as itis most likely to create a deadlock scenario as having multiple dispatchers accessingthe same jobs that are accessing the same database resources. What we have hereis a potential for deadlocks as the system is trying to manage multipledatabase resources (rows) at the same time.

What tends to compound this situation is the way that thedatabase is being accessed. Using the To Identity Store Pass creates the leastamount of deadlock strain on the system, since this is under the direct controlof the workflow system and its dispatchers, while using techniques such as the uIS_SetValue function, that can becalled from anywhere, at any time, create the greatest possibility as thesystem is managing standard job based access with unforeseen access via uIS_SetValue.
This scenario should be replaced by something like this:

In this case the potential for deadlocks is significantlyreduced since there is separate management of the database connections. It alsoprovides a degree of load-balancing and failover since if the D1 or D3Dispatchers are busy or unable to process an assigned task then the D4or D5 dispatchers respectively can take over. A good resource forthis can be found in the SAP document SAPNetWeaver Identity Management Identity Center Implementation Guide OptimizingDispatcher Performance.

What also needs to be recognized is that it’s not always asmuch “where” the requests come from, but when the requests come. Care should betaken to monitor the frequency and duration of the larger and more intensivetasks and workflows to make sure that the more involved tasks do not run at thesame time (For example the HCM load should probably not happen the same timethat the Directory Service reconciliation is occurring). These should be thefirst candidates for having their down dedicated dispatchers if there is a needto run them on similar schedules and this cannot be avoided.

Given all of this, the thing to remember when consideringdispatcher allocation is to make sure that there are not multiple dispatchersthat are competing for the same set of Identity Store resources at the sametime. As long as this is kept in mind when setting up dispatchers, thepossibility of deadlocks is minimized.
A related question to this is how many dispatchers are neededto assign for provisioning and de-provisioning operations. I have always used25,000 objects per dispatcher as a general rule. Based on this the scenarioshown above would be good for an enterprise where there are a maximum of 50,000users, roles, privileges or groups that are being managed in any given task.


As a final note, it is a good thing to remember that thedispatchers do not need to be installed on Microsoft Windows based systemsonly. Any UNIX/LINUX environment is just fine for setting up IDM Dispatchers.For more information, check out the SAP document: HowTo: Setting Up An Identity Management Dispatcher On A Unix Host Flavor.



Read the original blog entry...

More Stories By Matthew Pollicove

Matt Pollicove is an Identity Management architect, engineer, trainer, project manager, author and blogger with experience in user account provisioning, data synchronization, virtual directory and password management solutions. As a MaXware Technical Consultant and later as a System Engineer, he worked extensively with MaXware (now SAP) software products in large customer environments. In the past Matt has worked with several leading national and international consulting firms and is currently a Sr. Principal Consultant for Commercium Technologies. He is currently the Practice Lead for SAP NetWeaver Identity Management and SailPoint IIQ.