Google Data Centers are the large data center facilities Google uses to provide their services, which combine large amounts of digital storage (mainly hard drives and SSDs), compute nodes organized in aisles of racks, internal and external networking, environmental controls (mainly cooling and dehumidification), and operations software (especially as concerns load balancing and fault tolerance). This article describes the technological infrastructure behind Google's websites as presented in the company's public announcements.


The locations of Google's various data centers are as follows:[1]

United States:

  1. Berkeley County, South Carolina 33°03′50.8″N 80°02′36.1″W / 33.064111°N 80.043361°W / 33.064111; -80.043361 since 2007, expanded in 2013, 150 employment positions
  2. Council Bluffs, Iowa 41°13′17.7″N 95°51′49.92″W / 41.221583°N 95.8638667°W / 41.221583; -95.8638667 announced 2007, first phase completed 2009, expanded 2013 and 2014, 130 employment positions
  3. Douglas County, Georgia 33°44′59.04″N 84°35′5.33″W / 33.7497333°N 84.5848139°W / 33.7497333; -84.5848139 since 2003, 350 employment positions
  4. Jackson County, Alabama[2]
  5. Lenoir, North Carolina 35°53′54.78″N 81°32′50.58″W / 35.8985500°N 81.5473833°W / 35.8985500; -81.5473833 announced 2007, completed 2009, over 110 employment positions
  6. Montgomery County, Tennessee 36°37′37.7″N 87°15′27.7″W / 36.627139°N 87.257694°W / 36.627139; -87.257694 announced 2015
  7. Pryor Creek, Oklahoma at MidAmerica Industrial Park 36°14′28.1″N 95°19′48.22″W / 36.241139°N 95.3300611°W / 36.241139; -95.3300611 announced 2007, expanded 2012, 100 employment positions
  8. The Dalles, Oregon 45°37′57.04″N 121°12′8.16″W / 45.6325111°N 121.2022667°W / 45.6325111; -121.2022667 since 2006, 80 full-time employment positions

South America:




Original hardware

The original hardware (circa 1998) that was used by Google when it was located at Stanford University included:[3]

  • Sun Microsystems Ultra II with dual 200 MHz processors, and 256 MB of RAM. This was the main machine for the original Backrub system.
  • 2 × 300 MHz dual Pentium II servers donated by Intel, they included 512 MB of RAM and 10 × 9 GB hard drives between the two. It was on these that the main search ran.
  • F50 IBM RS/6000 donated by IBM, included 4 processors, 512 MB of memory and 8 × 9 GB hard disk drives.
  • Two additional boxes included 3 × 9 GB hard drives and 6 x 4 GB hard disk drives respectively (the original storage for Backrub). These were attached to the Sun Ultra II.
  • SDD disk expansion box with another 8 × 9 GB hard disk drives donated by IBM.
  • Homemade disk box which contained 10 × 9 GB SCSI hard disk drives.

Production hardware

Google used as of 2014, a heavily customized version of Debian (GNU/Linux). They migrated from a Red Hat-based system incrementally in 2013.[4][5]

The customization goal is to purchase CPU generations that offer the best performance per dollar, not absolute performance. How this is measured is unclear, but it is likely to incorporate running costs of the entire server, and CPU power consumption could be a significant factor.[6] Servers as of 2009–2010 consisted of custom-made open-top systems containing two processors (each with several cores[7]), a considerable amount of RAM spread over 8 DIMM slots housing double-height DIMMs, and at least two SATA hard disk drives connected through a non-standard ATX-sized power supply unit.[8] The servers were open top so more servers could be fit into a rack. According to CNET and to a book by John Hennessy, each server had a novel 12-volt battery to reduce costs and improve power efficiency.[7][9]

According to Google their global data center operation electrical power ranges between 500 and 681 megawatts.[10][11] The combined processing power of these servers might have reached from 20 to 100 petaflops in 2008.[12]

Network topology

Details of the Google worldwide private networks are not publicly available but Google publications[13][14] make references to the "Atlas Top 10" report that ranks Google as the third largest ISP behind Level 3.[15]

In order to run such a large network with direct connections to as many ISP as possible at the lowest possible cost Google has a very open peering policy.[16]

From this site we can see that the Google network can be accessed from 67 public exchange points and 69 different locations across the world. As of May 2012 Google had 882 Gbit/s of public connectivity (not counting private peering agreements that Google has with the largest ISPs). This public network is used to distribute content to Google users as well as to crawl the Internet to build its search indexes.

The private side of the network is a secret but recent disclosure from Google[17] indicate that they use custom built high-radix switch-routers (with a capacity of 128 × 10 Gigabit Ethernet port) for the wide area network. Running no less than two routers per datacenter (for redundancy) we can conclude that the Google network scales in the terabit per second range (with two fully loaded routers the bi-sectional bandwidth amount to 1,280 Gbit/s).

