Veritas Clustering

Veritas clustering sits at the heart of many enterprise HA environments I’ve supported. When it’s configured well, failover feels invisible. When it’s not, outages become memorable for the wrong reasons.

This page is part of my Infrastructure learning notes.

The mental model

A cluster is not just two servers sharing storage. It’s a coordinated system where:

1. Resources (IP addresses, mount points, applications) are grouped into service groups
2. Nodes monitor each other and arbitrate who owns each service group
3. Agents start and stop applications in the right order during failover

Understanding that order — and what depends on what — is where most troubleshooting time goes.

Core concepts

Concept	What it means
Service group	Logical bundle of resources that fail over together
Resource	IP, mount, application, or other managed object inside a service group
Heartbeat	Communication path nodes use to detect failures
Agent	Script or module that starts/stops an application during failover
Dependency	Rule that one resource must be online before another can start

Common pitfalls

• Split-brain risk when heartbeat networks aren’t isolated properly
• Resource dependencies that cause cascading failures during failover
• Stale mounts after storage path changes without updating cluster configuration
• Insufficient testing of failover paths in maintenance windows

My approach

Before changing any production cluster:

1. Document the current service group layout and dependencies
2. Validate heartbeat and storage connectivity on every node
3. Run a controlled failover in a maintenance window
4. Keep a rollback plan and communicate expected behavior to stakeholders

When Veritas fits the stack

Veritas clustering is common in environments that need:

• Application-level HA beyond a single hypervisor host
• Controlled startup order for multi-tier services
• Shared storage failover with explicit resource ownership
• Operational runbooks for planned maintenance and incident recovery

What to learn next

• Map every service group before touching production
• Practice failover in a maintenance window, not during an incident
• Document storage, network, and application dependencies together
• Pair cluster work with monitoring and escalation paths

I’ll add deeper scenarios here over time — storage migrations, multi-node upgrades, and automation patterns from live environments.

Related

• Infrastructure overview
• Docker & Kubernetes

If you’re building HA systems today, start with the dependency map. Everything else follows from there.