Surviving failures in bandwidth-constrained datacenters

Abstract

Abstract-Datacenter networks have been designed to tolerate failures of network equipment and provide sufficient bandwidth. In practice, however, failures and maintenance of networking and power equipment often make tens to thousands of servers unavailable, and network congestion can increase service latency. Unfortunately, there exists an inherent tradeoff between achieving high fault tolerance and reducing bandwidth usage in network core; spreading servers across fault domains improves fault tolerance, but requires additional bandwidth, while deploying servers together reduces bandwidth usage, but also decreases fault tolerance. We present a detailed analysis of a large-scale Web application and its communication patterns. Based on that, we propose and evaluate a novel optimization framework that achieves both high fault tolerance and significantly reduces bandwidth usage in the network core by exploiting the skewness in the observed communication patterns.

Survivability and Fault Tolerance in the Cloud

“…The 9s are a logarithmic measures; that is, a system with five 9s availability is 10s times more available than another one with four 9s. • Fault domain: A fault domain is a set of devices that share a single point of failure [10]. For instance, servers connected to the same top-of-rack switch belong to the same fault domain.…”

“…Bodik et al [10] studied resource allocation in data centers that achieve the best tradeoff between fault tolerance and bandwidth usage. Indeed, when VMs of the same VDC (termed "service" in the paper) are spread across the data center, they are less likely to be affected by the same failure (e.g., top-of-rack failures) but they consume significant bandwidth in the data center network, as they are far from each other (Fig.…”

“…[10,16]). Furthermore, many of them have assumed that the cluster is homogenous, that is, all devices have the same availabilities and failure rates (e.g., Ref.…”

Power-efficient resource-guaranteed VM placement and routing for time-aware data center applications

“…Each TTA request also has a randomly generated resource requirement graph G k , as tenant applications can have a diverse range of communication patterns ranging from star and mesh to linear and ring [38]. Since the number of tiers in the resource requirement graph is likely to be small [38], we consider the resource requirement graph G k with three different sizes 2, 4, and 8.…”

“…Each TTA request also has a randomly generated resource requirement graph G k , as tenant applications can have a diverse range of communication patterns ranging from star and mesh to linear and ring [38]. Since the number of tiers in the resource requirement graph is likely to be small [38], we consider the resource requirement graph G k with three different sizes 2, 4, and 8. Followed by real cloud providers such as Amazon and Google which provide a small finite set of instances [14,35], we support the resource heterogeneity by defining = {"S", "M", "L", "XL"} where a VM belonging to the "S", "M", "L", and "XL" consumes 1, 2, 4, and 8 units of the server's resources, respectively.…”