Technical essays of current IT-relevant topics: Here you can download our whitepapers.
Safe and reliable operation of a data centre’s electrical system can be guaranteed by a combination of regular maintenance intervals and a superordinate management system comprising residual-current monitoring and targeted analysis of measured values. On the one hand, regular maintenance work forms the prerequisite for component or system longevity, yet on the other, represents an immense cost factor. New concepts are emerging on the market, and the IT sector is following trends in the automotive industry. Leading car manufacturers dispensed with fixed maintenance intervals long ago, preferring sensors which determine the exact condition of brake or clutch pads. The vehicle information system lets the driver know in advance when their vehicle needs maintenance or worn parts must be replaced. In addition, independent repair shops are now authorised to perform maintenance on vehicles. As such, customers have the advantage of choosing a low-cost, time-optimised solution. So why not apply the same principle to data centres?
When the word “redundancy” is uttered, many IT professionals will immediately think of N+1-redundant UPS and CRAC units, or of multiple power supplies in servers and switches. Yet it is not merely the presence of redundant devices or components that provides the solution. Instead, monitoring of threshold values is what ensures true redundancy. Particularly at rack level (i.e. for end devices), the issue of redundancy is all too often underestimated or even misinterpreted.
Until just a few years ago, data centres were built to last 20-30 years. Although this long-term planning was able to consider capacity needed later on to some extent, it was impossible to predict technological developments or changes in boundary conditions defined by legislation, standards or directives. Consequently, many operators are faced with a reality where the status quo in their existing data centres cannot be altered because 100% availability is needed. As the familiar saying goes: “never change a running system”.
