Rack & Fabric Planner
Pack a representative rack, move access switching between rack and row, trace A/B packet paths and expose the physical or logical constraint that binds first.
This interactive teaching scenario begins with a representative 42U cabinet, eighteen two-unit servers, top-of-rack access and two logical fabrics. Every default is an editable assumption. The page does not recommend a rack, switch, cable, cooling interface or topology, and it does not convert unlike constraints into a hidden score.
Learning objectives
- Treat rack units as one constraint among depth, weight, power, cooling, outlets and service access
- Compare top-, middle- and end-of-row access without hiding switch count, cable length or network-rack consequences
- Test access, fabric, shared-route and external-room failures against explicit attachment and diversity assumptions
Rack units are only the first boundary
The live elevation reconciles server equipment, in-rack network units, accessories, free space and overflow against the entered rack height. Adding or removing a server changes that physical stack immediately. Separate checks preserve dimensions that a U-count cannot prove: equipment and connection depth, installed rack envelope, server-removal clearance, rack mass, the lower of rack and entered structural weight limits, real power, rack-PDU outlet count and unsealed openings.
Liquid-ready is also treated as an interface, not a badge. Requested liquid heat capture remains unsupported until a rear-door or direct-liquid rack interface is selected. When an interface is present, the result still exposes residual air heat instead of implying that every kilowatt leaves through liquid. Point loads, floor distribution, seismic restraint, airflow and vendor fit remain outside this compact model.
Top, middle or end of row
Top-of-rack access consumes U and power in every IT rack, creates short endpoint cables and limits one access-switch event to a local rack group. Middle-of-row and end-of-row options move switch U into modeled network racks and reduce duplicated switch count, but extend horizontal cable runs and enlarge the simplified access-failure group. Switch count is derived from entered server-facing port capacity; the page reports used and remaining ports, endpoint cable runs, total illustrative cable length, access-switch power, uplinks and transceiver ends.
These comparisons expose the consequence of a placement choice without pretending to produce a bill of materials. Patch panels, structured-cabling topology, connector standards, pathways, bend radius, cable fill, latency, optics reach, switch buffers and maintenance access require project-specific work.
Logical A/B is not physical diversity
The packet-path view keeps fabric A and fabric B as explicit lanes and repeats every connection in a semantic table. Dual attachment may cover all or only part of the server population; single-attached endpoints are divided between lanes. Losing one full fabric therefore preserves all dual-attached servers while stranding the portion pinned to that failed side. A top-of-rack access loss has a smaller modeled blast radius than a row-aggregated access loss.
Separate switches do not prove separate routes. A shared-tray event can remove both fabrics when route diversity is not selected. If routes are explicitly diverse, that event has no matching shared target and the model declines to invent an outage. The same rule applies to the external boundary: a shared meet-me room loss isolates the internal fabric, while explicitly diverse external rooms remove that common target from this exercise.
Capacity and failure drill
Entered demand per server is compared with one complete fabric's modeled uplink capacity. The displayed demand-to-capacity ratio can identify an entered full-fabric constraint, but it is not a latency, throughput, convergence or application-performance prediction. Before revealing a selected fault, the learner predicts stable, degraded, isolated or outage. The result then reports reachable servers, affected servers, external reachability and whether the chosen event actually maps to the current topology.
Use the constraint register to see which boundary is active, watched, clear or not evaluated. The model does not claim availability, Tier status, code compliance or commissioning success. It omits traffic distribution, ECMP behavior, routing protocols, failure detection, convergence timing, control-plane faults, oversubscription below the declared boundary, security policy and carrier diversity.
Use and limitations
Use this planner to compare assumptions, explain dependencies and identify the next engineering question. Real design still needs verified equipment data, rack and floor loading, electrical and thermal coordination, fire/life-safety review, cable and pathway design, network architecture, manufacturer limits, current standards, authority requirements and integrated testing.
Save and compare rack-and-fabric versions in Design Pro or continue into the Playbook reference trail.