8. Information on other settings¶
This chapter provides the information on the other monitor or notification settings.
This chapter covers:
8.5. Cluster service automatic startup prohibition after improper stop
8.6. Grace period dependence at the automatic failover between server groups
8.1. Shutdown monitoring¶
8.1.1. Shutdown monitoring¶
8.1.2. Displaying and changing the shutdown monitoring¶
- Performs consistentlyShutdown is monitored. The heartbeat (see "5. Heartbeat resources details") timeout must be longer than the time required for the OS to shut down, including the applications exiting.
- Performs only upon the occurrence of a group deactivation failureShutdowns are monitored only upon the occurrence of a group deactivation failure. The heartbeat timeout (see "5. Heartbeat resources details") must be longer than the time required for the OS to shut down, including that needed for the applications to quit.It is recommended that you set Performs only upon the occurrence of a group deactivation failure if you are using shared disks, mirror disks or hybrid disks.
- DisableShutdown is not monitored.
8.1.3. Shutdown monitoring method¶
You can select how to monitor shutdown from:
- SoftdogFor this method, set the timer by using the softdog driver.
- IpmiFor this method, set the timer by using OpenIPMI. If OpenIPMI is not installed, you need to install it. For ipmi, see "Understanding User mode monitor resources".
- KeepaliveFor this method, set the clpkhb and clpka drivers of EXPRESSCLUSTER are used to set the timer.
Note
Check the distribution and kernel versions supported by the clpkhb and clpka drivers by referencing Supported distributions and kernel versions"in "Software" in "Installation requirements for EXPRESSCLUSTER" in the "Getting Started Guide".Check them when applying security patches which are released by a distributor to the operating cluster (when the kernel version is changed).
8.1.4. Setting of SIGTERM¶
Monitoring method: softdog
Successful shutdown (when softdog is selected and SIGTERM is enabled)
Issue a command (e.g., clpstdn, clpdown, shutdown, reboot).
Start the shutdown monitoring.
The shutdown of the OS starts.
If the OS issues SIGTERM during the shutdown, the shutdown monitoring ends due to enabled SIGTERM.
The shutdown of the OS succeeds.
Between (d) and (e), no stall can be detected.
Successful shutdown (when softdog is selected and SIGTERM is disabled)
Issue a command (e.g., clpstdn, clpdown, shutdown, reboot).
Start the shutdown monitoring.
The shutdown of the OS starts.
Even if the OS issues SIGTERM during the shutdown, the shutdown monitoring does not end at this point due to disabled SIGTERM.
- The shutdown monitoring ends and the softdog driver is unloaded.The shutdown of the OS succeeds.
Monitoring method: ipmi
Successful shutdown (when ipmi is selected and SIGTERM is enabled)
Issue a command (e.g., clpstdn, clpdown, shutdown, reboot).
Start the shutdown monitoring.
The shutdown of the OS starts.
If the OS issues SIGTERM during the shutdown, the shutdown monitoring ends due to enabled SIGTERM.
The shutdown of the OS succeeds.
Between (d) and (e), no stall can be detected.
Successful shutdown (when ipmi is selected and SIGTERM is disabled)
Issue a command (e.g., clpstdn, clpdown, shutdown, reboot).
Start the shutdown monitoring.
The shutdown of the OS starts.
Even if the OS issues SIGTERM during the shutdown, the shutdown monitoring does not end at this point due to disabled SIGTERM.
The shutdown of the OS succeeds.
A reset occurs.
Even if the shutdown is successful without any stalled status, a server is reset by ipmi.
On a server that can be powered off by software, reset is not performed.
It is recommended to enable SIGTERM if ipmi is selected as a method of monitoring.
When a stalled status occurs in OS shutdown.
When a stalled status in shutdown is detected
Issue a command (e.g., clpstdn, clpdown, shutdown, reboot).
Start the shutdown monitoring.
The shutdown of the OS starts.
A stall occurs during the shutdown of the OS.
A reset occurs.
8.1.5. Using heartbeat timeout¶
Use the timeout value for shutdown monitoring with the heartbeat timeout value.
8.1.6. Timeout¶
8.2. Bonding¶
8.2.1. Floating IP resource¶
Notes
If you specify "active-backup" to bonding mode, the communication may be temporarily lost when switching slave interfaces.
Bonding setting example
Note
For interconnection IP address, specify IP addresses only.
The following shows example settings to use FIP resource on bonding:
Device |
Slave |
Mode |
---|---|---|
bond0 |
eth0
eth1
|
active-backup(1)
balance-tlb(5)
|
bond0 |
eth0
eth1
|
active-backup(1)
balance-tlb(5)
|
For Server 1 and Server 2 in the figure below, slave interfaces eth0 and eth1 are combined by bonding to constitute a master interface bond0. To access Server 1 and Server 2, an IP address is set for the floating IP resource. It is possible for both the host on the same LAN as the cluster server and the host on the remote LAN to connect to the cluster server with the floating IP. The router does not need specific settings for using the floating IP.
IP address for the floating IP resource: 192.168.1.3
When FIP resource is enabled on srv1 by ifconfig: (bonding mode is set to "balance-tlb(5).")
$ ifconfig
bond0 Link encap:Ethernet HWaddr 00:00:01:02:03:04
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:6807 errors:0 dropped:0 overruns:0 frame:0
TX packets:2970 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:670032 (654.3 Kb) TX bytes:189616 (185.1 Kb)
bond0:0 Link encap:Ethernet HWaddr 00:00:01:02:03:04
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:236 errors:0 dropped:0 overruns:0 frame:0
TX packets:2239 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:78522 (76.6 Kb) TX bytes:205590 (200.7 Kb)
eth0 Link encap:Ethernet HWaddr 00:00:01:02:03:04
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:3434 errors:0 dropped:0 overruns:0 frame:0
TX packets:1494 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:332303 (324.5 Kb) TX bytes:94113 (91.9 Kb)
Interrupt:18 Base address:0x2800 Memory:fc041000-fc041038
eth1 Link encap:Ethernet HWaddr 00:00:05:06:07:08
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:215 errors:0 dropped:0 overruns:0 frame:0
TX packets:1627 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:77162 (75.3 Kb) TX bytes:141394 (138.0 Kb)
Interrupt:19 Base address:0x2840 Memory:fc042000-fc042038
eth2 Link encap:Ethernet HWaddr 00:00:09:10:11:12
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask: 255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:47 errors:0 dropped:0 overruns:0 frame:0
TX packets:1525 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2820 (2.7 Kb) TX bytes:110113 (107.5 Kb)
Interrupt:24 Base address:0x3000 Memory:fc500000-fc500038
The above block of "bond0" to be used for the public LAN or the second interconnect indicates the data on a device with eth0 and eth1 combined for bonding.
The block of "bond0:0" shows the data on the floating IP address activated on bond0.
"eth2" is a device to be used for the first interconnect.
8.2.2. Mirror disk connect¶
Notes
It is not recommended to use a mirror disk connect on bonding because communication may be interrupted temporarily when switching slave interfaces. Depending on the timing of mirroring, mirror recovery may be performed after switching bonding has completed.
An example of bonding setup
The following is an example of setting up bonding on a mirror disk connect:
Cluster Server |
Device |
Slave |
Mode |
---|---|---|---|
srv1 |
bond0 |
eth1
eth2
|
balance-rr(0)
active-backup(1)
balance-tlb(5)
|
srv2 |
bond0 |
eth1
eth2
|
balance-rr(0)
active-backup(1)
balance-tlb(5)
|
8.3. Alert Service¶
8.3.1. What is Alert Service?¶
EXPRESSCLUSTER X Alert Service (hereafter Alert Service) is a function to report failures mentioned above found in EXPRESSCLUSTER-installed cluster systems to system administrators in remote locations.
Failures are reported in three ways, each serving a different purpose.
- E-mail reportAlert messages in the Cluster WebUI are sent by e-mail to administrators.
- Network Warning lightThe network warning light is a visual display of the status of the server. When the server shuts down successfully, the network warning light goes off.The e-mail report and the network warning light function work independently of each other.
- SNMP trap sendingWhen a Cluster WebUI alert message is displayed, the contents of the alert are sent with an SNMP trap.
Alert Service allows you to:
Receive information about failures while not physically located in the same place as the management PC. This is achieved via e-mail reporting function.
Receive e-mail messages on your mobile phone.
Visually be alerted of failures by viewing the network warning light.
Recognize a failure audibly by reproducing the audio file for the network warning light.
Notify the servers that are configured as the destination of the details of errors by SNMP trap sending.
Mail Report notifies the content of the alert in the following format by e-mail.
Subject:
EXPRESSCLUSTER
Body:
Message: Server [down server] has been stopped. Type: nm ID: 2 Host: [mail sending source server name] Date: [send time stamp]
8.3.2. Notes on Alert Service¶
To use the mail report and network warning light functions, EXPRESSCLUSTER X Alert Service 5.1 for Linux is required.
The task of Alert Service is to send the first report of failure but not to examine or find the cause of failure. When a failure occurs, instead of using the Alert Service, try other methods, such as viewing EXPRESSCLUSTER logs or syslog, to find out the cause of the error.
If you use the Linux network warning light function, it may prove necessary to install the rsh package
8.3.3. Mail report actions¶
Alert Service sends the same messages as the Cluster WebUI. See "Messages reported by syslog, alert, mail, SNMP trap, and Message Topic" in "11. Error messages" in this guide for information on which alert messages to be sent.
You can change the alerts that are reported by e-mail. For more information, see "Cluster properties - Alert Service tab" in "2. Parameter details" in this guide.
8.3.4. Network Warning Light status¶
The network warning light performs the following operations.
- When the server is startedWhen the server starts up successfully, warning light changes to green.
- When the server shuts downWhen the server shuts down successfully, warning light goes off.
- When the server failsWhen the server fails, its warning light flashes in red. If all servers in the cluster fail, the warning light of the server that failed last will not work because the network warning light is controlled by a normal server that monitors other servers.
Once the network warning light is lit or starts flashing, it will not go off until the cluster shuts down. Run the clplamp command introduced in the following section to put the light out. For more information on the clplamp command, see "Turning off warning light (clplamp command)" in "9.2. EXPRESSCLUSTER commands" in this guide.
For a network warning light (specified by NEC) that supports playback of an audio file, the setting also enables audio file reproduction to link to On/Off.
8.3.5. Operations of SNMP trap sending¶
The contents of Cluster WebUI alert messages are sent with an SNMP trap. For alert messages subject to SNMP trap sending, see "Messages reported by syslog, alert, mail, SNMP trap, and Message Topic" in "11. Error messages" in this guide.
The alerts subject to SNMP trap sending can be changed. For more information, see "Cluster properties - Alert Service tab" in "2. Parameter details" in this guide.
For details on the SNMP trap, see "SNMP trap sending".
8.4. SNMP linkage¶
8.4.1. SNMP linkage¶
SNMP linkage enables SNMP trap sending from EXPRESSCLUSTER and information acquisition by SNMP from an SNMP manager according to the EXPRESSCLUSTER MIB definitions.
8.4.2. EXPRESSCLUSTER MIB definitions¶
The information sent/acquired with SNMP linkage is configured by the MIB definition files.
To use the functions of SNMP trap sending and information acquisition by SNMP, described later, MIB definition files are required.
To receive SNMP traps from EXPRESSCLUSTER by using an SNMP manager, or to acquire cluster statuses from an SNMP manager, set the EXPRESSCLUSTER MIB definition files in the SNMP manager.
For how to set the MIB definition files in an SNMP manager, refer to the manual for the SNMP manager.
The EXPRESSCLUSTER MIB definition files are placed in the following directory on the EXPRESSCLUSTER X DVD-ROM.
<EXPRESSCLUSTER_X_DVD-ROM>\Common\<version number>\common\mib
The MIB definition files provide the functions described below.
No. |
MIB definition file |
Description |
---|---|---|
NEC-CLUSTER-SMI.mib |
Configures the EXPRESSCLUSTER MIB tree root path. |
|
NEC-CLUSTER-EVENT-MIB.mib |
Configures the trap and MIB definitions for the EXPRESSCLUSTER SNMP trap sending function. |
|
NEC-CLUSTER-MANAGEMENT-MIB.mib |
Configures MIB definitions for the following EXPRESSCLUSTER information:
- Cluster information
- Server information
- Group information
|
The available functions depend on the files set in the SNMP manager.
To receive SNMP traps from EXPRESSCLUSTER:
1. NEC-CLUSTER-SMI.mib2. NEC-CLUSTER-EVENT-MIB.mib
To acquire information by SNMP:
1. NEC-CLUSTER-SMI.mib3. NEC-CLUSTER-MANAGEMENT-MIB.mib
8.4.3. SNMP trap sending¶
SNMP trap sending serves to send the contents of Cluster WebUI alert messages to the SNMP manager.
To send a trap, the SNMP trap sending destination is required to be configured. Configure it by referring to Destination Settings of SNMP Trap in "Alert Service tab" in "Cluster properties" in "2. Parameter details" in this guide.
The traps to be sent are defined by NEC-CLUSTER-EVENT-MIB.
NEC-CLUSTER-EVENT-MIB defines the following MIB objects.
clusterEventNotifications group
This group defines the traps to be sent. The MIB objects defined for the group function as described below.
No. |
SNMP TRAP OID |
Description |
---|---|---|
clusterEventInformation |
Trap for information level alerts.
A clusterEvent group MIB object is attached.
|
|
clusterEventWarning |
Trap for warning level alerts.
A clusterEvent group MIB object is attached.
|
|
clusterEventError |
Trap for error level alerts.
A clusterEvent group MIB object is attached.
|
clusterEvent group
This group defines the information appended to the traps. The MIB objects defined for the group function as described below.
No. |
SNMP OID |
Description |
---|---|---|
clusterEventMessage |
Indicates the alert message. |
|
clusterEventID |
Indicates the event ID. |
|
clusterEventDateTime |
Indicates the time at which the alert originated. |
|
clusterEventServerName |
Indicates the server from which the alert originated. |
|
clusterEventModuleName |
Indicates the module from which the alert originated. |
8.4.4. Information acquisition by SNMP¶
By using the SNMP protocol, some information about the EXPRESSCLUSTER configuration and status can be acquired. However, EXPRESSCLUSTER does not include SNMP agent functions. For an SNMP agent, the Net-SNMP snmpd daemon needs to be implemented separately.
SNMP agent
The SNMP agent serves to return a response about the configuration information or status information (GetResponse) to information acquisition requests (GetRequest, GetNextRequest) from an SNMP manager (network management software).
Note
To use information acquisition by SNMP, you must take the steps described in "Setting up the SNMP linkage function" in the "Installation and Configuration Guide".
8.4.5. MIB objects acquirable with SNMP linkage¶
The MIB objects that can be acquired with the SNMP linkage function are defined by NEC-CLUSTER-MANAGEMENT-MIB.
NEC-CLUSTER-MANAGEMENT-MIB defines the following MIB objects.
clusterGeneral group
This group is used to acquire cluster information. The MIB objects defined for the group function as described below.
No. |
SNMP OID |
Description |
---|---|---|
clusterName |
Indicates the name of the cluster. |
|
clusterComment |
Indicates the comment of the cluster. |
|
clusterStatus |
Indicates the current status of the cluster. The correspondence between the MIB value and the Cluster WebUI status is as described below. MIB value status
---------------------
normal Normal
caution Caution
error Error
unknown -
|
clusterServer group
This group is used to acquire server information. Indexes on acquisition of clusterServerTable are sorted by server priority. The MIB objects defined for the group function as described below.
No. |
SNMP OID |
Description |
---|---|---|
clusterServerLocalServerIndex |
Indicates the index of the server receiving the present SNMP information acquisition request (clusterServerIndex). |
|
clusterServerTable |
Indicates the information table for the server. |
|
clusterServerEntry |
Indicates the server information list. The index for the list is clusterServerIndex. |
|
clusterServerIndex |
Indicates the index for uniquely identifying the server. |
|
clusterServerName |
Indicates the name of the server. |
|
clusterServerComment |
Indicates a comment for the server. |
|
clusterServerStatus |
Indicates the current status of the server. The correspondence between the MIB value and the Cluster WebUI status is as described below.
Values other than those indicated above may be acquired depending on the status of the server. |
|
clusterServerPriority |
Indicates the priority of the server. |
|
clusterServerProductName |
Indicates the name of the EXPRESSCLUSTER product installed on the server. |
|
clusterServerProductVersion |
Indicates the version of the EXPRESSCLUSTER product installed on the server. |
|
clusterServerProductInstallPath |
Indicates the installation path of EXPRESSCLUSTER on the server. |
|
clusterServerPlatformName |
Indicates the name of the platform on the server. |
clusterGroup group
This group is used to acquire group information. The MIB objects defined for the group function as described below.
No. |
SNMP OID |
Description |
---|---|---|
clusterGroupTable |
Indicates the information table for the group. |
|
clusterGroupEntry |
Indicates the group information list. The index for the list is clusterGroupIndex. |
|
clusterGroupIndex |
Indicates the index for uniquely identifying the group. |
|
clusterGroupName |
Indicates the name of the group. |
|
clusterGroupComment |
Indicates a comment for the group. |
|
clusterGroupType |
Indicates the type of the group. The correspondence between the MIB value and the group type is as described below. MIB value Group type
---------------------------------------
failover Failover group
cluster Management group
virtualMachine Virtual machine group
|
|
clusterGroupStatus |
Indicates the current status of the group. The correspondence between the MIB value and the Cluster WebUI status is as described below. MIB value status
---------------------------
online Online
onlineFailure Online Failure
offlineFailure Offline Failure
offline Offline
unknown Unknown
onlinePending Online Pending
offlinePending Offline Pending
|
|
clusterGroupCurrentServerIndex |
Indicates the index of the server on which the group is currently active (clusterServerIndex). The return value of a deactivated group is -1. |
8.5. Cluster service automatic startup prohibition after improper stop¶
8.5.1. Cluster service automatic startup prohibition¶
This function prohibits the EXPRESSCLUSTER service from automatically starting up at the next OS activation after the cluster has been shut down, reboot, or stopped by Cluster WebUI or the EXPRESSCLUSTER service has been stopped by using a command other than the clpstdn command and the clpcl -t -a command.
When the automatic startup prohibition setting is enabled, the EXPRESSCLUSTER service will not automatically start at the next server activation after the cluster has been shut down, reboot, or stopped by Cluster WebUI or the EXPRESSCLUSTER service has been stopped by using a command other than the clpstdn command and the clpcl -t -a command.
Even in cases where cluster shutdown or cluster stop is executed, if an error occurs in the EXPRESSCLUSTER service stop sequence, or if the stop sequence is not executed due to the likes of an OS reset or a power interruption, the EXPRESSCLUSTER service will not automatically start at the next OS activation.
8.5.2. Displaying and changing the automatic startup prohibition setting¶
- Cluster service's not stop normal, prohibit automatic startupProhibits cluster service automatic startup at the next OS activation if the servers are stopped by a means other than cluster shutdown or cluster stop, or if the cluster shutdown or stop sequence does not finish successfully.
- Not prohibit cluster service automatic startup after improper stopDoes not prohibit cluster service automatic startup.
8.5.3. Conditions for automatic startup prohibition¶
The conditions for automatic startup prohibition are as described below.
The cluster is stopped by a means other than cluster shutdown or cluster stop.
The cluster service stop sequence is not executed due to a reason such as an OS reset, panic, or power interruption.
Group deactivation fails in the cluster service stop sequence as a result of cluster shutdown or stop.
The cluster is stopped on one of the servers comprising the cluster.
8.5.4. Notes on automatic startup prohibition¶
At OS activation, if the EXPRESSCLUSTER service does not start automatically, activate the EXPRESSCLUSTER service by using Cluster WebUI or the clpcl command.
At OS activation, if the EXPRESSCLUSTER service does not start automatically, Cluster WebUI alert messages and syslog messages are output.
8.6. Grace period dependence at the automatic failover between server groups¶
8.6.1. What is the grace period dependence?¶
One server group waits specified time for the other server group to start failover when the automatic failover is executed between server groups. When the grace period elapsed after the server down was detected, the failover is executed.
8.6.2. Condition for the grace period dependence¶
One server group waits for the other server group with any of the following configurations to start the failover.
Use Server Group settings in the Info tab is selected.
Multiple server groups are specified for Server Groups that can run the Group in the Startup Server tab.
Prioritize server group failover policy is selected and Enable only manual failover among the server group is not selected for Auto Failover of Failover Attribute in the Attribute tab.
In the following cases, one server group does not wait specified time for the other server group to start failover:
One server executes the failover to another server within the same server group.
The server down is detected by the server down notification.
The forced stop is successfully executed while the type of forced stop is selected for other than Do Not Use, or the condition not to execute the forced stop is met.
The NP resolution resource is configured.
8.6.3. Displaying and changing the grace period dependence¶
Specify the waiting time for Grace period of server group failover policy.
If 0 is specified, one server group does not wait for the other server group to start failover.
8.6.4. Notes on the grace period dependence¶
If any operation is done for the failover target group while the other server group waits during the grace period, the settings to wait during the grace period is canceled and the other server group does not failover.
If the once-failed server is detected to be alive while the other server waits during the grace period, the settings to wait during the grace period is canceled and the failover is not executed.
If the failover target server goes down, the failover may start later than when the grace period ends.
8.7. Witness server service¶
8.7.1. What is Witness server service?¶
Witness service is the service to receive Witness heartbeat from each server in the cluster and send back the status information of receiving the heartbeat from each server as a response. It is installed in a server outside of the cluster.
8.7.2. Notes on Witness server service¶
Witness server service operates in Node.js environment. Therefore, Node.js needs to be installed before the installation of the Witness server service.
See "System requirements for the Witness server" in "Installation requirements for EXPRESSCLUSTER" in the "Getting Started Guide".
8.7.3. How to install Witness server service¶
Install the Witness server service by using npm command for Node.js environment. Store the Witness server service module in an arbitrary folder, and execute the following command.
> npm install --global clpwitnessd-<version>.tgz
Obtain the Witness server service module in the following path of the DVD-ROM for installation:
Common/<version>/common/tools/witnessd/clpwitnessd-<version>.tgz
8.7.4. How to configure Witness server service¶
To change the settings of Witness server service, edit the configuration file directly. Open the folder indicated in the first row of the execution results of the command below.
> npm list --global clpwitnessd
Example of execution results:
C:\Users\Administrator\AppData\Roaming\npm
`-- clpwitnessd@4.1.0
Edit clpwitnessd.conf.js that is stored in node_modules\clpwitnessd under the opened folder, with a text editor such as notepad.
Setting items are as follows.
Item |
Default |
Description |
---|---|---|
http.enable |
True |
Specify whether to execute HTTP server or not.
true: execute
false: not execute
|
http.port |
80 |
Specify the wait port number for HTTP server. |
http.keepalive |
10000 |
Specify the keep alive time for HTTP server in milliseconds. |
https.enable |
False |
Specify whether to execute HTTPS server or not.
true: execute
false: not execute
|
https.port |
443 |
Specify the wait port number for HTTPS server. |
https.keepalive |
10000 |
Specify the keep alive time for HTTPS server in milliseconds. |
https.ssl.key |
server_key.pem |
Specify a secret key file to be used for HTTPS server. |
https.ssl.crt |
server_crt.pem |
Specify a certification file to be used for HTTPS server. |
log.directory |
- |
Specify the log output destination folder. |
log.level |
info |
Specify the log output level.
error: Only error logs are output.
warn: Error logs and warning logs are output.
info: Warning logs and information logs are output.
debug: Information logs and detailed logs are output.
|
log.size |
1024 * 1024 * 512 |
Specify the log rotation size in bytes. |
data.available |
10000 |
Specify the default time limit for the communication status information of the cluster server in milliseconds. |
8.7.5. How to execute Witness server service¶
Execute the following command to start up Witness server service in the fore ground. For how to execute the Witness server service as Windows service or Linux daemon, refer to the following section, "Using Witness server service as the OS service".
> clpwitnessd
8.7.6. Using Witness server service as the OS service¶
If you want to start Witness server service at the OS startup, the Witness server service requires to be registered as the OS service.
The following exemplifies how to register Witness server service as the OS service (in case of Windows service control manager and Linux systemd). The method of registration for the OS service differs depending on the environment. Configure the registration to suit your environment by referring to the explanation below.
Registration for Windows service control manger
The following exemplifies the procedure to register by using npm package winser.
Install winser by npm command. Use the following command so that winser package is downloaded from npm repository and then installed.
> npm install --global winser
Create a folder to execute the service in any location. By default, this folder stores log files, SSL secret key file and SSL certificate file.
Create package.json file for the service registration with winser, under the folder created in the above step 2. Enter " \\ " to separate the characters of the path. The path specified for "start" is line-fed for the convenience of character numbers but actually is in one row.
{ "name": "clpwitnessd-service", "version": "1.0.0", "license": "UNLICENSED", "private": true, "scripts": { "start": "C:\\Users\\Administrator\\AppData\\Roaming\\npm\\clpwitnessd.cmd" } }
Execute winser command to register and start the Witness server service.
> winser -i -a
Select Control Panel -> Administration Tools -> Service, and confirm that the service (ex. clpwitnessd-service) with the name specified for "name" of package.json has been registered.
Registration for Linux systemd
The following exemplifies the procedure to register by creating the unit file of systemd.
- Create a directory to execute the service in any location. By default, this folder stores log files, SSL secret key file and SSL certificate file.(ex. /opt/clpwitnessd) (ex. /opt/clpwitnessd)
- Create the unit file of the Witness server service in /etc/systemd/system.(ex. clpwitnessd.service) (ex. clpwitnessd.service)
[Unit] Description=EXPRESSCLUSTER Witness Server After=syslog.target network.target [Service] Type=simple ExecStart=/usr/bin/clpwitnessd WorkingDirectory=/opt/clpwitnessd KillMode=process Restart=always [Install] WantedBy=multi-user.target
Execute systemctl command to register and start the Witness server service.
# systemctl enable clpwitnessd # systemctl start clpwitnessd