Making data center maps is usually a thankless task. Rarely viewed, the maps are often abandoned after creation -- if they're drawn up in the first place.
Data center maps combine diagrams and documentation on the racks, the hardware inside, and sometimes more details. Learning how to properly create maps can be time-consuming, but it's a valuable skill to have.
Those that look after the IT infrastructure of your company, big or small, should take care of the data center maps. Here's how to make it a worthwhile process.
What should data center maps contain?
The most basic diagram shows the racks in the data center and the equipment inside. This should include physical servers, all communication gear such as switches and routers, uninterruptible power supply units, backup drives and any other piece of hardware that lives in your data center.
Additional details add extra value to documentation. Include communication paths to show what network segment a device connects to, or its multiple paths for redundancy to different switches. If you need to repatch in a server, a detailed diagram will help preserve you multiple paths. If you don't have a map, you might install multiple network interface cards into the same switch at the other end, erasing the planned redundancy.
Why bother with data center documentation?
Documentation is one of the most abandoned aspects of IT. Time is valuable -- it's hard to justify documenting configurations when there are systems to build, fix and optimize. But when you actually need this information, you'll be thankful that someone found the time. Having a floor plan of the data center lets you visualize future changes, especially if you need to install temporary equipment for an upgrade.
Data center documentation is vital for a disaster recovery plan, where you may need to recreate the environment after a disaster. It also helps on remote tasks, like talking a technician through swapping a failed hard drive over: "Count four servers down, fifth drive across ..."
Mapping is likely an expected part of your job -- you have a duty of care to the company to keep records. You wouldn't want to try and work out where everything is on your first day, so you shouldn't do the same to your successor. Even the CIO should want to know what their infrastructure looks like.
Don't forget the rest of your team. If you're in charge of the data center and build it from the ground up, don't think you can remember everything, even if it isn't in the ballpark of the Google data center. If you're not there, what happens? After all, you need at least one person who can help when you finally find time to take a vacation.
The whole IT team should have the data center map, even developers. If a developer is the only person around, they might need to reboot a server or check cables. Trying to fix a problem is frustrating when you don't know the right setup. Basic information, like where a physical server -- which you've never seen before -- is located, can save a lot of running around. Data center maps are worth their weight in gold when disaster strikes: The host blue screen or a kernel panic occurs, requiring someone to press the reboot button.
Documentation should only be available to parties that need either physical access or knowledge of schematics for planning. Consider security based on who might need access to the documentation, and the risk incurred if unauthorized people saw the data it contains. If an intruder gained access to your data center and knew to take the server labelled "customer database," then having the map would help them succeed.
Are constant updates really necessary?
In some ways, outdated diagrams can be worse than no diagrams at all. Updates are vital, but are often overlooked by IT departments.
If there's no documentation, you'll have to find out how something is configured without any path to follow. Incorrect documentation will lead you down the wrong path. Imagine you've spent half an hour trying to find a physical server during an outage, only to learn it was virtualized months ago.
Updating data center maps won't take nearly as long as the original creation. Diagrams and documentation should be updated immediately after a change, and ideally this should be a step in the change management process.
How to make data center diagrams
Microsoft Visio is the king of creating and editing data center diagrams. Many hardware companies, such as Cisco, provide Visio stencils of products to make diagrams simple. There are also community-driven Visio stencil sites, such as VisioCafe, that host user-submitted creations.
Maps around the world
Visio-style stencil diagrams of racks and their contents are the most common maps. Alternatively, some IT teams use a data center floor plan diagram, showing a top-down view of the room. Apart from the racks, these floor plans often include the location of air conditioning units/vents, communication wall boxes and other physical equipment. Maps often document both front and rear views of each rack, with labels on each physical device in the rack. This sets them apart from other reference documents, such as system contextual diagrams that show how systems work and what interacts with them.
Visio is still popular, but there are many other more basic tools popping up. One open source example, RackTables, goes for function over form, but still has a lot of the key information to record racks and contents. Even an Excel spreadsheet is an acceptable method of documenting the data center, as long as the information is correct and regularly maintained.
Rerouting: Virtualization broke my maps
Data center mapping was easier when everything was physical. These days, virtual servers are much harder to diagram -- as the same schematic logic doesn't apply --- and they can migrate from one server to another with automatic orchestration.
A contextual diagram shows which physical hosts can hold which virtual machine clients. Due to the disconnect between the static virtual machine hosts and the dynamic virtual machine clients, the clients themselves may not need to be a part of your data center mapping.
About the author: Adam Fowler is IT operations manager at a law firm in Australia. He's worked in IT for over a decade, including responsibilities in systems, infrastructure and operational service. He blogs about all things IT at http://www.adamfowlerit.com/.
Learn how to create organized, thorough server documentation