How Modern DCIM Helps Multi-Tenant Colocation Data Centers Be More Competitive

Overview

The evolution of DCIM is summarised as 1.0 (1990s, local UPS management), 2.0 (2000s, space planning, capacity management and PUE for centralized sites) and 3.0 (today, distributed IT, resiliency, security, sustainability and tenant transparency). As in WP 281 it covers monitoring and device management alongside planning and modelling (VM-to-power-path mapping, failure simulation); passing alarm data to third-party ticketing via APIs or an SNMP MIB is listed as a monitoring function that reduces outage risk and mean time to repair.

Colocation-specific features are tenant portals with rack elevations, power capacity reports and camera views; sustainability reporting per tenant, per site and portfolio-wide covering PUE (current and historical), subsystem energy (total, IT, losses), scope 2 carbon by subsystem from local emission factors, CUE, WUE and waste; and a floor-plan overlay showing the commercial status of racks and space. Default status labels are open (for sale), closed (in use), reserved (kept for customer) and internal (booked for internal use).

The pitfalls: a typical data centre can feed many tens of thousands of data points into a DCIM server, and overly broad thresholds lead to ignored alarms such as an unnoticed UPS fault. Energy and emissions are underreported if DCIM does not collect data from all cooling units, including redundant ones. Preferred tools support open protocols such as SNMP (SNMPv3) and BACnet plus APIs, and integrate with BMS, EPMS, ITAM and ticketing systems. Related standards are ISO/IEC 30134-2, 30134-8 and 30134-9, and the document takes a vendor perspective.

Key points

1. DCIM 1.0: 1990s local UPS management; 2.0: 2000s space, capacity and PUE; 3.0: distributed IT, resiliency, security, sustainability, tenant transparency.
2. Alarm data goes to ticketing via API or SNMP MIB, reducing outage risk and repair time.
3. Sustainability reporting: PUE, subsystem energy, scope 2, CUE, WUE, waste, per tenant, site and portfolio.
4. Commercial status labels: open, closed, reserved, internal.
5. A typical data centre feeds many tens of thousands of data points; broad thresholds lead to ignored alarms.
6. Energy and emissions are underreported if any cooling unit, including redundant ones, is not collected.
7. Preferred: SNMPv3, BACnet and APIs; integration with BMS, EPMS, ITAM and ticketing.

Using it in design

• Add tenantId and commercialStatus (open, closed, reserved, internal) to racks, cages and floor zones, with a floor-plan overlay coloured by status and per-zone remaining power, cooling and ports.
• Check open U, network port, power, cooling and required redundancy (2N or UPS runtime) before allowing equipment placement.
• Give every cooling unit, including redundant ones, an energy meter point and flag unmetered units so PUE, CUE and WUE are not underreported.
• Export the asset/power-path model in a DCIM-importable form and list required device protocols (SNMPv3, BACnet, Modbus) in the BOM.

Who should read it

Colocation operators' product, operations and design teams, and engineers on projects that need tenant transparency.

Related standards

• ISO/IEC 30134-2
• ISO/IEC 30134-8
• ISO/IEC 30134-9

Publication details

Authors

Patrick Donovan

Publisher

Schneider Electric

Year

2023

Document number

WP 290

Document language

English

Source type

Manufacturer

Access

Free to read

Licence

Copyright retained; citation only — the publisher’s terms apply to the original document

Citation