After reading through this short blog you should know all that you need to know on how to configure and monitor ‘daemons’ in SAP Sourcing. If you have any further questions, just write a comment and I would be glad to answer them!
Before diving deep, let us be clear what ‘daemons’ mean in this context. They are nothing but “background processes/threads” that takes care of various complex, time-consuming, repeated & critical tasks (e.g. Sending emails, Cache replication, Rfx Response Preparation, etc) in SAP Sourcing.
In a typical installation of SAP Sourcing, you may have two or more application servers clustered to support varying loads. Some system level daemons are expected to run in ALL of these application servers (e.g. System daemons like Cache Synchronization daemon). These daemons are called Multicast Daemons. There is another category of daemons that are expected to run in “exactly one” application server in the cluster. These daemons are called Point-to-Point Daemons (P2P). P2P daemons are generally responsible for processing a complex process just once (e.g. Rfx Response Prepare Daemon).
SAP Sourcing provides flexibility and fine grained control to distribute these P2P daemons among different application servers in the cluster. OK, but why should you care about distributing the daemons? You don’t have to if you don’t need to. Let us assume for a second that you have a cluster of two or more SAP Sourcing servers and all your P2P daemons are running on the same server. What if you frequently have large sourcing events? Can the fact that all of the daemons are running on the same server impact the application performance for your users? The answer to this is yes. The users who have been load balanced to the application server where all the daemons are running are going to experience a non-negligible performance decrease compared to the other users who have been assigned to a different application server. The extent of this is largely dependent on the size and number of events that are running. In such a situation, it is beneficial to either distribute the daemon load across multiple application servers in the cluster or to explicitly assign the daemons to a dedicated daemon server that users will not be load balanced to.
The first part of the blog mainly focuses on how these daemons can be distributed.
Distributing P2P Daemons
SAP Sourcing has over 100 Daemons. These are logically grouped into approximately 20 different Daemon Categories. The daemon categories are just there to allow for easy and efficient daemon administration. To give administrators added control over the resource consumption of each of their servers, SAP Sourcing provides a way to distribute daemons across application servers. The way daemons are distributed is by ‘negation logic’. Each application server in the cluster has a possibility to switch off or disable a particular daemon category. What this means is that for a given application server where a daemon category has been disabled, that application server will not at anytime run the daemons within that category. If you want to assign a daemon to application server 3, in application server 1 & 2, the daemons should be disabled. If you don’t want a particular daemon to run in an application server, just disable it in that particular application server. Here is the 3 step instruction on how to do this:
1. Login in as ‘enterprise’ user. Navigate to ‘System Administration’ tab, under ‘System Management‘ click on ‘Registered Servers’
2. Now you can see all the registered servers. Choose the server where you want to disable daemons by clicking on the service link. This will take you to the Service Registration page of that cluster member
3. Now ‘Edit’ and navigate to the ‘Daemons’ tab in the Service Registration page. Uncheck “Auto-Enable All Daemons” (if enabled) to see the master list of daemons. By default all daemons are enabled to run in all the application servers. As you can see in figure 3, some of the system level daemons (e.g. Cache Management) cannot be disabled. Depending upon which daemon category you want to distribute (‘User Management’ in this case) to other application servers, disable them in this application server. This means all daemons belonging to the User Management category are not allowed to run on this application server. Make sure at least one application server has this daemon category enabled to make sure this daemon is runnable in the cluster.
Note on Auto Recovery of Daemons: Daemons are fault tolerant and they recover on any failure (including hardware). If a daemon fails due to a hardware failure, it will be restarted in another system in the cluster. If we disable the daemon to run in all the servers except for one with the hardware failure, then at the time of failure, the daemon is completely stopped, which would lead to reliability issues. For this reason, it is recommended that administrators configure their daemons so that they are enabled to run in more than one application server.
Monitoring Daemons
When you suspect there are issues with processing of the daemons or if you are just curious to see which servers they are running on, you can navigate to ‘Setup > Background Task Status’ and view the various reports associated with the background task status. The key reports are ‘Pending Damon Alerts’, ‘Pending Daemon Events’, and ‘Daemon Registration’. In the first two reports, you can see all the events and alerts that are yet to be processed. If you are sure a particular event/alert is causing problem and is no longer required to be processed, you can delete alerts/events from these reports. Caution should be taken here since once an event or alert is deleted, the task that is associated with it will no longer be completed. For tasks such as an import job that can be manually retried later, this is fine. But for tasks such as the closing of an auction, incorrectly deleting these could leave you in a bad state. In the third report (Daemon Registration), you can see a list of all of the daemons and where they are running. Deleting a daemon from this page will cause it to be restarted once it finishes its current task. If the daemon is enabled on multiple application servers, then it will be restarted on one of the other servers. Otherwise, it will restart on the same server.
- SAP Managed Tags:
8 Comments
