|
Load Balancing allows MSO administrators to distribute FOCUS users across multiple MSO regions to reduce contention for system resources and provides a transparent and efficient way to distribute users across multiple MSO regions. With Load Balancing, the MSO administrator can control access to and the use of resources. The administrator's job is simplified with Load Balancing because users are routed only to the MSO regions that are set up for their applications. All users have access to MSO FOCUS with a single profile and are automatically routed to the region that has sufficient capacity. |
Topics: |
Users are routed to the MSO region with the applications they wish to run. For MSO administrators, all communications setup is done once. Implementing Load Balancing is as simple as adding a keyword to the configuration file.
As MSO users Logon, Load Balancing has the capability of automatically distributing them across a group of up to 32 MSO regions within a single MVS image. Users may connect to MSO via TSO, VTAM, or CICS. MSO, in conjunction with the IBI Subsystem at the time of initial connection, determines which MSO address space in the group of defined and started address spaces is the "best one" to connect this MSO user.
The actual routing is based upon the number of users currently logged on to each MSO region, the level of CPU activity each MSO region has incurred during its last MSO Resource Monitor (MRM) interval, and finally, all things being equal, a "Round Robin" selection.
Load Balancing simplifies the setup and installation of multiple MSO regions. Communication is set up with one primary MSO region. The MSO Logon procedure is just one VTAM applid or VTAM menu selection, or one CICS transaction. The search for an available MSO region is transparent to the user.
Load Balancing introduces the concepts of groups or application groups and applications. Put simply, a group is a set of MSO regions participating in Load Balancing. The MSO administrator defines the group. There can be one or more groups but there must be at least one. The MSO administrator chooses a single group when the user community is fairly homogeneous. There can be up to 32 MSO regions in a group.
MSO administrators can use application groups to segregate users into homogenous groups of MSO regions. For example, you might create TEST, PROD, and STAGE groups. Or, an application group may be created to segregate users into non-competing (for resources) groups. To keep users in Accounting from competing for resources with Engineering, the MSO administrator could set up three application groups, giving each the number of MSO regions required for that user community.
A given MSO region can belong to only one group. If it does not belong to any group, that region does not participate in Load Balancing.
Groups can be further subdivided into mutually exclusive applications. An application is a name representing users with similar needs and Logon Profiles. It is not necessary for the MSO administrator to assign applications. If no application names are assigned, all users will be balanced across all MSO regions assigned to the application group.
If a single group has many applications, the MSO administrator can assign application names to one or many of the participating MSO regions, effectively restricting those users with the same application to a subset of the total number of MSO regions available.
Applications further restrict competition between MSO regions. If for example the engineering group has a very important application (Cost Analysis), the MSO administrator can assign that application to many of the MSO regions to optimize Load Balancing. Less important applications (Vacation Requests) can be assigned to only a few of the group's regions.
An application name can appear in multiple groups and has different characteristics in each group. If the FOCUS users are updating an existing application then that application name can exist in the PROD, TEST, and STAGE groups. For example, the On-line Ordering System has been extensively changed. Some users are using the new system (STAGE), some users are using the old system (PROD) and there are the developers making changes (TEST). Each set of users is running the application named On-line Ordering System but the On-line Ordering System is different in each group.
The IBI Subsystem must be active and the MSO program libraries must be APF authorized to support this feature.
MSO Load Balancing depends upon a repository of information that pertains to all MSO regions in the MVS system. Each MSO region updates its own status information stored in ECSA. In this Common Storage Area, above the 16-megabyte virtual storage line, storage is not taken up in what is termed the Private area. It does not affect the amount of private storage below the 16-megabyte line available to all MVS programs. MSO uses the IBI Subsystem to update this information in ECSA. It stores information about the number of users currently logged on and the amount of CPU that it consumed during its last MRM interval.
Logon Request: to Primary or initially contacted MSO Region
If the VTAM Logon request did not contain a userid, the MSO Logon Screen is displayed to the user by the primary or initially contacted region.
All three communication environments allow the user to specify the Load Balancing Group name and the application name that controls MSO region selection by Load Balancing. If the connection request does not specify an MSO Application Group or application, the defaults that are set in the IBI subsystem are used. The initially contacted MSO region does not do any Logon verification of the user. After entering a userid, the next step begins. The CICS and TSO user does not specify userid or password as this is carried over from the originating environment.
The VTAM user sees the MSO Logon Screen if the minimum required information for Logon to the target region was not specified.
For the VTAM Logon, the minimum information required is Userid and Password if EXTSEC=YES is specified in the MSO Configuration File and Userid is required if EXTSEC=NO.
At this point Logon processing usually completes and the TOE screen is displayed. However, the Logon request may fail because of resource constraints in the destination MSO region.
FFFFFFFF OOOOO CCCCC UU UU SSSS
FFFFFFFF OOOOOOO CCCCCCC UU UU SSSSSS
FF OO OO CC CC UU UU SS SS
FF OO OO CC UU UU SSS INFORMATION
FFFFF OO OO CC UU UU SSSSS
FFFFF OO OO CC UU UU SSS BUILDERS,
FF OO OO CC CC UU UU SS SS
FF OOOOOOO CCCCCCC UUUUU SSSSSS INCORPORATED
FF OOOOO CCCCC UUU SSSS
USERID ==>
PASSWORD ==>
SERVICE ==> DEFAULT SERVICE FOCUS
APPLICATION ==> DEFAULT APPLICATION
APPL GROUP ==> DEFAULT APPL GROUP
ACCOUNT ==>
USER PARM ==>
SERVER REGION PGMRAMM2
NEW PASSWORD ==> VTAM APPLID PMRMM203
REPEAT NEW PSWD ==> TERMINAL T37CT01B
SECURITY GROUP ==>
PRESS PF3/PF15 TO EXIT
Defaults for both the Load Balancing Group name and the application may be set in the IBI Subsytem. These defaults take effect whenever a user accesses an MSO Load Balancing Region without specifying an APPLGROUP name or an APPL name. When these defaults are set in the IBI Subsystem for the group or application name it takes effect for all non-specific MSO access requests. The initially contacted MSO region, in this case, does not control the Load Balancing Group that the user is placed into.
The Load Balancing Subsystem defaults are set via subsystem commands that are entered as follows:
MVS Console
IBIS SET APPLNAME = applname
IBIS SET APPLGROUP = groupname
SYSIN to the SUBSYSI job when starting the IBI Subsystem or while it is active
SET APPLNAME = applname
SET APPLGROUP = groupname
The current IBI Subsystem settings for the Load Balancing defaults may be displayed by executing the command in any of the above formats:
IBIS DISPLAY LOADBALANCING
| Information Builders |