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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Репликация объектов не копирует теги индекса исходного BLOB-объекта в целевой BLOB-объект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "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-028T00:00:00Z"
        }
      }
    ]
  }
}

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

При создании файла определения политики укажите полные ИД ресурсов Azure Resource Manager для записей sourceAccount и destinationAccount, как показано в примере в предыдущем разделе. Чтобы узнать, как найти ИД ресурса для учетной записи хранения, ознакомьтесь с разделом Получение идентификатора ресурса для учетной записи хранения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот разбивка затрат. Сведения о цене каждого компонента затрат см. в разделе Цены на хранилище Blob в Azure.

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

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

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

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

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