Most of us think of the network as a single
entity that can be managed, coached, and coaxed as needed. That's
certainly the goal, and even the theme of Sun's latest advertising
campaign. In reality, any network is a loosely managed team of
components, spanning wiring closets, configuration files, and
applications that use or abuse resources. It's rare that a single point
of failure can be identified easily, or that the same element fails
repeatedly. Failures in one part of the infrastructure affect
applications or services several logical layers away, masking the true
source of the problem. Physical plant problems ripple upstream,
disrupting name or file services. When one player fails, the whole team
goes south.

As businesses become more dependent on the correct operation of
networks for groupware, Internet, intranet, and e-mail capabilities,
network reliability will become another buzzword adored by analysts and
touted by vendors. We'll look at the issues underlying network
reliability, including but not limited to
network performance and traffic control.

We'll examine physical access and security
problems, bandwidth allocation, configuration files, and
service dependencies.

From there it's on to application exposures, such as unduly long network latency or resending lost requests. We'll conclude with some suggested metrics and measurement techniques, designed to help you demonstrate that you have your network team under
control.

Go team! Yeah team! An end-to-end approach

How do you take a team approach to network reliability? Instead of
focusing on the individual components, look at how they interact and
form an end-to-end system, and examine the relationships of network
devices and subsystems to higher level services. Taking the team
analogy a step further, define some ideal attributes for a reliable,
well-built network:

• Consistent behavior from any access point
• Reliable,
  predictable performance
• Redundancy to make up for any individual
  failure

A good "team approach" example is the United States telephone system.
No matter where you go to plug in your handset, the RJ-11 jacks appear
the same. The dialtone is the same, as are the touchtones and dialing
sequences from any access point. There is only minor variation in the
time required to connect a call, and the system has enough fault
tolerance built in to survive a number of failures on the natural
disaster scale. The telephone service model is appropriately strong
because it describes a distributed data center -- predictable, regular,
reliable performance right to the end user access point. Perhaps the
most impressive feature of the telephone system is that its reliability
is transparent -- you don't "feel" the system. Rarely does a caller
notice the changes in topology that occur in response to congestion or
failures, because reliability is designed into the system in layers.

We'll cover the layers of network reliability from the ground wire up:

• Physical plant, focusing on the security and manageability of
  the cable plant.
  
  
  
  
• Traffic management, including congestion control, network latency,
  and performance assurance.
  
  
  
  
• Host and service configuration, ensuring that the network appears
  consistent throughout.
  
  
  
  
• Service dependencies, outlining the impact of name and file
  services on applications.
  
  
  
  
• Application exposures to network failures and some common solutions
  to them.
  
  
  
  
• End-to-end security, adding privacy and integrity concerns to the
  reliability of the physical plant and service mechanisms.

Unfortunately, most people associate "network reliability" with simple
congestion control and end-to-end connectivity. When packets are
flowing, they consider the network reliable. This narrow definition
skirts issues

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine