Cloud Storage 如何提供 11 个 9 的持久性，以及您如何从中获得帮助

任何存储解决方案最基本的方面之一就是持久性——您的数据应该如何防止丢失或损坏？这对于云环境来说尤为重要。 Cloud Storage 的设计年持久性至少为 99.999999999%，即 11 个 9 。这意味着即使有 10 亿个对象，经过 100 年后您也不会丢失其中的一个。

我们非常重视实现我们在持久性方面的目标。在本篇文章中，我们将探讨保护 Cloud Storage 数据的集中主要方式。同时，数据保护最终将会是一项需要共担的责任（最常见的数据丢失原因是用户或存储管理员的意外删除），因此我们将提供最佳实践来帮助您保护数据免受自然灾害与用户的错误。

物理持久性

大多数人在防止网络、服务器与存储硬件故障的背景下来考虑持久性。

在 Google ，我们的理念是软件最终将成为防止硬件故障的最佳方式。这种方式让我们能够以具有吸引力的成本来获得更高的可靠性，而不用依赖奇特的硬件解决方案。我们假设硬件会一直出现故障——因为他们确实如此！但这并不意味着持久性必然会受到影响。

为了将对象存储在 Cloud Storage 中，我们将其分解为多个“数据块”，并将它们放置在配备有不同电源的多台服务器上。我们还为冗余创建了许多“代码块”。当发生硬件故障（例如服务器、磁盘）时，我们使用数据和代码块重建整个对象。这种技术被称为纠删码。此外，我们存储了查找和读取对象所需的元数据的多个副本，以便在一个或多个元数据服务器出现故障时，我们能够继续访问对象。

其中的关键要求是，在确认成功写入之前，我们始终跨多个可用区以冗余的方式存储数据。我们使用的编码提供了足够的冗余来支持超过 11 个 9 的持久性目标，从而应对硬件故障。一旦数据被成功存储，我们会定期的验证校验和，以保护静态数据免受某些类型的数据错误影响。如果出现校验和不匹配的情况，将使用我们编码中存在的冗余对数据进行自动修复。

最佳实践：使用双区域或多区域位置

这些保护层是让数据规避物理持久性风险的良好方式，但是它们可能无法防止针对一个地区的实质性物理破坏——试想一下战争行为、小行星撞击或是其他大规模的灾难。

Cloud Storage 所提供的 11 个 9 的持久性目标适用于单个区域。为了进一步防范可能摧毁整个区域的自然灾害，请考虑将您最重要的数据存储在双区域或多个区域的存储分区中。这些存储分区会自动实现跨地理区域的数据冗余。使用这些存储分区并不需要对您的应用程序进行额外的配置或是修改 API ，这种方式却可以针对那些虽然非常罕见但还是会潜在发生的灾难性事件提供额外的持久性。作为额外的好处，这些位置类型还可以提供更加显著的高可用性 SLA ，因为即使某个区域暂时无法访问，我们还可以从多个位置以透明的方式为您的对象提供服务。

传输中的持久性

另一类的持久性风险来自于传输中的数据损坏。这可能发生在 Cloud Storage 服务内部跨网络传输数据，或是在向/从 Cloud Storage 上传或下载对象的过程中。

为了防止这类数据损坏的原因， Cloud Storage 在设计时就让传输中的数据始终可以受到校验和保护，并且无一例外。在校验和验证错误的情况下，会根据情况自动重试请求或返回错误。

最佳实践：使用校验和进行上传和下载

虽然 Google Cloud 会对我们在服务中传输的所有 Cloud Storage 对象进行校验，但为了实现端到端的保护，我们建议您在将数据上传到 Cloud Storage 时提供校验，并在下载对象时在客户端上对相关的校验进行验证。

人为引起的持久性风险

可以说，数据丢失的最大风险来源于人为错误——不仅是我们作为服务的开发人员和操作人员所犯的错误，也来自于存储用户所犯的错误！

