Репликация объектов для блочных BLOB'ов

Репликация объектов асинхронно копирует блочные блобы между исходной учетной записью хранения и целевой учетной записью. Ниже перечислены некоторые сценарии, поддерживаемые репликацией объектов.

• Свести к минимуму задержку. Репликация объектов снижает задержку для запросов на чтение, позволяя клиентам потреблять данные из региона, находящегося в более близкой физической близости.
• Увеличьте эффективность для вычислительных рабочих нагрузок. При репликации объектов вычислительные рабочие нагрузки могут обрабатывать те же наборы блочных BLOB-объектов в разных регионах.
• Оптимизировать распределение данных. Вы можете обрабатывать или анализировать данные в одном месте, а затем реплицировать только результаты в дополнительные регионы.
• Оптимизация затрат. После репликации ваших данных вы можете снизить затраты, переместив их на уровень архива с помощью политик управления жизненным циклом.

На следующей схеме показано, как репликация блочных объектов BLOB копирует их из исходной учетной записи хранения в одном регионе на целевые учетные записи в двух разных регионах.

Дополнительные сведения о настройке репликации объектов см. в разделе Настройка репликации объектов.

Предварительные требования и предостережения для репликации объектов

Репликация объектов требует включения следующих функций служба хранилища Azure:

• Лента изменений: включить для исходной учетной записи. Чтобы узнать, как включить канал изменений, см. статью Включение и отключение канала изменений.
• Управление версиями BLOB-объектов: включите его как для исходной, так и для целевой учетной записи. Чтобы узнать, как включить версионность, см. статью Включение и управление версиями BLOB-объектов.

Включение канала изменений и версионирования объектов BLOB может привести к дополнительным затратам. Дополнительные сведения см. на странице цен служба хранилища Azure.

Репликация объектов поддерживает учетные записи хранения общего назначения версии v2 и учетные записи блочных BLOB-объектов уровня Premium. Исходные и целевые учетные записи должны быть учетными записями общего назначения v2 или учетными записями блоков BLOB премиум-класса. Репликация объектов поддерживает только блочные блобы; она не поддерживает append-блобы и page-блобы.

Репликация объектов поддерживает учетные записи, зашифрованные либо ключами, управляемыми Microsoft, либо ключами, управляемыми клиентом. Дополнительные сведения о ключах, управляемых клиентом, см. в разделе Управляемые клиентом ключи для шифрования служба хранилища Azure.

Репликация объектов не поддерживает blobs в исходном аккаунте, зашифрованные ключом, предоставленным клиентом. Дополнительные сведения о предоставленных клиентом ключах см. в разделе Предоставление ключа шифрования при запросе в хранилище BLOB.

В политике репликации объектов не поддерживается отработка отказа, управляемая клиентом, ни для исходной, ни для целевой учетной записи.

Репликация объектов не поддерживается в аккаунтах с включенным иерархическим пространством имён.

Репликация объектов не поддерживается для BLOB-ов, загруженных с использованием API Data Lake Storage.

Принцип действия репликации объектов

Функция репликации объектов асинхронно копирует BLOB-объекты в контейнере в соответствии с правилами, которые вы настраиваете. Сервис копирует содержимое blob, любые версии, связанные с ним, а также метаданные и свойства blob из исходного контейнера в контейнер назначения.

Внимание

Так как данные блочных BLOB-объектов реплицируются асинхронно, исходная учетная запись и целевая учетная запись не будут немедленно синхронизированы.

Репликация объектов (OR) теперь поддерживает репликацию приоритетов, которая ставит приоритет на репликацию всех операций в политике OR. Когда включена репликация приоритета ИЛИ, производительность репликации всех операций улучшается. Если исходная и целевая учетная запись политики репликации находятся на одном континенте, репликация по приоритету OR также выполняется для 99,0% объектов в течение 15 минут при поддерживаемых рабочих нагрузках. Производительность функций гарантируется соглашением об уровне обслуживания (SLA). Для получения дополнительной информации см. термины SLA и статью о приоритетной репликации объектов .

Вы также можете проверить состояние репликации в исходном BLOB-объекте, чтобы определить, завершена ли репликация. Дополнительные сведения см. в разделе Проверка состояния репликации BLOB-объектов.

Управление версиями BLOB-объекта

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

Если у вашей учетной записи хранилища есть политики репликации объектов, вы не можете отключить версионирование BLOB-ов для этой учетной записи. Перед отключением версирования BLOB-объектов необходимо удалить все политики репликации объектов в учетной записи.

