Однократная запись на уровне контейнера считывает много политик (WORM) для неизменяемых данных BLOB-объектов
Однократная запись на уровне контейнера — это тип политики неизменяемости, которую можно задать на уровне контейнера. Дополнительные сведения о неизменяемом хранилище для Хранилище BLOB-объектов Azure см. в разделе "Хранение критически важных для бизнеса больших двоичных объектов" с неизменяемым хранилищем в неизменяемом хранилище в состоянии записи один раз, чтение многих (WORM)
Availability
Политики WORM на уровне контейнера (CLW) доступны для всех новых и существующих контейнеров. Эти политики поддерживаются для учетных записей хранилища BLOB-объектов общего назначения версии 2, блочных BLOB-объектов класса Premium, общего назначения версии 1 (устаревшая версия) и хранилища BLOB-объектов (устаревшая версия).
Совет
Корпорация Майкрософт рекомендует обновить учетные записи общего назначения версии 1 до версии 2 общего назначения, чтобы воспользоваться дополнительными функциями. Сведения об обновлении существующей учетной записи хранения общего назначения версии 1 см. в статье Обновление учетной записи хранения.
Эта функция поддерживается для учетных записей иерархического пространства имен. Если иерархическое пространство имен включено, нельзя переименовать или переместить большой двоичный объект, если большой двоичный объект находится в неизменяемом состоянии. Имя BLOB-объекта и структура каталогов предоставляют необходимые данные уровня контейнера, которые нельзя изменить после неизменяемой политики.
Для этой функции нет процесса включения; он автоматически доступен для всех контейнеров. Дополнительные сведения о настройке политики в новом или существующем контейнере см. в разделе "Настройка политик неизменяемости WORM на уровне контейнера".
Удаление
Контейнер с набором политик WORM уровня контейнера должен быть пустым перед удалением контейнера. Если в контейнере есть набор политик с включенным иерархическим пространством имен, каталог должен быть пуст, прежде чем его можно будет удалить.
Сценарии
| Сценарий | Запрещенные операции | Защита BLOB-объектов | Защита контейнеров | Защита учетных записей |
|---|---|---|---|---|
| Контейнер защищается активной политикой хранения на основе времени с областью действия контейнера и/или удержанием по юридическим причинам. | Удаление BLOB-объекта, вставка BLOB-объекта1, задание метаданных BLOB-объекта, вставка страницы, задание свойств BLOB-объекта, создание моментального снимка BLOB-объекта, инкрементное копирование BLOB-объекта, добавление блока2 | Все большие двоичные объекты в контейнере неизменяемы для содержимого и метаданных пользователей. | Удаление контейнера завершается ошибкой, если политика WORM уровня контейнера действует. | служба хранилища удаление учетной записи завершается ошибкой, если контейнер имеет хотя бы один большой двоичный объект. |
| Контейнер защищен политикой хранения с истекшим сроком действия с областью действия контейнера, и не действует удержание по юридическим причинам | Вставка BLOB-объекта1, задание метаданных BLOB-объекта, вставка страницы, задание свойств BLOB-объекта, создание моментального снимка BLOB-объекта, инкрементное копирование BLOB-объекта, добавление блока2 | Операции удаления не допускаются. Операции перезаписи не допускаются. | Удаление контейнера завершается сбоем, если в контейнере существует хотя бы один BLOB-объект, независимо от того, заблокирована или разблокирована политика. | Удаление учетной записи службы хранилища завершается сбоем, если существует по крайней мере один контейнер с заблокированной политикой хранения на основе времени. Разблокированные политики не обеспечивают защиту от удаления. |
1 Служба хранилища Azure допускает использование операции вставки BLOB-объекта для создания нового большого двоичного объекта. Последующие операции перезаписи существующего пути больших двоичных объектов в неизменяемом контейнере не допускаются.
2 Операция добавления блока разрешена только для политик с включенным свойством allowProtectedAppendWrites или allowProtectedAppendWritesAll.
Разрешение на запись добавочных BLOB-объектов
Добавочные BLOB-объекты состоят из блоков данных и оптимизированы для операций добавления данных, необходимых для сценариев аудита и ведения журнала. При разработке добавочные BLOB-объекты позволяют только добавлять новые блоки в конец большого двоичного объекта. Независимо от неизменности изменение или удаление существующих блоков в добавочном большом двоичном объекте не допускается. Дополнительные сведения о добавочных BLOB-объектах см. в разделе О добавочных BLOB-объектах.
Параметр свойства allowProtectedAppendWrites позволяет создавать новые блоки в добавочный большой двоичный объект при сохранении неизменяемости защиты и соответствия требованиям. Если это значение включено, вы можете создать добавочный BLOB-объект непосредственно в защищенном политикой контейнере и продолжить добавлять новые блоки данных в конец добавочного BLOB-объекта с помощью операции Append Block. Можно добавлять только новые блоки; существующие блоки изменять или удалять нельзя. Включение этого параметра не влияет на поведение блочных или страничных BLOB-объектов.
Параметр свойства AllowProtectedAppendWritesAll предоставляет те же разрешения, что и свойство allowProtectedAppendWrites и добавляет возможность записи новых блоков в блочный большой двоичный объект. API Хранилища BLOB-объектов не предоставляет приложениям возможность делать это напрямую. Однако приложения могут сделать это с помощью методов добавления и очистки, доступных в API Data Lake Storage 2-го поколения. Кроме того, это свойство позволяет приложениям Майкрософт, таким как Фабрика данных Azure, добавлять блоки данных с помощью внутренних API. Если рабочие нагрузки зависят от любого из этих средств, используйте это свойство, чтобы избежать ошибок, которые могут появляться при попытке добавить данные в BLOB-объекты.
Добавочные BLOB-объекты остаются в неизменяемом состоянии в течение действующего периода хранения. Поскольку могут быть добавлены новые данные, помимо первоначального создания большого двоичного объекта, существует небольшая разница в способе определения срока хранения. Эффективный срок хранения — это разница между временем последнего изменения добавочного BLOB-объекта и заданным пользователем периодом хранения. Аналогично, когда интервал хранения продлевается, при вычислении действующего периода хранения неизменяемое хранилище использует самое последнее значение указываемого пользователем интервала хранения.
Например, предположим, что пользователь создает политику хранения на основе времени с включенным свойством AllowProtectedAppendWrites и интервалом хранения 90 дней. Сегодня в контейнере создается добавочный BLOB-объект logblob1, и новые журналы будут добавляться в этот добавочный BLOB-объект в течение следующих 10 дней. Таким образом, действующий период хранения в случае logblob1 составит 100 дней начиная с сегодняшнего дня (время последнего добавления + 90 дней).
Политики хранения на основе разблокированного времени позволяют включить и отключить параметры свойств AllowProtectedAppendWritesAll и allowProtectedAppendWritesAll в любое время. После блокировки политики хранения на основе времени невозможно изменить параметры свойств allowProtectedAppendWrites и AllowProtectedAppendWritesAll .
Ограничения
Для учетной записи хранения максимальное количество контейнеров с неизменяемой политикой (хранением на основе времени или юридическим удержанием) составляет 10 000.
Для контейнера максимальное число тегов юридического удержания в любое время равно 10.
Максимальная длина тега удержания по юридическим причинам составляет 3 буквенно-цифровых символа. Максимальная длина составляет 23 буквенно-цифровых символа.
Для контейнера в течение длительности политики сохраняются не более 10 журналов аудита политики юридического удержания.