These custom switch-routers are connected to DWDM devices to interconnect data centers and point of presences (PoP) via dark fibre.

From a datacenter view, the network starts at the rack level, where 19-inch racks are custom-made and contain 40 to 80 servers (20 to 40 1U servers on either side, while new servers are 2U rackmount systems.[18] Each rack has a switch). Servers are connected via a 1 Gbit/s Ethernet link to the top of rack switch (TOR). TOR switches are then connected to a gigabit cluster switch using multiple gigabit or ten gigabit uplinks.[19] The cluster switches themselves are interconnected and form the datacenter interconnect fabric (most likely using a dragonfly design rather than a classic butterfly or flattened butterfly layout[20]).

From an operation standpoint, when a client computer attempts to connect to Google, several DNS servers resolve www.google.com into multiple IP addresses via Round Robin policy. Furthermore, this acts as the first level of load balancing and directs the client to different Google clusters. A Google cluster has thousands of servers and once the client has connected to the server additional load balancing is done to send the queries to the least loaded web server. This makes Google one of the largest and most complex content delivery networks.[21]

Google has numerous data centers scattered around the world. At least 12 significant Google data center installations are located in the United States. The largest known centers are located in The Dalles, Oregon; Atlanta, Georgia; Reston, Virginia; Lenoir, North Carolina; and Moncks Corner, South Carolina.[22] In Europe, the largest known centers are in Eemshaven and Groningen in the Netherlands and Mons, Belgium.[22] Google's Oceania Data Center is claimed to be located in Sydney, Australia. [23]

Project 02

One of the largest Google data centers is located in the town of The Dalles, Oregon, on the Columbia River, approximately 80 miles (129 km) from Portland. Codenamed "Project 02", the $600 million[24] complex was built in 2006 and is approximately the size of two American football fields, with cooling towers four stories high.[25] The site was chosen to take advantage of inexpensive hydroelectric power, and to tap into the region's large surplus of fiber optic cable, a remnant of the dot-com boom. A blueprint of the site appeared in 2008.[26]

Summa papermill

In February 2009, Stora Enso announced that they had sold the Summa paper mill in Hamina, Finland to Google for 40 million Euros.[27][28] Google plans to invest 200 million euros on the site to build a data center.[29] Google chose this location due to the availability and proximity of renewable energy sources.[30]

Modular container data centers

In 2005,[31] Google was researching a containerized modular data center. Google filed a patent application for this technology in 2003.[32]


Most of the software stack that Google uses on their servers was developed in-house.[33] According to a well-known Google employee, C++, Java, Python and (more recently) Go are favored over other programming languages.[34] For example, the back end of Gmail is written in Java and the back end of Google Search is written in C++.[35] Google has acknowledged that Python has played an important role from the beginning, and that it continues to do so as the system grows and evolves.[36]

The software that runs the Google infrastructure includes:[37]

  • Google Web Server (GWS) – custom Linux-based Web server that Google uses for its online services.
  • Storage systems:
  • Chubby lock service
  • MapReduce and Sawzall programming language
  • Indexing/search systems:
    • TeraGoogle – Google's large search index (launched in early 2006), designed by Anna Patterson of Cuil fame.[42]
    • Caffeine (Percolator) – continuous indexing system (launched in 2010).[43]
    • Hummingbird – major search index update, including complex search and voice search.[44]
  • Borg declarative process scheduling software

Google has developed several abstractions which it uses for storing most of its data:[45]

  • Protocol Buffers – "Google's lingua franca for data",[46] a binary serialization format which is widely used within the company.
  • SSTable (Sorted Strings Table) – a persistent, ordered, immutable map from keys to values, where both keys and values are arbitrary byte strings. It is also used as one of the building blocks of Bigtable.[47]
  • RecordIO – a sequence of variable sized records.[45][48][49]

Software Development Practices

Most operations are read-only. When an update is required, queries are redirected to other servers, so as to simplify consistency issues. Queries are divided into sub-queries, where those sub-queries may be sent to different ducts in parallel, thus reducing the latency time.[18]

To lessen the effects of unavoidable hardware failure, software is designed to be fault tolerant. Thus, when a system goes down, data is still available on other servers, which increases reliability.

Search infrastructure


Like most search engines, Google indexes documents by building a data structure known as inverted index. Such an index obtains a list of documents by a query word. The index is very large due to the number of documents stored in the servers.[21]

