Wait—even if you have only one site, don't skip this section—at least not yet. First, since this is a book about reliability, I'd be remiss if I didn't have at least a gentle reminder about the importance of considering site failures in designing for reliability.
If you have only one site from which to deliver service to the Internet, then a failure of that site may knock your service off the Internet regardless of the amount of advice you follow from later chapters of this book.
But your interests in reliability may well be limited to keeping your clients connected to servers run by others on the Internet. If so, a site failure might well wipe out your clients as well as your Internet connection. It's often reasonable to discount planning for site failure in these cases.
Ok, If you've made it this far and still don't see the need to consider site failure, you can skip the rest of this section (but please don't skip the rest of the chapter). From here on out, let's assume that you are concerned about providing reliable service to others on the Internet.
So, just what is a site failure? Let's define it as a broad category of events that cause several systems at a single site to fail at the same time. Site failures are sometimes also called "site disasters" since a local disaster such as a tornado or earthquake can induce widespread system failure. But it's best to think broadly since mundane events like extended power outages or backed up sewers can also cause site failures. For many suburban sites, a single misplaced scoop of a backhoe's bucket may be all it takes to sever all communications lines or power to a site for a day or more.
Perhaps the single most important point to keep in mind when designing for reliability is the old aphorism: a chain is no stronger than its weakest link. Applied here, this means that it might not be a wise decision to spend money on a second T1 to another ISP if your AC power is perennially flaky and you haven't already invested in a UPS (and perhaps a generator).  The flip side of this coin is that even with pristine AC power and the utmost in reliable Internet connections, flaky server hardware running a buggy server operating system cannot deliver reliable service to the Internet.
The "chain" you need to consider in designing for reliability includes every hardware and software component involved in making your service appear on the Internet. It also includes all the human, environmental, and utility components that support them.
With the above reminder out of the way, the generalities of planning for reliability in the face of site failure are best left to other texts. Our discussion will be limited to the . . . .
What if your servers cannot be replicated? What if you're in a site with dual fiber entrances? How many sites do you have now?
What if you're a local ISP with all your equipment at a single site? Consider the relative costs of adding a virtual POP vs. a physical POP. A VPOP may well cost less, but it doesn't do anything for your reliability. If upstream bandwidth is already taxed at your main site, the incremental cost of adding a second site may not be that much more than adding a VPOP.
How many sites will you have in the future? Do you already have a private network connecting two sites? Trend for multi-site companies Private nets (now called "intranets") Intranet with single Internet connection Intranet with multiple Internet connections VPN Intranet tunneled over Internet Summary & Conclusions
On the other hand, tell yourself that it was a wise decision to buy this book because it reminded you to keep your priorities straight.
|How Will Address Space be Assigned to Networks?||Up||How Many Internet Connections are Required?|
Copyright © 1999-2000 by Robert A. Van Valzah