Modius Data Center Blog

Computational Fluid Dynamic (CFD) software provides modeling of data center airflow and quick identification of hot spots.  A CFD system’s three-dimensional, multi-colored thermal maps are downright sexy, and, if you’ll pardon the pun, extremely cool.  When changes are made to the data center intentionally, CFD analysis can be repeated to detect the introduction of new thermal problems.  So far, so good.

But what happens when the data center changes unintentionally?  Today, CFD users require real-time thermal imaging of hot spots that could result from contingencies like equipment failure, blockage or cabinet overloading.  Furthermore, users want more than just problem visualization – they want recommendations for problem mitigation.  They want a CFD model with some muscle – in effect, a CFD on steroids.

What is a CFD on Steroids, and more importantly, why do we need it?

The CFD on steroids works in real-time by collecting and synthesizing all available sensor data within the data center.  It leverages wireless, wired, server-based and return/discharge air-temperature readings to determine not only the immediate problem, but also the immediate impact.  This high-fidelity monitoring system renders a thermal topology map and also sends immediate notification to operations personnel stating what temperature has been registered, where it is located, and that urgent action is needed.

Really pumping you up

... Or is there a cheaper alternative?

The latest advent in data center cooling is intelligent networked HVAC systems.  The HVAC systems are intelligently managed to allow remote sensors to provide feedback so that the HVAC system can tune cooling to meet the dynamic demand of the IT infrastructure.  The systems are “intelligent” in that they can change the speeds/frequency of the fan (VFD) to provide more or less air to the cooling zones and cabinets supported by the cooling system.  Further, they can auto-engage the economizer (for ambient cooling) and control water valves to provide greater efficiency to powering air-conditioning units.  They are also on a network so that they can be controlled in total rather than only independently, with one turning up while another could be throttling down. 

All very, very, cool stuff and can greatly influence one of the largest data center cost, powered cooling.  Ok, now the downside, wow.. is it really $1M to do it.  In most cases, the answer is yes. The cooling system manufacturers are hoping that you will replace your existing system and allow them to generate a services engagement for them to spend the next year turning up and tuning the system. 

So here is the question … Is there any way to make my existing HVAC smarter and NOT spend the $1M??  Glad you asked and yes there is.  Before spending that cash, there are three steps you can take in making your existing more efficient and they include:

1. Installing Variable frequency drives
2. Unifying data from temp/humidity monitoring at the cabinet
3. Compute, measure, and integrate into the BMS

Step 1. Install Variable Frequency Drives for controlling airflow

As discussed previously in earlier blogs, VFD’s will provide the throttle necessary to achieve energy efficiency.  Several states, including California, are providing rebated for installing VFD’s and pay for nearly 60% of the cost of the equipment (for more information on this topic, contact us at info@modius.com, and we can help put you in touch with the right people).  But remember … VFD’s are only as good as the control procedures you put in place to in order to modulate the cooling as required at the rack level.

Step 2. Unify data from a broad cross-section of temperature and humidity instrumentation points

In order to get the best possible data about what is actually happening at the rack level, there are several practical ways to extend your temperature and humidity instrumentation across your environment.  This may include not only deploying the latest generation of inexpensive  wirefree environmental sensors, as well as unifying data that is already being captured by existing instrumentation from wired, wireless, power strip-based or server-based instrumentation.  

The most cost effective way is to leverage the environmental data  the new servers are already collecting (often referred to as chassis-level instrumentation).  The new servers from the leading three vendors register both the server inlet and exhausted temperature.  Depending on the deployment architecture, this can provide you with a lot of fidelity including front/rear, min, max, average, and standard at the bottom, middle and top of the cabinet. 

In most cases, this is enough information to provide equipment demand for direct cooling.  Where you don’t have newer servers that support temperature, wireless sensors are the next best option.  There are several vendors on the market that make these products and are nice in that they are easy to set up and you can place just about anywhere.  If you have data being generated from power strips or wired sensors, incorporate those as well (the more information, the better).

Step 3. Compute, measure, and integrate into the BMS

