Measuring and Monitoring: One Aspect of Data Center Infrastructure Management

A data center is a complex building. It houses IT and facilities equipment along with office and amenity accommodations. Because of this, its operations touch many categories of areas, and different automated tools and operation techniques are required to manage and run it effectively. It would be great if we had a handful of standards that applied to most components for their management. In reality, it is not so. In general, there are IT and facilities views of data centers and having one single view has been hard. Because of this, IT and facilities have been managed separately, although some attempts have been made to manage them together.

It is necessary to understand the infrastructure of a data center before you can manage it effectively. There are a few classifications given in the area of how data center infrastructure is managed. One informal categorization might be inventory, change, capacity, simulation, and efficiency modeling, although some analysts use more comprehensive categories.

One basic aspect of data center infrastructure management (DCIM) is to measure and monitor what’s happening in a data center. To run a data center effectively, we need to know what’s in the data center (asset management) and how each component is functioning, including its status and consumption of energy (measuring and monitoring). It sounds trivial to add a sensor to each component and poll its condition regularly. We can interrogate and manage each component as well as the aggregate to grasp the entire status of a data center from a dashboard. Describing it at a high level is straightforward and simple, but the devil is in the details. There are several vendors in this space, and I have talked to some of them, like SynapSense, Sentilla, and Aperture, in the past.

Recently, I had a chance to speak to Richard Jenkins, VP Marketing of RF Code. RF Code manufactures RF tags and sensors as well as the software to process the data they collect, and markets them as an integrated system. Their solution tracks assets, and monitors the environment around the assets in a data center.

Asset management is one of the basic functions of a data center. Not confined to a data center, corporate assets need to be tracked from time to time because they may be lost physically or be hard to locate without close tracking. In the past, asset management was done manually on a

 

spreadsheet. When there are many pieces to track in a data center, manual tracking requires an enormous effort and is not practical. On top of that, equipment, especially in IT, gets moved and replaced constantly. Without some automated means, it is next to impossible to track each piece’s location correctly.

Also, it is essential to monitor each piece of equipment and measure data relevant to its operation, because each element in the data center must function flawlessly to ensure reliable operation. Without automated means, it is almost impossible to do so for the large number of components residing in a data center.

It is relatively easy to claim that you have a solution in asset management and monitoring at a data center by deploying sensors and the software to manage them. So I asked Richard about RF Code’s differentiation. Every company claims that its solutions and products are unique and stand out from the competition. His answer was twofold.

Product layering: One part is a common infrastructure to track and monitor elements in a data center. In a single infrastructure, different tags and sensors hang together, ranging from sensors for humidity and temperature to those for motion. This is well described in the following figure.

In this common hardware infrastructure, they put in a higher layer of software for more sophisticated processing.

Open API: Expanding this common product infrastructure philosophy, I would like to classify two major trends for integration. The DCIM market is growing but still rather confusing. There are many aspects to managing a data center. A few analysts have defined a model and areas of coverage. In addition, an increasing number of vendors have rebranded their tools and utilities as solutions for DCIM. Because no single vendor could provide a complete and comprehensive solution for the entire data center operation, large and small vendors alike have started to partner together to provide comprehensive solutions.

Some may provide nonstandard APIs only common to their partners to integrate their tools and utilities to work seamlessly together. The advantage of that scheme is that you have good coverage of tightly integrated DCIM functions as long as you make that particular group as vendors of your choice. Also, if that group’s APIs become standard, it would be great. The downside of that is that you may become locked in to that group of vendors. They may not have some functions that may become necessary for you later. If other ways of integrating functions and APIs become standard, you may need to adjust your solutions accordingly.

Another way is make your solutions interoperable with established standards, such as network/serial data formats, and web-based standards like XML and JSON. Those well-established standards tend to be at a higher level, and your level of integration may be looser than in the former approach. However, the upside of this approach is to guarantee that your solution would be integrated with any other tools or utilities that conform to the established standards and would be future proof.

