In the Spotlight: Deployment of Protocol Gateways for Legacy Equipment
Perhaps your data center is new and modern from the top down. Everything is the latest generation with built-in monitoring. But, very often, this is not the case. Maybe it is just a few CRAC/CRAHs that are legacy devices, or perhaps just a few PDUs. But they can become a reoccurring thorn if not appropriately managed.
We have covered the importance of getting data into its final state as quickly as possible with a homogenous view of the world. The sooner your data is consumed and normalized, the better for the overall health and accuracy of your DCIM monitoring solution. Keep anomalies and data issues as far out at the edge as possible – so when problems occur, like connectivity is lost, you have the smallest connectivity profile to examine. The more of your data transfer that occurs in regular channels, the easier it is to isolate a problem.
Serial is a killer. Serial data chains can be problematic. Nuances in line inductance, termination, and end loads can lead to hard to identify problems and complexity. The industry has moved away from these towards networking – where TCP protocols are understood, and their digital nature makes them easier to troubleshoot. But you may be stuck with legacy devices that do not directly support network connectivity and how to deal with them. Plain and simple, a protocol gateway as close to the device as physically possible. A single gateway per device where possible. These boxes connect to your legacy device via a serial connection and provide the data over a network. They turn your legacy Modbus serial device into a Modbus TCP device.
Why as physically close as possible? To reduce the length of the serial chain, reducing the chance of a human error. Your network guys can replace and restore a damaged network cable much more easily than tracking a bad serial connection. Having a protocol gateway right on the device provides the best profile for troubleshooting if the bulk of the cable run is network-based. If you can communicate with the protocol gateway over the network, then a serial connectivity issue is narrowed down to just a few feet.
Why a single gateway per device? The boxes are inexpensive. Sure, a single protocol gateway could report the status of many serial devices. Still, serial chains are notorious for data issues where one device or connection breaks connectivity to all devices on the chain. This is time-consuming and expensive to troubleshoot. Deal with this proactively, so you are not troubleshooting a serial connection in the middle of a crisis. One gateway per device means one device cannot interfere with another device. If you lose connectivity, you will only lose the problem device, not multiple shared devices. And since you placed the gateway as close as possible to the device, your team only has to troubleshoot a very narrow space – while everything else stays online.
Are you looking for even more resilience in DCIM? Take a look at our OpenData DCIM solution. Unlike serial, network traffic on managed switches can have alternate paths and failover configurations. In addition, getting legacy devices onto a complete network as close to the edge lets you leverage modern advancements to maximize uptime. But, of course, that is always an advantage.
Join us for a demo? You can reach us at firstname.lastname@example.org