跳转到内容
搜索文档

Sippy

最后更新 查看 MarkdownAgent 设置

Sippy 是一项数据迁移服务,允许您在请求数据时将数据从其他云提供商复制到 R2,而无需支付通常与移动大量数据相关的迁移出口费用。

通过在应用程序流程中已有的请求(您本来就需要支付出口费用)同时复制对象到 R2,可以减少迁移特定的出口费用。

工作原理

为 R2 存储桶启用 Sippy 后,在 WorkersS3 API公共存储桶 上实现以下迁移策略:

  • 请求对象时,如果在 R2 存储桶中找到,则从 R2 存储桶提供。
  • 如果在 R2 中未找到对象,则同时从源存储存储桶返回对象并复制到 R2。
  • 所有其他操作(包括 put 和 delete)继续正常工作。

Sippy 何时有用?

将 Sippy 作为迁移策略的一部分可能是不错的选择,当您:

  • 想开始迁移数据,但希望避免一次性迁移所有数据的前期出口费用。
  • 想通过从 R2 提供频繁访问的对象来消除出口费用进行实验,而无需投入时间进行数据迁移。
  • 有频繁变化的数据,希望在避免停机的情况下进行迁移。Sippy 可用于提供服务请求,同时 Super Slurper 可用于迁移剩余数据。

如果您想一次性将所有数据从现有云提供商迁移到 R2,建议使用 Super Slurper

开始使用 Sippy

开始之前,您需要:

  • 现有的 R2 存储桶。如果还没有,请参阅创建存储桶
  • 源对象存储存储桶的 API 凭据
  • (仅 Wrangler)具有读写权限的 Cloudflare R2 Access Key ID 和 Secret Access Key。更多信息请参阅身份验证

通过仪表板启用 Sippy

  1. 在 Cloudflare 仪表板中,前往 R2 object storage(R2 对象存储) 页面。

    Go to Overview ↗
  2. 选择要迁移对象到的存储桶。

  3. 切换到 Settings(设置) 选项卡,然后滚动到 On Demand Migration(按需迁移) 卡片。

  4. 选择 Enable(启用) 并输入要迁移对象的 AWS / GCS 存储桶详情。您输入的凭据必须具有读取该存储桶的权限。Cloudflare 还建议将凭据范围限定为仅允许读取该存储桶。

  5. 选择 Enable(启用)

通过 Wrangler 启用 Sippy

设置 Wrangler

首先,安装 npm。然后安装 Wrangler(Developer Platform CLI)

在 R2 存储桶上启用 Sippy

使用 wrangler login 命令 登录 Wrangler。然后运行 r2 bucket sippy enable 命令

npx wrangler r2 bucket sippy enable <BUCKET_NAME>

这将提示您选择支持的对象存储提供商并引导您完成设置。

通过 API 启用 Sippy

有关所需参数和启用 Sippy 的示例,请参阅 API 文档。有关 Cloudflare API 入门信息,请参阅发起 API 调用

查看迁移指标

启用后,Sippy 公开有助于了解正在进行的迁移进度的指标。

指标 描述
Requests served by Sippy 一段时间内 R2 提供服务的请求百分比。百分比越高,表示需要向源存储桶发出的请求越少。
Data migrated by Sippy 一段时间内从源存储桶复制到 R2 的数据量。以字节为单位报告。

查看当前和历史指标:

  1. 在 Cloudflare 仪表板中,前往 R2 object storage(R2 对象存储) 页面。

    Go to Overview ↗
  2. 选择您的存储桶。

  3. 选择 Metrics(指标) 选项卡。

您可以选择查询的时间窗口。默认为最近 24 小时。

在 R2 存储桶上禁用 Sippy

仪表板

  1. 在 Cloudflare 仪表板中,前往 R2 object storage(R2 对象存储) 页面。

    Go to Overview ↗
  2. 选择要禁用 Sippy 的存储桶。

  3. 切换到 Settings(设置) 选项卡,滚动到 On Demand Migration(按需迁移) 卡片。

  4. 点击 Disable(禁用)

Wrangler

要禁用 Sippy,运行 r2 bucket sippy disable 命令

npx wrangler r2 bucket sippy disable <BUCKET_NAME>

API

有关禁用 Sippy 所需参数和示例的更多信息,请参阅 API 文档

支持的云存储提供商

