Scenarios

The scenarios described below give detailed information for each case. The detailed information is intended to be used together with the generic instructions above.

Scenario 1: Using a Specific JRE When Launching an Application

In this scenario, assume you want all grid nodes belonging to a particular grid application to be running in JVMs from a specific JRE. The rest of the grid and other applications should not be affected. Typical reasons for wanting to do this may be that the application only works using a specific patch level or a JRE from a specific vendor.

In this scenario, assume that:

  • The grid host is named HOST1

  • HOST1 has a JRE installed on the following path "C:\Program Files\Java\jre6".

  • The grid application APP1 is deployed on HOST1

To use a specific JRE when launching an application

  1. Create a script file on the grid host (HOST1), for example, C:\GridNodeStartScript\StartNodeJRE6.cmd, containing the following single line:

    "C:\Program Files\Java\jre7\bin\java.exe" %*

    As can be seen, the script line simply targets java.exe in the JRE that was wanted, and, by the use of "%*" at the end of the line, it makes sure to propagate all arguments that were passed to the script.

  2. Configure the application to use the script by editing the Java Executable grid property. Use the following values:

    • Override in the context of an application (APP1 in this case).

    • In the matrix, identify the host column belonging to the host (HOST1) and click on the value link in the first row (the application level row).

    • Enter the following path in the dialog box: C:/GridNodeStartScript/StartNodeJRE7.cmd. Remember to use forward slashes in the path.

    The application nodes should now be launched using the specified script on HOST1.

Note: The examples given here are trying to illustrate the generic approach of creating a script file and configuring the Java Executable grid property to point to that script file. This generic approach allows for advanced scripts to be created. However, this particular example is so simple that you actually don’t have to create a script file at all. In this case, you could just enter "C:/Program Files/Java/jre7/bin/java.exe" as the value of the Java Executable grid property and skip the script file completely.

Scenario 2: Constraining an Application to a Subset of Available CPU Cores

In this scenario we have an application that is using the CPU very heavily and thus starving other applications from CPU cycles. Since the grid is intended to run several applications in the same grid, it is important that an application is not allowed to monopolize resources. To solve this problem, you need to constrain the application to a subset of the available CPU cores on the host(s) that the application is running on. This would conserve resources for other applications.

In this scenario, assume that:

  • The host is running the Windows operating system

  • The grid host is named HOST1

  • HOST1 has a JRE installed on the following path "C:\Program Files\Java\jre7".

  • The grid application APP2 is deployed on HOST1

To constrain an application to a subset of available CPU cores

  1. Create a script file on the grid host (HOST1), for example, C:\GridNodeStartScript\StartNodeCore.cmd, containing the following single line:

    START /B /AFFINITY 3 "" "C:\Program Files\Java\jre7\bin\java.exe" %*

    As can be seen, the script line uses the Windows Start command to start the JVM (java.exe) and, by the use of "%*" at the end of the line, it makes sure to propagate all arguments that were passed to the script. The Start command allows us to specify the CPU affinity. In the example, the affinity is set to 3, which means that cores 0 and 1 will be used (3 in binary format = 11).

    Note the empty quotes "" after the /AFFINITY 3 argument. Due to some strange behavior of the Start command, it seems to be needed if and only if the next argument (path to java.exe) needs quotes. In the example the path contains a space, so quotes are needed, hence the extra empty quote.

  2. Configure the application to use the script by editing the Java Executable grid property. Use the following values:

    • Override in the context of an application (APP2 in this case).

    • In the matrix, identify the host column belonging to the host (HOST1) and click on the value link in the first row (the application level row).

    • Enter the following path in the dialog box: C:/GridNodeStartScript/StartNodeCore.cmd. Remember to use forward slashes in the path.

The application nodes should now be launched using the specified script on HOST1 and the application nodes should be constrained to cores 0 and 1.

This may be verified in Windows Task Manager. Right-click on the process corresponding to a grid node started by the script above. Select Set Affinity… and verify that the correct set of cores is enabled.

Note:  In the menu of Windows Task Manager, select View > Select Columns, and make sure that the Command Line column is selected. Information from the command line will make it easier to find your grid node among all processes.

Scenario 3: Running Grid Nodes Belonging to an Application as a Specific User

Grid nodes are started using the same user as the grid agent is running as. Normally, an application is not concerned about this user. It is a user that was specified when the grid was created and it should be work appropriately. However, if a particular application has to be running as another user, you have a problem. The grid is intended to run multiple applications in the same grid, so a particular application can’t be allowed to change the user that the entire grid is using since that would impact the other applications. In this case, you need to launch nodes belonging to just this particular application using anther user.

Doing this in a safe way can be tricky since it may require that user names and passwords are hard coded in script files. yet that is not something that can be recommended for security reasons.

Due to the problems just mentioned, no concrete example or recommendations will be given in this case. However, several general observations can be made.

On a UNIX platform, you have the sudo command and on Windows you have the runas command that can be used to start processes as another user. Neither of them accepts that passwords are passed to them from the command line. This is good since hard coding passwords in script files should be avoided.

Third-party tools exist that are similar to the Windows runas command and also accept a password on the command line. However, these are not recommended by Infor for the reasons mentioned above, even though they would technically solve the problem. Some of the third-party tools support encryption of the password information. Potentially those tools may provide a secure way of solving this problem but Infor does not give any recommendations in this area.

Giving the user access to the configuration area

If a particular user is used to run all or some of the grid nodes, it is crucial that the user has sufficient security rights in the grid configuration area. The topic, Changing the Grid Service User, describes how to change the directory security. The information is for Windows but the situation is the same on all platforms. The user has to be given access to the grid configuration area.