Примечание.

В место назначения копируются только BLOB. Сервис не копирует ID версии blob. После того как сервис размещает blob в точке назначения, он назначает новый идентификатор версии.

Удаление объекта BLOB в исходной учетной записи

Когда вы удаляете BLOB-объект в исходной учетной записи, текущая версия BLOB-объекта становится предыдущей версией, и текущей версии больше не существует. Сервис сохраняет все существующие предыдущие версии blob. Сервис реплицирует это состояние в целевую учетную запись. Дополнительные сведения о том, как операции удаления влияют на версии BLOB-объектов, см. в разделе Управление версиями при операциях удаления.

Моментальные снимки

Репликация объектов не поддерживает моментальные снимки больших двоичных объектов. Сервис не воспроизводит снимки с blob в исходном аккаунте в целевой учетной запись.

Теги индекса BLOB-объектов

Теперь репликация объектов поддерживает копирование тегов индекса из исходных BLOB-объектов в целевые BLOB-объекты. Эту возможность можно настроить как часть нового или существующего правила репликации. Дополнительные сведения см. в разделе "Настройка репликации объектов".

Внимание

Репликация тегов сейчас доступна в режиме предварительной версии. Ознакомьтесь с Дополнительными условиями использования для предварительных версий Microsoft Azure, чтобы узнать правовые условия, применимые к функциям Azure, которые находятся в бета-версии, предварительной версии или иным образом еще не выпущены в общий доступ.

Распределение двоичных объектов по уровням

Репликация объектов поддерживается, если исходные и целевые учетные записи находятся на любом уровне в сети (горячий, холодный или холодный). Исходные и целевые учетные записи могут находиться на разных уровнях. Однако репликация объектов ошибается, если блоб в исходной или целевой учетной записи перемещен на архивный уровень. Увлажнение архивированного комка не запускает репликацию объекта. Репликация объектов активируется только при повторном обновлении данных BLOB-объектов после восстановления. Дополнительные сведения о уровнях BLOB-объектов см. в разделе уровни доступа данных BLOB-объектов.

Неизменяемые блобы

Политики неизменяемости для Хранилище BLOB-объектов Azure включают политики хранения на основе времени и юридические удержания. Если политика неизменяемости действует в целевой учетной записи, может быть затронута репликация объектов. Дополнительные сведения о политиках неизменяемости см. в разделе Хранение критически важных данных BLOB-объектов для бизнеса с неизменяемым хранилищем.

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

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

Политики и правила репликации объектов

При настройке репликации объектов создается политика репликации, указывающая исходную учетную запись хранилища и целевую учетную запись. Политика репликации включает одно или несколько правил, которые определяют исходные и целевые контейнеры и указывают, какие исходные объекты хранения реплицируются.

После настройки репликации объектов служба хранилища Azure периодически проверяет канал изменений для исходной учетной записи и асинхронно реплицирует все операции записи или удаления в целевую учетную запись. Задержка репликации зависит от размера реплицируемого блочного BLOB-объекта.

Политики репликации

При настройке репликации объектов вы создаёте политику репликации на целевой учетной записи через провайдера ресурсов служба хранилища Azure. После создания политики репликации служба хранилища Azure присваивает ей идентификатор политики. Затем необходимо связать эту политику репликации с исходной учетной записью при помощи идентификатора политики. Идентификатор политики исходного и целевого аккаунтов должен совпадать для репликации.

Исходная учетная запись может реплицироваться максимум на две целевые учетные записи, при этом можно использовать по одной политике для каждой целевой учетной записи. Аналогичным образом учетная запись может служить целевой учетной записью не более двух политик репликации.

Исходные и целевые учетные записи могут находиться в одном регионе или в разных регионах. Они также могут находиться в одной подписке или в разных подписках. При необходимости исходные и целевые учетные записи могут находиться в разных клиентах Microsoft Entra. Вы можете создать только одну политику репликации для каждой пары исходного и целевого аккаунта.

Правила репликации

Правила репликации указывают, как служба хранилища Azure реплицирует блобы из исходного контейнера в целевой контейнер. Для каждой политики репликации можно указать до 1000 правил репликации. Каждое правило репликации определяет один исходный и целевой контейнер, а каждый исходный и целевой контейнер можно использовать только в одном правиле. В результате в одной политике репликации может участвовать не более 1000 исходных контейнеров и 1000 целевых контейнеров.

