ONTAP Cluster Fundamentals and Administration
This domain tests how an ONTAP cluster is assembled, how quorum keeps it available, and the administrative tasks that keep it healthy.
Cluster architecture
A cluster is a set of nodes managed as one system. Clients reach data through data LIFs, administrators through a cluster management LIF and per-node management LIFs. Nodes are installed as HA pairs and connected by the HA interconnect and the cluster interconnect. Each node has one vote, and epsilon adds one extra vote to break ties. A cluster must hold a majority of possible votes to serve data.
Administration
Initial setup uses cluster create or System Manager; verify with cluster show, system node show, and network interface show. Licensing is capacity-based or feature-based; inspect it with system license show. ONTAP upgrades are rolling and non-disruptive when HA is healthy: add the image with cluster image add, validate with cluster image validate, then update one HA pair at a time. Configure EMS and AutoSupport before making changes.
Worked example
A 4-node cluster has epsilon on node1. Possible votes are 5, so quorum is 3. If node1 and node2 fail, node3 and node4 hold 2 votes and the cluster loses quorum. If node2 and node3 fail instead, node1 has its own vote plus epsilon and node4 has one vote, giving 3 votes, so the cluster keeps quorum. Epsilon placement therefore matters during maintenance.
Traps
Assuming any two surviving nodes keep a 4-node cluster online; confusing the cluster interconnect with the HA interconnect; upgrading every node at once; and forgetting that a 2-node cluster depends on epsilon and HA takeover.