Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Функция репликации объектов асинхронно копирует блочные BLOB-объекты между исходной и целевой учетными записями хранения. Ниже перечислены некоторые сценарии, поддерживаемые репликацией объектов.
- Минимизация задержки. Репликация объектов может сократить задержку запросов на чтение, позволяя клиентам использовать данные из региона, наиболее близкого к их физическому расположению.
- Увеличьте эффективность для вычислительных рабочих нагрузок. При репликации объектов вычислительные рабочие нагрузки могут обрабатывать те же наборы блочных BLOB-объектов в разных регионах.
- Оптимизация распределения данных. Вы можете обрабатывать или анализировать данные в одном месте, а затем реплицировать только результаты в дополнительные регионы.
- Оптимизация затрат. После репликации данных можно сократить затраты, переместив его на архивный уровень с помощью политик управления жизненным циклом.
На следующей схеме показано, как репликация объектов реплицирует блочные BLOB-объекты из исходной учетной записи хранения в одном регионе в конечные учетные записи в двух разных регионах.
Дополнительные сведения о настройке репликации объектов см. в разделе Настройка репликации объектов.
Предварительные требования и предостережения для репликации объектов
Для репликации объектов требуется, чтобы были также включены следующие функции службы хранилища Azure.
- Канал изменений. Необходимо включить в исходной учетной записи. Сведения о включении канала изменений см. в разделе Включение и отключение канала изменений.
- Версионирование BLOB: должно быть включено как в исходной, так и в целевой учетной записи. Чтобы узнать, как включить версионность, см. статью Включение и управление версиями BLOB-объектов.
Включение канала изменений и версионирования объектов BLOB может привести к дополнительным затратам. Дополнительные сведения см. на странице цен службы хранилища Azure.
Репликация объектов поддерживается для универсальных учетных записей хранения версии 2 и премиум-учетных записей с блоб-объектами. Исходные и целевые учетные записи должны быть учетными записями общего назначения v2 или учетными записями блоков BLOB премиум-класса. Функция репликации объектов поддерживает только блочные BLOB-объекты; добавочные и страничные BLOB-объекты не поддерживаются.
Репликация объектов поддерживается для учетных записей, зашифрованных с помощью ключей, управляемых корпорацией Майкрософт, или ключей, управляемых клиентом. Дополнительные сведения о ключах, управляемых клиентом, см. в разделе Ключи, управляемые клиентом, для шифрования службы хранилища Azure.
Репликация объектов не поддерживается для BLOB-объектов в исходной учетной записи, зашифрованных с помощью ключа, предоставляемого клиентом. Дополнительные сведения о ключах, представляемых клиентом, см. в статье Указание ключа шифрования при отправке запроса в Хранилище BLOB-объектов.
В политике репликации объектов не поддерживается отработка отказа, управляемая клиентом, ни для исходной, ни для целевой учетной записи.
Репликация объектов пока не поддерживается в учетных записях с включенным иерархическим пространством имен.
Репликация объектов не поддерживается для блобов, загружаемых с помощью API Data Lake Storage.
Принцип действия репликации объектов
Функция репликации объектов асинхронно копирует BLOB-объекты в контейнере в соответствии с правилами, которые вы настраиваете. Содержимое большого двоичного объекта, все связанные с ним версии, а также метаданные и свойства большого двоичного объекта копируются из исходного контейнера в целевой.
Внимание
Так как данные блочных BLOB-объектов реплицируются асинхронно, исходная учетная запись и целевая учетная запись не будут немедленно синхронизированы.
OR теперь поддерживает приоритетную репликацию, которая определяет приоритет репликации всех операций в политике OR. Если включена репликация приоритета OR, производительность репликации всех операций улучшается. Если исходная и целевая учетная запись политики репликации находятся на одном континенте, репликация по приоритету OR также выполняется для 99,0% объектов в течение 15 минут при поддерживаемых рабочих нагрузках. Производительность функций гарантируется соглашением об уровне обслуживания (SLA). Дополнительные сведения см. в разделе об уровне обслуживания и статье о приоритете репликации объектов.
Вы также можете проверить состояние репликации в исходном BLOB-объекте, чтобы определить, завершена ли репликация. Дополнительные сведения см. в разделе Проверка состояния репликации BLOB-объектов.
Управление версиями BLOB-объекта
Для репликации объектов требуется включить управление версиями больших двоичных объектов как в исходной, так и в целевой учетной записи. При изменении реплицированного большого двоичного объекта в исходной учетной записи в этой же учетной записи создается новая версия большого двоичного объекта, отражающая предыдущее его состояние до внесения изменений. Текущая версия в исходной учетной записи отражает самые последние обновления. Текущая версия и любые предыдущие версии реплицируются в целевую учетную запись. Дополнительные сведения о том, как операции записи влияют на версии больших двоичных объектов, см. в разделе Управление версиями при операциях записи.
Если в вашей учетной записи хранения действуют политики репликации объектов, вы не можете отключить управление версиями BLOB для этой учетной записи. Перед отключением версирования BLOB-объектов необходимо удалить все политики репликации объектов в учетной записи.
Примечание.
В место назначения копируются только BLOB. Идентификатор версии большого двоичного объекта не копируется. После размещения BLOB в целевом местоположении назначается новый идентификатор версии.
Удаление объекта BLOB в исходной учетной записи
Когда BLOB-объект удаляется из исходной учетной записи, его текущая версия становится предыдущей, и текущая версия больше не существует. Все существующие предыдущие версии блоба сохраняются. Это состояние реплицируется в целевую учетную запись. Дополнительные сведения о том, как операции удаления влияют на версии BLOB, см. в разделе Управление версиями при операциях удаления.
Моментальные снимки
Репликация объектов не поддерживает моментальные снимки больших двоичных объектов. Моментальные снимки блоба в исходной учетной записи не реплицируются в целевую учетную запись.
Теги индекса BLOB-объектов
Репликация объектов не копирует теги индекса исходного BLOB-объекта в целевой BLOB-объект.
Распределение двоичных объектов по уровням
Репликация объектов поддерживается, если исходные и целевые учетные записи находятся на любом уровне в сети (горячий, холодный или холодный). Исходные и целевые учетные записи могут находиться на разных уровнях. Однако репликация объектов ошибается, если блоб в исходной или целевой учетной записи перемещен на архивный уровень. Дополнительные сведения о уровнях BLOB-объектов см. в разделе "Уровни доступа" для данных BLOB-объектов.
Неизменяемые блобы
Политики неизменяемости для Azure Blob Storage включают временные политики удержания и юридические блокировки. Если политика неизменяемости действует в целевой учетной записи, может быть затронута репликация объектов. Дополнительные сведения о политиках неизменяемости см. в статье Хранение критически важных для бизнеса данных большого двоичного объекта с помощью неизменяемого хранилища.
Если в целевом контейнере есть политика неизменяемости на уровне контейнера, изменения объектов в исходном контейнере, например обновления или удаления, по-прежнему могут завершиться успешно. Однако эти изменения могут не реплицироваться в целевой контейнер из-за ограничения неизменяемости. Дополнительные сведения о том, какие операции запрещены политикой неизменяемости, действие которой ограничено контейнером, см. в разделе Сценарии с областью действия уровня контейнера.
Если версия большого двоичного объекта целевой учетной записи имеет активную политику неизменяемости уровня версии, операция удаления или обновления, выполняемая в соответствующей версии большого двоичного объекта исходного контейнера, может завершиться успешно. Однако репликация этой операции в целевой объект завершается ошибкой. Дополнительные сведения о том, какие операции запрещены политикой неизменяемости, действие которой ограничено контейнером, см. в разделе Сценарии с областью действия уровня версии.
Политики и правила репликации объектов
При настройке репликации объектов создается политика репликации, указывающая исходную учетную запись хранения и целевую учетную запись. Политика репликации включает одно или несколько правил, которые определяют исходные и целевые контейнеры и указывают, какие исходные объекты хранения реплицируются.
После настройки репликации объектов служба хранилища Azure периодически проверяет канал изменений для исходной учетной записи и асинхронно реплицирует все операции записи или удаления в целевую учетную запись. Задержка репликации зависит от размера реплицируемого блочного BLOB-объекта.
Политики репликации
При настройке репликации объектов вы создаете политику репликации в учетной записи назначения через поставщика ресурсов Azure Storage. После создания политики репликации служба хранилища Azure назначает ей идентификатор политики. Затем необходимо связать эту политику репликации с исходной учетной записью при помощи идентификатора политики. Чтобы репликация была выполнена, идентификаторы политик в исходной и целевой учетных записях должны совпадать.
Исходная учетная запись может реплицироваться максимум на две целевые учетные записи, при этом можно использовать по одной политике для каждой целевой учетной записи. Аналогичным образом учетная запись может служить целевой учетной записью не более двух политик репликации.
Исходные и целевые учетные записи могут находиться в одном регионе или в разных регионах. Они также могут находиться в одной подписке или в разных подписках. При необходимости исходные и целевые учетные записи могут находиться в разных клиентах Microsoft Entra. Для каждой пары исходной или целевой учетной записи может быть создана только одна политика репликации.
Правила репликации
Правила репликации определяют, как Azure Storage реплицирует блобы из исходного контейнера в целевой контейнер. Для каждой политики репликации можно указать до 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-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 в файле определения политики в каждом сценарии.
| При создании файла определения политики для этой учетной записи... | Установите идентификатор политики на это значение | Установите идентификаторы правил на это значение |
|---|---|---|
| Целевой счет | Строковое значение 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 для управления набором учетных записей хранения. Например, можно создать политику с deny эффектом, чтобы предотвратить создание учетной записи хранения, в которой свойство 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-объектов.
Поддержка функций
На поддержку данной функции может повлиять включение протокола Data Lake Storage 2-го поколения, протокола сетевой файловой системы (NFS) 3.0 или протокола SFTP. Если вы включили любую из этих возможностей, см. Поддержка функций Blob Storage в учетных записях хранения Azure, чтобы оценить поддержку этой функции.
Выставление счетов
Нет затрат на настройку репликации объектов, включая задачу включения канала изменений, включения управления версиями и добавления политик репликации. Однако репликация объектов несет затраты на транзакции чтения и записи в учетных записях источника и назначения. Взимается плата за репликацию данных из исходной учетной записи в целевую учетную запись, а также взимается плата за чтение при обработке канала изменений.
Вот разбивка затрат. Сведения о цене каждого компонента затрат см. в разделе Цены на хранилище Blob в Azure.
| Стоимость обновления объекта Blob в исходном аккаунте | Затраты на репликацию данных в целевой учетной записи |
|---|---|
| Затраты на выполнение операции записи | Затраты на транзакцию для чтения записи из потока изменений |
| Стоимость хранения блоба и каждой версии блоба1 | Затраты на транзакцию для чтения BLOB и его версий2 |
| Стоимость добавления записи в журнал изменений | Затраты на транзакцию для записи больших двоичных объектов и их версий2 |
| Затраты на получение данных на прохладных и холодных уровнях | Стоимость хранения блоба и каждой версии блоба1 |
| Стоимость исходящеготрафика сети 3 |
1 На исходной учетной записи, если уровень объекта blob или его версии не изменяется, вы платите за уникальные блоки данных, содержащиеся в этом объекте blob и его версиях. Смотрите цены на версионирование BLOB-объектов и выставление счетов. В целевой учетной записи для каждой версии выставляются счета за все блоки версии, независимо от того, уникальны ли эти блоки.
2 Это включает только версии BLOB-объектов, созданные с момента завершения последней репликации.
3 Репликация объекта копирует всю версию в место назначения (а не только уникальные блоки версии). Эта передача повлечет за собой затраты на исходящий трафик сети. Смотрите цены на пропускную способность.
Совет
Чтобы снизить риск непредвиденного счета, включите репликацию объектов в учетной записи, содержащей только несколько объектов. Затем измерьте влияние на затраты, прежде чем включить функцию в рабочей среде.