Google对EB级别数据的备份恢复分享

Raymond Blum领导着一个由网站可靠性工程师(Site Reliability Engineer, SRE)所组成的团队负责维护Google神秘的数据资源。尽管Google从来没有透露过这些数据的量到底有多大，不过据消息称，虽然没有达到令人咋舌的YB级别，不过也达到了几个EB。光是GMail的数据就差不多达到了EB级别。在这个视频 NYC Tech Talk Series- How Google Backs Up the Internet Along With Exabytes Of Other Data ( Google Tech Talk  October 22, 2013)中，Blum解释了常规备份策略对Google无效的原因，那就是这些策略随着备份规模的扩大需要等量的投入。如果备份两倍的数据量需要两倍的时间、能源、存储空间等投入的话，那么这种备份策略就不是可扩展的。所以必须得提升备份策略的效率使得数据备份能力永远领先于备份需求。所以，针对备份1EB和2EB数据的不同需求必须有着不同的策略。这个演讲就是关于Google怎么做到这一点的。Blum的演讲幽默风趣，信息量大，值得一看。

相关背景：2011 Gmail故障

以下是演讲重点及个人笔记：

1. 终极原则是保证百分之百的数据可用性，不能出现数据丢失

• 即便是2011是Gmail宕机事件都没有丢失数据，数据的存储需要经过一个技术栈，这个栈中得每个层级都很关键，包括人的这一层。
• 如果你丢失了2GB文件中的200KB数据，从统计的角度来说是不错的，但是对数据而言可能就完全损坏了。
• 数据可用性比访问可用性更重要，系统宕机不是世界末日，丢失数据才是。
• 应当精良保证数据与其备份满足介质损坏隔离、存储层隔离、应用层隔离以及地理隔离。

2. 可用性与完整性是首要保障目标

• 对于Google engineers, BigTable, GFS以及Colossus而言数据的可用性与完整性都是首要保障目标。各系统各司其职不断监测及修复数据中的瑕疵与错误以保证可用性与完整性。

3. 数据备份不是最终目的，能够正常恢复才是

• 仅仅备份数据是无用的。你真正需要关心的是数据恢复。备份是为了实现数据恢复这个奢侈的功能所必须付出的代价。所以为了让数据恢复过程尽可能简单，只好让数据备份承担更多，更复杂的任务。
• 在需要使用数据之前就及时发现可能的问题。持续的恢复尝试。不断地随机选择%5的备份数据进行恢复并与原数据进行比较，在数据丢失前找出可能的备份遗漏。

4. 冗余是保证系统鲁棒性的重要条件，但冗余也存在一些问题

• 有人总是质疑Google的东西总是出问题，Blum说那是扯淡，这就跟人体的新陈代谢一样。Google从不奢望造出来的东西不会出问题，因为这是自然法则。
• 冗余性使得集群相比单台质量很好的机器更具稳定性。但台机器可能会被灾难摧毁，不过将普通机器分散到50个不同的地域则没那么容易被摧毁了。
• 在不同软件栈、不同地域、不同时间点都做到冗余，不要让数据直接通过栈，保证每个层级都保留有相应地数据，一旦某层级的数据丢失，起码其他层级还有重复的数据。
• 大规模并行系统更容易出现数据丢失，运行于3万台机器上的MapReduce在遇到bug之前是很棒的，但是一旦遇到bug，这会被放大到形成灾难。
• 本地备份并不能有效保证数据安全，如果己方发生自然灾害，那数据中心内的备份机制(如RAID)并不能保护数据安全。
• Google文件系统(GFS)将RAID提升了一个等级，这个技术Google直到一年前都还在用。这个技术使得同时将数据写入分布于不同城市的多个数据中心，所以只需要其中的一小部分就能恢复整个数据。
• 数据冗余对不同地域间的数据保存很有效。而数据实时拷贝则对于某些希望保持数据同步的应用场景很有效。

5. 保证数据备份的多样性也是非常重要的

