Transit operations separates management out-of-band networking from the GPU compute fabric in a municipal AI row. What distinction should the design preserve?
Select an answer to reveal the explanation.
Short Explanation
Keep the transit row’s back-door management path separate from the high-speed GPU highway—like service alleys versus the main rail line. OOB keeps BMC reachable when the compute fabric is sick; the AI fabric is for the heavy GPU chatter.
Full Explanation
Transit operations should preserve a hard distinction between management/out-of-band planes and the AI compute fabric: OOB carries BMC and recovery reachability, while the GPU fabric carries high-bandwidth training and inference traffic. That separation keeps consoles, power control, and firmware tools available when the compute network is congested, misconfigured, or down—exactly when municipal operators need them most. Forcing OOB and GPU fabrics onto the same VLAN and MTU profile collapses failure domains and can let noisy collective traffic or a fabric fault impair management access. Allowing the GPU fabric to replace BMC after the first training job starts removes the independent path required for hung hosts, bad drivers, or failed OS boots. Limiting OOB switches to desktop jump boxes that never touch GPU servers misunderstands HGX-class needs: the servers themselves require managed BMC connectivity. Exam caveat: limited, carefully controlled paths from jump hosts to BMC networks are normal; merging OOB into the high-speed GPU data plane is what designs must avoid. Operational check: trace a transit-row failure drill—disable or break a compute leaf in a lab window and confirm BMC console and power control still succeed via the dedicated management path.