Hitachi

For Linux(R) (x86) Systems HA Monitor Cluster Software


6.19.1 Timing of user command issuance: when the server status has changed

HA Monitor issues a user command automatically in response to a change in the server's or HA Monitor's status. There are multiple timings for status changes. HA Monitor specifies parameters corresponding to the timing in arguments and then issues the user command. If the server whose status has changed is in the server mode, you can specify whether HA Monitor is to issue a user command when processing begins or when it ends. For servers and resource servers in the monitor mode, HA Monitor can issue a user command only when processing begins. Note that HA Monitor continues its processing of the relevant server after the user command is completed, and depending on the parameters, this processing might be executed asynchronously with MA Monitor processing.

This subsection explains the parameters that are passed from HA Monitor when a user command is issued based on a change in the server's status and explains the timing of user command issuance.

Organization of this subsection

(1) Parameters that are passed based on a change in the server's status

The following table lists and describes the parameters that are passed to user commands based on a change in the server's status.

Table 6‒17: List of parameters that are passed to user commands based on a change in the server's status

Server status

Server status parameter

Start and end parameters on the active server#1

Start and end parameters on the standby server#1

When a server starts

-s

start (start startup processing)

start (start startup processing)

end (terminate startup processing)#7

end (terminate startup processing)

When a server terminates normally

-e

start (start normal termination processing)#2

start (start normal termination processing)

--

end (terminate normal termination processing)

When a server is terminated according to the schedule

-p

start (start planned termination processing)#2

start (start planned termination processing)

--

end (terminate normal termination processing)

When the standby server terminates

-e

--

sbyend (start command processing)

--

--

Active server failure

When hot-standby switchover is possible

-a

start (start error handling processing)

start (start hot-standby switchover processing)

end (terminate error handling processing)

end (terminate hot-standby switchover processing)#7

When hot-standby switchover is impossible

-o#8

start (start error handling processing)

--

end (terminate error handling processing)

--

When HA Monitor waits for the active server to be restarted

-r#7

start (start waiting for restart)#2

--

--

--

When the restart limit of the active server is detected

-n#7

start (detects a restart limit)#3

start (detects a restart limit)#4

--

--

When the standby server fails

-a

--

sbyend (start error handling processing)

--

--

When a host fails

-h

--

start (start hot-standby switchover processing)#9

--

end (terminate hot-standby switchover processing)#7, #9

Planned hot standby

-w#5

start (start command processing)

start (start hot standby processing)

end (terminate command processing)

end (terminate hot-standby switchover processing)#7

When hot-standby switchover fails

-f

--

start (hot standby error)

--

--

Start retry limit error during hot standby processing#6

-t#7

start (start retry limit error notification)

--

--

--

Legend:

--: A user command is not issued.

Bold type: If the server whose status changed is a monitor-mode server or resource server, the parameter is not passed. Therefore, a user command is not issued in this case.

#1

The top item on a row is the start parameter, and the bottom item on a row is the termination parameter.

#2

end is not issued because the time is the same as for start.

#3

-a is issued after this parameter.

#4

If restart is specified in the switchtype operand in the server environment definition, -a is issued after this parameter. If manual is specified in the switchtype operand, nothing is issued after this.

#5

The user command is also started with -w in the following cases:

  • A failure occurs on the active server in the monitor mode.

  • When servers are grouped and hot standby processing is performed due to a failure on another active server (including the resource server).

#6

The parameter is passed if retry is specified in the switch_error operand in the server environment definition.

#7

This processing is executed asynchronously with HA Monitor processing.

#8

The user command is also started with the -o parameter if the server fails to start for any of the following reasons:

  • Server startup is canceled by the ip_neck, vg_neck, fs_neck, uoc_neck, or start_timeout operand specified in the server environment definition.

  • The wait-state server termination command (mondeact) is run while the server that failed to start is in the start retry state (>ONL).

  • In a case where yes is specified for waitserv_exec in the server environment definition, the start command specified for the name or actcommand operand in the server environment definition returns a result other than 0.

#9

When the active server is started by using the monact command in the online serverless mode, hot-standby switchover processing is assumed and this parameter is passed.

The following table lists and describes the parameters that are passed to user commands based on a change in the HA Monitor status.

Table 6‒18: List of parameters that are passed to user commands based on a change in the HA Monitor status

HA Monitor status

Start and end parameters on the local host

Detailed information parameter for a remote host

When HA Monitor starts on the local host