После того как вы создадите правило репликации, все существующие объекты BLOB игнорируются; по умолчанию копируются только новые блочные объекты BLOB, добавленные после создания правила. Однако можно указать, что копируются новые и существующие блочные BLOB-объекты. Можно также определить настраиваемую область копирования, которая копирует все блочные BLOB-объекты, созданные после указанного времени.

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

Оба контейнера, исходный и целевой, должны существовать, прежде чем их можно будет указать в правиле. После создания политики репликации выполнение операций записи в целевом контейнере не допускается. Любые попытки записи в целевой контейнер завершатся ошибкой с кодом 409 (конфликт).

Чтобы записать в целевой контейнер с правилом репликации, необходимо сначала отключить репликацию. Вы можете отключить правило, либо убрав его для этого контейнера, либо полностью убрав политику репликации.

Операции чтения и удаления в целевом контейнере разрешены, если политика репликации активна.

Для BLOB-объекта в целевом контейнере можно вызвать операцию Установить уровень BLOB, чтобы переместить его на уровень архивации. Дополнительные сведения об уровне архива см. в разделе Уровни доступа для данных BLOB-объектов.

Примечание.

Изменение уровня доступа объекта BLOB в исходной учетной записи не изменяет уровень доступа этого объекта BLOB в целевой учетной записи.

Файл определения политики

Используйте JSON-файл для определения политики репликации объектов. Вы можете получить файл определения политики из существующей политики репликации объектов или создать политику репликации объектов, отправив файл определения политики.

Пример файла определения политики

В следующем примере политика репликации в целевой учетной записи устанавливается одним правилом. Правило нацелено на блобы с префиксом b и задаёт минимальное время создания для репликации. Не забудьте заменить значения в угловых скобках собственными значениями.

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "metrics": {
		  "enabled": false
    },
    "priorityReplication": "false",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Пользовательские фильтры

Фильтры можно настраивать с разными опциями в JSON-файле:

• Сопоставьте пятна по префиксам — воспроизводите только те пятны, чьи имена начинаются на букву b.

"filters": {
          "prefixMatch": [
            "b"
          ],
        }

• Сопоставьте блобов по времени создания — реплицируйте только те, что созданные в указанное время или позже.

"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}

• Реплицируйте все blob-ы — установите минимальное время создания на максимально раннее возможное значение.

"filters": {
  "minCreationTime": "1601-01-01T00:00:00Z"
}

Указание полных идентификаторов ресурсов для исходных и целевых учетных записей

При создании файла определения политики укажите полные идентификаторы ресурсов Azure Resource Manager для записей sourceAccount и destinationAccount, как показано в примере в предыдущем разделе. Для получения информации о том, как найти идентификатор ресурса для учетной записи хранилища, см. в разделе Get the resource ID for a storage account.

Полный ИД ресурса имеет следующий формат:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

Файл конфигурации политики ранее требовал только указания имени учетной записи, вместо полного идентификатора ресурса для учетной записи хранилища. С появлением свойства безопасности AllowCrossTenantReplication в версии 2021-02-01 REST API провайдера ресурсов служба хранилища Azure, теперь необходимо предоставить полный идентификатор ресурса для любых политик репликации объектов, которые вы создаёте, когда репликация между арендаторами запрещена для аккаунта хранения, участвующего в политике репликации. служба хранилища Azure использует полный идентификатор ресурса, чтобы проверить, находятся ли исходные и целевые учетные записи в одном клиенте. Дополнительные сведения о запрете репликации между клиентами см. статью Запретить репликацию между клиентами Microsoft Entra.

Хотя использование только имени учетной записи по-прежнему поддерживается для репликации между клиентами, Microsoft рекомендует использовать полный идентификатор ресурса в качестве рекомендации. Все предыдущие версии REST API поставщика ресурсов служба хранилища Azure поддерживают использование полного пути идентификатора ресурса в политиках репликации объектов.

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

Идентификатор учетной записи хранения в определении политики	Репликация между арендаторами разрешена	Репликация между арендаторами запрещена
Полный ИД ресурса	Можно создавать политики для одного и того же арендатора. Можно создавать межарендаторские политики.	Можно создавать политики для одного и того же арендатора. Невозможно создавать политики для нескольких арендаторов.
Только имя учетной записи	Можно создавать политики для одного и того же арендатора. Можно создавать межарендаторские политики.	Невозможно создавать политики ни в пределах одного арендатора, ни между несколькими арендаторами. Возникает ошибка, так как служба хранилища Azure не удается убедиться, что учетные записи источника и назначения находятся в одном клиенте. Эта ошибка указывает на то, что для записей sourceAccount и destinationAccount в файле определения политики необходимо задать полный ИД ресурса.

