Our recent DCIM implementations provide an insight to actual use pattern with enterprise DCIM customers in the South Asia region. While analyst reports, mostly focused on the North American and Western Europe markets, suggest Energy Efficiency, Capacity Planning and Compliance considerations as foremost reasons for DCIM deployment, here’s our observations:
- While 80% of our enterprise data center customers have licensed for GFS Crane DCIM full suite, the principal (but not only) reason for their deployment was to prevent a data center outage.
- To prevent this outage, customers needed instant monitoring and getting alerts from all critical infrastructures.
- If customer had a BMS, DCIM had to integrate with that.
- If customer did not have a BMS, then DCIM had to integrate directly with the devices, and specifically with those they perceived as the MOST critical, or the weakest link in the chain.
- The other DCIM functions in order of importance were: management dashboards with KPIs, data center visualization, asset and change management (with workflow approvals and audit trails) and capacity planning.
The above use patterns are for enterprise DCIM, as against DCIM in multi-tenant data centers who of course have additional reasons for DCIM deployment like automating customer on-boarding process, capacity planning and power/space inventory management, energy billing and offering customer portals for self-service.
Most enterprise data centers in India are less than 50 Racks and a large proportion do not have BMS or instrumentation for monitoring of physical infrastructure. They rely on periodic manual monitoring taking readings from device consoles, room thermometers and hand-held power meters. The inadequacy of this archaic approach is obvious to all. Hence the options are BMS, DCIM or a combination of both, latter two when customers are looking beyond monitoring and sending alerts.
The weakest link with one customer, operating in a region with daily twelve-hour power outages, were DG sets and fuel supply. Hence, GFS Crane DCIM had to offer a comprehensive fuel automation system including 24x7 hour monitoring of DG sets and fuel tanks and controlling fuel levels in the tanks.
With a High Performance Computing customer, paranoid about poor power quality or extended power outage damaging expensive equipment, GFS Crane DCIM provided extensive alerts as well as analytics, not just on individual UPS devices, but also on banks of them with DR policies defined within the DCIM. Passive alerts were converted to actionable instructions for preventing an application outage, and quickly isolating any expensive equipment from such power related incidents. Of course, both these customers are also benefiting from GFS Crane DCIM’s comprehensive asset & change management, capacity planning, power and environment management capabilities across both physical as well as IT infrastructure – the latter with Intel Data Center Manager.
I take this opportunity to wish all our customers, partners and visitors to our web site a Very Happy & Prosperous New Year.
Not unlike Network Management Systems (NMS), Data Center Infrastructure Management (DCIM) software also monitors diverse set of equipment. The equipment ranges from server, network switches, Power Distribution Units (PDUs), panels, sensors, Diesel Generator (DG) sets. These devices have different protocols – MODBUS, SNMP, and BACNET. In addition, the parameters, that are monitored, are also different. For example the monitored parameters from a DG set may be output voltage, output power, and output current for all phases. Now in the case of a sensor it may be temperature and relative humidity. The software needs to capture the data from the various devices, keep in persistent store and report/alert on the data. This poses a problem if we want to store in traditional row/column format of relational data base. We will explore the implementation options and the method adopted.
Implementation Options in RDBMS
If we choose to store the monitored data in traditional relational form we have couple of options:
Build a super set of column list from all the monitored devices
If we choose this option then let’s say that we have 3 devices A, B & C and for A the monitored parameters are x, y, for B the monitored parameters are y, z, and for C the monitored parameters are x, z. So if we have a table with columns x, y and z it should suffice. Well in the real world the number of devices can run into hundreds of types with each device having multiple unique parameters. In that case you will see that the number of columns will easily run into few hundreds making the table design unwieldy. Furthermore, when it is populated with data it will be sparse. Of course, every time a new device is added with unique parameter, one will have to add columns to the table making the design untenable.
Have a table per device
This approach is somewhat better than the previous one - in the design add a table, which is unique to the type of device. For example there will be a table for DG set with columns for parameters that are monitored for a DG set, a table for a sensor with temperature and relative humidity as columns, so on and so forth. It sounds logical. However, this design also suffers from similar deficiencies as stated above. Let us say you have 2 DG sets from two different manufacturers and their monitored parameters, although having overlaps, are not exactly same. So what do we have to do – add two different tables for 2 DG sets? There goes the design principle for a toss!
How to retrofit in a RDBMS based solution?
Having described the issues that we encountered, how do we design the persistence of monitored data? The natural choice would have been NOSQL databases such as Cassandra or similar persistent store. The NOSQL data model is a dynamic schema, column-oriented data model. This means that, unlike a relational database, you do not need to model all of the columns required by your application up front, as each row is not required to have the same set of columns. Columns and their metadata can be added by your application as they are needed without incurring downtime to your application.Since we had to retrofit the design into an already existing relational schema, we chose have a single column of text (varchar field in RDBMS terminology) sufficiently large to hold the monitored data. However, we devised a scheme such that when we acquire data we say what field it is, what is the unit and what is the value. For example if from a sensor we acquire temperature and relative humidity, the data that is written into the table will be “field = temp, unit = Celsius, value = 22/field = RH, unit = %, value = 50”. Similarly for a generator a data row may be “field = voltage, unit = volt, value = 240/field = power, unit = KW, value = 100”. Both these data points will go into the same column and another column for their unique device id. Having done this we simplified the design, its maintenance and reporting. A separate reporting module which normalizes the data after suitably extracting from the monitored table suffices to do all kind of reporting from each unique device. It is flexible enough to add new devices with its own unique parameters without changing the core tables. This is how we married structure and unstructured data.
Having had a few successful DCIM implementations under our belt now, a few lessons to share:
- Baseline your existing Data Center: document what systems and procedures are being followed today. For example, how do I keep track of my assets today?
- Map out your desired Standard Operating Procedures (SOP): mention desired state (wish list) and timeframe in which you can expect to implement the changes. For example: I would like to get real-time the PUE of all my Data Centers, starting 90 days from now.
- Why do I need DCIM? Will DCIM be able to keep track of all assets and maintain an up-to-date accurate asset register? Will DCIM be able to get the real-time PUE? This is what I could call “plugging the gaps”.
- Setting longer term objectives: Is there a corporate goal towards cost reduction? How can DCIM help to reduce annual capital and operating costs? Or, is there a corporate goal for Sustainability? Can DCIM help with less carbon emissions from my Data Center?
During the baseline exercise, review asset and space utilization in the data center as well as power consumption and costs. Also, review the utilization and performance of all equipment. Are there some servers which are heating up too fast? Are there some production servers which have less than 10% utilization?
As Data Centers form the core of a business function, DCIM software should be viewed as a business application that can contribute towards meeting your company’s business objectives.
- Has your company been spending too much money on power in maintaining its data centers? DCIM can help by accurately measuring power and cooling requirements and identifying ways to reduce power costs.
- Do you need to deliver higher SLAs to your customers at a lower price? By enabling proactive alerts and mapping inter-dependencies of all equipment, power and network maps of the entire Data Center, DCIM will be able to predict failures before they actually happen.
- Are you running out of space in your data centers? DCIM can provide you the tools to monitor and manage floor and rack space in a data center enabling you to take timely decisions when to invest in higher density racks.
Identify first the priorities and then implement the features of your DCIM solution in a phased manner. An attempt to implement all features at once will be a sure recipe for disaster, as many ERP implementations in the past have shown.
Keep in mind that DCIM introduces business process changes in the data center making it extremely important that you get the buy-in of all stakeholders at the outset. Since data centers form the heart of any business it is necessary to get management involved right from the start.
I would encourage Data Center practitioners to share what outcomes they would like to see from a successful DCIM implementation as well as get insight from customers who have actually deployed a DCIM Software.