The index is partitioned by document IDs into many pieces called shards. Each shard is replicated onto multiple servers. Initially, the index was being served from hard disk drives, as is done in traditional information retrieval (IR) systems. Google dealt with the increasing query volume by increasing number of replicas of each shard and thus increasing number of servers. Soon they found that they had enough servers to keep a copy of the whole index in main memory (although with low replication or no replication at all), and in early 2001 Google switched to an in-memory index system. This switch "radically changed many design parameters" of their search system, and allowed for a significant increase in throughput and a large decrease in latency of queries.[50]

In June 2010, Google rolled out a next-generation indexing and serving system called "Caffeine" which can continuously crawl and update the search index. Previously, Google updated its search index in batches using a series of MapReduce jobs. The index was separated into several layers, some of which were updated faster than the others, and the main layer wouldn't be updated for as long as two weeks. With Caffeine the entire index is updated incrementally on a continuous basis. Later Google revealed a distributed data processing system called "Percolator"[51] which is said to be the basis of Caffeine indexing system.[43][52]

Server types

Google's server infrastructure is divided into several types, each assigned to a different purpose:[18][21][53][54][55]

  • Web servers coordinate the execution of queries sent by users, then format the result into an HTML page. The execution consists of sending queries to index servers, merging the results, computing their rank, retrieving a summary for each hit (using the document server), asking for suggestions from the spelling servers, and finally getting a list of advertisements from the ad server.
  • Data-gathering servers are permanently dedicated to spidering the Web. Google's web crawler is known as GoogleBot. They update the index and document databases and apply Google's algorithms to assign ranks to pages.
  • Each index server contains a set of index shards. They return a list of document IDs ("docid"), such that documents corresponding to a certain docid contain the query word. These servers need less disk space, but suffer the greatest CPU workload.
  • Document servers store documents. Each document is stored on dozens of document servers. When performing a search, a document server returns a summary for the document based on query words. They can also fetch the complete document when asked. These servers need more disk space.
  • Ad servers manage advertisements offered by services like AdWords and AdSense.
  • Spelling servers make suggestions about the spelling of queries.


  1. ^ "Google data centers, locations". Google. Retrieved 21 July 2014. 
  2. ^ https://www.google.com/about/datacenters/inside/locations/jackson-county/
  3. ^ ""Google Stanford Hardware"". Archived from the original on February 9, 1999. Retrieved 2017-03-23.  . Stanford University (provided by Internet Archive). Retrieved on July 10, 2006.
  4. ^ "Which Linux distribution does Google run on its production servers? - Quora". www.quora.com. Retrieved 2017-06-09. 
  5. ^ Merlin, Marc (2013). "Case Study: Live upgrading many thousand of servers from an ancient Red Hat distribution to a 10 year newer Debian based one" (PDF). Linux Foundation. Retrieved 2017-06-09. 
  6. ^ Tawfik Jelassi; Albrecht Enders (2004). "Case study 16 — Google". Strategies for E-business. Pearson Education. p. 424. ISBN 978-0-273-68840-2. 
  7. ^ a b Computer Architecture, Fifth Edition: A Quantitative Approach, ISBN 978-0123838728; Chapter Six; 6.7 "A Google Warehouse-Scale Computer" page 471 "Designing motherboards that only need a single 12-volt supply so that the UPS function could be supplied by standard batteries associated with each server"
  8. ^ Google's secret power supplies on YouTube
  9. ^ Google on-server 12V UPS, 1 April 2009.
  10. ^ Google Green infographics
  11. ^ Analytics Press Growth in data center electricity use 2005 to 2010
  12. ^ Google Surpasses Supercomputer Community, Unnoticed?, May 20, 2008.
  13. ^ "Fiber Optic Communication Technologies: What's Needed for Datacenter Network Operations", Research, Google 
  14. ^ "FTTH look ahead — technologies & architectures", Research, Google 
  15. ^ James Pearn. How many servers does Google have?. plus.google.com. 
  16. ^ "kumara ASN15169", Peering DB 
  17. ^ "Urs Holzle", Speakers, Open Network Summit 
  18. ^ a b c Web Search for a Planet: The Google Cluster Architecture (Luiz André Barroso, Jeffrey Dean, Urs Hölzle)
  19. ^ Warehouse size computers
  20. ^ Denis Abt High Performance Datacenter Networks: Architectures, Algorithms, and Opportunities
  21. ^ a b c Fiach Reid (2004). "Case Study: The Google search engine". Network Programming in .NET. Digital Press. pp. 251–253. ISBN 978-1-55558-315-6. 
  22. ^ a b Rich Miller (March 27, 2008). "Google Data Center FAQ". Data Center Knowledge. Retrieved 2009-03-15. 
  23. ^ Brett Winterford (March 5, 2010). "Found: Google Australia's secret data network". ITNews. Retrieved 2010-03-20. 
  24. ^ Google "The Dalles, Oregon Data Center" Retrieved on January 3, 2011.
  25. ^ Markoff, John; Hansell, Saul. "Hiding in Plain Sight, Google Seeks More Power." New York Times. June 14, 2006. Retrieved on October 15, 2008.
  26. ^ Strand, Ginger. "Google Data Center" Harper's Magazine. March 2008. Retrieved on October 15, 2008. Archived August 30, 2012, at the Wayback Machine.
  27. ^ "Stora Enso divests Summa Mill premises in Finland for EUR 40 million". Stora Enso. 2009-02-12. Retrieved 2009-12-02. 
  28. ^ [dead link] "Stooora yllätys: Google ostaa Summan tehtaan". Kauppalehti (in Finnish). Helsinki. 2009-02-12. Retrieved 2009-02-12. 
  29. ^ "Google investoi 200 miljoonaa euroa Haminaan". Taloussanomat (in Finnish). Helsinki. 2009-02-04. Retrieved 2009-03-15. 
  30. ^ Finland – First Choice for Siting Your Cloud Computing Data Center. Archived 2013-07-06 at the Wayback Machine. Accessed 4 August 2010.
  31. ^ https://www.theregister.co.uk/2009/04/10/google_data_center_video
  32. ^ "United States Patent: 7278273". Patft.uspto.gov. Retrieved 2012-02-17. 
  33. ^ Mark Levene (2005). An Introduction to Search Engines and Web Navigation. Pearson Education. p. 73. ISBN 978-0-321-30677-7. 
  34. ^ "Python Status Update". Artima. 2006-01-10. Retrieved 2012-02-17. 
  35. ^ "Warning". Panela. Blog-city. Archived from the original on December 28, 2011. Retrieved 2012-02-17. 
  36. ^ "Quotes about Python". Python. Retrieved 2012-02-17. 
  37. ^ "Google Architecture". High Scalability. 2008-11-22. Retrieved 2012-02-17. 
  38. ^ a b c Fikes, Andrew (July 29, 2010), "Storage Architecture and Challenges", TechTalk (PDF), Google 
  39. ^ "Colossus: Successor to the Google File System (GFS)". SysTutorials. 2012-11-29. Retrieved 2016-05-10. 
  40. ^ Dean, Jeffrey 'Jeff' (2009), "Design, Lessons and Advice from Building Large Distributed Systems", Ladis (keynote talk presentation), Cornell 
  41. ^ Shute, Jeffrey 'Jeff'; Oancea, Mircea; Ellner, Stephan; Handy, Benjamin 'Ben'; Rollins, Eric; Samwel, Bart; Vingralek, Radek; Whipkey, Chad; Chen, Xin; Jegerlehner, Beat; Littlefield, Kyle; Tong, Phoenix (2012), "F1 — the Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business", Research (presentation), Sigmod: Google 
  42. ^ "Anna Patterson – CrunchBase Profile". Crunchbase.com. Retrieved 2012-02-17. 
  43. ^ a b The Register. Google Caffeine jolts worldwide search machine
  44. ^ "Google official release note". Google.com. Retrieved 2013-09-28. 
  45. ^ a b "Google Developing Caffeine Storage System TechWeekEurope UK". Eweekeurope.co.uk. 2009-08-18. Retrieved 2012-02-17. 
  46. ^ "Developer Guide – Protocol Buffers – Google Code". Code.google.com. Retrieved 2012-02-17. 
  47. ^ [1]
  48. ^ windley on June 24, 2008 1:10 PM (2008-06-24). "Phil Windley's Technometria Velocity 08: Storage at Scale". Windley.com. Retrieved 2012-02-17. 
  49. ^ "Message limit – Protocol Buffers Google Groups". Groups.google.com. Retrieved 2012-02-17. 
  50. ^ "Jeff Dean's keynote at WSDM 2009" (PDF). Retrieved 2012-02-17. 
  51. ^ Daniel Peng, Frank Dabek. (2010). Large-scale Incremental Processing Using Distributed Transactions and Notifications. Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation.
  52. ^ The Register. Google Percolator – global search jolt sans MapReduce comedown
  53. ^ Chandler Evans (2008). "Google Platform". Future of Google Earth. Madison Publishing Company. p. 299. ISBN 978-1-4196-8903-1. 
  54. ^ Chris Sherman (2005). "How Google Works". Google Power. McGraw-Hill Professional. pp. 10–11. ISBN 978-0-07-225787-8. 
  55. ^ Michael Miller (2007). "How Google Works". Googlepedia. Pearson Technology Group. pp. 17–18. ISBN 978-0-7897-3639-0. 

Further reading

External links