Cloudflare 目前支持从以下云对象存储提供商复制数据到 R2:

  • Amazon S3
  • Google Cloud Storage (GCS)

R2 API 交互

启用 Sippy 后,它会改变 R2 存储桶在 WorkersS3 API公共存储桶 上某些操作的行为。

操作 新行为
GetObject 对 GetObject 的调用首先尝试从 R2 存储桶检索对象。如果对象不存在,则从源存储存储桶提供对象,同时上传到请求的 R2 存储桶。

其他注意事项:
  • 源存储桶中对象的修改在初始复制后不会反映在 R2 中。对象存储在 R2 后,不会重新检索和更新。
  • 只有 HTTP 响应中以 x-amz-meta- 为前缀的用户定义元数据会被迁移。其余元数据将被省略。
  • 对于较大的对象(大于 199 MiB),可能需要多次 GET 请求才能将对象完全复制到 R2。
  • 如果对尚未完全复制到 R2 的对象有多个同时 GET 请求,Sippy 可能多次从源存储存储桶获取对象以服务这些请求。
HeadObject 行为类似 GetObject,但仅检索对象元数据。不会将对象复制到请求的 R2 存储桶。
PutObject 行为不变。对 PutObject 的调用会将对象添加到请求的 R2 存储桶。
DeleteObject 行为不变。对 DeleteObject 的调用会删除请求的 R2 存储桶中的对象。

其他注意事项:
  • 如果在 R2 中删除对象但未在源存储存储桶中删除,后续的 GetObject 请求将导致从源存储桶检索对象并复制到 R2。

上面未列出的操作行为不变。更多信息请参阅 Workers API 参考S3 API 兼容性

为存储提供商创建凭据

Amazon S3

要从 Amazon S3 复制对象,Sippy 需要访问存储桶的权限。虽然可以使用具有正确权限的任何 AWS Identity and Access Management (IAM) 用户凭据,但 Cloudflare 建议创建具有最小权限集的用户。

创建具有正确权限的凭据:

  1. 登录 AWS IAM 账户。
  2. 创建具有以下格式的策略,并将 <BUCKET_NAME> 替换为要授予访问权限的存储桶:
    {
    	"Version": "2012-10-17",
    	"Statement": [
    		{
    			"Effect": "Allow",
    			"Action": ["s3:ListBucket*", "s3:GetObject*"],
    			"Resource": [
    				"arn:aws:s3:::<BUCKET_NAME>",
    				"arn:aws:s3:::<BUCKET_NAME>/*"
    			]
    		}
    	]
    }
  3. 创建新用户并将创建的策略附加到该用户。

现在可以在启用 Sippy 时使用 Access Key ID 和 Secret Access Key。

Google Cloud Storage

要从 Google Cloud Storage (GCS) 复制对象,Sippy 需要访问存储桶的权限。Cloudflare 建议使用 Google Cloud 预定义的 Storage Object Viewer 角色。

创建具有正确权限的凭据:

  1. 登录 Google Cloud 控制台。
  2. 前往 IAM & Admin(IAM 和管理) > Service Accounts(服务账号)
  3. 创建具有预定义 Storage Object Viewer 角色的服务账户。
  4. 前往创建的服务账户的 Keys(密钥) 选项卡。
  5. 选择 Add Key(添加密钥) > Create a new key(创建新密钥) 并下载 JSON 密钥文件。

现在可以通过 Wrangler 或 API 启用 Sippy 时使用此 JSON 密钥文件。

注意事项

ETags

虽然 R2 的 ETag 生成在常规操作期间与 S3 兼容,但使用 Sippy 迁移对象时,ETag 并不保证相等。 Sippy 会自主决定迁移对象时使用的操作,以优化性能和网络用量。它可能会选择通过分段操作迁移对象,这会影响 ETag 计算

例如,原本通过单次 PutObject 操作上传到 S3 的 320 MiB 对象,可能会通过分段操作迁移到 R2。在这种情况下,其在 R2 上的 ETag 将与 S3 上的 ETag 不同。 同样,原本通过分段操作上传到 S3 的对象,如果 Sippy 为迁移选择的分段大小与原始上传时的分段大小不同,其在 R2 上的 ETag 也可能不同。

因此,不建议依赖迁移前后 ETag 的一致性。

这篇文档对您有帮助吗?