Enabling Cloud Storage end-to-end checksums for improved data integrity and durability

TL;DR · AI 摘要
Enabling end-to-end checksums in Cloud Storage Google Cloud Blog Storage & Data Transfer Enabling Cloud Storage end-to-e...
核心要点
- 主题聚焦:Enabling Cloud Storage end-to-end checksums for
- 来源:Google Cloud Blog,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
在 Cloud Storage 中启用端到端校验和 | Google Cloud 博客
存储与数据传输
通过端到端校验和提升 Cloud Storage 数据完整性与持久性
2026 年 10 月 2 日
##### Denis Serenyi
高级软件工程师
##### Yamini Allu
软件工程师
##### 今天试用 Gemini Enterprise
职场人工智能的入口
立即试用
在 Google Cloud,我们深知您始终依赖我们来保障数据在静止和传输状态下的持久性与完整性。现在,我们通过在所有 Cloud Storage SDK 中默认启用端到端校验和功能,让开发者更便捷地利用 Cloud Storage 原生的数据完整性特性。
如同任何基于磁盘的存储系统,数据位在从应用到磁盘的整个传输过程中都可能发生翻转。Cloud Storage 一直允许客户端上传时提供对象数据的校验和,并在下载时接收数据的校验和。自诞生以来,Cloud Storage 无论对象如何上传到 Cloud Storage,都会在元数据中为每个对象存储校验和。
但直到最近,确保端到端数据完整性仍需要开发者额外计算并提供校验和。Cloud Storage 始终会计算接收到数据的 crc32(32 位循环冗余校验),并确保磁盘上的数据与该校验和匹配。当客户端请求包含对象的校验和时,Cloud Storage 会验证该校验和是否一致。然而,当上传请求未包含校验和时,数据在传输到服务器端计算校验和之前可能发生位翻转,而并非所有客户和客户端默认启用客户端校验和,导致数据在此阶段缺乏保护。
为解决这一问题,最新版本的所有 Cloud Storage SDK 现在会在内部对上传的数据进行校验和计算,并在应用未提供时将该校验和传递给 Cloud Storage。SDK 还支持在下载对象时验证对象的校验和。
最后,在许多使用场景中,应用程序会下载对象的特定范围而非完整对象。当使用 Cloud Storage SDK 与我们的 gRPC API 进行范围读取时,SDK 会利用 gRPC 内置的端到端范围校验和功能,用于验证接收到的数据。
我们强烈建议升级到最新版本的 SDK,以充分利用这些重要的完整性功能。
现在,让我们一窥内部实现
确保从您的应用到磁盘盘片的数据与其关联的校验和之间持续的“责任链”,且在任何可能位翻转而不被察觉的环节都没有缺口,是一项极具挑战性的任务。准确实现这一点至关重要:在我们目前拥有数十万 Cloud Storage 前端的规模下,位翻转并非理论上的可能性,而是偶尔会发生的真实事件。
例如,考虑这个简单场景:当 Cloud Storage 的前端接收到您的数据时,这些数据会使用每个对象的加密密钥进行加密。这涉及数据复制:明文数据通过加密器传递到包含密文的新内存缓冲区。极少数情况下,源或目标内存缓冲区中的位在此过程中会发生翻转。然而,在我们的规模下,这些极少见的事件会频繁发生。
在这种情况中,我们通过逆向整个流程来维护数据保管链:在加密数据(1)后,我们计算一个用于保护密文的校验和。随后我们解密密文(2),如果得到的明文与原始数据不匹配(3),我们将丢弃所有数据并重新开始。这会导致大量额外的CPU时间被用于加密和校验和计算,但这是确保数据完整性的必要步骤。
另一个挑战是数据在通过我们系统各层时如何被拆分和聚合。当数据上传到云存储时,会被拆分成多个块,每个块都有自己的校验和。为了在大规模下高效管理数据,云存储会将数千个块组合成一个称为分片文件(shard file)的存储单元。这些以GB为单位的文件是云存储最终将数据传递给集群级存储系统Colossus的方式。在内部,Colossus使用里德-所罗门编码将数据分布到多个磁盘上,以防止单个磁盘、机器或机架的故障。这需要将分片文件数据切割成块,每个块再次通过校验和进行保护。
为了在数据经历所有这些转换时维护数据保管链,我们利用了循环冗余校验(CRCs)的一些特性,例如拼接功能。当两个数据缓冲区各自拥有自己的CRC时,可以低成本地计算出这两个拼接缓冲区的CRC,而无需重新校验数据。这一特性在许多场景中都非常实用,例如在将块拼接成分片文件时:Colossus可以低成本地从组成块中计算出整个分片文件的CRC,并将其存储在元数据中。
最终,数据会落在由我们的“D”文件服务器管理的磁盘上(我们的网络附加磁盘)。D为Colossus块中每个数据范围存储内联校验和。每当从磁盘读取数据时,会在多个层级进行验证:Colossus客户端会将其读取的数据与D的内联校验和进行比对,而云存储前端则逐块读取数据,验证每个块的校验和后再发送给客户端。这些块级校验和使得我们的gRPC协议能够为范围读取提供可由SDK验证的校验和,同时不会丢失数据保管链。
数据保管链:在数据转换过程中维护数据完整性
上图展示了Google云存储内部多个层级间的数据完整性交接过程。在读取时,校验和会在多个层级进行内联验证,以防止静默损坏。
- 客户端将完整的对象校验和传递给云存储前端。
- 数据被拆分为块,并计算每个块的校验和。
- 分片级校验和基于拼接的块级CRC计算得出。
- 分片存储在磁盘块中,并添加了另一层块级内联校验和。
在云存储团队,我们始终致力于为客户提供最高标准的数据完整性保障。通过将端到端校验和作为SDK的默认设置,并在整个内部存储堆栈中维护数据保管链,数据从上传到最终下载的整个过程中都会保持原样。这种持续的警惕性体现了我们保护您数据的承诺,无论数据规模如何。要充分利用这些保护措施,我们建议升级到最新版本的SDK。
发布于
- 存储与数据传输 /think