2.49 PutBucketLifecycle

Создает новую конфигурацию жизненного цикла для сегмента или заменяет существующую конфигурацию жизненного цикла.
Наряду со стандартными заголовками, система поддерживает параметры, заголовки и элементы специфичные для данной операции, перечисленные ниже
Подробную информацию об операции и примеры см. в документации AWS: PutBucketLifecycle

Предыдущее название операции: PUT Bucket lifecycle

Примечание. Только владелец хранилища может создавать правила жизненного цикла.

Примечание. Не следует устанавливать правило жизненного цикла и конфигурацию межрегиональной репликации для одного и того же бакета.


Заголовки запроса (Request Headers)

  • Content-MD5
Система поддерживает следующие опциональные заголовки запроса в качестве расширения операции PUT Bucket lifecycle.
  • x-gmt-tieringinfo
  • x-gmt-compare
  • x-gmt-post-tier-copy

Заголовок x-gmt-tieringinfo

Этот заголовок запроса позволяет настроить бакет для автоматического перемещения объектов из локального хранилища в удаленную систему хранения по расписанию. Для получения дополнительной информации о функции автоматического многоуровневого хранения в см. раздел «Обзор функции автоматического многоуровневого хранения».

Заголовок x-gmt-tieringinfo имеет следующий формат:
x-gmt-tieringinfo: PROTOCOL|EndPoint:Endpoint,Action:Action[,Mode:proxy][,TieringBucket:TieringBucket]

  • PROTOCOL (обязательно) — укажите одно из следующих значений:
    • S3 - перемещение объектов в хранилище Amazon S3;
    • S3GLACIER - перемещение объектов в Amazon Glacier;
    • GCS - перемещение объектов в Google Cloud Storage;
    • AZURE - перемещение объектов в Microsoft Azure;
    • SPECTRA - перемещение объектов в хранилище Spectra Logic BlackPearl
    Примечание. Если вы используете систему, совместимую с S3, отличную от Amazon S3, Glacier или Google Cloud Storage, используйте «S3» в качестве протокола. Это касается в том числе и, например, размещение данных в удаленном регионе RTCloud.
    Примечание. Ограничения на автоматическое размещение в зависимости от типа хранилища:
    • По умолчанию максимальный размер объекта, который может быть автоматически размещен в Amazon, Google или других совместимых с S3 хранилищах, составляет 50 ГБ. Это ограничение не применяется к размещению в Azure или Spectra BlackPearl.
    • Размещение в Azure или Spectra BlackPearl не поддерживается для исходных хранилищ, в которых включено версионирование или которое было включено ранее.
    • При использовании автоматического размещения в Spectra BlackPearl для хранилища объекты в этом хранилище не будут автоматически размещаться, если их размер не превышает 5 МБ. Объекты размером 5 МБ или меньше останутся на месте.

  • EndPoint:EndPoint (обязательно) — URL-адрес конечной точки сервиса, который будет использоваться в качестве места назначения для автоматического многоуровневого хранения. Например, для Amazon S3 выберите региональную конечную точку, наиболее подходящую для вашего местоположения (например, s3-us-west-1.amazon-aws.com). Или в случае Spectra BlackPearl укажите URL-адрес для вашего места назначения Spectra BlackPearl. Если конечным местом назначения для многоуровневого хранения является Glacier, необходимо указать здесь конечную точку Amazon S3, а НЕ конечную точку Glacier. Система сначала переместит объекты на указанную вами конечную точку Amazon S3, а затем оттуда они будут немедленно перемещены в соответствующее местоположение Glacier.
    Примечание. Необходимо использовать вложенное кодирование URL. Сначала закодируйте значение конечной точки (саму конечную точку), а затем закодируйте все значение x-gmt-tieringinfo.
    Примечание. После настройки автоматического распределения по уровням хранения (auto-tiering lifecycle) для исходного бакета вы не сможете впоследствии изменить конечную точку распределения по уровням хранения для этого исходного бакета.

  • Action: Action (обязательно) — Этот параметр определяет, как система будет обрабатывать запросы S3 GET Object для объектов, которые были переведены в место назначения многоуровневого хранения. Варианты:
    • stream — Если клиент отправляет запрос GET Object , система извлекает объект из места назначения и передает его клиенту потоком. Этот метод поддерживается только в том случае, если используется протокол S3, GCS или AZURE.
    • nostream — Если клиент отправляет запрос GET Object , система отклоняет запрос GET. Вместо этого клиенты должны отправить запрос POST Object restore, чтобы временно восстановить копию объекта в локальное хранилище.
    Если используется протокол S3, GCS или AZURE, можно использовать либо «stream», либо «nostream». Если используется протокол S3GLACIER или SPECTRA, необходимо использовать «nostream» (опция «stream» не поддерживается для этих мест назначения).
  • Mode: proxy (необязательно) — Если вы укажете этот параметр, то:
    • Все объекты, загруженные в бакет с этого момента (все объекты, загруженные после успешной отправки запроса на изменение жизненного цикла бакета PUT), будут немедленно переведены в целевую систему.
    • Любые объекты, уже находящиеся в бакете на момент отправки запроса на изменение жизненного цикла бакета PUT, будут подчиняться графику перевода, определенному в теле запроса.
    Примечание. Если вы хотите использовать режим прокси и не хотите, чтобы объекты, уже находящиеся в хранилище, автоматически распределялись по уровням в зависимости от расписания, вам все равно необходимо включить тело запроса. В этом случае в конфигурации жизненного цикла в теле запроса вы можете установить атрибут «Status» в значение «Disabled» (см. пример ). В результате объекты, уже находящиеся в бакете, не будут автоматически распределяться по уровням, и все объекты, впоследствии загруженные в бакет (после успешной отправки запроса PUT Bucket lifecycle), будут немедленно перемещены в целевую систему.
    Режим прокси поддерживается только в том случае, если используется протокол S3, GCS или AZURE (режим прокси не поддерживается для многоуровневого хранения S3GLACIER или SPECTRA). Для получения дополнительной информации о режиме прокси, также известном как «режим моста», см. Обзор функции автоматического многоуровневого хранения.
  • TieringBucket:TieringBucket ((необязательно)— Имя бакета, в который будут перемещаться объекты в целевой системе многоуровневого хранения. Это может быть:
    • Имя бакета, который уже существует в целевой системе и владельцем которой являетесь. В этом случае система будет использовать эту существующий бакет в качестве целевого.
    • Имя бакета, который вы хотите, чтобы был создан в целевой системе для использования в качестве целевого. Убедитесь, что вы выбрали имя бакета, которое с высокой вероятностью будет уникальным в целевой системе. Если указанное вами имя бакета не является уникальным в целевой системе, система не сможет создать бакет, и запрос PUT Bucket lifestyle завершится неудачей.
    Если вы опустите параметр tiering bucket, то в целевой системе будет создан бакет многоуровневого хранения со следующим именем:
    <исходное имя корзины, усеченное до 34 символов>-<28-символьная случайная строка>
     # Example 1 (before URL encoding) Tiering to Amazon S3, into target bucket
     # named 'bucket12'. Streaming for local GETs will be supported.
     x-gmt-tieringinfo: S3|EndPoint:http://s3.amazonaws.com,Action:stream,TieringBucket:bucket12
     
     # Example 1 after nested URL encoding (endpoint value first, then whole
     # header value)
     x-gmt-tieringinfo: S3%7CEndPoint%3Ahttp%253A%252F%252Fs3.amazonaws.com%2CAction%3Astream%2CTieringBucket%3Abucket12
     
     # Example 2 (before URL encoding) Tiering to Azure. HyperStore will derive target
     # bucket name from source bucket name. Streamed local GETs will not be supported,
     # clients must use Restore.
     x-gmt-tieringinfo:AZURE|EndPoint:https://blob.core.windows.net,Action:nostream
    
     # Example 2 after nested URL encoding (endpoint value first, then whole
     # header value)
     x-gmt-tieringinfo:AZURE%7CEndPoint%3Ahttps%253A%252F%252Fblob.core.windows.net%2CAction%3Anostream
    
    ВАЖНО! Если вы используете заголовок запроса x-gmt-tieringinfo, то для элемента тела запроса "StorageClass" необходимо указать "GLACIER". Установите Storage Class на GLACIER, даже если конечным местом назначения для многоуровневого хранения является AmazonS3 или другое совместимое с S3 хранилище.

Заголовок x-gmt-compare

Если вы включите этот заголовок в свой запрос "PUT Bucket lifecycle" и установите значение заголовка "LAT", то в правилах жизненного цикла, которые вы настроите с помощью компаратора "Days", правило будет реализовано как количество дней с момента последнего доступа к объекту (Last Access Time=LAT). Если вы не используете этот расширенный заголовок или если вы включаете заголовок, но не присваиваете ему значение или присваиваете любое значение, кроме "LAT", то правила жизненного цикла на основе "Days" будут реализованы как количество дней с момента создания объекта (поведение Amazon S3 по умолчанию). Вы можете использовать этот заголовок для создания: правил автоматического ранжирования на основе последнего доступа (используйте этот заголовок, а также заголовок x-gmt-tierinfo). правил истечения срока действия на основе последнего доступа (используйте этот заголовок, но не заголовок x-gmt-tierinfo).
Примечание. Время последнего доступа к объекту обновляется, если к объекту обращаются либо для получения данных (GET или HEAD), либо для их изменения (PUT/POST/Copy). Если объект создан, но к нему больше никогда не обращались, время его последнего доступа будет равно времени его создания.
Примечание. Если вы используете заголовок x-gmt-compare и устанавливаете для него значение "LAT", он не применяется ни к одному из правил NoncurrentVersionTransition или NoncurrentVersionExpiration в рамках политики жизненного цикла (для устаревших версий версионированных объектов). Эти типы правил всегда основаны на времени, прошедшем с момента, когда версия объекта стала устаревшей (была заменена новой версией объекта).

Заголовок x-gmt-post-tier-copy

Если вы используете заголовок x-gmt-tieringinfo для настройки автоматического ранжирования для бакета, вы также можете дополнительно использовать заголовок x-gmt-post-tier-copy, чтобы указать количество дней, в течение которых должна храниться локальная копия объектов, находящихся в режиме автоматического ранжирования. Например, если вы установите x-gmt-post-tier-copy: 7, то после автоматического ранжирования каждого объекта в целевое хранилище копия объекта будет храниться в исходном бакете в течение 7 дней. После этого локальная копия будет удалена, и локально будут сохранены только метаданные объекта. Верхнего предела для этого значения нет. Таким образом, если вы хотите, чтобы срок хранения локальной копии был практически неограниченным, вы можете, например, установить этот заголовок равным 36500, чтобы указать срок хранения локальной копии в 100 лет. Если вы опустите заголовок запроса x-gmt-post-tier-copy, то по умолчанию локальные объекты удаляются после их успешного автоматического переноса в целевую систему многоуровневого хранения, и локально сохраняются только метаданные объектов.


Элементы запроса (Request Elements)

  • AbortIncompleteMultipartUpload
  • Date
  • Days
  • DaysAfterInitiation
  • Expiration
  • ExpiredObjectDeleteMarker
  • Filter
  • ID
  • LifecycleConfiguration
  • NoncurrentDays
  • NoncurrentVersionExpiration
  • NoncurrentVersionTransition
  • Prefix 
    Примечание. Если вы используете «Режим моста» («Bridge Mode») (в котором объекты автоматически распределяются по уровням сразу после загрузки в систему), оставьте поле «Prefix» пустым. Режим моста не поддерживает фильтрацию по префиксу.
  • Rule
  • Status
  • StorageClass
    Примечание. Если вы используете заголовок запроса расширения x-gmt-tieringinfo, то для элемента запроса "StorageClass" необходимо указать "GLACIER". Установите класс хранения на GLACIER, даже если конечным местом назначения для многоуровневого хранения является Amazon S3, Google, Azure или другая система.
    Обратите внимание, что в случае многоуровневого хранения в Azure, если вы выполните вызов GET Bucket (List Objects) для бакета, для любых объектов, которые были перенесены в Azure, ответ будет указывать, что класс хранения этих объектов — STANDARD (несмотря на то, что вы указали GLACIER в качестве класса хранения в вызове PUT Bucket Lifecycle). Такое поведение является ожидаемым. В случае объектов, перенесенных в любое другое место назначения, вызов GET Bucket (List Objects) будет указывать, что объекты имеют класс хранения, указанный вами в вызове PUT Bucket Lifecycle.
  • Transition

Тело запроса при использовании режима прокси (Proxy Mode)

Если вы используете режим "прокси" для управления жизненным циклом бакета (см. "Расширение API S3" в разделе "Заголовки запроса"), вам все равно необходимо включить тело запроса. Конфигурация жизненного цикла, указанная в теле запроса, будет применяться к объектам, уже находящимся в бакете (если таковые имеются), в то время как режим прокси (для немедленного перехода) будет применяться ко всем объектам, загруженным после успешной отправки запроса PUT на управление жизненным циклом бакета. Если в бакете уже есть объекты, и вы не хотите применять к ним никаких переходов, сделайте тело запроса конфигурацией жизненного цикла с атрибутом "Status", установленным в значение "Disabled" ("Отключено"), как в следующем примере:

<LifecycleConfiguration>
    <Rule>
        <ID>
               DummyLifecycleConfig
        </ID>
        <Filter>
               <Prefix></Prefix>
        </Filter>
        <Status>
               Disabled
        </Status>
        <Transition>
            <StorageClass>
                GLACIER
            </StorageClass>
            <Days>
                0
            </Days>
        </Transition>
    </Rule>
</LifecycleConfiguration>





  см. также:

к S3 API


Рейтинг@Mail.ru Яндекс.Метрика