This document describes how to configure the active/standby management function based on openUBMC.

openUBMC active/standby management is used to manage multiple nodes that have an active-standby relationship in a modular device. The main function is active/standby switchover between nodes. For example, if the current BMC encounters a fatal alarm and cannot continue running, it is demoted to standby, and another active BMC is selected to ensure proper device running.

The preceding functions are implemented through object configurations. The following describes these configurations in detail.

ActiveStandbyLocal ​

Configuration Interpretation ​

Generally, Id uses the slot number and can be customized if there is no slot number. Id is used to match the default active BMC. That is, if a node is set as active, it sends a signal ahead of other nodes to participate in the active/standby arbitration.

The address and port number of the local BMC are used to create a server for remote access, as this local BMC is considered a remote node for other nodes. Make sure the port is available.

The data source for the presence signal is unrestricted. For example, CPLD can be read through Accessor or obtained from the presence status of the downstream Connector.

Configuration Example ​

    "ActiveStandbyLocal_0":{
        "Id": 1,
        "Presence": "#/Object1.Presence",
        "Address": "192.168.100.114",
        "Port": 51000
    }

ActiveStandbyRemote ​

The configuration is similar to that of ActiveStandbyLocal. The following describes the configuration differences.

The local BMC will call the resource collaboration interface of the remote BMC for configuration, meaning that the local BMC will access the remote BMC using the configured address and port.

Configuration Example ​

    "ActiveStandbyLocal_0":{
        "Id": 2,
        "Presence": "#/Object2.Presence",
        "Address": "192.168.100.115",
        "Port": 51001
    }

SwitchRule ​

Configuration Interpretation ​

This configuration applies to the following scenarios:

1. An active/standby switchover needs to be performed immediately when specific conditions are met. For example, if a fatal alarm occurs and the active node needs to be demoted to standby, a switchover request is sent after the preceding configuration takes effect.

2. An active/standby switchover is not expected to happen, for example, in scenarios where the firmware is being upgraded and activated. You can configure a prohibition rule to prevent the switchover. After the threshold is triggered, a check is performed to determine whether the prohibition rule takes effect.

Configuration Example ​

    "SwitchOverRule_0": {
        "RuleType": 1,
        "Threshold": 1,
        "Reading": "<=/Scanner_CPLD1.Value",
        "Operator": 5,
        "Enabled": true,
        "Direction": 0,
        "Description": "CPLD Validating"
    }

Resource Display Example ​

> busctl --user tree bmc.kepler.active_standby_mgmt
...
├─/bmc/kepler/Managers
    │ /bmc/kepler/Managers/1
    │  /bmc/kepler/Managers/1/ActiveStandby
    │   /bmc/kepler/Managers/1/ActiveStandby/Local  # Local BMC
    │   /bmc/kepler/Managers/1/ActiveStandby/Remotes
    │     /bmc/kepler/Managers/1/ActiveStandby/Remotes/ActiveStandbyRemote_0_01  # Remote BMC
    │     /bmc/kepler/Managers/1/ActiveStandby/Remotes/ActiveStandbyRemote_1_01  # Remote BMC
    │   /bmc/kepler/Managers/1/ActiveStandby/SwitchRules
    │     /bmc/kepler/Managers/1/ActiveStandby/SwitchRules/SwitchRule_0  # Switchover rule
    │     /bmc/kepler/Managers/1/ActiveStandby/SwitchRules/SwitchRule_1  # Switchover rule
    ...

ActiveStandbyService ​

Configuration Interpretation ​

This class contains a series of hardware signals related to active/standby status read as well as properties for assisting active/standby detection.

Optional items, such as the heartbeat detection interval, can be configured as needed.

Since these configurations are used to support various industries, all hardware signals may not be available. For example, if BoardInRead of the read class is not necessary, it can be fixed to 1.

The write class is implemented by writing 1 (write) and 0 (clear). The basic process is as follows: Enable write protection, write the active/standby switchover to the register, and read ActiveRead to obtain hardware signals to determine the active/standby status.

Therefore, if write protection is not involved, you can omit it.

Configuration Example ​

    "ActiveStandbyService_0": {
        "DefaultActiveId": 1, // By default, BMC 1 in the chassis is the active BMC.
        "StandbyToActiveWrite": "#/Accessor_ToActive.Value",
        "ActiveToStandbyWrite": "#/Accessor_ToStandby.Value",
        "StandbyToActiveWriteProtect": "#/Accessor_ToActivePro.Value",
        "ActiveToStandbyWriteProtect": "#/Accessor_ToStandbyPro.Value",
        "HeartbeatWrite": "#/Accessor_Heartbeat.Value",
        "HealthStatusRead": "#/Scanner_Health.Value",
        "ActiveRead": "#/Scanner_Active.Value",
        "BoardInRead": "#/Scanner_BoardIn.Value",
        "HeartbeatIntervalMS": 300,
        "HeartbeatTimeoutMS": 3000,
        "StatusIntervalMS": 200
    }

The data in the example comes from Accessor, but the data source is not necessarily a hardware register and can be adapted based on industry-specific requirements.