Purpose
The main goal of this wiki is to clarify few points and questions about the ABAP Logon group, mainly some gray areas about RFC load balance.
Overview
A Logon Group is a group of servers that belongs to one SAP system. It is maintained in transaction SMLG.
Logon groups are used to automatically distribute user logons to individual instances or to groups of SAP instances (Applications Server).
Group "SPACE" is maintained automatically with all active servers. It is possible to manually overwritten in SMLG this SPACE group.
The group defined in SMLG contains only active servers and the load each server has its own load values. The actual members of a logon group and its quality are calculated during runtime by the report RSRZLLG0. This is triggered on each server of the system by rdisp/autoabaptime (every 5 minutes by default) or after 5 SAPGUI logons. Servers which did not run such a calculation within the last 5 minutes + 10% are removed. This removes servers which are active but are busy for any reason.
For every group one favorite server is determined and sent to the Message Server.
How does logon group based load balancing work?
SAPGUI
a. The saplogon process connects to the MS and asks for the favorite server of the logon group.
b. The Message Server sends back the IP address and port number of the favorite server.
c. SAPGUI uses this information to connect to the Application Server.
This procedure repeats for every logon.
RFC
a. The saplogon process connects to the MS and asks for the favorite server of the logongroup.
b. If the "Ext. RFC-enable" field is selected, the RFC client performs load balancing.
If this field is not set, server that is entered as the best server in the logon group is used and the system does not perform any further balancing among the servers of a logon group.
c. RFC client balancing the connection among the servers of this logon group.
d. To the next connection, a check is performed to determine whether the data is still valid (information from timeout and RFC logons defined in table RZLLICLASS). In such situations its structure of data is updated with a next request to the MS and the client then receives the list of all servers of the group with its quality and delta quality. It reorders the list using random numbers.
HTTP(s)
a. The Message Server redirect the request to the favorite application server.
b. As from this first connection the URL in the browser change to the application server hostname.
The SAP recommends using Web Dispatcher as load balancer to Web connections.
Load balance Strategy
For each group you can define one of the following load balancing type:
B = Best (default value)
The client uses the server with the best quality. The quality of a server is decreased by the delta quality after each connection.
R = Round Robin
All servers do have the same quality of 1,000 and delta quality of 1.
This may be a problem if many RFC programs start at the same time. It is possible that all RFC programs select the same application server for the first logon.
For this reason there is a random number used during the Round Robing load balancing that is used to choose the application server.
W = Weighted Round Robin
All server do have the same quality of 10,000,000. The delta quality is 10,000 divided by the number of dialog work processes.
Important to know
- Opening a new mode does not trigger load balancing.
- The user cannot be transferred to another server. If a server is not working any longer, the user has to open a new connection.
- For RFC connections load balancing is done for every new connection. RFC calls on an existing connection do not cause load balancing, you stay connected with the same server. To enforce load balancing you have to close the current RFC connection and open a new one.
- If you have set the Extended RFC Load Balancing flag for a logon group, load balancing is done locally at client side.
- The RFC client receives a new list after 120 seconds or 200 connections (default). You can set different values for each group in table RZLLICLASS.
- Round-Robin and Weighted-Round-Robin do not apply to SAPGUI connections.
- There is no "server-side" load balancing.
- RFC connections do not cause a new calculation of server groups like SAPGUI connections do.
- To validate if the RFC load balance is enable in a logon group, the lgtst tool can be used. Note that the TRUE means RFC load balancing active.
lgtst -H <MS host> -S <MS serv> -G <group> -C 6 ------------------------------------------------------------------------- > lgtst -H <MS host> -S <MS serv> -G <group> -C 2 using trcfile: dev_lg Logon data for logon groups: ------------------------------ Group MYGROUP : [<IP>] [3200] [740] [TRUE] [<instance>] Group MYGROUP : [<IP>] [3200] [740] [TRUE] [<instance>] -------------------------------------------------------------------------
- There is a program responsible by the load calculation. It is possible to monitor the execution of this program over:
RZ03 -> Select the APPS -> Utilities -> More utilities -> Contr/St.Area
See program RSRZLLG0.
Recommendation
- Keep the rdisp/autoabaptime equal on all instances of one system;
- Keep the date and time synchronized in all application servers;
- It is not recommended to change the default time of rdisp/autoabaptime (300 seconds);
- If this is a RFC load balance you must select the "Ext. RFC-enable" field for the group attributes;
- In case of RFC load balance, the configuration of table RZLLICLASS must be properly adjusted as per the requirements;
Related Content
Related Documents
Related Notes
593058 - New RFC load balancing procedure
64015 - Description of test program lgtst
26317 - Set up for LOGON group for autom. load balancing
38119 - SAP Logon: Administration of functions
27044 - Login workload Balancing verification test
649008 - HTTP load balancing using the SAP message server
118093 - Concepts of defining 'limits' in logon load balancing