-m

Start startup processing

start

--

When HA Monitor terminates on the local host

-m

Terminate startup processing

end

--

When HA Monitor fails on a remote host

-m

--

-d host-name (HA monitor failure detected on the remote host indicated by host-name)#

Legend:

--: A user command is not issued.

#

When a standby server in the online serverless mode is started as the active server by using the monact command, the user command for this parameter is not executed.

(2) Timing of user command issuance (when the server status has changed)

This subsection explains the timing of user command issuance.

The following figure shows the parameters that are passed when the server is started and their issuance timing.

Figure 6‒42: Parameters that are passed when the server is started and their issuance timing

[Figure]

The following figure shows the parameters that are passed when the server is terminated normally and their issuance timing.

Figure 6‒43: Parameters that are passed when the server is terminated normally and their issuance timing

[Figure]

The following figure shows the parameters that are passed when planned termination is performed on the server and their issuance timing.

Figure 6‒44: Parameters that are passed when planned termination is performed on the server and their issuance timing

[Figure]

The following figure shows the parameters that are passed when the standby server is terminated and their issuance timing.

Figure 6‒45: Parameters that are passed when the standby server is terminated and their issuance timing

[Figure]

The following figure shows the parameters that are passed in the event of an active server failure and their issuance timing.

Figure 6‒46: Parameters that are passed in the event of an active server failure and their issuance timing

[Figure]

The following figure shows the parameters that are passed when hot standby processing cannot be performed and their issuance timing.

Figure 6‒47: Parameters that are passed when hot standby processing cannot be performed and their issuance timing

[Figure]

The following figure shows the parameters that are passed when the system is to wait until the active server is restarted and their issuance timing.

Figure 6‒48: Parameters that are passed when the system is to wait until the active server is restarted and their issuance timing

[Figure]

The following figure shows the parameters that are passed when the active server's restart wait limit time has elapsed and their issuance timing.

Figure 6‒49: Parameters that are passed when the active server's restart wait limit time has elapsed and their issuance timing

[Figure]

The following figure shows the parameters that are passed in the event of a standby server failure and their issuance timing.

Figure 6‒50: Parameters that are passed in the event of a standby server failure and their issuance timing

[Figure]

The following figure shows the parameters that are passed in the event of a host failure and their issuance timing.

Figure 6‒51: Parameters that are passed in the event of a host failure and their issuance timing

[Figure]

The following figure shows the parameters that are passed when planned hot standby processing is performed and their issuance timing.

Figure 6‒52: Parameters that are passed when planned hot standby processing is performed and their issuance timing

[Figure]

The following figure shows the parameters that are passed when an active server failure has occurred and hot standby processing has failed and their issuance timing.

Figure 6‒53: Parameters that are passed when an active server failure has occurred and hot standby processing has failed and their issuance timing

[Figure]

[Figure]

The following figure shows the parameters that are passed when an active server failure has occurred in a multi-standby configuration, but hot standby processing has failed and the server is to be switched over to another standby server and their issuance timing.

Figure 6‒54: Parameters that are passed when an active server failure has occurred in a multi-standby configuration, but hot standby processing has failed and the server is to be switched over to another standby server and their issuance timing

[Figure]

[Figure]

The following figure shows the parameters that are passed when a host failure has occurred and hot standby processing has failed and their issuance timing.

Figure 6‒55: Parameters that are passed when a host failure has occurred and hot standby processing has failed and their issuance timing

[Figure]

The following figure shows the parameters that are passed when a host failure has occurred in a multi-standby configuration, but hot standby processing has failed and the server is to be switched over to another standby server and their issuance timing.

Figure 6‒56: Parameters that are passed when a host failure has occurred in a multi-standby configuration, but hot standby processing has failed and the server is to be switched over to another standby server and their issuance timing

[Figure]

[Figure]

The following figure shows the parameters that are passed when planned hot standby processing has failed and their issuance timing.

Figure 6‒57: Parameters that are passed when planned hot standby processing has failed and their issuance timing

[Figure]

[Figure]

The following figure shows the parameters that are passed when planned hot standby processing has failed and the server is to be switched over to another standby server and their issuance timing.

Figure 6‒58: Parameters that are passed when planned hot standby processing has failed and the server is to be switched over to another standby server and their issuance timing

[Figure]

[Figure]

Figure 6‒59: Parameters that are passed in the event of a start retry limit error and their issuance timing

[Figure]

[Figure]