• 多份副本的确对大部分宕机事件很有效。例如一颗陨石砸中了数据中心，而你正好有一个副本在不同地域的另一个数据中心，数据就得以保存了。但如果你的存储栈有一个bug，异地复制N份并不能阻止bug扩散到所有的副本。而现实中砸中数据中心的陨石的数量远远少于代码中的bug，用户错误以及写缓冲崩溃等故障。
• 如果你担心数据放在一个地方不安全，那么多找几个地方存放。如果你担心用户会造成系统异常，那么对用户的交互设置隔离级别。如果你希望能够避免单个软件故障带来的影响，那么使用多个软件。利用多个存储提供商提供的服务可以有效避免单个服务商故障对业务的影响。

6. Google利用磁带来进行数据备份

• 磁带的存储能力遵循摩尔定律。
• 磁带存储加强数据备份的多样性，设想如果针对SATA磁盘的驱动有个bug，那磁带能够保护你的数据。因为不同的设备使用不同的软件。
• 将磁带数据加密意味着别有用心的人将耗费大量时间来解密以获取数据。
• 什么东西都可能会坏，使用磁盘进行备份时，当磁盘损坏时你就能知道因为你能够监控它。但如果使用磁带进行备份损坏就不能及时发现，因为只有在你使用数据的时候才会发现磁带损坏了。所以在使用之前应该对磁带进行测试。

7. 备份规模的扩展是个大问题，不能让扩展的代价伴随备份数据量线性增长

• 数据中心需要考虑几个问题：1.单个节点的备份能力是否是无限的？2.所有的备份是否都按照地域做了集群划分？3.传输数据的带宽如何?4.需要多大带宽来满足金钱驱动的业务需求？
• 综合考虑各种必需的代价。不是每个节点都有备份设备，必需通过网络对备份能力做合理的划分。
• 不能让扩展代价线性增长。不能因为备份需求扩大了100倍就准备100倍相应的人力、物力资源。需要寻找事半功倍的方法。自动化是提升利用率和效率的主要方法。

8. 让一切都自动化运行

• 作业必须实现自动化，对于需要时常备份和恢复的服务来说，系统必须能够满足：备份、恢复、集成测试等过程都是通过作业计划进行调度。当故障发生时也能够被自动处理。
• 为可能出现的错误准备预案，在错误率发生变化时及时报警。
• 作为管理员来说，不需要关心异常报告之外的细节操作。可能偶尔会关心下平均错误率，但是除非系统报告错误率发生很大变化可能是发生了异常，否则不需要去亲自干预。
• 管理员不应该去关心日常的状态操作，为系统准备好自动化操作的相关工具、接口等资源，然后让系统来完成诸如检测，固件升级等操作，管理员在后台监视可能的异常状态即可。
• 随着任务的增长保持效率的提升以满足备份任务增长的需要。
• 数据恢复的顺序通过优先级来划分。当前紧要的数据(如Gmail收件箱和发送邮件)必须先于非紧要数据(如邮件归档)恢复。活跃用户的数据必须先于非活跃用户的数据恢复。

9. 整个备份恢复系统必须被看做一个统一的整体

• 不要想着只在某个数据中心做备份，因为随着数据中心的发展，其规模都应该需要合理的扩展。
• 将备份系统看做全局范围联动的系统，当备份发生时，可能涉及全局系统。
• 备份的地域隔离应该是由调度算法自动完成的，用户不应该知道数据被备份到了什么地方。
• 如果网络情况允许，备份能力应该自由流转，而不应该被地域所限制。

10. 灾难恢复测试(Disaster Recovery Testing)

• 每个N个月就会有一次灾难演练，模拟每个层面的应对措施。
• 怎么做才能使得不论灾难造成多大的破坏都能够使得数据能够恢复，这是一个值得思考的问题。
• 通过测试找到基础设施，管理运维方面的漏洞。
• 提供补给链冗余策略。

11. 在充分相信团队成员以及责任被明确划分的前提下，一个巨型组织是能够有效运转的。

• 信任团队成员能够清楚他们的职责。
• 确保组织层面之间能够很好的沟通，接口良好。