Network Architecture for Fusion SMB Clusters

This guide covers recommended network interface and VLAN layout for Fusion SMB cluster nodes. It is written for clusters backed by a distributed file system (such as IBM Storage Scale / GPFS) where storage traffic and SMB client traffic share the same servers, but the principles apply to any Fusion SMB cluster deployment.

note

Fusion SMB itself is network-topology agnostic: it binds to whatever interfaces the operating system presents (see the listen parameter). The choices below are made at the OS and switch level.

Guiding Principles

Assume two uplink (top-of-rack) switches. Enterprise ToR deployments almost always come in pairs, and best-practice cluster networking should treat two switches as the baseline, as switches are patched regularly for security and firmware updates, and each update reboots the switch. With a single uplink switch, every patch cycle is a production outage. With two, a node keeps serving through a switch reboot. The layout below that claims redundancy assumes the node's links are distributed across both switches.

Separate storage/cluster traffic from SMB client traffic. Run the storage and cluster-daemon network on different physical ports from the SMB client-facing network. This is a failure-isolation measure: a problem confined to the client network does not disturb storage access or cluster heartbeats, and vice versa. Keeping cluster heartbeat traffic off a potentially congested client network also reduces the risk of delayed heartbeats triggering an unnecessary failover. Operationally, the separation also makes troubleshooting simpler, because one port is the storage port, and the other is the protocol port.

Prefer host-tagged VLANs over switch-port assignment. Where a port carries traffic for a given VLAN, prefer 802.1Q tagging configured on the host (a trunk port plus a host-side VLAN subinterface, e.g. ens1f0.150) over an untagged access port whose VLAN membership lives only on the switch. With untagged access ports, configuration state lives only on the switch port, making the design administratively brittle: plug the host into the wrong port and traffic silently lands in the wrong network. With host-side tagging, a miscabled port fails loudly instead of quietly working incorrectly.

Node-level cluster failover is the backstop. A properly configured Pacemaker/Corosync cluster moves a failed node's resources to a surviving node. The per-node link and switch redundancy described below exists so that single events — one switch rebooting for a patch, one link or port failing — do not escalate into a full node failover. The cluster handles what the per-node redundancy cannot.

Reference Layouts

The examples below use two networks: a storage/cluster-daemon network (VLAN 100) and an SMB client access network where Fusion SMB services are exposed (VLAN 150). Two ToR switches, Switch A and Switch B, are assumed.

Layout A — Single dual-port NIC (not redundant)

            ┌─ ens1f0  VLAN 100 (storage/cluster)  ──> Switch A
  NIC 1 ────┤
            └─ ens1f1  VLAN 150 (SMB clients)       ──> Switch B

Two ports, one per network. This is the minimum viable layout, and it is not redundant — two ports cannot give two networks an uplink to each switch.

Survives: nothing, at the node level.

• Loss of NIC 1 takes the node's networking offline entirely.
• Loss of the storage port (or Switch A) takes storage access offline for that node.
• Loss of the client port (or Switch B) takes SMB service offline for that node.

In every case the node stops serving and the cluster must fail its resources to another node. Use this layout only when hardware constraints leave no room for a second NIC.

Layout B — Two dual-port NICs (most redundant)

            ┌─ ens1f0  VLAN 100 (storage/cluster)  ──> Switch A
  NIC 1 ────┤
            └─ ens1f1  VLAN 150 (SMB clients)       ──> Switch A

            ┌─ ens2f0  VLAN 100 (storage/cluster)  ──> Switch B
  NIC 2 ────┤
            └─ ens2f1  VLAN 150 (SMB clients)       ──> Switch B

Each network is now present on two ports, on two NICs, across two switches:

• Storage (VLAN 100): ens1f0 → Switch A, ens2f0 → Switch B
• Clients (VLAN 150): ens1f1 → Switch A, ens2f1 → Switch B

Survives:

• Any single switch failure or reboot. If Switch A goes down for a patch, NIC 2's ports keep both networks reachable through Switch B.
• Any single NIC failure. If NIC 1 fails, NIC 2 still carries both networks through Switch B.
• Any single port or link failure, for the same reason.

This is the recommended greenfield layout: no single switch, NIC, or link failure forces a node failover.

note

These layouts describe physical failure domains only and intentionally leave NIC bonding and multipath out of scope to keep things simple. How redundancy across the two paths is realized is a matter of your own network and cluster design; see Active-Active Cluster for basic Fusion SMB cluster setup instructions.

Validation Checklist

Before placing a cluster into production, verify the following with Layout B:

1. Switch loss: reboot (or disconnect) Switch A, then Switch B in turn. Both networks remain reachable on the node throughout, with no SMB client disruption and no Pacemaker failover or fencing events.
2. NIC loss: disable each NIC in turn. Both networks remain reachable via the other NIC, again with no cluster events.
3. Link loss: pull each cable one at a time, confirming the same.
4. VLAN tagging: connecting a node to an unconfigured switch port fails rather than silently joining the wrong network.
5. Node failover and failback: with the network redundancy confirmed, validate that an actual node failure (not just a link/switch event) correctly moves Fusion SMB resources to a surviving node and back (see Active-Active Cluster).