← Cloudflare R2 / r2 / data-migration

Sippy

Sippy представляет собой сервис миграции данных, который позволяет копировать данные от других облачных провайдеров в R2 по мере запроса, не оплачивая лишние сборы за исходящий трафик, обычно связанные с переносом больших объёмов данных.

Специфичные для миграции комиссии за исходящий трафик снижаются за счёт использования запросов в рамках вашего приложения, для которых вы уже платите за исходящий трафик, чтобы одновременно копировать объекты в R2.

Как это работает

Если Sippy включён для бакета R2, он применяет следующую стратегию миграции в Workers, S3 API, а также публичные бакеты:

Когда запрашивается объект, он отдаётся из вашего бакета R2, если найден.
Если объект не найден в R2, он будет одновременно возвращён из исходного бакета хранилища и скопирован в R2.
Все остальные операции, включая put и delete, продолжают работать в обычном режиме.

Когда полезен Sippy?

Использование Sippy как части стратегии миграции может быть удачным выбором в следующих случаях:

Вы хотите начать миграцию данных, но не хотите сразу платить за исходящий трафик, чтобы перенести все данные одним разом.
Вы хотите поэкспериментировать, раздавая часто запрашиваемые объекты из R2, чтобы избежать платы за исходящий трафик, не тратя время на миграцию данных.
У вас часто меняются данные, и вы хотите провести миграцию без простоя. Sippy можно использовать для обработки запросов, пока Super Slurper можно использовать для переноса оставшихся данных.

Если вы хотите перенести все данные из существующего облачного провайдера в R2 за один раз, рекомендуем использовать Super Slurper.

Начало работы с Sippy

Прежде чем начать, вам потребуется:

Существующий бакет R2. Если у вас его еще нет, см. Создание бакетов.
Учётные данные API для исходного бакета объектного хранилища.
(Только для Wrangler) Access Key ID и Secret Access Key Cloudflare R2 с правами на чтение и запись. Дополнительная информация: Аутентификация.

Включение Sippy через Dashboard

На панели управления Cloudflare перейдите к разделу Объектное хранилище R2 страницу.
Перейдите в Обзор ↗
Выберите бакет, в который нужно перенести объекты.
Перейдите на вкладку Настройки вкладке, затем прокрутите вниз до On Demand Migration карточка.
Выберите Включить и укажите данные бакета, из которого хотите перенести объекты. Введённые учётные данные должны иметь права на чтение из этого бакета. Cloudflare также рекомендует ограничить область действия учётных данных только чтением из этого бакета.
Выберите Включить.

Включение Sippy через Wrangler

Настройка Wrangler

Для начала установите npm ↗. Затем установите Wrangler, интерфейс командной строки платформы разработчика.

Включение Sippy для бакета R2

Войдите в Wrangler с помощью wrangler login команда. Затем выполните r2 bucket sippy enable команда:

npx wrangler r2 bucket sippy enable <BUCKET_NAME>

Это предложит вам выбрать одного из поддерживаемых провайдеров объектного хранилища и проведет вас через настройку.

Включение Sippy через API

Сведения о необходимых параметрах и примеры включения Sippy см. в Документация по API. Информацию о начале работы с Cloudflare API см. Выполняйте вызовы API.

Просмотр метрик миграции

Если Sippy включён, он предоставляет метрики, которые помогают отслеживать прогресс текущих миграций.

Метрика	Описание
Запросы, обслуженные Sippy	Процент от общего числа запросов, обслуженных R2 за определённый период времени. Чем выше процент, тем меньше запросов требуется направлять к исходному бакету.
Данные, перенесённые с помощью Sippy	Объём данных, скопированных из исходного бакета в R2 за определённый период времени. Указывается в байтах.

Чтобы просмотреть текущие и исторические метрики:

На панели управления Cloudflare перейдите к разделу Объектное хранилище R2 страницу.
Перейдите в Обзор ↗
Выберите свой бакет.
Выберите Метрики на вкладке.

При необходимости можно выбрать временной интервал для запроса. По умолчанию используются последние 24 часа.

Отключите Sippy для бакета R2

Dashboard

На панели управления Cloudflare перейдите к разделу Объектное хранилище R2 страницу.
Перейдите в Обзор ↗
Выберите бакет, для которого нужно отключить Sippy.
Перейдите на вкладку Настройки вкладку и прокрутите вниз до On Demand Migration карточка.
Нажмите Отключить.

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)
Azure Blob Storage
S3-совместимые провайдеры хранилища

Взаимодействие с R2 API

Когда Sippy включён, он меняет поведение некоторых действий с вашим бакетом R2 в Workers, S3 API, а также публичные бакеты.