Both approaches are valid because we cannot tell how the DCIM market will shape up in the future. RF Code selected the latter approach.

Wireless communications: The second point Richard raised was wireless communications. When you see racks of IT gear in their surroundings, you probably see many cables for networking and power alike all over the place. If we place sensors in all the strategic locations, you would be inundated with many more cables for communications and sourcing for power. Managing those cables alone would add a burden for data center operators. RF Code, as its name indicates, manufactures and markets only wireless sensors with no cables. A battery-powered wireless node sounds like a great idea.

But it creates its own problems in general:

  1. Scalability with wireless communications crosstalk
  2. Security
  3. Battery life
  4. A large effort in tagging

As for #1, their radio complies with the ISO 18000–7: Air interface at 433.92 MHz. When you deploy a large number of nodes for communications, interference tends to happen and accurate communications may not be guaranteed. RF Code has developed a set of technologies to pack wireless nodes in a way that prevents interference among them and has obtained seven patents in this area to increase the number of nodes without interference. Their patents are listed here. The details are beyond the scope of this blog.

As for #2, some security-sensitive organizations, such as financial institutions, do not want to use wireless communications because of the potential security risk. Unlike in wired communications, packets can be easily grabbed in wireless communications and the information in them stolen. Wireless communications can be protected via encryption (by something like SSL), but encryption eats bandwidth. RF Code has an option not to encrypt the communication but to send very proprietary data. It would still be possible for someone to make a reader that could read their tags’ beacons if hackers really wanted to “sniff” the data.

However, aside from the tag-identifier data (basically, a serial number) and current sensor reading (for sensors, or for asset tags that feature tamper detection/motion detection/IR receivers), there is no other information about the assets included in the beacon. So even if an asset tag is affixed to a very important piece of equipment, its beacon data doesn’t look any different from data affixed to anything else—it’s just a number. All tag-ID-to-asset correlation is done in the backend stem, which would clearly be secured behind a firewall. RF Code’s customers include a number of banks, such as Lloyds Bank in the UK.

As for #3, each of RF Code’s wireless nodes is powered by an internal battery with a life of somewhere around five to seven years. That means that every five to seven years a battery must be replaced. In a data center, a server’s life is about that long or even shorter. When a battery requires replacement, the server is also replaced. That is why I think this may not be a big issue.

Also note that some of their asset tags equipment and all of their sensors are user serviceable, enabling the user to replace the battery. They also include a “low-battery warning” feature that will alert the admin that the battery is getting low when it gets down to about 20% charged.

As for #4, as the amount of equipment grows, the effort to tag it all grows as well. It would be a major effort to tag an existing data center. When equipment has been deployed already, reaching each piece may be cumbersome and difficult. IT equipment like servers may be stored inside a rack, and extra effort may be required to attach a tag at the right location. Some servers may have an outlet exhaust on the side rather than on the back. Without proper placement, a tag may be influenced by the sideways exhaust. Also, without detailed documentation, tagging information may be only on the equipment’s label and nameplate, which may not be very precise or adequate. For example, it may not be easy to find out which department particular equipment belongs to and what it is for.

In any event, it would be much easier to place a tag on each piece of equipment and device before its deployment. RF Code gets involved in an early stage of data center construction and avoids this problem. But if people need to tag assets that are already in place, they recommend that they do so as part of a typical annual inventorying process that requires staff to physically account for each individual asset. Since they have to do this for accounting purposes anyway, tagging assets as part of that process presents the least additional effort.

Expanding the idea of tagging as early as possible before the data center is in operation, let’s consider a container-based data center. A container-based solution has several advantages. Those include ready-made modular additions to data center capacity and less garbage as a result of not having to unwrap each component. When a container-based solution is put together, a tag can be applied to each piece of equipment as it is assembled into the container. At the time of the assembly, it is easy to reach any location for tagging. Also, the information on each piece of equipment is readily available, and each tag can contain precise information.

