TL;DR

• Liquid cooling moves heat; it does not distribute or meter power. The rack still needs metered, switched distribution — and in a liquid-cooled cabinet the metering requirement usually rises, because the cooling equipment adds a second power population whose failure takes down the compute it supports.
• The CDU feed decision is a visibility decision. Share the rack PDU and a cooling fault appears as an outlet event. Feed it separately and the same fault is invisible at rack level. Both are valid; leaving it undecided is the error.
• Published envelope: 63 A maximum total load, up to 48 outlets. Input covers 100–277 VAC single phase, 312–418 VAC three phase, and DC at 48, 240 and 336 VDC.
• Choose the function model by your response, not your feature list. The published ladder runs Type D (total metering only) to Type A (total and outlet metering plus switching). Outlet switching only earns its cost where the answer is to isolate a circuit.
• Water logging is the sensor specific to liquid cooling. Published optional sensors cover temperature and humidity, door, smog, and water logging — and a coolant leak is a failure mode an air-cooled cabinet does not have.

There is a persistent assumption worth challenging directly: that a liquid-cooled rack needs less power infrastructure because it runs cooler. It does not run cooler in any sense that matters to distribution. The CDU is a substantial electrical load with its own pumps, controller, and fans. A rear-door heat exchanger has fans, pumps, and controls. The compute behind it has not become a smaller load; in most deployments it has become a larger one.

What liquid cooling changes is the failure topology. In an air-cooled rack, a failed fan is a capacity problem for that server. In a liquid-cooled rack, a failed pump in the CDU can take down an entire row of compute that depends on it. That change is the entire argument for why the PDU specification in a liquid-cooled installation deserves more attention rather than less.

The published reference product for this article is a remote-controlled intelligent rack PDU with total and outlet-level metering and switching, up to 48 outlets, a 63 A maximum total load current, input covering single-phase and three-phase AC plus DC feeds, and socket formats spanning IEC C13, C19, German, UK, US, and IEC 60309 industrial connectors.

Why the Power Requirement Does Not Shrink

The practical way to think about a liquid-cooled rack is as two distinct power populations rather than one load.

The IT population is the compute itself, and it behaves as it always has. High density, high power per rack, and a duty cycle close to constant.

The cooling population is new to the rack and is the part that gets missed. A CDU brings pumps, a control board, sensors, and often a heat rejection component. A rear-door heat exchanger brings fans and pumps. These are not small loads and they are not constant, because they cycle with server load.

The reason to keep them separate is not accounting tidiness. It is that the two populations have different failure semantics, and the monitoring and switching decisions follow directly from that.

The last row is one that catches people during equipment selection rather than during PDU selection. The compute takes rack-standard connectors, and a CDU controller or pump unit frequently takes an industrial connector. That is a constraint on what the PDU must provide, and it is worth establishing early because it changes what the cooling equipment inlet has to accept.

The Four Function Models and How to Choose Between Them

The published range is organised as a four-tier ladder by monitoring and switching depth. Understanding the ladder is the fastest way to specify correctly, because it lets you buy the tier your response plan actually needs rather than the one with the longest feature list.

The published specification gives each tier slightly different phrasing — Type A combines all four, Type B covers total metering and switching, Type C covers total metering with individual outlet metering, and Type D covers total metering alone. The table above is the practical summary of that ladder.

Where outlet switching stops being useful

This is the part worth thinking about for a liquid-cooled rack specifically, because the usual answer — isolate the failing circuit — breaks down on a cooling circuit.

Isolating a failing server is straightforward: you stop a machine that is already broken. Isolating a CDU in the same rack as live compute means stopping the cooling for equipment that is still running. That is not a fault response; it is a self-inflicted outage.

So outlet switching on a cooling circuit has value only where your response is genuinely to remove that circuit from service — for scheduled maintenance, for a controlled capacity reduction, or for a cabinet that is being decommissioned. If your response plan for a cooling alarm is to investigate rather than isolate, then Type A switching on that circuit is a feature you are paying for and not using.

Type C is frequently the better fit for a liquid-cooled cabinet: total metering plus outlet metering gives you the visibility to tell whether an abnormal draw is coming from compute or from cooling, without carrying switching capability you will not exercise.

The Electrical Envelope to Size Against

The published specification for this range is broad enough to cover most rack power designs, and the figures worth holding onto are the input range, the current limit, and the outlet count.

Three observations.

The DC capability is the one most buyers do not notice. The published input range includes 100–240 VDC and 43–56 VDC alongside the AC ranges. That matters in installations where auxiliary DC distribution is present alongside mains feeds, and it is a capability question that should be settled at specification rather than discovered during commissioning.

63 A is a ceiling, not a typical figure. Whether your rack uses it depends entirely on density and on whether the cooling load shares the feed. The point of the figure is that it defines where the single-feed boundary is; beyond it, the published range already offers three-phase, which is usually the cleaner answer than splitting into two racks.

48 outlets is more than most racks need, which is intentional. Outlet count is what determines metering granularity, and granularity is what lets you distinguish a compute load from a cooling load. A PDU with four outlets in a liquid-cooled cabinet is a PDU that cannot answer the question you installed it to answer.

