Building High Availability

Download the entire InformationWeek SMB, distributed in an all-digital format as part of our Green Initiative
(Registration required.)

We will plant a tree for each of the first 5,000 downloads.

Let's face facts: Servers die, storage fails, network connectivity drops, power goes out. There are simply too many things that can go wrong when providing IT services, even for a simple application. At the same time, small and midsize enterprises won't tolerate outages. Thus, it's incumbent upon IT to build for high availability. You need multiple roads in your network, storage, and application layers to ensure employees can access the information and apps they need.

High availability (HA) means building redundancy into critical business systems so the failure of one component, such as a bad NIC in a server, won't cause the application to fail. It's similar to building multiple highways into a city: If problems arise on one road, traffic can take an alternate route. Standard HA practices include deploying redundant hardware and using multiple network links.

The decision to build highly available systems, however, should always be a business decision. That's because HA is expensive, so by working with the business units, you can focus on the services that are truly critical to the company. With a clear mandate in hand, you can formulate a cost-effective strategy. Then the pressure is on IT to pick the right technologies to get the job done.

Measure First

Before you start building multiple roads, you have to know the amount of traffic to accommodate. In other words, don't build a six-lane highway if you only need two. Every application consumes memory, processing, network capacity, and storage in a unique way. As a result, the first part of the process is to assess the resources your core applications need to run properly. Your application and workload analysis will naturally unearth the degree of availability you need to get the job done, and your design will flow from there.

That's the technical side. You also need to work with the business side to calculate how much the downtime of critical applications costs the company--which in turn will dictate how much you can spend to keep systems up and running. For instance, do seconds or milliseconds matter on a transaction-by-transaction basis? Such calculations will determine whether you need to build a two-, four, or six-lane highway.

Let's use Microsoft Exchange as an example. Business has very little patience for email being down, so spending the dollars to bring more availability to your messaging environment is the answer. To assess your application requirements, look at factors like CPU utilization and the kinds of messaging load you support; for instance, your users may send high volumes of email with large files attached. These data points will influence your server and storage designs.

2011 Backup Survey

New Possiblities for Data Protection
Become an InformationWeek Analytics subscriber and get our full backup report.

This report includes 35 pages of action-oriented analysis packed with 25 charts. What you'll find:

• Insight on backup, deduplication, and cloud-based storage
• Discussion of virtualization and backups
• Survey results from 420 IT pros

Get This And All Our Reports