SAP Note 26317 - Set up for LOGON group for autom. load balancing

Symptom:

It is unclear how the LOGON groups should be set up for automatic load balancing.

Other terms

CCMS
Transaction SMLG
Group logon
Group logon procedure
SAPLOGON
SAPGUI

Reason and Prerequisites

Group distribution can be configured in a variety of ways.

Solution
Introduction

LOGON groups are used to automatically distribute user logons to individual instances or to groups of SAP instances (Applications Server).
The idea behind this is that a user does not log on to a special instance but rather logs on to a so-called LOGON group, and is then logged on to the relevant instance with the lowest load (that is, the best average response time. The advantages of using this procedure are twofold:

1. Users are no longer tied down to individual instances that might possibly become overloaded.

2. Since users now log on to logical LOGON groups and not to physical instances, instances can be exchanged or created within a group without the SAPGuis having to be reconfigured.

LOGON group maintenance

LOGON group maintenance and configuration can be carried out using Transaction SMLG (Tools -> Administration -> Computing center -> Management system -> Configuration -> LOGON Groups).

a) A common group is used for all instances. If only a small number of instances exist, this configuration is the best solution as regards optimal load balancing and redundancy. Only if a larger number of instances exist does it make sense to distribute users for each specific application to two or more instances. Example of a system with only a few instances:
Instance Group Max. no. users Max. average resp. time
app1_C11_00 Public
app2_C11_00 Public
app3_C11_00 Public

Example of a system with a large number of instances:
Instance Group Max. no. users. Max. average resp. time
app1_C11_00 FI-Users
app2_C11_00 FI-Users
app3_C11_00 SD-Users
app4_C11_00 CO-Users
app5_C11_00 CO-Users
app6_C11_00 SD-Users

b) One or more LOGON groups are set up for several instances. Several groups can be allocated to the same instances.
In this case, the users of a LOGON group are distributed in such a way that the load on each of the relevant instances is as little as possible. If only a limited of users are to be allowed access to instances, or if a predefined average response time may not be exceeded, then maximum values can be entered for the number of users or for the average response time. The optional definition of these values guarantees as much as possible that users are only logged on to the instance if the limiting values are not exceeded. However, the definition of limiting values does not prevent users from logging on to the instance directly. It is also possible to log on to an instance with exceeded threshold values if all of the instances available for the LOGON group in question were also defined with limiting values and these were subjected to a relatively greater load. Example:
Instance Group Max. no. users Max. av. resp. time
app1_C11_00 FI Users 20 1500
app1_C11_00 SD Users 20 1500
app1_C11_00 Adminstration 20 1500
app2_C11_00 FI Users
app2_C11_00 CO Users
app3_C11_00 SD Users

Note: The definition of limiting values is optional and is not normally visible. You can make this visible by choosing Properties -> Display Variants -> Change in the menu list. Double-click the logon group and a dialog box opens that allows you to adjust the limiting value.
Limiting values must always be kept uniform for each instance (this is regulated automatically by the maintenance Transaction SMLG), since the average response time or the number of users can only be calculated globally for each instance and not for user of a specific group. In other words, the limiting values apply to one instance, regardless of group, but at the same time, can be set up differently for the same group for another instance.
However, in most cases, it is unnecessary to specify limiting values since the sole aim is to achieve an even distribution of users with regard to system load.

c) Groups are set up for only one instance, but several groups can be allocated to an instance. The distribution of user logons resulting from this configuration is not dependent on the system load. That is why it does not make sense to define limiting values for user number or average response time either. The disadvantage of this is that if an instance is not available an alternative instance is not automatically provided. The group definition must then be changed so that the logons of the group affected are redirected to other instances.
Example:
Instance Group Max. no. users Max. av. resp. time
app1_C11_00 FI Users
app2_C11_00 CO Users
app3_C11_00 Administration

Technical information
The utilization information is determined for every instance by a report which is executed automatically every 5 minutes. This report stores information in a special storage area in the message server from which the SAPGuis can then request the best instances of a group at that particular point in time. To avoid situations where a large number of users want to log on within this 5-minute period (this would lead to a large load being placed on the best instances of a group at that particular point in time), the utilization information for each instance is updated after every fifth logon.