The big picture of AI data centers

Current explanation · 1/5 · Start the checks at the work permit

Up next: Fix the lab target for the on-site comparison

1. Start the checks at the work permit

   Do not guess the cause and start by changing settings. If you group the following evidence into records from the same time window, another operator can reproduce the boundary at which the expected state broke.

2. Fix the lab target for the on-site comparison

   Lab scenario:: Compare the fixture's work order with the BMC sensor list and write a Go/No-Go record for entering the site. Instructions:: In the browser, read the training output below and write a verdict. Do not send the commands to real equipment. To reproduce the commands separately, prepare an approved isolated environment with the relevant tools and example files. Save the entire output, and if the permit, the labeling, and the actual asset do not match, do not move on to the next change.

3. Distinguish the output of the hazard review from what it means

   The point is not to memorize the values themselves but to confirm that the sensors can be read and that the temperatures and PSU status belong to the target named in the work order. The values shown are reproduced examples for training, not measurements taken on real equipment. Identifiers and values can differ by device, driver, and cluster.

4. Decide whether to proceed or stop at the observation record

   You succeed when a single pre-check sheet explains the permit number, the rack and asset match, the emergency procedure, the sensor state, and whether to stop. Record the execution time, target identity, commands used, key output, verdict, and next action together in the result.

5. Re-verify recovery for server rooms and work safety

   If the target or the labeling differs, do not touch anything on site; record photos, the asset tag and the time. Keep the No-Go until the work order is corrected or the approver re-confirms the target. After recovery, measure again with the same commands and the same success criteria. Do not close an incident just because things appear normal.

Current explanation · 1/5 · Start the check at the rack position

Up next: Fix the lab target for the chassis

1. Start the check at the rack position

   Do not guess the cause and start by changing settings. If you group the following evidence into records from the same time window, another operator can reproduce the boundary at which the expected state broke.

2. Fix the lab target for the chassis

   Lab scenario:: From a server inventory fixture, extract the physical, firmware, and OS identifiers and merge them into a single asset record. Instructions:: In the browser, read the training output below and write a verdict. Do not send the commands to real equipment. To reproduce the commands separately, prepare an approved isolated environment with the relevant tools and example files. Save the entire output, and if even one of the serial, MAC, or intended use does not match, do not move on to the next change.

3. Distinguish the output of the parts list from its meaning

   The point is not to memorize the values themselves but to confirm that the identifiers from the three layers converge on the single asset in the work order. The values shown are reproduced examples for training, not measurements taken on real equipment. Identifiers and values can differ by device, driver, and cluster.

4. Make the go/stop decision on CMDB linkage

   Success means linking the rack position, chassis serial, GPU and NIC PCI addresses, disk serials, and owner with nothing missing, and flagging every mismatch. Record the execution time, target identity, commands used, key output, verdict, and next action together in the result.

5. Re-verify recovery for racks and server components

   If there is a mismatch, do not start a firmware update or an OS installation. Attach the read-only inventory and ask the asset owner to correct the CMDB or the work target. After recovery, measure again with the same commands and the same success criteria. Do not close an incident just because things appear normal.

Current explanation · 1/14 · Start the checks at the power input

Up next: Fix the lab target for server load

1. Start the checks at the power input

   Do not guess the cause and start by changing settings. If you group the following evidence into records from the same time window, another operator can reproduce the boundary at which the expected state broke.

2. Fix the lab target for server load

   Lab scenario:: Using the provided sensor snapshot, judge the power headroom and the effect of the cooling anomaly on the GPU clock. Instructions:: In the browser, read the training output below and write a verdict. Do not send the commands to real equipment. To reproduce the commands separately, prepare an approved isolated environment with the relevant tools and example files. Save the entire output, and if you see loss of an A/B feed, a temperature rise, or throttling, do not move on to the next change.

3. Distinguish the output of heat rejection from what it means

   The point is not to memorize the values themselves but to confirm that power, temperature, and clock are within the allowed range at the same moment and that no throttle reason is present. The values shown are reproduced examples for training, not measurements taken on real equipment. Identifiers and values can differ by device, driver, and cluster.

4. Make the go/stop decision on the performance results

   You succeed when you state in numbers the headroom on each A/B feed, the temperature change, the clock impact, and the threshold for stopping new load. Record the execution time, target identity, commands used, key output, verdict, and next action together in the result.

5. Re-verify recovery of power and cooling

   If the temperature keeps rising or one feed disappears, stop new workloads and reduce the load. Check the PDU and CRAC status with the facilities owner, then re-verify under the same load. After recovery, measure again with the same commands and the same success criteria. Do not close an incident just because things appear normal.

