217
Chapter 15:
Designing a Network
because the data might be static and easy to restore from tape if the disk array is lost.
Other applications might require the highest level of data-loss safety possible, with
failover servers each having mirrored RAID 1 or RAID 10 arrays and online tape
backup systems updating a backup tape every hour or for every transaction. Similarly,
some companies might work with data that is so sensitive that they must install the
best firewalls, perhaps even two levels of firewalls, and hire full-time professionals
dedicated to keeping the data secure. Other companies might be satisfied if they are
only reasonably secure.
The point is that you must determine how important these issues are to the company
for which you are designing the network. Then you can propose different solutions to
address these needs and factor them into the rest of your design.
Growth and Capacity Planning
The final area to consider is the expected growth of the network, particularly if the
company expects this growth to be substantial. As mentioned earlier in this chapter, a
network designed for a rapidly growing company looks different from one for a slowly
growing company, even if both companies start out at the same size. In the former case,
you want a design that you can quickly and easily expand without needing to replace
much of the existing hardware and software. In the latter case, you can get by with a
simpler network design.
Consider the impact of growth on the different parts of the network that you've
already examined (applications, users, and services), because linear growth does not
always mean a matching linear impact to the network. Assuming linear growth, the
impact to the network might be much lower or much higher than the curve.
For example, you saw in Chapter 4 how Ethernet uses a collision detection mechanism
to manage network traffic. In that chapter, you also learned that Ethernet scales linearly,
but only up to a point. Once the network starts to become saturated, performance begins
to drop rapidly because of the chaotic nature of Ethernet's collision detection scheme.
Consider a 10 Mbps Ethernet network transmitting 3 Mbps of traffic. This traffic probably
flows smoothly, with few collisions and few retransmissions required. Push the network
demand up to 4 or 5 Mbps, however, and its performance grinds to a halt as the network
becomes saturated, and you end up with as many collisions and retransmissions as real
data. In fact, the total amount of good data flowing over a saturated Ethernet network will
be less than the amount flowing over a less-saturated network.
You can also find examples where an increase in demand doesn't cause a
corresponding increase in network or server load. For example, the server load for
a complex e-mail system might increase only by a small amount if you doubled the
number of users, because the system's overhead generates most of the load. The storage
requirements for an accounting system might not double just because you keep twice as
much data in it to accommodate the overhead that might consume most of the existing
space. Alternatively, that same accounting system might consume four times as much
storage space if you double the data storage, because it might have a relatively inefficient
indexing scheme. The point is that you need to know how different applications scale