RF Code works with IBM and HP to integrate the data they collect with their software system. Although large companies like IBM and HP have many divisions and each division sometimes behaves like an independent company, both companies have a container-based data center solution. Incorporating RF Code’s solutions into their container-based data centers would improve their deployment.

Finally, I asked Richard two questions: about the DCIM market and their future plans.

DCIM market present and future

Present:

Richard and I were in agreement that the DCIM market is poorly defined and is very confusing. He felt that DCIM started to receive recognition only in the past 12 months. He also mentioned that DCIM is a poorly formed acronym. He thought it was more like data center management infrastructure (DCMI) than DCIM, which typically tracks assets and monitors power consumption and environmental conditions. It also needs to integrate with building management systems. But that is not enough. On top of what DCIM provides, DCMI needs to have functions for software loads, networking, and hardware management. With those additional functions, DCMI could provide real-time proactive management of a data center.

I agree with his idea. Many of the currently available solutions mostly touch the facilities side and have very little impact on IT equipment. Even if they touch the IT side, it is only to look at each piece of IT equipment as a black box and not to deal with what’s happening inside, such as loading factor, software status, virtualization, and software execution efficiency. The reason for the omission is simply the difficulty of measuring and monitoring such data and analyzing and incorporating it into the dashboard for visualization and good integration of IT and facilities. I am glad that a vendor like RF Code has a good vision of DCIM similar to mine.

Future:

As for the near future of the DCIM market, I asked Richard if he thought some companies will dominate the market. It’s crowded right now. Many vendors market their solutions as DCIM, and they come in many sizes and functions, such as established companies like Intel and Schneider. Smaller companies like RF Code provide niche, pure DCIM solutions. Richard thought that for the time being, the DCIM market will be dominated by a combination of large established companies and startups. I agree with him. Using the business intelligence market as an example, he predicted how the market might shape up. Smaller companies will be merged or acquired by larger ones, and consolidation will take place as it did in the BI market. At some point, DCIM will be one of the functions in the larger infrastructure management solution market.

RF Code’s future directions

RF Code applies their technologies to the data center segment as well as to the oil and gas market. I thought their technologies could be applied to the power industry. The power grid consists of a large assortment of devices and equipment. Smart grid is an attempt to merge power, communications, and IT technologies into a cohesive system to increase the effectiveness of power generation, transmission, distribution, and consumption. Along the power grid, there are many assets deployed to support each function, and it is important to track them accurately. For example, after a power outage is confirmed, it is necessary to locate which device or equipment is at fault and identify its location so that a service crew can be sent to repair it.

The power grid must be maintained to guarantee reliable operations to keep the lights on. Each device and piece of equipment needs to be monitored for its proper operation in real time. As each becomes electronics-based from the electromagnetic base, each component will be controlled in a more precise manner, and tracking its location and status will be more important. I think RF Code’s products could be adjusted to be applied to the power industry, but each vertical has its own idiosyncrasies in vocabulary and operations. It may not be so easy to do. They do not have a plan to expand into this market at this time.

They instead would like to grow into the higher stack to increase functions with software.

Final thoughts

Although people have started to realize the importance of managing the data center infrastructure in the US, it is not clear whether, or what kind of, comprehensive solutions should be employed. Because the market is still young and no clear standards are set, people are hesitant to invest in a comprehensive solution. But they want to deploy a piecemeal solution that brings a visible result. The DCIM market outside of the US, like APAC, is still being formed. When I talked to a large data center provider, it was not clear to them what DCIM is or what DCIM covers. DCIM is an important market and will grow, but more education on its merits will promote it further.

Zen Kishimoto

About Zen Kishimoto

Seasoned research and technology executive with various functional expertise, including roles in analyst, writer, CTO, VP Engineering, general management, sales, and marketing in diverse high-tech and cleantech industry segments, including software, mobile embedded systems, Web technologies, and networking. Current focus and expertise are in the area of the IT application to energy, such as smart grid, green IT, building/data center energy efficiency, and cloud computing.

, , , , , , ,

Leave a Reply


*