Proceedings Template word
Figure 3: System components of a delivery network. To
Download 493.43 Kb. View original pdf
|
| Figure 3: System components of a delivery network. To understand how these components interact, it is instructive to walk through a simple example of a user attempting to download a web page through the Akamai network. 4.3 System Design Principles The complexity of a globally distributed delivery network brings about a unique set of challenges in architecture, operation and management—particularly in an environment as heterogeneous and unpredictable as the Internet. For example, network management and data collection needs to be scalable and fast across thousands of server clusters, many of which are located in unmanned, third-party data centers, and any number of which might be offline or experiencing bad connectivity at any given time. Configuration changes and software updates need to be rolled out across the network in a safe, quick, and consistent manner, without disrupting service. Enterprises also must be able to maintain visibility and fine-grained control over their content across the distributed platform. To guide our design choices, we begin with the assumption that a significant number of failures (whether they beat the machine, rack, cluster, connectivity, network levels) is expected to be occurring at all times in the network. Indeed, while not standard in system design, this assumption seems natural in the context of the Internet. We have seen many reasons that Internet failures can occur in Section 3, and have observed it to be true empirically within our own network. What this means is that we have designed our delivery networks with the philosophy that failures are normal and the delivery network must operate seamlessly despite them. Much effort is invested in designing recovery from all types of faults, including multiple concurrent faults. This philosophy guides every level of design decision—down to the choice of which types of servers to buy the use of robust commodity servers makes more sense in this context than more expensive servers with significant hardware redundancy. While it is still important to be able to immediately identify failing hardware (e.g., via ECC memory and disk integrity checks that enable servers to automatically take themselves out of service, there are diminishing returns from building redundancy into hardware (e.g, dual power supplies) rather than software. Deeper implications of this philosophy are discussed at length in [1]. We now mention a few key principles that pervade our platform system design Download 493.43 Kb. Share with your friends:
|