6. An In-Rack CDU's loop ends inside the rack

   In this example, the In-Rack CDU fits into a 4U slot at the top or bottom of a 19-inch rack. Facility water enters the primary side of that 4U unit, takes heat from the equipment coolant in a plate heat exchanger, and returns. On the secondary side, equipment coolant passes through the rack manifold and the cold plates in each tray and returns within the same rack. Because the loop is short, the fluid volume is small, and filling, draining, and sampling are easy.

7. An In-Row CDU serves the whole row as a single loop

   An In-Row CDU is a floor-standing cabinet the same height as a rack, placed at the end of a row, between rows, or in an aisle. Facility water comes only as far as this cabinet, and the secondary-side equipment coolant supply header runs above the row or under the floor past every rack before returning through the return header. Because one unit serves the whole row, there are only one or two units to manage and no rack space is used, but the headers, branches, and hoses form one large loop with a volume of hundreds of liters or more.

8. Compare the two structures on the same items

   Form factor and location:: In-Rack units are built into a 4U slot at the top or bottom of the rack; In-Row units are floor-standing cabinets as tall as the racks, placed at the end of a row, between rows, or in an aisle. Scope of one unit:: In-Rack serves one rack; In-Row serves anywhere from several racks to an entire row. At the 2 MW class, official material includes an example of one unit serving 12 GB300 NVL72 racks. Where facility water reaches:: With In-Rack, facility water enters the rack itself, so facility water piping runs inside the IT room; with In-Row, it reaches only the CDU, so only equipment coolant piping runs along the rack row. Technology cooling volume:: In-Rack holds a few tens of liters (for example, 15.6 L), which makes filling, draining, and sampling easy; In-Row puts all headers, branches, and hoses on one loop, reaching hundreds of liters or more. Impact when one CDU fails:: With In-Rack, only that one rack; with In-Row, every rack the CDU serves, so add CDU N+1 or a UPS as well. What needs maintenance and water quality management:: In-Rack means managing filters, pumps, and sampling on one CDU per rack; In-Row means one or two CDUs per row. Rack space:: With In-Rack, the CDU occupies 4U, reducing the number of trays; with In-Row, the rack is unaffected, but floor space and front and rear service aisles are required. Where each fits:: In-Rack suits a small number of racks, retrofits into rooms that remain partly air-cooled, and rapid rack-by-rack growth; In-Row suits new builds and large AI clusters where high-density racks arrive a full row at a time.

9. kW figures without an approach temperature cannot be compared

   A heat exchanger cannot make the two water temperatures exactly equal. That gap between the facility water supply temperature and the technology cooling supply temperature is the approach temperature; the smaller it is, the colder the coolant you can produce from the same facility water, and conversely the same coolant temperature can be produced from warmer facility water, which reduces the chiller load. That is why vendor datasheets always attach a condition, such as "○○ kW at ○ °C ATD".

10. CDU vendor review: what the official material confirms

    Vertiv:: The In-Rack CoolChip CDU 121 (4U, 121 kW at 4 °C ATD, dual pumps, 50 µm filter), the In-Row and perimeter CoolChip CDU 600, 1350, and 2300 (600, 1,350, and 2,300 kW at 4 °C ATD, liquid-to-liquid), and the liquid-to-air CoolChip CDU 70 (70 kW) form one product family, and Vertiv's own technical documents summarize the pros and cons of In-Rack (1 rack affected), In-Row (several racks), and gallery (several rows). CoolIT Systems:: The range includes the In-Rack CHx80 (4U, 80 kW, N+1 pumps and power) and CHx200, plus the Row-based CHx2000 (2,000 kW at 5 °C ATD, 2,125 LPM at 35 psi, front and rear service, 12 racks of GB300 NVL72 per CDU). Capacity figures are stated together with ATD, flow rate, and pressure. Motivair by Schneider Electric:: The In-Rack CDU (4U, up to 105 kW, dual circulation pumps, mounted at the top or bottom of the rack) and the floor-standing MCDU-25 to MCDU-60 form one portfolio, and the MCDU-45 and 55 for utility corridor installation were announced on 2025-12-15. Since the 2025 acquisition by Schneider Electric, the company has emphasized integration with chiller plants. Boyd:: The In-Row liquid-to-liquid ROL4000 is rated at 2 MW at 3 °C ATD, with 80 psi available pressure, seal-less N+1 pumps, dual power feeds for each pump circuit, and a 0.2 µm side-stream filter. It is listed on the OCP Marketplace and references the fifth-generation Google Project Deschutes design. No In-Rack product could be confirmed in the official material. nVent:: The lineup includes the In-Rack RackChiller CDU100 (4U, 15.6 L on the secondary side, 2 pumps in N+1), the Row CDU RackChiller CDU800 (installed on a slab, on a raised floor, within a row, or in a separate mechanical room), and the Project Deschutes Open CDU (2 MW at 3 °C ATD, 1,890 LPM, 80 psi, N+1 seal-less pumps, 0.2 µm filter). nVent defines the role of the CDU as FWS isolation and limits on TCS temperature, dew point, flow rate, water quality, and pressure, and presents the ASHRAE S30 to S50 class table alongside. STULZ:: The In-Row class CyberCool CMU is specified at 345 to 1,380 kW and rated for 32 °C facility water supply and 36 °C equipment coolant supply, with optional redundant controllers, power, and pumps, and Modbus, BACnet, and SNMP control; it integrates the heat exchanger, pumps, valves, and controller in one cabinet. No In-Rack product could be confirmed in the official materials. OCP Project Deschutes (specification):: This is not a product but an open specification contributed by Google. It defines a 5th-generation In-Row CDU at 2 MW, approach 3 °C at 500 GPM, N+1 seal-less pumps, DI water or PG25, dual AC feeds, and a width of about 65 inches, and Boyd, nVent, Vertiv, and STULZ have listed products built to it on the OCP Marketplace.

