{"id":32830,"date":"2023-09-15T09:30:22","date_gmt":"2023-09-15T01:30:22","guid":{"rendered":"https:\/\/www.deepin.org\/?p=32830"},"modified":"2023-09-15T14:38:10","modified_gmt":"2023-09-15T06:38:10","slug":"2023-09-15","status":"publish","type":"post","link":"https:\/\/www.deepin.org\/en\/2023-09-15\/","title":{"rendered":"An article on SBD (a storage-based extended protection service)"},"content":{"rendered":"\"\"<\/p>\n

OVERVIEW<\/span><\/h2>\n

SBD is a storage-based extended protection service that stands for STONITH Block Device.<\/span>\u00a0<\/span><\/p>\n

The highest priority for highly available clusters is to protect data integrity. This protection is achieved by preventing uncoordinated parallel access to data stores. Clusters use several control mechanisms to achieve this goal.<\/span><\/p>\n

However, electing several DCs in a cluster can result in network partitions or software failures. If this so-called \"node splitting\" is allowed to occur, data corruption may occur.<\/span>\u00a0<\/span><\/p>\n

The main mechanism that can be used to avoid this situation is node shielding through STONITH. If SBD is used as a node shielding mechanism the node can be shut down in the event of a node split without the need for an external shutdown device.<\/span><\/p>\n

SBD Components and Mechanisms<\/span><\/h2>\n

SBD Partition<\/strong><\/p>\n

In an environment where all nodes have access to shared storage, a small partition of the device is formatted for use with SBD. the size of this partition depends on the block size of the used disks (for example, for a standard SCSI disk with a block size of 512 bytes, the size of this partition would be 1 MB; a DASD disk with a block size of 4 KB would require a partition with a 4 MB size). The initialization process creates a message layout on the device, configuring message slots for up to 255 nodes.<\/span><\/p>\n

SBD Daemon<\/strong><\/p>\n

After configuring the appropriate SBD daemon, bring it online on each node and start the cluster. It terminates after all other cluster components have shut down, ensuring that cluster resources are never activated without SBD supervision.<\/span><\/p>\n

Messages<\/strong><\/p>\n

This daemon automatically assigns one of the message slots on the partition to itself and continuously monitors it for messages sent to itself. Upon receiving a message, the daemon will immediately execute a request, such as initiating a power-down or reboot cycle for masking.<\/span><\/p>\n

In addition, this daemon continuously monitors connectivity to the storage device and terminates itself when it is unable to connect to the partition. This ensures that it does not disconnect from the mask message. If clustered data resides in the same logical unit in different partitions, the workload will terminate as soon as connectivity to storage is lost, so no additional points of failure are added.<\/span><\/p>\n

softdog<\/strong><\/p>\n

Whenever you use SBD, you must ensure that the checkpoints are working properly. Newer systems support hardware checkpoints, which need to be \"energized\" or \"fed\" by a software component. The software component (in this case the SBD daemon) \"feeds\" the checkpoints by periodically writing service pulses to the checkpoints. If the daemon stops feeding checkpoints, the hardware forces the system to reboot. This prevents the SBD process itself from failing, such as losing response or getting stuck due to I\/O errors.<\/span><\/p>\n

If a Pacemaker cluster is active, SBD will not block itself when the majority of the device's nodes are lost. For example, suppose your cluster contains three nodes: A, B, and C. Due to network separation, A can only see itself, while B and C can still communicate with each other. In this case, there are two cluster partitions, one with a quorum due to the majority of nodes (B and C) and the other without (A). If this happens when the majority of the blocking devices are inaccessible, node A will immediately shut itself down, while nodes B and C will continue to operate.<\/span><\/p>\n

SBD Usage Requirements<\/span><\/h2>\n
    \n
  • Up to three SBD devices can be used for storage-based shielding. When using one to three devices, the shared storage must be accessible from all nodes.<\/span><\/li>\n
  • The path to the shared storage device must be permanent and consistent across all nodes in the cluster. Use stable device names, such as \/dev\/disk\/by-id\/dm-uuid-part1-mpath-abcedf12345.<\/span><\/li>\n
  • Shared storage can be connected via Fibre Channel (FC), Fibre Channel over Ethernet (FCoE), or even iSCSI, and zone-based RAID and multipathing are recommended for reliability.<\/span><\/li>\n
  • An SBD device can be shared between different clusters as long as the number of nodes sharing the device does not exceed 255.<\/span><\/li>\n<\/ul>\n

    Setting up the SBD device<\/span><\/h2>\n

    SBD Device Initialization<\/strong><\/p>\n

    To use SBD with shared storage, you must first create message layouts on one or three block devices. sbd create command writes metadata headers to one or more of the specified devices. It will also initialize message slots for up to 255 nodes. If the command is executed without any other options, the default timeout settings are used.<\/span><\/p>\n

    Note: Ensure that the device or devices to be used for SBD do not hold any important data. Execution of the sbd create command directly rewrites approximately the first MB of the specified block device(s) without further requests or backups.<\/span><\/p>\n

      \n
    1. Decide which block device or block devices to use for SBD.<\/span><\/li>\n
    2. Use the following command to initialize the SBD device:<\/span><\/li>\n<\/ol>\n

      root # sbd -d \/dev\/SBD create<\/p>\n