ONTAP Cluster Fundamentals and Administration
What this domain tests
These questions check that you can explain how nodes, votes, and management interfaces fit together and that you can read the CLI output that proves a cluster is healthy. Expect cluster sizing, quorum and epsilon, management LIF roles, NTP, and licensing.
Core rules
- A cluster is 2–24 nodes running the same ONTAP release family; mixed versions are allowed only inside an upgrade window.
- Every node holds one vote. ONTAP assigns epsilon to exactly one node so the total vote count is odd, and a cluster needs a majority of votes to accept configuration changes.
- Interface roles are fixed at creation: cluster management, node management, data, cluster, and intercluster. The cluster management LIF is the address used by System Manager and the REST API.
- Time must be synchronized by NTP before cluster creation; Kerberos, certificates, and SnapMirror all fail on clock skew.
- Package licenses such as Base, SnapMirror, SnapVault, and FlexClone are cluster-wide, not per node.
Worked example
A four-node cluster (one vote each, epsilon on node 3) loses nodes 1 and 2. Available votes are 2 of 4, but the majority is 3, so quorum is lost: cluster show marks the survivors unhealthy, volume and SnapMirror changes are rejected, and data service continues only briefly. A fifth node would have made the cluster tolerate two failures, because 3 of 5 votes is still a majority.
Traps
Assuming the epsilon node is a "master" - there is no master; epsilon only breaks ties. Assuming a cluster may run long-term on mixed ONTAP versions. Forgetting that node management LIFs are per node and do not fail over, while cluster management LIFs can move.