Document Type | Technical Information
Category | Administration
Applicable Product Version | 7FS02PS
Document Number | TADTI017
Overview
This document guides the Operation when the Interconnect goes down depending on the occurrence of a socket error.
Method
This describes the Operation when the Master Interconnect goes down while both nodes in the cluster are in an up state.
Case 1. No socket error occurrence
1. The Monitor Thread detects the Interconnect and writes it to the cfile.
2. The Master node selects the node to schedule out.
3. At this time, since the Master nodeโs Interconnect is down, the Master nodeโs cluster goes down according to scheduling priority.
Case 2. Socket error occurrence
1. (Before the Monitor Thread detects the Interconnect) Socket error detected โ "connection reset by peer. fd:11" log occurs in cm log.
2. CM excludes the Slave from the group (due to FAST_NET_ERROR_DETECTION).
3. Slave cluster goes down.
- When ifconfig down occurs on the Slave, the Slave nodeโs cluster goes down regardless of the occurrence of a socket error.
- When the Slave detects a socket error, it verifies the actual down status of the Master node via the cfile, and even if it does not receive a Slave down connection termination signal, the Slave Interconnect is down, so the Slave node goes down according to scheduling priority. (During testing, VIP switches to the Master node and the Slave node cluster goes down.)
NoteWhen performed via ifconfig down, the occurrence of socket errors varies depending on the OS and VM type. (This is handled by the OS, so the exact behavior is difficult to verify.)Testing should be performed using other commands such as ip addr or nmcli instead of ifconfig-related packages (net-tools).