软件错误可能是数据持久性的最大风险。为了避免 bug 错误造成的持久性损失，我们首先采取措施避免会导致数据损坏或数据擦除的 bug 。然后，我们维护安全措施以快速检测这些类型的 bug ，目的是在持久性退化或演变成为持久性损失之前就捕获它们。

为了预先捕获这些 bug ，我们仅将已通过大量集成测试后的 Cloud Storage 新版本部署到生产环境中。测试过程包括执行各种边缘情况故障场景，例如可用区宕机，并将数据编码和放置 API 的行为与以前的版本进行比较，以筛选回归。

一旦新的软件版本获得批准，我们就会按照可用区分阶段推出升级，升级将从非常受限的初始影响区域开始，然后慢慢增加，直至广泛应用。这样做可以让我们在问题产生重大影响之前发现它们，并且如果在需要的情况下，仍然有额外的数据副本（或足够数量的纠删码块）可以实现数据恢复。如有必要，这些软件在推出时会受到密切监控，并且制定了快速回滚计划。

您还可以做很多的事情来保护您的数据免于丢失。

最佳实践：启用对象版本控制

最常见的数据丢失原因之一是存储管理员或最终用户意外删除数据。当您启用对象版本控制时， Cloud Storage 会保留已删除的对象，以备您在日后有需要时恢复它们。通过配置对象生命周期管理策略，您可以限制版本化对象在永久删除之前保留的时间，以便于更好的控制存储成本。

最佳实践：备份您的数据

Cloud Storage 11 个 9 的持久性目标并不会消除数据备份的需求。例如，需要考虑如果怀有恶意的黑客获取了您的 Cloud Storage 账户访问权限，他们会对您的数据做什么？根据您的目标，备份可能是另一个区域，或另一个云、本地的第二个数据副本，甚至可以是在具备气隙隔离的磁带或磁盘上。

最佳实践：使用数据访问保留策略和审计日志

对于长期数据保留，请使用 Cloud Storage 存储分区锁定功能来设置数据保留策略，并确保可以在特定时间段内锁定数据。这样做可以防止意外修改/删除，并且与数据访问日志结合使用时，可以满足监管与合规性要求，例如 FINRA、SEC 和 CFTC 以及某些医疗保健行业的数据保留规定。

最佳实践：使用基于角色的访问控制策略

您可以通过确保 IAM 数据访问控制策略遵循职责分离和最小权限原则，来限制黑客和意外删除的影响范围。例如，将能够创建存储分区的人与可以删除项目的人分开。

加密密钥和持久性

所有 Cloud Storage 的数据都被设计为在静态和在云中传输时始终进行加密。由于对象在没有加密密钥的情况下无法被读取，因此丢失加密密钥对于持久性来说也是一个重大风险——毕竟，如果您无法读取高度持久化数据，那它们又有什么用呢？使用 Cloud Storage ，您有三种密钥管理选择：1）信任 Google 为您管理加密密钥，2）将客户管理的加密密钥（CMEK 与 Cloud KMS 一起使用，或 3）将客户提供的加密密钥（CSEK）与外部密钥服务器一同使用。

Google 采取与前面所述类似的步骤（包括纠删码和一致性检查）来保护其控制下的加密密钥的持久性。

最佳实践：保护您的加密密钥

通过选择 CMEK 或 CSEK 来管理您的密钥，您可以直接控制并管理您自己的密钥。在这些情况下，您还必须以至少提供 11 个 9 持久性的方式保护您的钥匙。对于 CSEK ，这意味着对您的密钥进行异地备份，即使您的密钥丢失或以某种方式损坏，您也拥有恢复的途径。如果不采取此类的预防措施，加密密钥的持久性将会决定数据的持久性。

超越 11 个 9

Google Cloud 非常重视保护您的数据。实际上，迄今为止，本文中概述的众多技术以使 Cloud Storage的年持久性超越 11 个 9 。再加上我们再本指南中分享的最佳实践，将帮助您确保数据在您需要的时候可以访问——无论是在今天的晚些时候还是在未来的数十年之后。要开始您的云上数据存储旅程，请查看此全面的 Cloud Storage 操作指南集合。