Sizing a 4K Editing Cluster and Its SmartConnect Pool
A regional post-production company needs 400 TB usable capacity for 4K video editing, with 30% annual growth and N+2 protection. A vendor proposes six nodes, each with 48 TB raw capacity, dual 25 GbE front-end ports, and a 100 GbE back-end. The existing core network is 10 GbE with two 40 GbE uplinks. Thirty-five editors use SMB over 10 GbE; a render farm of 20 Linux nodes uses NFSv3. The customer wants one SmartConnect zone and one IP pool with eight addresses. During a proof of concept, six nodes delivered 192 TB usable. Editors reported latency when twelve concurrent streams landed on one node. The vendor says adding more IPs to the pool will fix the latency and that six nodes are enough because dedupe and compression will recover the missing capacity. The company wants a recommendation before signing.
1. Calculate usable capacity for the proposed six nodes and determine how many nodes are needed for 400 TB usable at N+2. What headroom would you recommend for 30% growth?
Read the worked answer
For n nodes at N+2, usable capacity is raw x (n-2)/n. Six nodes give 6 x 48 x 4/6 = 192 TB, which matches the proof of concept. To reach 400 TB at 48 TB per node: 48(n-2) >= 400, so n >= 10.33, meaning 11 nodes give 432 TB usable. For 30% growth, target 400 x 1.3 = 520 TB. Eleven nodes give 432 TB, 12 nodes give 480 TB, and 13 nodes give 528 TB. Recommend 13 nodes for the stated growth, or 11 now with a funded expansion path. Do not count dedupe or compression as guaranteed capacity in the sizing calculation.
2. Evaluate the network design. Where is the likely bottleneck, and how should the front-end and uplinks be changed?
Read the worked answer
The storage nodes have ample front-end bandwidth: 13 nodes x 2 x 25 GbE = 650 GbE. The core has only two 40 GbE uplinks, or 80 GbE aggregate. Thirty-five editors at 10 GbE can demand 350 GbE if they burst, so the uplink is heavily oversubscribed and will be the bottleneck before the nodes are. Upgrade the core to 100 GbE or add multiple 100 GbE uplinks, and use LAG with a balanced hash. For SMB, enable SMB multichannel so clients can use multiple TCP connections. For NFS, use multiple mount paths or session trunks where supported. Adding SmartConnect IPs alone will not fix an 80 GbE core uplink.
3. Is an eight-address SmartConnect pool appropriate for this design? How should the pool and zone be designed?
Read the worked answer
Eight addresses may be too few for 13 nodes and 46 clients, especially if one IP lands on a hot node. Design at least one SmartConnect IP per node, preferably two, and consider separate pools or zones for SMB editors and NFS render traffic if their policies or DNS names differ. A single zone can work if all clients use the same access zone and DNS delegation. Adding IPs alone will not fix a hot node if the policy is simple round-robin and clients keep reconnecting to the same address. Use a dynamic or CPU-based SmartConnect policy, verify DNS delegation, and test failover by taking a node down during editing.