Modius Data Center Blog

Measuring Available Redundant Capacity (ARC) in the Data Center

Posted by Jay Hartley, PhD on Fri, Dec 18, 2009 @ 07:00 AM

One of the key power usage metrics that I often find our customers requesting is  Available Redundant Capacity (ARC). This metric can mean different things to different people, but in simple terms, we at Modius like to define it as the amount of IT load that can be added to a data center system as a whole without sacrificing redundancy.

When viewed from the rack, row, room, or building level (or even across a network of data centers at the enterprise level), ARC provides a simple way to answer the question: “Where can I safely add new IT equipment without overloading and potentially bringing down my facility?”

Typically, most data centers don’t calculate ARC. Instead, operators set a simple alarm threshold on the Actual Loadof each device. For example, if the power load reaches 50% on a device (or more often 40% when de-rating), then the device or the monitoring system will throw an alarm.

However, this simple approach to thresholding based on device power usage doesn’t effectively capture all the conditions of the broader power distribution system. There can be hidden capacity that allows for safe failover, even though simple device-level thresholding suggests otherwise.

The goal of system ARC is to identify where you can handle additional load without sacrificing system redundancy. To calculate ARC for power of a device in a dual-feed situation, the calculation is simply:

ARC = {Device Capacity}/2 – {Actual Load}

In most cases, the Device Capacity will be de-rated to allow for some margin. In the case of power capacity, it is common to de-rate apparent power (kVA) capacity by 80%. ARC can also be expressed in real power (kW) if you know or can estimate the power factor of the load. It is even more important to de-rate the capacity in the case kW measurements to allow for potential load problems that could degrade power factor.

Below is an ARC-based dashboard in action:

Here, the top panel shows how ARC has been calculated for 6 different data centers, along with a measure of cooling overhead. The lower panel shows the drill down for one of the sites.

When calculating the overall ARC for devices in parallel, you can add the ARCs of the individual units. For instance:

UPS A has 10 kVA ARC
UPS B has 8 kVA ARC
Together, they have 18 kVA ARC
Interestingly, it is possible to have a safely redundant system even though one of the individual devices has a negative ARC. For example:

UPS A has 3 kVA ARC
UPS B has −2 kVA ARC
The net ARC of the system is a small but safely positive 1 kVA
In this case, even though one UPS is nominally overloaded according to the simple one-device threshold, either UPS can fail without dropping any load.

Calculating system ARC from the individual device ARCs in this way assumes that the capacities of both parallel components are the same. This is most often the case, but in the rare instance that it is not, then you have to total the actual load across the devices, and compare it to the (de-rated) capacity of the smaller device. This ensures that the most-limited device can handle the entire load.

Some questions may arise when the load is imbalanced, as in the examples above. Such imbalances may arise because some of the load is not configured redundantly. Some loads also do not balance themselves between the two power paths. The ARC calculation doesn’t depend on knowing such details. Of course, any non-redundant load will be dropped if it loses its power source; however, as long as the system ARC is positive you know that any redundant load will be protected regardless of which power source is lost.

In summary, the goal of system ARC is to identify where you can handle additional load without sacrificing system redundancy. With parallel equipment, you can total the ARC of all components if they have the same capacity rating. When looking at ARC along the power chain, the correct system value will be the minimum ARC of any one set of components.

Kind regards,

Jay H. Hartley, PhD
Director of Professional Services
Jay.Hartley@Modius.com

Topics: Data-Center-Best-Practices, data center monitoring, Dr-Jay, data center capacity, data center energy efficiency, Measurements-Metrics, Capacity-Management

An Unforeseeable Leak Finds Its Way to Sybase’s Data Center

Posted by Jay Hartley on Wed, Sep 09, 2009 @ 07:00 AM

As a follow-up to our inaugural blog post regarding our implementation of continuous PUE monitoring at Sybase,  I wanted to share a real-world challenge Sybase recently encountered. Although Sybase is acknowledged as one of the country’s most efficient, reliable data centers, it is not without its unexpected challenges.

This spring, Sybase narrowly avoided a significant outage due to an unforeseen water leak from outside the walls of its data center. On each floor, directly above its high-availability Secure Data Center facility, are several kitchenettes (for the offices on that particular floor). On a recent weekend, a water hose popped in one of the kitchenettes connecting the sink to a cooler. Water gushed out and quickly flooded the kitchen. Worse, it eventually found its way down two stories between the walls to the data center facility below.


Sybase did not learn about the problem until one its PDUs was shut down by the leak. Luckily, its PDU redundancy avoided any outage. However, this unforeseeable leak resulted in a damaged PDU and a few downed servers.

To avoid an event such as this happening in the future, Sybase turned to Modius. Modius identified a cost-effective leak detection system to be installed in each of the kitchenettes in the building. We configured these residential-scale leak controller systems on the Modius Device Gateway and added it to the notification schema, demonstrating the versatility of our OpenData® system to capture data from practically any device used inside or outside a data center.

By utilizing one of the existing Modius I/O modules, we were able to configure and test the entire system in about 2.5 hours, providing Sybase a quick, cost-effective means to avoid an event such as this in the future.

Kind regards,
Jay H. Hartley, PhD
Director of Professional ServicesJay.Hartley[at]Modius.com

Topics: data center monitoring, data center availability, data center alarming

Latest Modius Posts

Posts by category

Subscribe via E-mail