Действие	Новое поведение
GetObject	При вызове GetObject сначала выполняется попытка получить объект из вашего бакета R2. Если объект отсутствует, он будет отдан из исходного бакета хранилища и одновременно загружен в запрошенный бакет R2. Дополнительные аспекты: Изменения объектов в исходном бакете не будут отражены в R2 после первоначального копирования. После того как объект сохранён в R2, он не будет повторно получен и обновлён. Учитываются только пользовательские метаданные с префиксом `x-amz-meta-` в HTTP-ответе будут перенесены. Остальные метаданные будут опущены. Для более крупных объектов (свыше 199 МиБ) может потребоваться несколько запросов GET, чтобы полностью скопировать объект в R2. Если одновременно поступает несколько запросов GET на объект, который ещё не полностью скопирован в R2, 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 рекомендует создать пользователя с ограниченным набором прав.

Чтобы создать учетные данные с нужными правами:

Войдите в свою учётную запись AWS IAM.

Создайте политику в следующем формате и замените <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>/*"
			]
		}
	]
}

Создайте нового пользователя и прикрепите к нему созданную политику.

Теперь вы можете использовать Access Key ID и Secret Access Key при включении Sippy.

Google Cloud Storage

Чтобы копировать объекты из Google Cloud Storage (GCS), Sippy требуются права доступа к вашему бакету. Cloudflare рекомендует использовать предопределенную Storage Object Viewer роль.

Чтобы создать учетные данные с нужными правами:

Войдите в консоль Google Cloud.
Перейдите в IAM & Admin > Сервисные аккаунты.
Создайте сервисный аккаунт с предопределённой Storage Object Viewer роль.
Перейдите в Ключи вкладке созданной вами учётной записи службы.
Выберите Add Key > Создание нового ключа и загрузите JSON-файл ключа.

Теперь вы можете использовать этот файл ключа JSON при включении Sippy через Wrangler или API.

Azure Blob Storage

Чтобы копировать объекты из Azure Blob Storage, Sippy требуются имя вашей учетной записи Azure Storage, контейнер, из которого выполняется копирование, а также ключ учетной записи или токен shared access signature (SAS). Укажите ровно один из этих двух типов учетных данных. Sippy необходимы права на чтение и просмотр списка для контейнера.

Чтобы использовать ключ учетной записи:

Войдите на портал Azure и перейдите к своей учётной записи хранилища.
В разделе Безопасность + сеть, выберите Ключи доступа.
Скопируйте имя учётной записи хранилища и один из указанных ключей.

Чтобы вместо этого использовать токен SAS, Cloudflare рекомендует ограничить его только контейнером, который вы переносите:

Войдите на портал Azure и перейдите к своей учётной записи хранилища.
В разделе Хранение данных, выберите Containers, затем откройте контейнер, из которого хотите выполнить миграцию.
Выберите Общие токены доступа, предоставьте Чтение и Список разрешения, затем выберите Создание SAS-токена и URL.
Скопируйте сгенерированный SAS-токен.

Теперь вы можете использовать имя учётной записи, имя контейнера и либо ключ учётной записи, либо SAS-токен при включении Sippy.

S3-совместимое хранилище

Чтобы копировать объекты от S3-совместимого провайдера хранилища, Sippy требуются URL конечной точки S3 API для вашего бакета, а также Access Key ID и Secret Access Key с правом чтения из него. Cloudflare рекомендует ограничить эти учетные данные только чтением из бакета, который вы переносите.

Обратитесь к документации вашего поставщика хранилища, чтобы найти конечную точку S3 API для вашего бакета и создать учётные данные доступа только для чтения.

Теперь вы можете использовать URL бакета, Access Key ID и Secret Access Key при включении Sippy.

Важные замечания

ETags

Формирование ETag в R2 в целом совместимо с S3, но при миграции объекта с помощью Sippy совпадение ETag не гарантируется. Sippy самостоятельно принимает решения об операциях, которые использует при миграции объектов, чтобы оптимизировать производительность и использование сети. Он может перенести объект несколькими частями, что влияет на Вычисление ETag.

Например, объект размером 320 МиБ, изначально загруженный в S3 с помощью одной PutObject операция может быть перенесена в R2 с помощью составных операций. В этом случае ETag объекта в R2 не будет совпадать с его ETag в S3. Аналогично, объект, изначально загруженный в S3 с помощью составных операций, также может иметь другой ETag в R2, если размеры частей, которые Sippy выбирает для миграции, отличаются от размеров частей, с которыми этот объект был первоначально загружен.

Поэтому не рекомендуется полагаться на совпадение ETag до и после миграции.