Google has revealed the root cause of the [1]outage that disrupted services at its europe-west2-a zone, based in London, during a recent heatwave.

"One of the datacenters that hosts zone europe-west2-a could not maintain a safe operating temperature due to a simultaneous failure of multiple, redundant cooling systems combined with the extraordinarily high outside temperatures," states Google's [2]incident report .

The report doesn't explain why the cooling systems failed, but does say Google first became aware of "an issue affecting two cooling systems in one of the datacenters that hosts europe-west2-a on Tuesday, 19 July 2022 at 06:33 US/Pacific and began an investigation."

We inadvertently modified traffic routing for internal services to avoid all three zones in the europe-west2

The Register has checked [3]weather records for the day in question: just before Google noticed cooling problems – 2:20PM in London – the temperature was 102°F/39°C.

That's a level of heat that's manageable in places where datacenter designers know that sort of temperature can be expected. But as July 19 was the hottest day on record in London, the UK capital is not such a place.

[4]

Engineers worked on mitigations to the failed cooling systems from 07:02 Pacific, but their efforts failed.

[5]

[6]

London temperatures remained above 95°F/35°C deep into the evening and at around 6PM in London Google engineers "powered down this part of the zone to prevent an even longer outage or damage to machines."

In other words, they shut the zone down to save it from a worse outage.

[7]After config error takes down Rogers, it promises to spend billions on reliability

[8]Couldn't connect to West Europe SQL Databases last week? Blame operator error

[9]Microsoft reviews M365 resilience after Indian outage

Chaos kicked in after the shutdown decision. Closing the datacenter meant "Compute Engine terminated all VMs in the impacted datacenter, representing approximately 35 percent of the VMs in the europe-west2-a zone."

Google also made a mess of trying to provide redundancy.

[10]

"At the start of the incident, we inadvertently modified traffic routing for internal services to avoid all three zones in the europe-west2 region, rather than just the impacted europe-west2-a zone."

So while only part of europe-west2-a zone was down, Google told itself to ignore working resources.

Google and other cloud vendors advise users to employ multiple zones to improve resilience. Google's error, therefore, went against its own advice.

[11]

The cooling system came back online at 14:13 Pacific – past 10PM in London when temperatures were still sizzling.

"Google engineers are actively conducting a detailed analysis of the cooling system failure that triggered this incident," the report states.

The search giant and cloud aspirant has also pledged to:

Investigate and develop more advanced methods to progressively decrease the thermal load within a single datacenter space, reducing the probability that a full shutdown is required;

Examine procedures, tooling, and automated recovery systems for gaps to substantially improve recovery times in the future;

Audit cooling system equipment and standards across the datacenters that house Google Cloud globally.

The incident report also offers a detailed account of the incident's impact on Google cloud services, and offers the figure of 18 hours, 23 minutes as the duration of the outage – plus a "long tail duration" of 35 hours, 15 minutes before things were back to normal. ®

Get our [12]Tech Resources



[1] https://www.theregister.com/2022/07/19/google_oracle_cloud/

[2] https://status.cloud.google.com/incidents/fmEL9i2fArADKawkZAa2

[3] https://www.wunderground.com/history/daily/gb/london/EGLC/date/2022-7-19

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YuekWr@izQlvRp2cM-OvCAAAAJE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YuekWr@izQlvRp2cM-OvCAAAAJE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YuekWr@izQlvRp2cM-OvCAAAAJE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://www.theregister.com/2022/07/25/canadian_isp_rogers_outage/

[8] https://www.theregister.com/2022/07/25/azue_sql_post_mortem/

[9] https://www.theregister.com/2022/07/24/microsoft_revisits_m365_resilience_arrangements/

[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YuekWr@izQlvRp2cM-OvCAAAAJE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offprem/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YuekWr@izQlvRp2cM-OvCAAAAJE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[12] https://whitepapers.theregister.com/