I have already written several posting on Google data centers, but it does not hurt to post a new one when some new interesting material pops up. Take a virtual tour of Google’s Oregon data center article tells that the GoogleDalles data center in Oregon is open for a digital tour. Google is trying to entice more customers to its cloud services, to compete better with Amazon Web Services and Microsoft, and showing off its advanced facilities might help with that goal.
Take a virtual tour of Google’s Oregon data center article included a very nice
Google Data Center 360° Tour video that is best viewed in a virtual reality headset (like Google Cardboard) but works OK on the computer screen. What the incredibile video!
7 Comments
Tomi Engdahl says:
Simon Sharwood / The Register:
Google publishes paper detailing its cloud security strategy, including the deployment of custom chips on servers and peripherals — Even the servers it colocates (!) says new docu revealing Alphabet sub’s security secrets — Google has published a Infrastructure Security Design Overview …
Google reveals its servers all contain custom security silicon
Even the servers it colocates (!) says new doc detailing Alphabet sub’s security secrets
http://www.theregister.co.uk/2017/01/16/google_reveals_its_servers_all_contain_custom_security_silicon/
Google has published a Infrastructure Security Design Overview that explains how it secures the cloud it uses for its own operations and for public cloud services.
Revealed last Friday, the document outlines six layers of security and reveals some interesting factoids about the Alphabet subsidiary’s operations, none more so than the revelation that “we also design custom chips, including a hardware security chip that is currently being deployed on both servers and peripherals. These chips allow us to securely identify and authenticate legitimate Google devices at the hardware level.”
Google Infrastructure Security Design Overview
https://cloud.google.com/security/security-design/
The content contained herein is correct as of January 2017, and represents the status quo as of the time it was written. Google’s security policies and systems may change going forward, as we continually improve protection for our customers.
CIO-level summary
Google has a global scale technical infrastructure designed to provide security through the entire information processing lifecycle at Google. This infrastructure provides secure deployment of services, secure storage of data with end user privacy safeguards, secure communications between services, secure and private communication with customers over the internet, and safe operation by administrators.
Google uses this infrastructure to build its internet services, including both consumer services such as Search, Gmail, and Photos, and enterprise services such as G Suite and Google Cloud Platform.
The security of the infrastructure is designed in progressive layers starting from the physical security of data centers, continuing on to the security of the hardware and software that underlie the infrastructure, and finally, the technical constraints and processes in place to support operational security.
Google invests heavily in securing its infrastructure with many hundreds of engineers dedicated to security and privacy distributed across all of Google, including many who are recognized industry authorities.
Tomi Engdahl says:
Google Shares Details of Its Security Infrastructure
http://www.securityweek.com/google-shares-details-its-security-infrastructure
Google Designs Its Own Custom Hardware Security Chips to Securely Identify and Authenticate Legitimate Google Devices at the Hardware Level
Google recently shared details on the security infrastructure that protects its data centers that house both its existing services and its growing Google Cloud Platform (GCP).
Tomi Engdahl says:
Is Google’s Renewable Energy Plan What It Seems?
http://electronicdesign.com/power/google-s-renewable-energy-plan-what-it-seems?NL=ED-003&Issue=ED-003_20170123_ED-003_225&sfvc4enews=42&cl=article_2_b&utm_rid=CPG05000002750211&utm_campaign=9364&utm_medium=email&elq2=7f21682d9ee5484881a340680b229877
Google announced that it will purchase enough renewable energy to match 100% of its operations in 2017 in hopes that regulated utilities will eventually offer better options.
When I first heard about Google’s latest announcement, I thought the company was going to rely completely on renewable energy to directly energize its data centers. I was surprised by such an achievement, as data centers operate 24/7 and wind and the sun are not constantly available resources. But it turned out that is not the case—yet. Google’s renewable energy plan is just an excuse for all the greenhouse gas (GHG) emissions that it will keep generating as it mostly energizes its data centers with fossil fuels.
Tomi Engdahl says:
Google routing blunder sent Japan’s Internet dark on Friday
Another big BGP blunder
https://www.theregister.co.uk/2017/08/27/google_routing_blunder_sent_japans_internet_dark/
Last Friday, someone in Google fat-thumbed a border gateway protocol (GGP) advertisement and sent Japanese Internet traffic into a black hole.
The trouble began when The Chocolate Factory “leaked” a big route table to Verizon, the result of which was traffic from Japanese giants like NTT and KDDI was sent to Google on the expectation it would be treated as transit.
Since Google doesn’t provide transit services, as BGP Mon explains, that traffic either filled a link beyond its capacity, or hit an access control list, and disappeared.
The outage in Japan only lasted a couple of hours, but was so severe that Japan Times reports the country’s Internal Affairs and Communications ministries want carriers to report on what went wrong.
BGP Mon dissects what went wrong here, reporting that more than 135,000 prefixes on the Google-Verizon path were announced when they shouldn’t have been.
Since it leaked what the monitors call “a full table” to Verizon, the fat-thumb error also provided a “peek into what Google’s peering relationships look like and how their peers traffic engineer towards Google”.
BGP leak causing Internet outages in Japan and beyond.
https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/
A closer look at our data shows not only BGP hijack incidents but also a high number of BGP leak events. A random example is this one: 171.5.0.0/17 announced by AS45629 (Jastel out of Thailand), which all of a sudden became reachable with Google as a provider for Jastel.
In the example above we can see how Google accidentally became a transit provider for Jastel by announcing peer prefixes to Verizon. Since verizon would select this path to Jastel it would have sent traffic for this network towards Google. Not only did this happen for Jastel, but thousands of other networks as well.
Google is not a transit provider and traffic for 3rd party networks should never go through the Google network. Jastel has a few upstream providers and with the addition of Google and Verizon to the path, it’s likely only Verizon customers (which is still significant) would have chosen this path and only those that had no other alternative or specifically prefered Verizon over shorter paths. However this is just the start.
A word about traffic engineering
Google is one of the largest (CDN) networks in the world. It has an open peering policy and is extremely well connected with many peers. It’s also the source of a large amount of traffic with popular websites such as Youtube, Google search, Google Drive, Google Compute, etc. As a result many networks exchange a significant volume of traffic with just Google and those with direct peering with Google will want to make sure Google picks the right peering link with them. So as result large networks will start to deploy traffic engineering tricks to make sure traffic flows over the correct peering links with Google. The most powerful trick in the book is to start de-aggregating and announce more specifics. This means no matter the AS path length or whatever local-pref Google sets locally, the more specific prefixes are always preferred.
A unique insight into Google’s network
Since Google essentially leaked a full table towards Verizon, we get to peek into what Google’s peering relationships look like and how their peers traffic engineer towards Google. Analyzing this data set we find many more specific prefixes. Meaning prefixes that are not normally seen in the global Internet routing table (DFZ) and only made visible to Google for traffic engineering requirements.
Tomi Engdahl says:
Google Details How It Protects Data Within Its Infrastructure
http://www.securityweek.com/google-details-how-it-protects-data-within-its-infrastructure
Google has decided to share detailed information on how it protects service-to-service communications within its infrastructure at the application layer and the the system it uses for data protection.
Called Application Layer Transport Security (ALTS), the technology was designed to authenticate communication between Google services and keep data protected while in transit. When sent to Google, data is protected using secure communication protocols such as TLS (Transport Layer Security).
According to the Web search giant, it started development of ALTS in 2007, when TLS was bundled with support protocols that did not satisfy the company’s minimum security standards. Thus, the company found it more suitable to design its own security solution than patch an existing system.
Application Layer Transport Security
https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/
CIO-level summary
Google’s Application Layer Transport Security (ALTS) is a mutual authentication and transport encryption system developed by Google and typically used for securing Remote Procedure Call (RPC) communications within Google’s infrastructure. ALTS is similar in concept to mutually authenticated TLS but has been designed and optimized to meet the needs of Google’s datacenter environments.
The ALTS trust model has been tailored for cloud-like containerized applications. Identities are bound to entities instead of to a specific server name or host. This trust model facilitates seamless microservice replication, load balancing, and rescheduling across hosts.
ALTS relies on two protocols: the Handshake protocol (with session resumption) and the Record protocol. These protocols govern how sessions are established, authenticated, encrypted, and resumed.
ALTS is a custom transport layer security solution that we use at Google. We have tailored ALTS to our production environment, so there are some tradeoffs between ALTS and the industry standard, TLS. More details can be found in the Tradeoffs section.
Tomi Engdahl says:
Google just put an AI in charge of keeping its data centers cool
https://www.zdnet.com/article/google-just-put-an-ai-in-charge-of-keeping-its-data-centers-cool/
DeepMind’s neural networks will tweak data center conditions to cut power usage.
Google is putting an artificial.intelligence system in charge of its data center cooling after the system proved it could cut energy use.
Now Google and its AI company DeepMind are taking the project further; instead of recommendations being implemented by human staff, the AI system is directly controlling cooling in the data centers that run services including Google Search, Gmail and YouTube.
“This first-of-its-kind cloud-based control system is now safely delivering energy savings in multiple Google data centers,” Google said.
Safety-first AI for autonomous data center cooling and industrial control
https://www.blog.google/inside-google/infrastructure/safety-first-ai-autonomous-data-center-cooling-and-industrial-control/
Tomi Engdahl says:
With a $22B run rate, does it matter if Google Cloud still loses money?
https://techcrunch.com/2022/02/02/with-a-22b-run-rate-does-it-matter-if-google-cloud-still-loses-money/