Environmental Sensors for a Cabinet That Contains Coolant

The published optional sensor set is temperature and humidity, door, smog, and water logging, with the temperature and humidity sensor additionally sold separately.

Each of these maps to a distinct failure mode, and in a liquid-cooled cabinet one of them maps to a failure mode that does not exist elsewhere.

Water logging is the liquid-cooling sensor. A coolant leak inside a cabinet is a failure mode an air-cooled rack cannot have, and it is the failure with the highest consequence per event: liquid near live electrical equipment. Published support for water logging as an option means it can be included; what it does not mean is that it is included by default.

Temperature and humidity is the one you have to budget for. It is published as sold separately, which is an easy detail to miss when comparing quotations. In a sealed cabinet the temperature question is arguably more important than in an open one, because there is less air exchange to moderate it.

Door sensor has a specific meaning here. In a cabinet containing coolant distribution, a door sensor is not only an intrusion indicator; it is also a way of knowing when a cabinet has been opened for service while the cooling loop was live. That is a useful distinction to confirm with your monitoring team rather than assume.

Integration: Protocols Decide Whether the Data Is Usable

Published protocol support spans HTTP, SNMP v1 and v2, MODBUS TCP/IP, MODBUS RTU over RS-485, FTP, Telnet, and IPv4, with the ability to configure and control the device over web and SNMP, and to upgrade firmware by network download.

That protocol set divides fairly cleanly by use. Building management and energy management platforms typically consume SNMP. Equipment-level control and monitoring inside the facility more often uses MODBUS, in either its TCP/IP or RTU form. HTTP covers browser-based access. FTP and Telnet appear in the published list as legacy support.

The practical point is that this is a specification-time decision with an expensive failure mode. Retrofitting protocol support to an installed PDU means replacing the unit, and a fleet of PDUs that cannot talk to your monitoring platform produces equipment that is technically metered and practically invisible.

Firmware upgrade is a fleet-level question

The published capability includes downloadable firmware updates so that field-installed products can gain features without replacement. That is a genuinely valuable property for a fleet, but it needs one qualification: confirm it applies per unit and at your configuration, not only at factory level.

A PDU that must be physically replaced to gain a function should be specified differently from one that does not, and the difference should be established before the purchase order rather than at the point where a feature turns out to need a truck roll.

Where I Would Push Back on This Framing

I have argued that a liquid-cooled rack needs more power visibility rather than less, and that is defensible. It is worth saying where a reasonable engineer would disagree.

The strongest counter-argument is about scale. In a large direct-to-chip or rear-door installation, the CDU is often not inside the rack at all — it sits in the row or on the floor, on its own electrical design, often with its own distribution. In that architecture the rack PDU is doing exactly what it did before, serving compute only, and the argument for a higher tier largely dissolves.

That is a real architecture and it is common. My argument applies most strongly to the deployment pattern where the CDU or heat exchanger is in-cabinet, which is common in smaller and edge deployments and in retrofits of existing cabinets where the cooling was added rather than designed in from the start.

A second qualification is on the value of outlet-level granularity. I have implied that more outlets are better, and in a liquid-cooled cabinet that is usually true. It is not true everywhere. In a small cabinet with two or three loads, total metering plus a decent environmental sensor set answers the operational questions, and the additional cost of a high outlet count buys precision that nobody looks at.

Finally, a practical point about this article specifically. The published product information behind it covers intelligent PDU design and rack power distribution in detail. It does not, by its nature, document liquid cooling equipment or coolant distribution design. Where this article discusses CDUs and rear-door heat exchangers, it is describing the electrical and monitoring requirements those systems impose on a rack, not their thermal or mechanical design. Where it addresses CDU feeds, connectors, and failure topology, treat those as the questions to put to your mechanical and facilities teams rather than as conclusions drawn from a PDU datasheet.

Frequently Asked Questions

Start With Your Rack, Not the Model

The most useful first conversation about a PDU for a liquid-cooled rack is a description of what is actually in the cabinet and how it is fed, because that determines everything else.

The intelligent PDU range covers the four function model tiers from total metering through to total and outlet-level metering with switching, across single-phase and three-phase AC and DC feeds, with socket formats from IEC C13 and C19 through to IEC 60309 industrial connectors.

The remote-controlled intelligent PDU product page carries the full technical parameter table, including the 63 A maximum total load current, up to 48 outlets, the environmental sensor option set, the protocol list, the three-year limited warranty, and the downloadable firmware capability.

For a broader view of how monitoring and switching combine into a facility system, the intelligent power distribution solution page sets out the same function ladder alongside the web-based management, configurable alerting, and environmental monitoring features that sit on top of it.

Useful things to include with an enquiry: whether cooling equipment is in-cabinet or remote, whether it shares the rack PDU or has a separate feed, total and per-circuit load, the connector formats your compute and cooling equipment use, your monitoring platform and protocol, which alarms should trigger a power action rather than a notification, and the environmental sensors your failure modes require.

You can reach the team through the contact page