Укажите идентификаторы политик и правил

В приведенной ниже таблице представлена сводка значений для записей policyId и ruleId в файле определения политики в каждом сценарии.

При создании файла определения политики для этой учетной записи...	Установите идентификатор политики на это значение	Установите идентификаторы правил на это значение
Целевой счет	Строковое значение default. служба хранилища Azure создает для вас идентификатор политики.	Пустая строка. служба хранилища Azure создает значения идентификаторов правил.
Исходная учетная запись	Значение идентификатора политики, которое получается при загрузке файла определения политики для целевой учетной записи.	Значения идентификаторов правил, которые возвращаются при загрузке файла с определением политики для целевой учетной записи.

Предотвращение репликации между клиентами Microsoft Entra

Клиент Microsoft Entra — это выделенный экземпляр Microsoft Entra ID, представляющий организацию для управления удостоверениями и доступом. Каждая Azure подписка имеет отношение доверия с одним клиентом Microsoft Entra. Все ресурсы в подписке, включая учетные записи хранения, связаны с тем же клиентом Microsoft Entra. Дополнительные сведения см. в разделе Что такое Microsoft Entra ID?

По умолчанию репликация между клиентами отключена для новых учетных записей, созданных с 15 декабря 2023 г. Если ваши политики безопасности требуют ограничить репликацию объектов на учетные записи хранилища, которые находятся только в пределах одного и того же арендатора, вы можете запретить репликацию между арендаторами, установив свойство безопасности, AllowCrossTenantReplication (предварительная версия). При отключении репликации объектов между арендаторами для учетной записи хранения служба хранилища Azure вводится дополнительное требование. Для любой политики репликации объектов, которая использует эту учетную запись хранения в качестве источника или назначения, обе учетные записи должны принадлежать одному и тому же клиенту Microsoft Entra. Дополнительные сведения о запрете репликации объектов между арендаторами см. раздел Предотвращение репликации объектов между арендаторами Microsoft Entra.

Чтобы запретить репликацию объектов между клиентами для учетной записи storage, задайте для свойства AllowCrossTenantReplication значение false. Если учетная запись хранилища в настоящее время не участвует в каких-либо политиках репликации объектов между клиентами, то присвоение свойству AllowCrossTenantReplication значения false предотвращает дальнейшую настройку политик репликации объектов между клиентами с этой учетной записью хранилища в качестве источника или места назначения.

Если учетная запись хранилища в настоящее время участвует в одной или нескольких политиках репликации объектов между арендаторами, то установка параметра AllowCrossTenantReplication в значение false не разрешена. Чтобы запретить межарендаторскую репликацию, необходимо удалить существующие межарендаторские политики.

По умолчанию свойство AllowCrossTenantReplication имеет значение false для учетной записи storage, созданной с 15 декабря 2023 года. Для учетных записей хранилища, созданных до 15 декабря 2023 года, если значение свойства AllowCrossTenantReplication для учетной записи хранилища равно null или true, то авторизованные пользователи могут настроить политики репликации объектов между клиентами, используя эту учетную запись в качестве источника или назначения. Дополнительные сведения о настройке политик для нескольких арендаторов см. в разделе Настройка репликации объектов для блочных BLOB-объектов.

Вы можете использовать Политика Azure для аудита набора учетных записей хранения, чтобы гарантировать, что свойство AllowCrossTenantReplication установлено с целью предотвращения репликации объектов между клиентами. Вы также можете использовать Политика Azure для применения управления для набора учетных записей хранения. Например, можно создать политику с эффектом deny, чтобы предотвратить создание учетной записи storage, в которой свойство AllowCrossTenantReplication имеет значение true, или изменить существующую учетную запись storage, чтобы изменить значение свойства на true.

Метрики репликации

Репликация объектов поддерживает две метрики для предоставления аналитических сведений о ходе репликации:

• Операции, ожидающие репликации: общее количество операций, ожидающих репликации из исходного хранилища в целевое хранилище учетных записей, регистрируемых по временным интервалам.
• Байты, ожидающие репликации: сумма байтов, ожидающих репликации из источника в целевые учетные записи хранилища, по временным интервалам

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

