3.2.3 Checking and Setting the Kernel Parameters

To operate the PRIMECLUSTER-related software, you need to edit the values of the kernel parameters based on the environment.

Target node:: All the nodes in which PRIMECLUSTER is to be installed

The kernel parameters differ according to the products and components to be used.

Check "Setup (initial configuration)" of PRIMECLUSTER Designsheets and edit the value if necessary.

Set an appropriate kernel parameter as follows based on the type of "Characteristics" in each table.

Addition
Set the total number of the recommended values and specified values for system default values and for each software.
Maximum value
Specify the maximum value in the recommended values and specified values for each software.
However, make sure to use the system default value if the maximum value is less than that.

The kernel parameter values differ depending upon:

CF Configuration
RMS Configuration
Using GFS

See

For details of the kernel parameters and instructions on changing parameter values, see "Solaris System Administration" in "Solaris X System Administrator Collection Vol. 1."
For information on the default values of the Solaris, see the "Solaris Tunable Parameters Reference Manual."

Note

The values used by products and user applications that operate in the PRIMECLUSTER system must also be included in the kernel parameter values.
To enable values that have been changed, you must restart the system after the settings.
To set the I/O fencing function, perform the settings described in "3.2.4 Setting I/O Fencing Function of GDS" before restarting the system.
If a kernel parameter value is already maximized, the change will not be added to the system.

3.2.3.1 CF Configuration

When the resource database is used

The table below shows the kernel parameter values that are required in the CF configuration when the resource database is used.

The kernel parameter values in /etc/system are automatically changed by the installer. Be sure to return the settings in /etc/system to their original state when you uninstall the package.

Note

For system expansion, if you increase the number of nodes and logical disks, you need to re-estimate the resources and restart each node in the cluster system. If you want to add nodes or logical disks to a cluster system after it is configured, it is necessary to set a kernel parameter in advance considering the number of the nodes and logical disks.

Kernel parameter	Characteristics	Value	Parameter description
semsys:seminfo_semmni	Addition	20	Maximum number of semaphore identifiers.
shmsys:shminfo_shmmax	Maximum value	4194304 *	Maximum size of the System V shared memory segment that can be created.
shmsys:shminfo_shmmni	Addition	30	Maximum number of the shared memory segments that can be created for the entire system.

4194304 is the minimum value that is required when the resource database is used.

If you set the smaller value than the default value (8388608) to shmsys:shminfo_shmmax, do not set the smaller value than the minimum value.

Also, you may need to change the value of shmsys:shminfo_shmmax depending on the number of cluster system resources.

Estimate the number of cluster system resources according to the following equation and change the value:

Number of resources = (a) + (b)

(a) Number of disks in shared system devices x (number of shared nodes + 1) x 2

(b) Total number of local disks (number of local disks in all cluster configuration nodes)

Value required for resource database = 1048576 + 2776 x number of resources

If the value calculated above is larger than the installation default value (8388608):
shmsys:shminfo_shmmax = Value required for resource database
If the value calculated above is smaller than the installation default value (8388608):
You do not need edit shmsys:shminfo_shmmax.
(The installation default value is used.)

RCI monitoring agent setup

When you set up asynchronous RCI monitoring, you must specify the timeout interval (kernel parameter) in /etc/system for monitoring via SCF/RCI. Kernel parameters vary depending on the server type. Then check your server type so you can set the appropriate timeout interval.

Note

This setting is not required in the following cases:

SPARC Enterprise M3000, M4000, M5000, M8000, and M9000 provided by companies other than Fujitsu in Japan
SPARC Enterprise M3000, M4000, M5000, M8000, and M9000 with logos of both Fujitsu and Oracle provided in other than Japan

Below table shows the server types that require setting of the monitoring timeout interval.

Server type	Model	Kernel parameter (driver name: scf_rdctrl_sense_wait)
SPARC Enterprise	M3000	scfd:scf_rdctrl_sense_wait
	M4000
	M5000
	M8000
	M9000

Method for Calculating Monitoring Timeout Intervals
Calculate monitoring timeout intervals as follows:
- Up to 2 domains: 2 seconds
- 3 or more domains: 1 second + (0.5 x number of domains)
```
    Example:
     - 3 domains: 2.5 seconds
     - 4 domains: 3.0 seconds
```
Note
Calculate timeout intervals based on the number of domains in the server that contains the largest number of domains in the RCI network.
Method for Setting Timeout Intervals in /etc/system
Before setting up the initial cluster configuration, modify /etc/system for all nodes according to below procedure.
1. Make a backup of /etc/system.
  Example:
  Make a copy of /etc/system and save it under the filename /etc/system.org.
  # cp /etc/system /etc/system.org
2. Set the monitoring timeout interval in /etc/system.
  As the monitoring timeout interval is specified in microseconds, you have to multiply the seconds calculated in above item "a." by 1,000,000 for this setting.
  set driver name: scf_rdctrl_sense_wait = monitoring timeout interval [microseconds]
  Example:
  Setting a 2-second monitoring timeout interval for a SPARC Enterprise server with 2 domains.
  set scfd:scf_rdctrl_sense_wait = 2000000
3. Restart the node.
  Example:
  # /usr/sbin/shutdown -y -g0 -i6

3.2.3.2 RMS Configuration

In order to ensure that RMS runs normally, the following kernel parameters need to be set. Therefore, when RMS is installed, the definitions of the parameters in /etc/system are automatically updated if not defined or defined with smaller value than the following "Value".

Kernel parameter	Characteristics	Value	Parameter description
msgsys:msginfo_msgmnb	Maximum value	4194304	Maximum size of the message that can be stored in a single message.
msgsys:msginfo_msgmni	Addition	8192	Maximum number of message queue identifiers that can be used for the entire system.
msgsys:msginfo_msgtql	Maximum value	65535	Maximum number of message headers

Note

In PRIMECLUSTER, message queues are used for interprocess communication.
When RMS is running, 2076 message queues are reserved from 0x4d2.
If you are using message queues for any applications, use the range other than the above (0x4d2 to 0xcee).
Even if definitions of the kernel parameters in /etc/system are automatically added/updated, change the value as necessary in consideration of the value required by other software and user applications.