Building high availability (HA) cluster solutions might be your expertise, but let’s face it, keeping your cluster configuration aligned with vendor best practices and in sync with changes to other IT layers such as OS, Storage, Networking and more can be extremely difficult.
When even the smallest misconfiguration or inconsistency can lead to unsuccessful fail-overs and even outages, are you 100% confident your Veritas Cluster Servers will fail-over successfully when needed?
VCS Configuration Alignment with Storage and Replication
Checking the configuration and accessibility of your underlying storage devices on a regular basis, AvailabilityGuard ensures that your availability and service goals are completely met. As a result, AvailabilityGuard gives you the confidence that your VCS Clusters will fail-over successfully, mount storage volumes and disk groups, and start applications.
In the case of Geo-Cluster (GCO) and Campus cluster, AvailabilityGuard ensures that your VCS Cluster is set correctly to manage the replication process and make LUNs accessible at the remote site.
Selected gap discovery issues:
- LUNS inaccessible to cluster nodes (local or remote nodes), or accessible to unauthorized hosts.
- SCSI-3 reservation best practice violations
- Data misplaced on incorrect storage tier, or on un-shared volumes.
- Incorrect replication settings – best practices for Consistency Groups, RDF, HORCM, GNS, agent and daemon, control/Gatekeeper devices, and more.
- Campus cluster and LV mirroring to incorrect sites
- And more.
Server and Application Level Settings
AvailabilityGuard analyzes the configuration of the different components within the domain of the VCS Cluster, including operating systems, zones, disk groups, file systems, Oracle and SQL database files and more. AvailabilityGuard verifies that the cluster configuration and the settings of each of these components are aligned and well-orchestrated. Any mismatch may lead to failed switch-overs.
- Mismatch between OS mount configuration and cluster mount resource config
- Existence of key directories/files as defined in resources (Oracle listener.ora, Apache httpDir, SYMCLI)
- Resource-specific best practices (NFSv4, Solaris Zones, DNS, etc.)
- Server network configuration – NIC bonding / teaming, private and public network connections, etc.
- And more.
VCS Node Alignment
Using an intelligent comparison engine, AvailabilityGuard proactively detects major differences between cluster nodes and allows the VCS Cluster administrator to easily fix inconsistencies that could lead to unexpected behavior at and following a cluster fail-over.
- Differences in OS version, level, SP, installed products, patches, user and group config, kernel parameters, services, kernel bits, domain, edition, licensed EMC/Veritas products, VG major numbers, configuration files, etc.
- Differencess in HBA settings, I/O fencing, time, etc.
- Differences in multipath config – number of path, LB policy, queue depth, path monitoring, and more.
- Different resource, resource attributes or dependency between GCO members
- Difference in application start / stop / monitor scripts between nodes
VCS Configuration Vulnerabilities
AvailabilityGuard verifies that VCS itself also complies with the vendor (Symantec) guidelines as well as with community-driven best practices. This is done by a deep analysis that includes comprehensive investigation of service groups, resources, LLT, GAB, network interface, fencing, and additional components.
- Valid resource and resource dependency configuration (mount and share, fileShare and lanman, etc.)
- Network Configuration best practices (correct IP/NIC resource definitions, GCO communication, Heartbeat settings, etc.)
- Valid states for resource, group and systems
- GCO / Campus Cluster Configuration (groups missing in secondary clusters, GCO replication agent best practices, etc.)
- I/O Fencing best practices