Hardware Reference
In-Depth Information
slow tasks is to provide software mechanisms to cope with such variability that is inherent
at this scale. This approach is in sharp contrast to the solution for a server in a conventional
datacenter, where traditionally slow tasks mean hardware is broken and needs to be replaced
or that server software needs tuning and rewriting. Performance heterogeneity is the norm for
50,000 servers in a WSC. For example, toward the end of a MapReduce program, the system
will start backup executions on other nodes of the tasks that haven't completed yet and take
the result from whichever finishes first. In return for increasing resource usage a few percent,
Dean and Ghemawat [2008]
found that some large tasks complete 30% faster.
Another example of how WSCs differ is the use of data replication to overcome failures.
Given the amount of equipment in a WSC, it's not surprising that failures are commonplace,
as the prior example atests. To deliver on 99.99% availability, systems software must cope
with this reality in a WSC. To reduce operational costs, all WSCs use automated monitoring
software so that one operator can be responsible for more than 1000 servers.
Programming frameworks such as MapReduce for batch processing and externally facing
SaaS such as search rely upon internal software services for their success. For example,
MapReduce relies on the Google File System (GFS) (
Ghemawat, Gobiof, and Leung [2003]
)
to
supply files to any computer, so that MapReduce tasks can be scheduled anywhere.
In addition to GFS, examples of such scalable storage systems include Amazon's key value
storage system Dynamo [
DeCandia et al. 2007
] and the Google record storage system Bigtable
[Chang 2006]. Note that such systems often build upon each other. For example, Bigtable
stores its logs and data on GFS, much as a relational database may use the file system provided
by the kernel operating system.
These internal services often make different decisions than similar software running on
single servers. As an example, rather than assuming storage is reliable, such as by using RAID
storage servers, these systems often make complete replicas of the data. Replicas can help
with read performance as well as with availability; with proper placement, replicas can over-
come many other system failures, like those in
Figure 6.1
. Some systems use erasure encoding
rather than full replicas, but the constant is cross-server redundancy rather than within-a-serv-
er or within-a-storage array redundancy. Hence, failure of the entire server or storage device
doesn't negatively affect availability of the data.
Another example of the different approach is that WSC storage software often uses relaxed
consistency rather than following all the ACID (atomicity, consistency, isolation, and durabil-
ity) requirements of conventional database systems. The insight is that it's important for mul-
tiple replicas of data to agree
eventually
, but for most applications they need not be in agree-
ment at all times. For example, eventual consistency is fine for video sharing. Eventual consist-
ency makes storage systems much easier to scale, which is an absolute requirement for WSCs.
The workload demands of these public interactive services all vary considerably; even a
popular global service such as Google search varies by a factor of two depending on the time
of day. When you factor in weekends, holidays, and popular times of year for some applica-
tions—such as photograph sharing services after Halloween or online shopping before Christ-
mas—you can see considerably greater variation in server utilization for Internet services.
Fig-
ure 6.3
shows average utilization of 5000 Google servers over a 6-month period. Note that
less than 0.5% of servers averaged 100% utilization, and most servers operated between 10%
and 50% utilization. Stated alternatively, just 10% of all servers were utilized more than 50%.
Hence, it's much more important for servers in a WSC to perform well while doing litle than
to just to perform efficiently at their peak, as they rarely operate at their peak.
Search WWH ::
Custom Search