• 0–5 минут
• 5–10 минут
• 10-15 минут
• 15–30 минут
• 30 мин-2 часа
• 2–8 часов
• 8-24 часа
• >24 часа

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

Вы можете включить метрики репликации в исходной учетной записи для мониторинга ожидающих байтов и ожидающих операций. Дополнительные сведения см. в разделе "Настройка метрик репликации".

Состояние репликации

Вы можете проверить состояние репликации для блоба в исходной учетной записи. Дополнительные сведения см. в разделе Проверка состояния репликации BLOB-объектов.

Примечание.

Пока продолжается репликация, невозможно определить процент копируемых данных.

Если статус репликации для blob в исходном аккаунте указывает на неудачу, расследуйте следующие возможные причины:

• Убедитесь, что политика репликации объектов настроена на целевой учетной записи.
• Убедитесь в том, что целевая учетная запись по-прежнему существует.
• Убедитесь, что целевой контейнер по-прежнему существует.
• Убедитесь, что целевой контейнер не был удален и не находится в процессе удаления. Удаление контейнера может занять до 30 секунд.
• Убедитесь в том, что целевой контейнер по-прежнему участвует в политике репликации объектов.
• Если исходный BLOB зашифрован с помощью ключа, предоставленного клиентом, в ходе операции записи, репликация объекта не выполняется. Дополнительные сведения о предоставленных клиентом ключах см. в разделе Предоставление ключа шифрования при запросе в хранилище BLOB.
• Проверьте, был ли исходный или целевой двоичный объект перемещён на уровень архива. Архивированные блоб-объекты нельзя реплицировать. Дополнительные сведения об уровне архива см. в разделе Уровни доступа для данных BLOB-объектов.
• Убедитесь, что контейнер назначения или блоб не защищен политикой неизменяемости данных. Контейнер или BLOB-объект может наследовать политику неизменности от родительского объекта. Дополнительные сведения о политиках неизменяемости см. в разделе Обзор неизменяемого хранилища для данных BLOB-объектов.

Поддержка функций

Поддержка этой функции может повлиять на включение протокола Data Lake Storage 2-го поколения, сетевой файловой системы (NFS) 3.0 или протокола SSH-передачи файлов (SFTP). Если вы включили любую из этих возможностей, ознакомьтесь с поддержкой функций Хранилище BLOB-объектов в учетных записях служба хранилища Azure для оценки поддержки этой функции.

Выставление счетов

Настройка репликации объектов не требует затрат, включая включение ленты изменений, версионирование и политики репликации. Однако репликация объектов несет затраты на транзакции чтения и записи в учетных записях источника и назначения. Плата за исходящий трафик при репликации данных из исходной учетной записи в целевую учетную запись также взимается, как и плата за операции чтения при обработке потока изменений.

Вот разбивка затрат. Чтобы узнать стоимость каждого компонента затрат, см. раздел Ценообразование Хранилище BLOB-объектов Azure.

Стоимость обновления объекта Blob в исходном аккаунте	Затраты на репликацию данных в целевой учетной записи
Затраты на выполнение операции записи	Затраты на транзакцию для чтения записи из потока изменений
Storage стоимость большого двоичного объекта и каждой версии большого двоичного объекта1	Затраты на транзакцию для чтения BLOB и его версий2
Стоимость добавления записи в журнал изменений	Затраты на транзакцию для записи больших двоичных объектов и их версий2
Затраты на получение данных на прохладных и холодных уровнях	Storage стоимость большого двоичного объекта и каждой версии большого двоичного объекта1
	Стоимость исходящеготрафика сети 3

¹ В исходной учетной записи, если уровень BLOB-объекта или его версии не изменяется, плата взимается за уникальные блоки данных в этом BLOB-объекте и его версиях. Смотрите цены на версионирование BLOB-объектов и выставление счетов. В учетной записи назначения с вас взимается плата за все блоки версии независимо от того, являются ли эти блоки уникальными.

² Эта стоимость включает только версии BLOB-объектов, созданные с момента завершения последней репликации.

³ Репликация объекта копирует всю версию в место назначения (а не только уникальные блоки версии). Эта передача повлечет за собой затраты на исходящий трафик сети. См. цены на Bandwidth.

Совет

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

Следующие шаги

• Настройка репликации объектов
• Предотвращение репликации объектов между тенантами Microsoft Entra.
• Версионирование BLOB-объектов
• Поддержка журнала изменений в Хранилище BLOB-объектов Azure