The data center market is unique but has a lot of issues that IT can provide solutions for. Data center infrastructure management (DCIM) is the monitoring, measuring, and understanding of what’s going on in a data center to produce action items for operations. One of DCIM’s objectives is to conserve energy at data centers.
Meeting venue at Digital Realty’s Santa Clara data center
The meeting consisted of two DCIM presentations and a panel discussion. One of the presentations was given by Nlyte‘s Doug Sabella, a DCIM vendor, and the other by VMware’s Sean Murray, a DCIM user (and the new president of the chapter). I’ll devote the space here to the two presentations, particularly the points made about software usability and data integration.
Data aggregation and integration
In operating a data center, we know that, in general, the more data we collect, the better we can grasp what’s going on. Data are coming from many directions with different formats and speeds and using different protocols asynchronously. How do we collect, aggregate, and merge them so that we can work with them to produce action items to manage data centers for efficiency, including energy efficiency?
In the following picture, Nlyte stores various kinds of data in a central database to be used to:
Nlyte’s central database to collect, aggregate, and store various types of data
Because the picture is not very clear, let me reproduce the data sources.
- IT hardware equipment: servers, storage, and network
IT software components: configurations and applications
- Facilities components: power, space, and cooling
- Facilities integrations: BMS/CFD (computational fluid dynamics) for power, cooling, and environments
- IT integrations: IT service management (ITSM), configuration management database (CMDB), discovery, VM, and ERP
- Data center integrations: RFID, barcode, and Intel DCIM
As can be easily seen, the data coming from those multiple sources are in different forms/protocols and arrive asynchronously. Some may come in real time and others, like CMDB, may be fairly static.
Nlyte has an alliance with Intel and that is why Intel DCIM is mentioned here. If and when the DCIM standard is established, any vendor’s solution may be placed here instead of Intel’s. I have not looked into the details of Nlyte’s database implementation and am not familiar with theirs. In general, the logical and physical views do not have to be the same. Logically, all the data stored in the database may have the same format. But physically data may stay in their original forms. If the database access software knows how to access each different data format, logically those data are in the same format.
This reminds me of software integrated development system (IDE). It stores software under development in a common intermediate form so that multiple software tools can access, share, and manipulate the code. The data aggregation and integration problem is not unique to the data center segment. With the advent of Big Data, this problem is everywhere. So far, I have seen three solutions, like multiple protocol exchange (MPX) by Tridium and Cisco, and OSIsoft’s solution. This may not have been given the attention it deserves. It is probably partly because it is a difficult problem to solve. By the way, analytics is a very important issue that deserves an entire blog by itself.
Software usability and effectiveness
Sean Murray’s presentation was very interesting because it discussed how a user who did not have a DCIM solution went about implementing DCIM at his own data center. Although he covered several subjects, I think one of his slides articulates what he wants from DCIM vendors.
What Sean Murray wants from DCIM vendors
His points are very interesting. You can read each one, but let me make a few comments.
- No single vendor has all the solutions: a Google search for “DCIM vendors” yields more than 100,000 hits. Sean thought there were 15 viable DCIM vendors. Each vendor has its own area of coverage and no single one provides all the solutions of DCIM. That is why several DCIM tool vendors are trying to work together by making their interfaces open. It will take some interface standards to solve this problem.
- Several problems are software usability problems: “too hard to use,” “no single interface regardless of platform,” “too long release cycle,” and “lack of flexibility” are simply failures of software solutions. They can be remedied fairly easily. I wonder whether DCIM tool developers are different from other software developers that seem to pay more attention to software usability.
- Limited offering: most tools concentrate on the energy side. There are few tools for asset management.
- No explicit user input mechanism: this means lack of customer advisory committees or user communities. No software solution satisfies customers without input from its users.
Judging from Sean’s remarks, a lot needs to be done. But the good news is that most of his points are well understood in the software development community and can be corrected.
DCIM is specific to data centers but infrastructure management applies to many buildings that are in the data center superset. By solving the DCIM problems discussed above, we can solve many building energy management problems. It seems that software’s importance is growing, which is good for someone like me whose roots are in software development.