深度解析Google雷击事故背后的技术架构

云计算
,发生故障并不可怕,可怕的是故障造成的数据丢失,给用户造成恶劣的影响。谷歌此次数据中心遭遇了重大雷击事故,但却仅有0.000001%的数据丢失,其迅速反应能力依旧值得肯定。

日前,比利时布鲁塞尔西南郊的St.Ghislaina小镇遭遇了强雷电天气,当时的雷电天气总计有四次击中了当地一处电力设施,并导致主要电力系统的供电中断,而谷歌的数据中心恰好就位于该电力设施的附近。其结果是,谷歌数据中心服务器中大约0.000001%的数据遭到了永久删除。

[[146480]]

由于谷歌当地的数据中心主要被用于驱动谷歌云计算引擎(Google Compute Engine)服务,这一引擎主要都是用于商用,因此包括谷歌邮箱、Youtube、Google Drive这些消费者层面的服务都没有受到影响。

一家名为“Azendoo”的法国初创企业负责人查尔斯-大卫(Charles David)表示,因为谷歌数据中心遭遇雷击,自己公司的服务遭遇了长达12小时的中断,幸运的是,Azendoo将自己的数据在另一处谷歌数据中心进行过备份。

接下来就从谷歌的官方声明来看看本次故障到底是什么情况。从谷歌的故障声明来看,在受到雷击后第一时间谷歌的团队就发出公告,披露事故处理情况以及下次公告时间,虽然是一连串的休息中,但是还是做到了信息透明,让用户心里有底。

 

深度解析Google雷击事故背后的技术架构

OK,扯淡结束,下面探探本次有些磁盘数据永久丢失的事情。据谷歌称是因为掉电,导致小部分在掉电时操作的数据未能完全保存。

分布式UPS功与过

谷歌曾在2011年公布了其上一年2的数据中心耗电情况。根据谷歌提供的数据,这家互联网公司一年的电力消耗量高达近23亿千瓦时,比21万个美国家庭一年的用电量加一块儿还要多。但是谷歌共拥有近90万台服务器,约占全球3%的服务器数量,但只使用全球数据中心1%的电力,显然谷歌数据中心的运作比其他数据中心更为高效,节省了大量的资金投入。

其总体思路是采用中压配电输送到机房周边,靠近负载就近经变压器降压成低压,再通过低压母线输电到机房内的IT机柜上。模块化的户外型变压器及低压配电柜环绕机房周边,采用集装箱型的柴油发电机组作为变配电的供电投切备份,柴发风管直立到屋顶上排风。经过变压器变压后的市电通过母线槽或者线缆直连到机房内的机柜上方,直接给自带分布式UPS的服务器供电。

Google的12V挂电池方案采用分布式电源加分布式电池作掉电备份,原理是每个服务器带一个电源并配一个铅酸电池,市电正常时候市电直接给设备供电并给电池充满电,市电中断时候电池放电备份几分钟,直至柴发起来继续供电。有两个显著特点:

1、电源产自中国,输出参数为13.65V &20.5A,这个服务器的总输出功率不会超过250w。

2、关于电池,免维护铅酸蓄电池无疑,从公开的资料上其容量只有3.2ah,充其量只能够维持3、4分钟以内的服务器掉电保护时间。

该方案的核心技术是电池管理及切换控制,实现供电效率达到99.99%。当市电停电后,直接挂接在12V输出上的电池短时放电,直至室外的柴发启动恢复服务器电源带载。电池参与放电的时间基本不到一两分钟,因此电池的容量很小,大约只有3.2Ah,备电时间远远小于传统数据中心15到30分钟的电池备电需求,因此对柴发的启动要求很高。

我们前面知道谷歌的柴发是模块化直接安装在变压器旁边的,很有可能是低压柴发,其启动很快。而且每台柴发对应一个变压器,没有复杂的柴发并机以及启动时序等问题,因此正常情况下柴发启动时间可以控制在十几秒以内,一两分钟的电池备电时间基本上是够了,但这对运维水平要求就非常高了。当然谷歌的软件架构和业务备份方面也足够强壮,甚至部分设备停电也不会影响到业务正常运行,因此只有强大的技术实力才可以采用这种供电架构。

但是本次谷歌就相当悲催,某个电力模块被直接击中四次(概率相当于你出门买彩票中500万的事情连续发在一个礼拜),导致UPS电力耗尽,因此导致设备掉电,损失了部分数据。

在随后发布的官方事故报告中,谷歌表示自己需要为这一事件负上全部责任,谷歌表示企业将所有数据存储在单一数据中心会不可避免的在遭遇数据中心级别意外时候面临巨大风险,因此也鼓励受对可用性要求较高的企业用户考虑将数据备份到其他谷歌存储服务中。

“尽管这一事件看起来并不严重,但却清晰的表明了企业将数据全部存储在单一数据中心所面临的巨大风险。”Proper Villains公司合伙人阿隆-图比克图比克说道。

说这些并不是帮谷歌去洗脱责任,而是希望大家可以从一个平常心,从技术角度来看待这个问题。因为,发生故障并不可怕,可怕的是故障造成的数据丢失,给用户造成恶劣的影响。谷歌此次数据中心遭遇了重大雷击事故,但却仅有0.000001%的数据丢失,其迅速反应能力依旧值得肯定,谷歌云计算引擎团队理应为此感到骄傲。
 

责任编辑:Ophira 来源: 科技百分百微信号
相关推荐

2009-01-04 09:26:44

架构Google服务器

2013-07-30 12:29:19

Google App Google技术Engine

2023-09-28 21:46:10

2011-04-15 17:43:15

Google App Google

2012-06-14 09:38:00

存储虚拟化

2015-01-22 10:36:40

大数据

2016-07-28 22:57:33

云计算Google

2012-06-19 09:53:55

Google数据

2013-08-14 11:14:20

开源Google

2024-02-22 14:06:39

C++指针开发

2009-06-10 09:21:45

Google Wave架构

2011-07-22 13:55:48

架构

2012-08-27 10:56:41

2018-11-27 16:11:01

阿里云Redis数据库

2021-05-07 09:46:39

云计算视图计算

2011-12-07 10:31:36

Google新闻

2016-12-19 11:33:26

2020-11-17 17:54:33

Google 开发者技术

2011-01-06 16:36:05

云计算Google

2016-11-18 12:13:04

数据技术双11大数据
点赞
收藏

51CTO技术栈公众号