CompTIA Network+ Availability: Racks, Power, DR Sites, and MTTR vs MTBF

What N10-009 objectives 2.4 and 3.3 cover

CompTIA Network+ N10-009 (V9) splits this material across two domains. Objective 2.4, in Network Implementation (20% of the exam), asks you to explain the important factors of physical installations: where equipment goes, how racks are laid out, power, and the environment. Objective 3.3, in Network Operations (19%), asks you to explain disaster recovery concepts: recovery metrics, recovery sites, high-availability designs, and testing.

Both answer one question: how does the network keep running, and how fast does it come back when it stops? This page treats them as one task.

MDF and IDF in one two-floor building

A fictional two-floor office shows the difference.

• Main distribution frame (MDF), floor 1. The ISP circuit enters here, and this room holds the router, the core switch, the servers, and the fiber distribution panel where the riser cable to the upper floor ends.
• Intermediate distribution frame (IDF), floor 2. A smaller closet with the floor-2 access switches, the patch panel for that floor's wall jacks, and a second fiber distribution panel for the riser from the MDF.

Every wall jack on a floor runs back to the patch panel in that floor's closet. Short patch cables then connect panel ports to switch ports, so moving a user means moving a patch cable, not pulling new cable. The objectives also list lockable racks: both rooms hold equipment that should be behind a lock. Choose rack size for the equipment you have plus room to grow, and check that the deepest device fits. The Network+ monitoring and documentation guide shows how the rack diagram and cable map record all of this.

Port-side exhaust and intake: an airflow check

Network switches move air through the chassis in one direction, and vendors often describe that direction relative to the side with the ports. With port-side exhaust, air leaves through the port side. With port-side intake, air enters there.

In a room laid out with cold and hot aisles, every device should draw air from the cold aisle. Take a top-of-rack switch mounted with its ports facing the rear of the rack, toward the server network cards. The servers blow hot air out of that side, so the switch's ports face the hot aisle. That switch needs port-side exhaust, so that it pulls cool air in from the cold-aisle side. Mount the same switch with its ports facing forward, into the cold aisle, and it needs port-side intake. Get it backward and the switch breathes the servers' exhaust.

Power on Network+: UPS, PDU, power load, and voltage

A UPS carries equipment through a short outage on battery and gives it time to shut down cleanly or for a generator to start. A PDU distributes power to the devices in a rack. Power load is the total the equipment draws, and voltage is whether each device's rated input matches the circuit it plugs into.

Worked power load. A rack holds three switches drawing 150 W each and two servers drawing 400 W each.

• 3 × 150 W = 450 W
• 2 × 400 W = 800 W
• Total: 450 + 800 = 1,250 W

Check both the UPS watt rating and its VA rating; neither limit may be exceeded. A unit rated 1,500 VA and 1,000 W cannot carry this 1,250 W rack because its real-power limit is too low. A 2,200 VA / 1,980 W unit clears the watt requirement with 730 W of nominal headroom, but you must also verify the load's apparent power, input requirements, and desired margin. Runtime at the actual load comes from the manufacturer's chart.

The environmental factors in 2.4 are humidity, fire suppression, and temperature. Keep the room within the ranges the equipment manufacturers specify, and treat fire suppression as a building and code decision that network staff need to know about, not one they make alone.

Uptime arithmetic for Network+

Availability targets turn into allowed downtime with one multiplication. Using a 365-day year, that is 8,760 hours or 525,600 minutes.

Each extra nine cuts the allowed downtime by a factor of ten. That is why a service-level agreement that promises 99.99% needs redundancy, not just a quick technician.

MTTR vs MTBF, with RTO and RPO in one line each

• MTTR is mean time to repair, as the N10-009 objectives expand it: the average time to get a failed component working again.
• MTBF is mean time between failures: the average running time between failures. It is an average, not a promise that any one device lasts that long.

The useful difference is control. MTBF mostly reflects the hardware and its conditions, such as temperature and power quality. MTTR is largely yours to reduce. In a fictional example, a failed branch switch takes about 8 hours to replace when the spare comes by courier. With a spare on the shelf, a current configuration backup, and out-of-band access, the same repair takes about 1 hour. The MTBF did not change. The outage did.

RTO is how long a service may stay down, and RPO is how much data, measured in time, you can afford to lose. Passy's Security+ guide to RTO and RPO works both on a timeline.

Cold, warm, and hot sites

Choose by the recovery time the business needs, then accept the cost that comes with it. A service that must be back within an hour rules out any site where equipment still has to arrive.

The free mixed set of 20 Network+ questions includes an item about a firm that must restart within an hour. You can check the one-hour restart DR-site item →, with an explanation for every option.

Active-active, active-passive, and DR tests

Active-active designs run both sites or devices at once and share the load. If one fails, the other carries everything, so each must be able to handle the full load alone. Active-passive designs keep a standby that takes over only on failure. VRRP, a standard first hop redundancy protocol, is a small active-passive example: RFC 5798 has one router control the shared gateway address while the others stand ready to take it over. FHRPs are covered in the Network+ routing guide.

The objectives list two kinds of test. A tabletop exercise is a discussion: the team walks through a scenario and the plan. A validation test actually exercises the failover or the restore and checks the result. In a fictional branch, the tabletop finds that the recovery runbook still lists the old ISP's support number. The validation test, run on a Saturday, moves the branch to its backup circuit and confirms that phones and the ticket system work. Both kinds catch problems the other misses.

For availability designs that live in the cloud, such as spreading servers across subnets behind a load balancer, see the cloud and data center guide.