Building management systems are traditionally very good at controlling systems such as VFDs and recognizing critical alarms.  What they are not good at is being easy to configure, integrate or extend across the network.  This is where you need to be able to provide a booster to how data is collected and synthesized. 

Modius OpenData is used to collected real-time data across the network into potentially hundreds of new devices and thousands of newly collected points.  Once the data is collected from servers, wireless sensors, pdu’s and wired sensors the data is correlated against key performance metrics then fed to the building management system so that it may adjust the VFD’s, water flow, and economizer.  Example metrics might be:

• Rack-by-rack temperature averages for inlet and outlet
• Row-by-row averages with alarm thresholds for any racks which exceed the row average by a particular margin
• Delta-T with alarms for specific thresholds

These types of computations can be based off of unified data from a variety of sources (sensors, strips, servers, etc.), all of which can be used to make your existing HVAC system smarter.  The most important point is to continually measure as you go and make a series of small or incremental optimizations based off of verified data.  The best news is that this architecture is the fraction of the cost of what new HVAC infrastructure costs and leverages your existing building management system.

When the topic of data center infrastructure comes up, there exists some confusion regarding how the two technologies, Serial and LAN, relate. Let me start by saying that nearly every piece of equipment built in the last 20 years includes at least one form of core controller interface. In fact, the engineering teams that build this type of equipment will tell you that one of the very first portions of a control system developed is the console/monitor access interface because it is this interface that typically is used to help continue to develop and debug the controller itself (as well as check it along the way for proper operation). Hence, every server, switch, router, and firewall, as well as every PDU, UPS, CRAC and Generator, has one – some form of interface exists in all Enterprise-class devices!

That said, the technology for these interfaces has changed over time. RS232 (and the very similar RS485) were all the rage for connectivity (due to simplicity and low costs) in the 70s and 80s. With the advent of true ‘networking’, Ethernet became popular (ironically for the very same reasons) in the early 90s and continues to be widely deployed as the interface standard to this day. However, the mechanisms to interact with these two types of interface are vastly different.

With Serial interfaces, the most common protocol is an ASCII-based ‘Text’ command line protocol. Commands are built using strings of characters, and the results are returned as strings of characters. For instance, a user could build a text command (of 18 characters) such as “SHOW SYSTEM UPTIME” which may result in the resulting series of 9 characters “1D 23H10M” to show 1 day and 23 hours and 10 minutes. The key point with regards to a Command-Line Interface protocol is that is specific to each and every vendor and in many cases each model number within that vendor’s catalog. This ultimately requires very model-specific device awareness in order to be able to communicate with this type of serial interface. Ultimately, the information being retrieved from these interfaces is going to be consumed by network attached servers and monitoring applications. Consequently, there are two steps needed to be able to deal with serial interfaces: 1) A physical conversion to get the information into a format suitable for the network to transport; and 2) the logical translation of ASCII commands and responses to networked packet values in tables. This is done using a device(s) sometimes referred to as a “gateway.” While these two conversions could be separated, they typically are included in a vendor-supplied gateway devices with an RS232 or RS485 port on one side, some small conversion processor inside, and the LAN port on the other side.

With LAN-based (Ethernet) interfaces it is much easier. Many standardized protocols exist to communicate natively from the device to the network, with the most common of these being SNMP and its inclusion of MIBs to describe how the informational packets are organized. SNMP (and the MIB) allows a network inquiry to be made against a table of operational values within the target device, and the results are formatted as expected values within the returned data packet. While there are some detail peculiarities, in general network-based protocols are much more standardized and widely accepted as the modern means.

What does this mean to you? If a device has a network interface, then a high probability exists that you’d be able to easily access and understand the performance values without any conversions whatsoever. Any modern intelligent iPDU (or Power Strip) is a great example of a device like this. It has a LAN connection and can report (in a known format) the power at each outlet and temperature of the unit itself by inquiring with a simple SNMP command. Devices like these have IP addresses and appear on the corporate network just like any other component. Conversely, if a particular device has ONLY a Serial interface, then look for a physical and logical gateway solution to do the conversion. These gateways are very specific (purpose built) for each model device and are usually supplied by the application provider that intends to consume the performance information.