LifeKeeper for Linux provides various fencing mechanisms. Depending on the server and storage configuration, available fencing mechanisms and allowed combinations of these may differ.

Refer to the information linked below for fencing mechanisms available in each server configuration. Details of storage configuration are described on the server configuration pages.

I/O Fencing Mechanism Summary

  • SCSI Fencing with SCSI-2 Reservations – By issuing a SCSI-2 reservation to the storage from the active node, the protected logical unit (LU) is locked, preventing simultaneous access from other nodes. When a communication failure is detected, a standby node will disable LU locks from other nodes, and then lock the protected LU, preventing simultaneous access from other nodes.
  • SCSI Fencing with SCSI-3 Reservations – By issuing a SCSI-3 reservation to the storage from the active node, the protected logical unit (LU) is locked, preventing simultaneous access from other nodes. When a communication failure is detected, a standby node will disable LU locks from other nodes, and then lock the protected LU, preventing simultaneous access from other nodes.
  • IPMI STONITH – When a communication failure is detected, the nodes will issue IPMI “power off” commands to the other nodes, preventing the protected service from starting on multiple nodes. This mechanism is available only for physical servers with IPMI interfaces.
  • VMware STONITH – When a communication failure is detected, the nodes will issue “power off” commands to the other nodes via the VMware host or vCenter APIs, preventing the protected service from starting on multiple nodes. This mechanism is available only for virtual machines running in VMware environments.
  • Quorum/Witness – When a communication failure is detected, an arbitrator will determine whether failover to a given node would effectively achieve service continuation. LifeKeeper normally prevents simultaneous access to LUs from multiple nodes with the reservation commands described above, but Quorom/Witness is mandatory in environments where reservations are not used. There are three modes of arbitration: dedicated Witness node, independent host, or shared storage (see Quorum/Witness for details).

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment