On this page:
Environments that include high-density hardware with multiple cores may benefit from Netmail Store’s multi-server functionality. This feature allows for the creation of multiple independent Netmail Store servers within a single physical chassis, with a subset of the drives assigned to each server. Chassis used for multi-server implementations require a minimum of 2 CPU cores, at least two disks, and at least 1GB of RAM per server.
Note: After you set up a multi-server configuration, shutting down or restarting one node affects all nodes in the multi-server chassis. For example, if you set up a four-process multiserver chassis and restart a single process (that is, single node), the entire four-node chassis restarts. This is true for both SNMP shutdown/restart and shutting down or restarting using the Admin Console. The reason is that all services in the multi-server chassis share the same resources.
The following configuration parameters in node.cfg must be used in order to make use of the multi-server feature of Netmail Store.
The processes parameter allows you to specify the number of independent Netmail Store server processes that should be started within a physical chassis. Best practice is to use no more processes than one less than the total number of CPU cores in the chassis. Using too many Netmail Store server processes will lead to performance degradation. The parameter value should be an integer number greater than 1. For example, to implement 2 server processes within a single physical chassis, the following entry would be added to the node or cluster configuration file:
processes = 2
Note: Make sure the number of IP addresses specified by ipaddress matches the number of processors specified by the processes parameter.
Network Setup Parameters
When using multi-server Netmail Store, static IP address assignments in the node or cluster configuration file must be used. It is not possible to use DHCP for IP address assignment when using multi-server mode. When using multi-server mode, the syntax of the ipaddress parameter is extended by appending the IP address for each process in a list separated by spaces. The number of IP addresses must equal the number of server processes specified in the 'processes' parameter. The netmask, default gateway, and all other network parameters are shared for all processes so they only need to be specified a single time, as in a single-process implementation. For example, for a chassis with two processes, the following node or cluster configuration file entries entries could be used:
processes = 2
ipaddress = 188.8.131.52 184.108.40.206
netmask = 255.255.0.0
gateway = 220.127.116.11
Note: While not required, administrators may find it helpful to assign IP addresses for a chassis in a contiguous sequence to assist with monitoring and maintenance of the related volumes. For example: 18.104.22.168, 22.214.171.124, etc.
When configuring a multi-server chassis, the vols parameter in the node or cluster configuration file specifies the volume or volumes that Netmail Store can use for cluster storage. The recommended setting, vols = all, causes Netmail Store to use all volumes except the USB flash drive. vols = all causes all disk volumes in a chassis to be evenly distributed among the number of Netmail Store processes as defined by the processes parameter. This distribution occurs automatically at boot time and adapts to any changes in the number of disks or processes from the previous boot. In other words, the distribution of disk volumes to the Netmail Store processes change if necessary.
Note: The volsN parameters (e.g.,vols0, vols1) in earlier versions of Netmail Store have been deprecated and should be replaced with vols = all.
When using multi-server mode, all nodes in a chassis are assigned a subcluster name, either by the administrator or automatically at boot time. The subcluster name can be optionally set using the subcluster parameter. If the subcluster parameter is blank or not set, an automatic value is assigned when using multiserver mode in Netmail Store. The automatic subcluster assignment sets the subcluster name to the value of the first IP address for the chassis. The automatic assignment of subcluster creates a different subcluster each multi-server chassis.
If you choose to name your subcluster, set subcluster = to a value of at most 16 characters, at most, in length. Special characters like quotation marks are not allowed. For instance, to name the chassis ‘ServerXYZ’, enter the following in the node or cluster configuration file:
subcluster = ServerXYZ
When you assign the subcluster, you can include more than one multi-server chassis in the same subcluster provided more than one subcluster is used for the whole cluster.
Note: If your multi-server configuration has more than one chassis, you must use the drive identification feature to determine which physical chassis a given virtual node belongs to in the subcluster. Nodes are sorted by IP address so it is possible that the Admin Console does not group nodes from different chassis together. To simplify this, you can optionally assign IP addresses in a chassis contiguously. For more information about volume identification, see Drive Identification API.
Monitoring and Administration
The Admin Console will show each physical chassis at the same level as a subcluster. The Shutdown and Restart SNMP commands or admin console actions should be carefully considered in a multi-server implementation. Performing a restart or shutdown of a single process within a chassis (which appears as equivalent to a node on the Admin Console) will restart or shut down all associated processes on the same chassis since they share system resources. The Retire action will only impact the volumes for the specified process. Thus, if you wish to retire all volumes within a chassis, you must initiate retire actions for all associated server processes within the chassis.