About the only thing harder than building a data center is dismantling one. The potential for disruption of business is much greater with data center decommissioning than with construction.
A case in point, the decommissioning of the Titan supercomputer at the Oak Ridge National Laboratory (ORNL), reveals just how complicated the process can be. More than 40 people were involved with the project, including staff from ORNL, supercomputer manufacturer Cray, and external subcontractors. Electricians were required to safely shut down the nine megawatt-capacity system. Cray staff was on hand to disassemble and recycle Titan’s electronics and its metal components and cabinets. A separate crew handled the cooling system. In the end, 350 tons of equipment and 10,800 pounds of refrigerant were removed from the site.
Trends in data center decommissioning
The trend for companies to move away from on-premises data centers continues. While most enterprise IT pros aren’t likely to face decommissioning a computer the size of Titan, they’ll likely be involved with dismantling smaller-scale data centers.
The pace of data center migration or closure will continue to accelerate in this decade, according to IDC Group Vice President for Worldwide Research, Rick Villars. “Every company we’ve spoken to is planning to close 10% to 50% of their data centers through 2025, and in some cases even 100%. No matter who you talk to, they absolutely have on the agenda they want to close data centers,” Villars says.
Successfully decommissioning a data center requires navigating many steps. Here’s how you can get started.
Inventory data-center assets
The first step is a complete inventory. Given the prevalence of zombie servers in IT environments, it’s evident that a significant amount of IT departments lack a firm grasp on data-center asset management.
“They need to know what they have. That’s the most basic. What equipment do you have? What apps live on what device? And what data lives on each device?” says Ralph Schwarzbach, a former security and decommissioning expert with Verisign and Symantec.
All that information should be in a configuration management database (CMDB) or data center infrastructure management (DCIM). This type of tool serves as a repository for configuration data about physical and virtual IT assets. DCIM enables a data center to optimize space utilization, equipment usage and energy usage. It does this by providing a complete view of the entire facility performance. Whichever tool you use, “having the tool and processes in place to maintain data accuracy are two distinct things,” Schwarzbach says.
While CMDB or DCIM is a necessity for asset inventory, “any good management system is only as good as the data you put in it,” says Al DeRose, a senior IT director responsible for infrastructure design, implementation, and management at a large media firm. “If your asset management department is very good at entering data, your management tool is extremely valuable. [In] my experience, smaller companies will do a better job of assets. Larger companies, because of the breadth of their space, aren’t so good at knowing what their assets are, but they are getting better.”
Map dependencies among data center resources
Meanwhile, a successful decommission includes mapping out dependencies in the data center. The older a data center is, the more dependencies you are likely to find.
It’s important to segment what’s in the data center so that you can move things in orderly phases and limit the risk of something going wrong, says Andrew Wertkin, chief strategy officer with BlueCat Networks, a networking connectivity provider that helps companies migrate to the cloud. “Ask how can I break this into phases that are independent – meaning ‘I can’t move that app front-end because it depends on this database,’” Wertkin says.
For example, let’s consider a wide area network (WAN). Each connection point is often optimized. When you start to disassemble the network, you need to know who is getting what in terms of connections and optimized services. Otherwise, you risk SLA issues when you break the connection. Changing the IP addresses of well-known servers, even temporarily, also creates connection problems. The solution is to do it one step at a time.