11. Criteria for choosing by site conditions

    In-Row requires an equipment coolant header for each rack row, so the floor and ceiling piping routes, the CDU footprint and front and rear service space, and power feed redundancy must be settled early in the design. In-Rack, conversely, needs a facility water branch, isolation valves, and a leak tray at every rack. Either way, the required flow rate and pressure loss budget are fixed by the OEM design documents; the layout choice does not do that calculation for you.

12. Fix the order of checks

    Before choosing a placement or comparing products, record the following items in the same design document. If even one is unconfirmed, do not guess the numbers; confirm them with the OEM or facility staff.

13. A lab in reading candidate specifications under the same conditions

    Lab scenario:: Read the training fixture of candidate CDU specifications and the 12-rack row layout, align the approach conditions, then write a placement verdict choosing In-Rack or In-Row, with your reasoning. Instructions:: In the browser, read the training fixture below and write a verdict. Do not send commands to real equipment or to a CDU controller. The column names are vendor, model, type, atd_c (approach °C), capacity_kw, flow_lpm, available_psi, pump_redundancy, secondary_volume_l, and racks_served. The values are representative figures from official manufacturer documentation, normalized for training.

14. Hold the placement decision if the specification or redundancy is lacking

    If a design review shows a capacity without its approach condition, a specification without flow rate and available pressure, or an In-Row layout with no CDU redundancy or UPS feed plan, hold the placement decision, fill in the values from the OEM design document and the facility P&ID, and compare again in the same table. On an installed site, if the temperature of several racks rises together, first check the CDU serving that row and the facility water boundary; if only one rack rises, narrow the scope to that rack's branch, QD, and filter. After recovery, compare again using the same table and the same success criteria. Do not approve a placement based on a vendor name or a single kW figure.

Current explanation · 1/5 · Start the checks from the user request

Up next: Pins down the lab target for the workload

1. Start the checks from the user request

   Do not guess the cause and start by changing settings. If you group the following evidence into records from the same time window, another operator can reproduce the boundary at which the expected state broke.

2. Pins down the lab target for the workload

   Lab scenario:: Using the given service inventory, map the dependencies of a single request and find three common points of failure. Instructions:: In the browser, read the training output below and write a verdict. Do not send the commands to real equipment. To reproduce the commands separately, prepare an approved isolated environment with the relevant tools and example files. Save the entire output, and if a dependency has no owner or shares a common failure domain, do not move on to the next change.

3. Distinguish the output of the resource path from what it means

   The point is not to memorize the values themselves but to confirm that you can trace which node and network path the replica serving the request sits on. The values shown are reproduced examples for training, not measurements taken on real equipment. Identifiers and values can differ by device, driver, and cluster.

4. Make the go/stop decision on the facility foundation

   The task is complete when you present a map that runs from the user symptom through at least eight dependencies to the facility, with the owner and verification command for each. Record the execution time, target identity, commands used, key output, verdict, and next action together in the result.

5. Re-verify recovery of the full path to the service

   Classify any boundary without an owner or a verification method as not operationally ready. Before release, add observability signals and an escalation path, and use fault injection to confirm that recovery follows the map. After recovery, measure again with the same commands and the same success criteria. Do not close an incident just because things appear normal.