Child pages
  • Appendix A - Implementing a Multi-Server Chassis
Skip to end of metadata
Go to start of metadata

This appendix describes how to enable the multi-server functionality in Netmail Store to create two or more independent nodes in a single physical chassis.

On this page:


Note: If your node boots from a CSN, the configuration described in this appendix is performed automatically and no further action is required.

Environments that include high-density hardware with multiple cores can benefit from the multi-server functionality available in the latest Netmail Store release. This feature allows you to create multiple independent Netmail Store nodes in a single physical chassis with a subset of drives assigned to each node.

For multi-server implementations, each node requires at least:

  • Two CPU cores
  • Two hard drives
  • 2GB RAM

If your node does not boot from a CSN, you must assign a static IP address to the node.

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 multi-server 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.

Configuration Parameters

The following configuration parameters in node.cfg must be used in order to make use of the multi-server feature of Netmail Store.

  • Chassis processes
  • Network setup
  • Volumes
  • Node subcluster

Processes Parameter

The chassis.processes parameter enables you to specify the number of independent Netmail Store server processes that should be started in a physical chassis. Netmail recommends using n-1 processes for a chassis with n CPU cores, as too many Netmail Store server processes impairs performance. The parameter value must be an integer greater than 1.

For example, to implement two server processes within a single physical chassis, add the following entry to the node or cluster configuration file:

processes = 2


  • A memory overhead exists with running multiple Netmail Store processes in a single chassis. A single Netmail Store process indexes more objects than multiple processes sharing the same amount of RAM.
  • Make sure the number of IP addresses specified by the network.ipAddress parameter matches the number of processors specified by the chassis.processes parameter. For example, if you set chassis.processes = 3, make sure you specify three IP addresses.

The network.ipAddress parameter is described in the next section.

  • If the chassis.processes parameter is set, the disk.volumes parameter (as discussed in a following section) must be left blank or set to all.

Network Setup Parameters

When you implement a multi-server Netmail Store storage cluster, you must assign each node a static IP address because DHCP cannot be implemented in multi-server mode. When you enable the multi-server mode, the network.ipAddress parameter syntax is extended by appending the IP address for each process in a list, separated by a space.

The number of IP addresses must equal the number of server processes specified in the chassis.processes parameter. The network.netmask, default network.gateway, and all other network parameters are shared for all processes. As a result, they only need to be specified once, as in a single-process implementation.

For example, for a chassis with two processes, you can use the following node or cluster configuration file entries:

processes = 2
ipaddress =
netmask =
gateway =

Note: Consider assigning your chassis IP addresses in a continuous sequence (for example, 192,10.11.201, and so on). While not required, this process can help you monitor and maintain the related volumes in an orderly fashion.

Using the vols Parameter

When you configure a multi-server chassis, the disk.volumes parameter in the node or cluster configuration file specifies the volume or volumes that Netmail Store can use for cluster storage. The recommended setting (disk.volumes = all) causes Netmail Store to use all volumes greater than the configured disk.minGB (64GB by default). If you are booting Netmail Store from a USB flash drive, that drive is automatically excluded from the volume list.

The disk.volumes = all parameter causes all disk volumes in a chassis to be distributed evenly among the number of Netmail Store processes as defined by the chassis.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 essence, 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.

Using the node.subcluster Parameter

When using the multi-server mode, all nodes in a chassis are assigned a subcluster name, either by the administrator or automatically at boot time. You can optionally set the subcluster name using the node.subcluster parameter.

If the node.subcluster parameter is blank or not set, an automatic value is assigned when using multi-server 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 node.subcluster = to a value up to 16 characters. Special characters such as quotation marks and dashes cannot be used. For instance, to name the chassis ServerXYZ, enter the following in the node or cluster configuration file:

node.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 includes more than one chassis, 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 will not group nodes from the same chassis together. To simplify this process, you can optionally assign contiguous IP addresses in a chassis. For more information about volume identification, see Appendix E - Drive Identification API.

You can use subclusters for other purposes, such as data protection. For example, if you have data centers in separate wings of your building, you can create subclusters to copy content to data centers in both wings to provide high availability in case of a partial building loss. A loss could be events like a fire, flooding, or air conditioning problems.

Monitoring and Administration

The Admin Console displays 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. Restarting the chassis or shutting down a single process within the chassis (which appears as equivalent to a node on the Admin Console) restarts or shuts down all associated processes on the same chassis because they share system resources.

The Retire action impacts only the volumes for the specified process. If you wish to retire all volumes within a chassis, initiate retire actions for all associated server processes within the chassis.

  • No labels