CompTIA Network+ N10-008 – Module: Examining Best Practices for Network Administration Part 3

5. 16.4 Rack Management

Usually in a data center or equipment room. We have servers and routers and switches mounted in racks. And in this video, we want to talk about some of the different rack options that we might have. We want to talk about how we can arrange the racks for proper ventilation. But first, as we’re out shopping for racks, let’s take a look at a few options we might have.

Normally, we’re going to be looking for a 19 inch rack. The holes on each side of the rack on the posts, they’re 19 inches apart. And for your routers and switches and servers, oftentimes you can get brackets that you attach to the side of those routers and switches and servers, those holes are 19 inches apart. And for some of the lighter weight equipment, maybe like a small router or a small switch, they can connect to a two post rack. This is where you have just two posts and you have brackets near the front of your router or switch.

And those brackets are going to bolt in to the two posts, even though there is no support for the rear of the switch or the rear of the router. And that’s okay because it’s a fairly lightweight device. However, when you start getting into heavier devices like big servers, you probably want to have a four post rack. And that’s where you have support at all four corners. And if you’re dealing with servers or any sort of equipment that you might need to open from time to time and get access to without taking out all of your screws and unbolting everything from the rack, you might want to put that device on rails and some racks.

They support a railing system where, just as you would open a drawer in a desk, you could pull out a server from your rack of equipment. And for security purposes, you might get the option where you could lock the device in where it could not be pulled out unless you unlock it. And one of the big design considerations we have when it comes to rack management is how we ventilate the equipment. We can have a lot of servers in a rack, and those servers can generate a significant amount of heat. How do we make sure that everything is cooled? It might not be enough to just have a big air conditioning unit in the room, because even though you’re blowing out cold air from some of the vents, maybe in the ceiling, maybe in the floor, it’s not necessarily going to get to the components inside of your routers or switches.

You might have hot spots because there’s not enough air flow. Let’s think about how we can improve airflow through the racks. Let’s say that we have these four different racks on screen, and we’re getting a view of these racks on their side. This is a profile view. And we’ll say that we have these racks sitting on top of a raised floor. We have an air conditioning unit on each end of this data center. And you can see that I’ve labeled where the front of the servers are and where the back of the servers are for each of these racks.

What we can do is be very strategic about the airflow. If our servers have fans inside of them, they’re going to be pulling air in from the front of the servers and then pushing it out the back of the servers. What we can do is provide cold air to the front of the servers and then let their fans send the hot air out the back after that air flows over the internal server components. And to optimize that, we can design different aisles between our servers.

We could designate cold aisles and hot aisles. Here’s what I mean. Let’s imagine that we have these two HVAC units and they’re sending cold air into the raised floor. And that air is coming up in what we’ve designated as our cold aisles. And notice that the front of the servers, they’re facing the cold aisles. That means that the fans inside of the servers, they’re going to pull in that cold air and send it out the back. And that is going to exhaust the hot air into the hot aisle, which will then be pulled back through the ceiling, through the HVAC return system. This is a very common design we see in data centers. And again, the goal is to make sure that we get optimal airflow going across the components that are inside of our racks.

6. 16.5 Change Control

Whether we’re doing network maintenance or network troubleshooting, we need to clearly understand what changes have occurred in the network. In fact, one of the first questions we’re going to ask someone when we’re doing troubleshooting is, hey, did anything recently change? Because oftentimes that change may have introduced an issue. We need to realize, though, that change is a necessary element in our networks. We need to make updates.

We need to apply security patches, we need to replace failed equipment. We might need to scale our network to install new equipment. So change has to happen. However, when that change happens, it might introduce some issues. And for that reason, one of the first things we check when we’re doing troubleshooting is we check to see has anything changed? And there needs to be some sort of a formalized system in place to track those changes and a system like that. And there are various software packages that can do this, but this system is called a change control system.

One of the big benefits of having a change control system or a procedure in place is to let different team members know what other team members are doing. And here’s a true story to illustrate that concept. I remember when I was working down at Walt Disney World in Florida. We were working on a design that would upgrade the network that interconnected the theme parks and some of the resorts. It would interconnect the magic kingdom. Epcot, the studios. Animal Kingdom and I had worked on this design for weeks. We’d mocked it up in a lab. I had to go before a design review board and defend why I had spanning tree configured like I did. I had to say, this is why this is the route. This is why this is blocking. We wanted to make sure everything would go smoothly when we did this upgrade. So before we did the upgrade, I sent out a change control notification.

It was letting other departments know within Disney that this change was about to be made at this certain time on this certain night. Because Disney World in Florida was interconnected with ABC News in New York. It was interconnected with Paul Harvey Radio in Chicago and Disneyland out in Anaheim, California. We wanted to make sure that nobody had a problem with what we were going to be doing on the Disney World backbone. So I fill out this online change control notification, and I waited to see if anybody had a problem with it. Nobody did. Awesome.

We were ready to go. So I show up about 01:00 A. m. 02:00 A. m. One morning, and we go into the tunnel system underneath the Magic Kingdom, and we swap out the switches. We move the fiber cables, lights start blinking. Everything looks great, but we go back to our office and notice that something is not working just perfectly. Specifically email. And as we dug deeper, we realized that all of the Disney. com domain email was not working. Everybody from Michael Eisner to Mickey Mouse could not get email. And this caused us a bit of concern in the wee hours of the morning. Was this just a coincidence? We had just performed an upgrade on the Disney World backbone. Now nobody’s email worked. Were those events related or not? And we were concerned that for some unknown reason, the upgrade we did had broken the email. Well, when the email team got in the next morning, they did some investigation and they realized that it wasn’t related to our change at all.

That was a big relief. What had happened was somebody out in Anaheim, California, replaced an ATM module, an Asynchronous transfer mode module, and that caused the email to break, and they had neglected to send out a change notification. So I had no idea that that change was being made. And it caused a lot of stress for myself and the people I was working with during those hours. And I tell you this story to emphasize the point that everybody on the team, specifically everybody on the It staff, needs to know about changes that are taking place on the network.

And when I say we should go through a formal procedure like this, a formal change control procedure, to notify others when a change is happening. I’m not talking about a situation where maybe there’s an urgent condition. And we know that we could resolve a condition just by giving a couple of commands in the router.

I don’t mean we always have to send out a change control notification beforehand. Sometimes if something is really urgent and we know exactly how to fix it, we might need to just fix it and then notify our teammates immediately afterwards. But if you want to plan a maintenance window when you’re going to be doing some sort of an upgrade or some sort of equipment swap, I encourage you to have some sort of formalized change control procedure in place so that your coworkers know what you’re doing. And then when they observe something, they’ve got that data point that, hey, you are making that change, and that might play into their troubleshooting.

• Category: Uncategorized