Modius Data Center Blog

How to achieve better visibility and control over your data center operations—without the risk.

Veterans of data center operations tell us that having visibility and gaining better control over the critical infrastructure and IT assets throughout their entire facility is the key to maximizing data center efficiency. 

Achieving this requisite visibility is not a trivial task. It involves overcoming the interoperability hurdles of monitoring all of the various critical systems—such as generators, chillers, water pumps, air exchangers, PDUs, power strips, on-board server instrumentation, and more.

On top of that, making sense of the various alarm schemas—which are so vital to maintaining control of data center performance and achieving a higher level of efficiency—can be more of a headache than the alarm system is worth.  They typically don’t factor input from the full gamut of facility and IT equipment into their respective alarm thresholds. Consequently, spurious alerts from the disparate alarm systems trip over themselves and conceal the true state of the data center.

If your work is impeded by spurious alarms…or if you find yourself ignoring low-level alarms because they’re out of context from your overarching data center priorities…or if you cringe at the thought of the time and cost involved in deploying a monitoring and alarm management solution across your entire data center, then Modius can help.

Modius offers OpenData Standard Edition, a low-cost unified alarm management and notification solution for monitoring all power and cooling equipment, including IT racks. At only $1,995 per user per year, it is the only solution in the industry offered at a very low cost and distributed as a downloadable, easy-to-install software package. This low-cost offering reduces the risk of “locking in” to a solution without having it thoroughly tested in your environment, on your own terms.

OpenData interoperates with most network equipment through its support of the essential communications protocols, including SNMP, Modbus and BACnet. It collects and stores performance data, normalizes it, then transforms the data into a simplified, federated view. This means you don’t have to kludge together various point solutions, or contend with different data formats or increments that add complexity to data center management.

And, because of OpenData’s intelligent monitoring capabilities, customers also benefit from a sensible, unified approach to alarm management. The OpenData software matches all monitored performance against configurable thresholds and sends out alarms via a centralized notification engine. Rather than send an overflow of low-level alerts, it only sends the alarms you need when they matter most. This means you can manage your data center as a complete system—instead of disparate components—and get insight to the true state of your data center.

Sign up for a free demo of OpenData Standard Edition today and uncover the true state of your data center in a matter of hours.

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.