Репликация объектов для блочных BLOB-объектов
Функция репликации объектов асинхронно копирует блочные BLOB-объекты между исходной и целевой учетными записями хранения. Ниже перечислены некоторые сценарии, поддерживаемые репликацией объектов.
- Минимизация задержки. Репликация объектов может сократить задержку запросов на чтение, позволяя клиентам использовать данные из региона, наиболее близкого к их физическому расположению.
- Повышение эффективности вычислений для рабочих нагрузок. При репликации объектов рабочие нагрузки вычислений могут обрабатывать одни и те же наборы блочных BLOB-объектов в разных регионах.
- Оптимизация распределения данных. Вы можете обрабатывать или анализировать данные в одном месте, а затем просто реплицировать полученные результаты в дополнительные регионы.
- Оптимизация затрат. После репликации данных можно уменьшить затраты, переместив их на уровень архива с помощью политик управления жизненным циклом.
На следующей схеме показано, как репликация объектов реплицирует блочные BLOB-объекты из исходной учетной записи хранения в одном регионе в конечные учетные записи в двух разных регионах.
Дополнительные сведения о настройке репликации объектов см. в разделе Настройка репликации объектов.
Предварительные требования и предостережения для репликации объектов
Для репликации объектов требуется, чтобы были также включены следующие функции службы хранилища Azure.
- Канал изменений. Необходимо включить в исходной учетной записи. Сведения о включении канала изменений см. в разделе Включение и отключение канала изменений.
- Управление версиями больших двоичных объектов. Необходимо включить как в исходной, так и в целевой учетной записи. Сведения о включении управления версиями см. в статье Включение управления версиями BLOB-объектов и работа с ним.
Включение канала изменений и управления версиями BLOB-объектов может повлечь за собой дополнительные затраты. Дополнительные сведения см. на странице цен службы хранилища Azure.
Репликация объектов поддерживается для учетных записей хранения общего назначения версии 2 и хранения BLOB-объектов ценовой категории "Премиум". Исходной и целевой учетными записями должны быть учетные записи хранения общего назначения версии 2 и учетные записи хранения BLOB-объектов (цен. категория "Премиум"). Функция репликации объектов поддерживает только блочные BLOB-объекты; добавочные и страничные BLOB-объекты не поддерживаются.
Репликация объектов поддерживается для учетных записей, зашифрованных с помощью ключей, управляемых корпорацией Майкрософт, или ключей, управляемых клиентом. Дополнительные сведения о ключах, управляемых клиентом, см. в разделе Ключи, управляемые клиентом, для шифрования службы хранилища Azure.
Репликация объектов не поддерживается для BLOB-объектов в исходной учетной записи, зашифрованных с помощью ключа, предоставляемого клиентом. Дополнительные сведения о ключах, представляемых клиентом, см. в статье Указание ключа шифрования при отправке запроса в Хранилище BLOB-объектов.
В политике репликации объектов не поддерживается отработка отказа, управляемая клиентом, для исходной или целевой учетной записи.
Репликация объектов не поддерживается для больших двоичных объектов, передаваемых с помощью API Data Lake Storage .
Принцип действия репликации объектов
Функция репликации объектов асинхронно копирует блочные BLOB-объекты в контейнере в соответствии с настроенными правилами. Содержимое большого двоичного объекта, все связанные с ним версии, а также метаданные и свойства большого двоичного объекта копируются из исходного контейнера в целевой.
Внимание
Так как данные блочного BLOB-объекта реплицируются асинхронно, исходная и целевая учетные записи не синхронизируются сразу. В настоящее время нет соглашения об уровне обслуживания, регулирующего длительность репликации данных в целевую учетную запись. Чтобы определить, завершена ли репликация, проверьте состояние репликации в исходном большом двоичном объекте. Дополнительные сведения см. в разделе Проверка состояния репликации BLOB-объектов.
Управление версиями BLOB-объекта
Для репликации объектов требуется включить управление версиями больших двоичных объектов как в исходной, так и в целевой учетной записи. При изменении реплицированного большого двоичного объекта в исходной учетной записи в этой же учетной записи создается новая версия большого двоичного объекта, отражающая предыдущее его состояние до внесения изменений. Текущая версия в исходной учетной записи отражает самые последние обновления. Текущая версия и любые предыдущие версии реплицируются в целевую учетную запись. Дополнительные сведения о том, как операции записи влияют на версии больших двоичных объектов, см. в разделе Управление версиями при операциях записи.
Если ваша учетная запись хранения имеет политики репликации объектов, вы не можете отключить управление версиями BLOB-объектов для этой учетной записи. Перед отключением управления версиями больших двоичных объектов необходимо удалить все политики репликации объектов в учетной записи.
Примечание.
В место назначения копируются только большие двоичные объекты. Идентификатор версии большого двоичного объекта не копируется. Большой двоичный объект, размещенный в целевом расположении, назначается новый идентификатор версии.
Удаление большого двоичного объекта в исходной учетной записи
При удалении BLOB-объекта из исходной учетной записи его текущая версия становится предыдущей, а новая текущая версия не создается. Все существующие предыдущие версии BLOB-объекта сохраняются. Это состояние реплицируется в целевую учетную запись. Дополнительные сведения о том, как операции удаления влияют на версии больших двоичных объектов, см. в разделе Управление версиями при операциях удаления.
Моментальные снимки
Репликация объектов не поддерживает моментальные снимки больших двоичных объектов. Ни один из моментальных снимков большого двоичного объекта не реплицируется из исходной учетной записи в целевую учетную запись.
Теги индекса BLOB-объектов
Репликация объектов не копирует теги индекса исходного BLOB-объекта в целевой BLOB-объект.
Распределение больших двоичных объектов по уровням
Репликация объектов поддерживается, если исходная и целевая учетные записи находятся на горячем или холодном уровнях. Исходная и целевая учетные записи могут находиться на разных уровнях. Однако репликация объектов завершится ошибкой, если большой двоичный объект в исходной или целевой учетной записи был перемещен на архивный уровень. Дополнительные сведения о уровнях BLOB-объектов см. в разделе "Уровни доступа" для данных BLOB-объектов.
Неизменяемые большие двоичные объекты
Перечень политик неизменяемости для Хранилища BLOB-объектов Azure включает политики хранения на основе времени и политики удержания по юридическим причинам. Если в учетной записи назначения действует политика неизменяемости, это может повлиять на репликацию объектов. Дополнительные сведения о политиках неизменяемости см. в статье Хранение критически важных для бизнеса данных большого двоичного объекта с помощью неизменяемого хранилища.
Если в учетной записи назначения действует политика неизменяемости на уровне контейнера, то при обновлении или удалении объекта в исходном контейнере операция в исходном контейнере может быть выполнена успешно, но при этом не удастся выполнить репликацию этой операции в контейнере назначения. Дополнительные сведения о том, какие операции запрещены политикой неизменяемости, действие которой ограничено контейнером, см. в разделе Сценарии с областью действия уровня контейнера.
Если в учетной записи назначения действует политика неизменяемости на уровне версии для версии большого двоичного объекта, то при выполнении операции удаления или обновления над версией большого двоичного объекта в исходном контейнере операция над исходным объектом может быть выполнена успешно, но при этом не удастся выполнить репликацию этой операции в объекте назначения. Дополнительные сведения о том, какие операции запрещены политикой неизменяемости, действие которой ограничено контейнером, см. в разделе Сценарии с областью действия уровня версии.
Политики и правила репликации объектов
При настройке репликации объектов создается политика репликации, указывающая исходную учетную запись хранения и целевую учетную запись. Политика репликации включает одно или несколько правил, задающих исходный и целевой контейнеры, и указывает, какие блочные BLOB-объекты в исходном контейнере будут реплицированы.
После настройки репликации объектов служба хранилища Azure периодически проверяет канал изменений для исходной учетной записи и асинхронно реплицирует все операции записи или удаления в целевую учетную запись. Задержка репликации зависит от размера реплицируемого блочного BLOB-объекта.
Политики репликации
При настройке репликации объектов в целевой учетной записи создается политика репликации через поставщика ресурсов службы хранилища Azure. После создания политики репликации служба хранилища Azure назначает ей идентификатор политики. Затем необходимо связать эту политику репликации с исходной учетной записью при помощи идентификатора политики. Чтобы репликация была выполнена, идентификаторы политик в исходной и целевой учетных записях должны совпадать.
Исходная учетная запись может реплицироваться максимум на две целевые учетные записи, при этом можно использовать по одной политике для каждой целевой учетной записи. Аналогичным образом учетная запись может быть целевой учетной записью для максимум двух политик репликации.
Исходная и целевая учетные записи могут находиться в одном или разных регионах. Они могут также находиться в одной подписке или в разных подписках. При необходимости исходные и целевые учетные записи могут находиться в разных клиентах Microsoft Entra. Для каждой пары "исходная учетная запись — конечная учетная запись" может быть создана только одна политика репликации.
Правила репликации
Правила репликации указывают, как служба хранилища Azure будет реплицировать BLOB-объекты из исходного контейнера в целевой. Для каждой политики репликации можно указать до 1000 правил репликации. В каждом правиле репликации определяется один исходный и один целевой контейнер, и каждый из этих контейнеров можно использовать только в одном правиле. Это значит, что в одной политике репликации можно указать не более 1000 исходных и 1000 целевых контейнеров.
При создании правила репликации по умолчанию копируются только новые блочные BLOB-объекты, которые впоследствии добавляются в исходный контейнер. Можно указать, что будут копироваться новые и существующие блочные BLOB-объекты, или можно определить пользовательскую область копирования, которая будет копировать блочные BLOB-объекты, созданные начиная с указанного момента.
Можно также указать один или несколько фильтров в рамках правила репликации, чтобы фильтровать блочные BLOB-объекты по префиксу. При указании префикса только большие двоичные объекты, соответствующие этому префиксу в исходном контейнере, будут скопированы в целевой контейнер.
Оба контейнера, исходный и целевой, должны существовать, прежде чем их можно будет указать в правиле. После создания политики репликации выполнение операций записи в целевом контейнере не допускается. Любые попытки записи в целевой контейнер завершатся ошибкой с кодом 409 (конфликт). Для записи в целевой контейнер с настроенным правилом репликации необходимо либо удалить правило, настроенное для этого контейнера, либо удалить политику репликации. Операции чтения и удаления в целевом контейнере разрешены, если политика репликации активна.
Для большого двоичного объекта в целевом контейнере можно вызвать операцию Задание уровня 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 поддерживается использование полного ИД ресурса в политиках репликации объектов.
В таблице ниже описано, что происходит при создании политики репликации с полным ИД ресурса и именем учетной записи в ситуациях, когда для учетной записи хранения разрешена или запрещена репликация между арендаторами.
| Идентификатор учетной записи хранения в определении политики | Репликация между арендаторами разрешена | Репликация между арендаторами запрещена |
|---|---|---|
| Полный ИД ресурса | Можно создавать политики для одного арендатора. Можно создавать политики для нескольких арендаторов. |
Можно создавать политики для одного арендатора. Можно создавать политики для нескольких арендаторов. |
| Только имя учетной записи | Можно создавать политики для одного арендатора. Можно создавать политики для нескольких арендаторов. |
Невозможно создавать политики ни для одного, ни для нескольких арендаторов. Происходит ошибка, так как службе хранилища Azure не удается проверить, находятся ли исходная и целевая учетные записи в одном арендаторе. Эта ошибка указывает на то, что для записей sourceAccount и destinationAccount в файле определения политики необходимо задать полный ИД ресурса. |
Указание идентификаторов политик и правил
В приведенной ниже таблице представлена сводка значений записей policyId и ruleId в JSON-файле для каждой ситуации.
| При создании файла определения политики для этой учетной записи... | Значение идентификатора политики | Значения идентификаторов правил |
|---|---|---|
| Целевая учетная запись | Строковое значение default. Служба хранилища Azure создаст идентификатор политики автоматически. | Пустая строка. Служба хранилища Azure создаст идентификаторы правил автоматически. |
| Исходная учетная запись | Значение идентификатора политики, которое возвращается при скачивании файла определения политики для целевой учетной записи. | Значения идентификаторов правил, которые возвращаются при скачивании файла определения политики для целевой учетной записи. |
Предотвращение репликации между клиентами 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.
Состояние репликации
Вы можете проверить состояние репликации для большого двоичного объекта в исходной учетной записи. Дополнительные сведения см. в разделе Проверка состояния репликации BLOB-объектов.
Примечание.
Хотя репликация выполняется, невозможно определить процент данных, которые были реплицированы.
Если состояние репликации больших двоичных объектов в исходной учетной записи указывает на сбой, проверьте, не произошло ли это по одной из следующих причин.
- Убедитесь, что в конечной учетной записи настроена политика репликации объектов.
- Убедитесь в том, что целевая учетная запись по-прежнему существует.
- Убедитесь, что целевой контейнер по-прежнему существует.
- Убедитесь в том, что целевой контейнер не находится в процессе удаления или не был удален. Удаление контейнера может занять до 30 секунд.
- Убедитесь в том, что целевой контейнер по-прежнему участвует в политике репликации объектов.
- Если исходный большой двоичный объект зашифрован с помощью предоставленного клиентом ключа при выполнении операции записи, репликация объекта завершится ошибкой. Дополнительные сведения о ключах, представляемых клиентом, см. в статье Указание ключа шифрования при отправке запроса в Хранилище BLOB-объектов.
- Проверьте, был ли исходный или целевой большой двоичный объект перемещен на архивный уровень. Архивные BLOB-объекты нельзя реплицировать с помощью репликации объектов. Дополнительные сведения об архивном уровне см. в разделе "Уровни доступа" для данных BLOB-объектов.
- Убедитесь в том, что целевой контейнер или BLOB-объект не защищен политикой неизменяемости. Учтите, что контейнер или BLOB-объект может наследовать политику неизменяемости от родительского объекта. Дополнительные сведения о политиках неизменяемости см. в статье Обзор неизменяемого хранилища данных BLOB-объектов.
Поддерживаемые компоненты
На поддержку данной функции может повлиять включение протокола Data Lake Storage 2-го поколения, протокола сетевой файловой системы (NFS) 3.0 или протокола SFTP. Если вы включили любую из этих возможностей, см. Сведения о поддержке функций хранилища BLOB-объектов в учетных записях хранения Azure, чтобы оценить поддержку данной функции.
Выставление счетов
Нет затрат на настройку репликации объектов. Сюда входит задача включения канала изменений, включения управления версиями, а также добавления политик репликации. Однако репликация объектов несет затраты на транзакции чтения и записи для исходных и целевых учетных записей, а также исходящие расходы на репликацию данных из исходной учетной записи в целевую учетную запись и расходы на чтение для обработки канала изменений.
Вот разбивка затрат. Сведения о цене каждого компонента затрат см. в разделе Хранилище BLOB-объектов Azure цены.
| Стоимость обновления большого двоичного объекта в исходной учетной записи | Затраты на репликацию данных в целевой учетной записи |
|---|---|
| Стоимость транзакции операции записи | Затраты на транзакцию для чтения записи канала изменений |
| Стоимость хранения большого двоичного объекта и каждого большого двоичного объекта версии1 | Затраты на транзакцию для чтения BLOB-объектов и BLOB-объектов версии2 |
| Стоимость добавления записи канала изменений | Затраты на транзакцию для записи больших двоичных объектов и БОЛЬШИХ двоичныхобъектов версии 2 |
| Стоимость хранения большого двоичного объекта и каждого большого двоичного объекта версии1 | |
| Стоимость исходящеготрафика сети 3 |
1 В исходной учетной записи, если вы не изменили уровень большого двоичного объекта или версии, вы получите счет за уникальные блоки данных в этом BLOB-объекте, его версии. См . цены на управление версиями BLOB-объектов и выставление счетов. В целевой учетной записи для версии выставляются счета за все блоки версии независимо от того, являются ли эти блоки уникальными.
2 Это включает только версии BLOB-объектов, созданные с момента завершения последней репликации.
Репликация 3 объекта копирует всю версию в место назначения (а не только уникальные блоки версии). Эта передача повлечет за собой затраты на исходящий трафик сети. См . цены на пропускную способность.
Совет
Чтобы уменьшить риск непредвиденного счета, включите репликацию объектов в учетной записи, содержащей только небольшое количество объектов. Затем измеряйте влияние на затраты, прежде чем включить функцию в рабочем параметре.