# Fencing recommendations

Fencing is an automated means of isolating a node that appears to be malfunctioning, used to protect the integrity of the DRBD volumes. In a test deployment of a Control Center high-availability cluster, fencing is not necessary. However, on production clusters, fencing is a critical consideration.

Work with your IT department to implement the best fencing solution for your infrastructure. Employ a technique that ensures that a failed node in the cluster is completely stopped to avoid application conflicts or conflicts with the cluster management software.

When fencing is employed in the high-availability cluster, use two NICs per node.

Before you configure and enable fencing in your production environment:
• Ensure that all components are deployed.
• Verify operation of the application that Control Center is managing.
• In a controlled scenario, confirm basic cluster failover.
If a fencing method is not defined, when the cluster attempts to fail over to the backup node, the following error results:
no method defined

Place the fencing device on the public network. (Passing heartbeat communication through a private network interface is not recommended. Doing so requires a complex fencing system that is prone to issues. For more information, see Quorum Disk documentation on the Red Hat website.)

Using a public network interface enables a healthy node to fence the unhealthy node, and prevents the unhealthy node from fencing the healthy node. If heartbeat communications pass through the public network and the link for a node goes down, the node with the down public network link cannot communicate with the fencing device.