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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для 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>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00: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 Storage теперь необходимо предоставить полный идентификатор ресурса для всех политик репликации объектов, которые создаются, когда в учетной записи "хранилище" запрещена репликация между клиентами, участвующими в политике репликации. Azure Storage использует полный идентификатор ресурса, чтобы проверить, находятся ли исходные и целевые учетные записи в одном клиенте. Дополнительные сведения о запрете репликации между клиентами см. в статье Предотвращение репликации между клиентами Microsoft Entra.

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

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

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

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

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

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

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

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

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

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

Вы можете использовать Azure Policy для аудита набора учетных записей хранилища, чтобы гарантировать, что свойство AllowCrossTenantReplication установлено для предотвращения репликации объектов между клиентами. Вы также можете использовать Azure Policy для обеспечения управления набором учетных записей хранения. Например, можно создать политику с эффектом 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 Storage.
• Проверьте, был ли исходный или целевой двоичный объект перемещён на уровень архива. Архивированные блоб-объекты нельзя реплицировать. Дополнительные сведения об уровне архива см. в разделе Уровни доступа к данным BLOB-объектов.
• Убедитесь, что контейнер назначения или блоб не защищен политикой неизменяемости данных. Учтите, что контейнер или BLOB-объект может наследовать политику неизменяемости от родительского объекта. Дополнительные сведения о политиках неизменяемости см. в разделе Обзор неизменяемого хранилища для данных BLOB-объектов.

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

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

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

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

Вот разбивка затрат. Чтобы узнать цену каждого компонента затрат, см. Цены на Azure Blob Storage.

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

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

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

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

• Настройка репликации объектов
• Предотвращение репликации объектов в клиентах Microsoft Entra
• Версионирование BLOB-объектов
• Поддержка Change feed в Azure Blob Storage