Adding a Third Node to a Switchless Two-Node Cluster
Two AFF A250 nodes run ONTAP 9.13.1 as a switchless cluster using direct-attached cluster ports c0a and c0b. The cluster serves 1,800 NFS and SMB users and is at 78% capacity. The team needs a third A250 node for capacity and for a new NFS-only project. The change window is four hours. A vendor engineer proposes racking the third node, cabling its cluster ports to the existing nodes' c0a/c0b ports, and running cluster join. The storage team is also asked whether the new node can join at a different ONTAP version to shorten preparation time. No cluster switches are currently installed, but two 25GbE switches are available in the rack. The operations team wants to know whether the proposal works, what must happen first, and how to reduce risk to production SMB sessions.
1. Is the vendor's proposal technically valid? Explain what the cluster topology requires and what must change before a third node can join.
Read the worked answer
The proposal is not valid as written. A switchless cluster is a strict two-node topology: the two nodes are connected directly through their cluster ports, and there is no supported way to attach a third node to those point-to-point links. The third node cannot simply cable into the existing c0a/c0b ports and run cluster join.
Before a third node can join, the cluster must be converted from switchless to switched. That means installing the two available 25GbE cluster switches, configuring the inter-switch link, and moving each existing node's cluster ports onto the switches. Only after the cluster network is switched and healthy can the third node be cabled and joined.
The version question is also a blocker. A node joining an ONTAP cluster must run a compatible release; the normal and safest practice is to match the existing cluster release exactly. Downgrading or mixing releases to save preparation time is not a valid shortcut.
A four-hour window is unrealistic for switch conversion, validation, node join, aggregate creation, and SMB validation. Split this into at least two changes: switch conversion first, then node addition.
2. Outline the sequence you would follow and the checks that prove the cluster is healthy before and after the new node is added.
Read the worked answer
Before conversion: record the cluster configuration, confirm both nodes have redundant cluster connectivity, verify NTP and DNS, confirm licenses and the ONTAP image for the new node, and validate that the switches are supported and correctly cabled. Check cluster switch health and port connectivity before moving production traffic.
Conversion: follow the documented switchless-to-switched procedure. Move one node's cluster ports at a time, verify cluster LIF connectivity and failover, then move the second node. Watch for cluster network errors, LIF migrations, and SMB session disruptions.
Join: cable the third node to both switches, verify its cluster ports are up, confirm the release matches, then join it. Validate with cluster show, network port show, network interface show -role cluster, and cluster switch health checks.
After join: confirm all three nodes are healthy, cluster LIFs can fail over across nodes, new aggregates can be created on the new node, and NFS/SMB clients can access data. Test SMB session continuity from a client and review event logs for cluster network or failover errors before declaring success.