Skip to content

VIP Failover

High Availability Clusters often rely on a Virtual IP (VIP) to provide a stable endpoint for clients, even when nodes fail or migrate. Automating VIP failover with Pacemaker ensures seamless transitions between nodes, maintaining service availability. This section details how to configure and manage VIP failover using Pacemaker resources and CRM commands.

Configuring VIP as a Pacemaker Resource

To automate VIP failover, define the VIP as a resource in Pacemaker using the ocf:heartbeat:IPaddr2 agent (or a compatible agent). This resource manages the IP address and ensures it moves to a healthy node during failover.

Example: Define a VIP resource

crm configure primitive VIP_IP ocf:heartbeat:IPaddr2 \
  params ip="192.168.1.100" cidr_netmask="24" \
  op monitor interval="30s" timeout="20s"

Key parameters:
- ip: The VIP address to manage.
- cidr_netmask: Subnet mask (e.g., 24 for /24 network).
- network: Optional, specifies the network interface (e.g., eth0).

Ensuring Service Dependencies and Ordering

The VIP must be fenced properly to avoid split-brain scenarios. Use stonith (fencing) to isolate failed nodes. Additionally, ensure services depend on the VIP being online before starting.

Example: Enforce VIP availability before service start

crm configure order start-vip-before-services \
  inferschema=true \
  then="VIP_IP" \
  then="apache"

This ensures the VIP resource is online before starting the apache service.

Monitoring and Testing VIP Failover

Use crm_mon -1 to monitor the cluster state and verify VIP placement. Simulate a node failure to test failover: 

pcs cluster stop node1

Observe the VIP migrating to a healthy node. Validate connectivity to the VIP and ensure services remain operational.

Key Takeaways

  • Define VIP as a Pacemaker resource using ocf:heartbeat:IPaddr2 to automate failover.
  • Enforce ordering constraints to ensure services depend on the VIP being online.
  • Test failover scenarios with pcs cluster stop and use crm_mon to verify VIP migration.
  • Integrate fencing (stonith) to prevent split-brain and ensure node isolation.
  • Monitor cluster status regularly to confirm VIP and service availability.