Access tiers for blob data

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

• Горячий уровень — сетевой уровень, оптимизированный для хранения часто используемых или изменяемых данных. Горячий уровень имеет самые высокие затраты на хранение, но самые низкие затраты на доступ.
• Холодный уровень — сетевой уровень, оптимизированный для хранения редко используемых или изменяемых данных. Данные на холодном уровне должны храниться не менее 30 дней. Уровень "холодный" имеет более низкие затраты на хранение и более высокие затраты на доступ по сравнению с горячим уровнем.
• Холодный уровень — сетевой уровень, оптимизированный для хранения данных, которые редко обращаются или изменяются, но по-прежнему требуют быстрого извлечения. Данные на холодном уровне должны храниться не менее 90 дней. На холодном уровне хранилища данные хранить дешевле, зато доступ к ним стоит дороже по сравнению с горячим уровнем.
• Архивный уровень — автономный уровень, оптимизированный для хранения данных, которые используются редко и имеют нестрогие требования к задержке (порядка нескольких часов). Данные на уровне архива должны храниться не менее 180 дней.

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

Сетевые уровни доступа

Когда данные хранятся в онлайн-уровне доступа (горячем, прохладном или холодном), пользователи могут сразу же получить к ним доступ. Горячий уровень — это лучший выбор для данных, которые активно используются. Холодный или холодный уровень идеально подходит для данных, доступ к которым осуществляется реже, но он по-прежнему должен быть доступен для чтения и записи.

Example usage scenarios for the hot tier include:

• Для данных, которые активно используются или данные, которые вы ожидаете, потребуются частые операции чтения и записи.
• Data that's staged for processing and eventual migration to the cool access tier.

Ниже приведены сценарии использования для холодных и холодных уровней доступа:

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

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

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

Blobs are subject to an early deletion penalty if they are deleted, overwritten or moved to a different tier before the minimum number of days required by the tier have transpired. For example, a blob in the cool tier in a general-purpose v2 account is subject to an early deletion penalty if it's deleted or moved to a different tier before 30 days has elapsed. For a blob in the cold tier, the deletion penalty applies if it's deleted or moved to a different tier before 90 days has elapsed. Эта плата пропорциональна. Например, если большой двоичный объект перемещается на холодный уровень, а затем удаляется через 21 дней, вы будете взимать плату за досрочное удаление, эквивалентную 9 (30 минус 21) дней хранения этого большого двоичного объекта на холодном уровне. Плата за досрочное удаление также возникает, если весь объект в течение указанного периода времени перезаписывается с помощью любой операции (т. е. Put Blob, Put Block List или Copy Blob). This charge is prorated based on the data storage price of the corresponding tier, i.e. deleting an archived blob after 120 days will lead to this object being charged for 180 days.

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

Archive access tier

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

• Долгосрочное резервное копирование, вторичное резервное копирование и архивные наборы данных
• Исходные (необработанные) данные, которые необходимо хранить даже после их окончательной обработки.
• Данные соответствия требованиям и архивные данные, которые нужно хранить в течение длительного времени и которые вряд ли когда-либо будут использоваться.

Чтобы узнать, как переместить большой двоичный объект на архивный уровень, см . статью "Архивировать большой двоичный объект".

Данные должны оставаться на архивном уровне не менее 180 дней. За их досрочное удаление будет взиматься плата. Например, если большой двоичный объект перемещается на архивный уровень, а затем удаляется или перемещается на горячий уровень через 45 дней, плата за раннее удаление будет взиматься, эквивалентная 135 (180 минус 45) дней хранения этого большого двоичного объекта на уровне архива.

Хотя блоб находится на уровне архива, его нельзя считывать или изменять. To read or download a blob in the archive tier, you must first rehydrate it to an online tier, either hot, cool, or cold. Data in the archive tier can take up to 15 hours to rehydrate, depending on the priority you specify for the rehydration operation. For more information about blob rehydration, see Overview of blob rehydration from the archive tier.

Метаданные архивированного BLOB-объекта остаются доступными для чтения, так что вы можете перечислить сам объект и его свойства, метаданные и теги индекса. Metadata for a blob in the archive tier is read-only, while blob index tags can be read or written. Storage costs for metadata of archived blobs will be charged on cool tier rates. Snapshots aren't supported for archived blobs.

The following operations are supported for blobs in the archive tier:

• Copy Blob
• Delete Blob
• Undelete Blob
• Поиск BLOB-объектов по тегам
• Получение метаданных BLOB-объекта
• Get Blob Properties
• Get Blob Tags
• List Blobs
• Set Blob Tags
• Set Blob Tier

Только учетные записи хранения, настроенные для LRS, GRS или RA-GRS, позволяют перемещать блобы на архивный уровень. Уровень архива не поддерживается для учетных записей ZRS, GZRS или RA-GZRS. Дополнительные сведения о конфигурациях избыточности для Azure Storage см. в статье Избыточность хранилища Azure.

To change the redundancy configuration for a storage account that contains blobs in the archive tier, you must first rehydrate all archived blobs to the hot, cool, or cold tier. Because rehydration operations can be costly and time-consuming, Microsoft recommends that you avoid changing the redundancy configuration of a storage account that contains archived blobs.

Перенос учетной записи хранения из LRS в GRS поддерживается, при условии, что никакие блоб-объекты не были перемещены на архивный уровень, когда учетная запись была настроена для LRS. An account can be moved back to GRS if the update is performed less than 14 days from the time the account became LRS, and no blobs were moved to the archive tier while the account was set to LRS.

Параметр уровня доступа к учетной записи по умолчанию

У учетных записей хранения есть настройка уровня доступа по умолчанию, указывающая онлайн-уровень, в котором создаются новые BLOB-объекты. Параметр уровня доступа по умолчанию можно задать как горячим, прохладным, так и холодным. Users can override the default setting for an individual blob when uploading the blob or changing its tier.

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

A blob that doesn't have an explicitly assigned tier infers its tier from the default account access tier setting. Если уровень доступа BLOB выводится из параметра уровня доступа учетной записи по умолчанию, то портал Azure отображает уровень доступа как "Горячий" (выводимый), "Прохладный" (выводимый) или "Холодный" (выводимый).

Изменение настройки уровня доступа по умолчанию для учетной записи хранения применяется ко всем BLOB-объектам в этой учетной записи, для которых уровень доступа не был установлен эксплицитно. If you toggle the default access tier setting to a cooler tier in a general-purpose v2 account, then you're charged for write operations (per 10,000) for all blobs for which the access tier is inferred. You're charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle to a warmer tier in a general-purpose v2 account.

При создании устаревшей учетной записи Blob Storage необходимо указать параметр уровня доступа по умолчанию как горячий или холодный при создании. За изменение настройки уровня доступа для учетной записи по умолчанию на более холодный уровень в устаревшей учетной записи Blob Storage плата не взимается. You're charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle to a warmer tier in a Blob Storage account. Майкрософт рекомендует, по возможности, использовать счета общего назначения версии 2 вместо BLOB-хранилищ.

Setting or changing a blob's tier

Чтобы явно задать уровень доступа для BLOB при его создании, укажите этот уровень при загрузке BLOB.

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

• By calling the Set Blob Tier operation, either directly or via a lifecycle management policy. Calling Set Blob Tier is typically the best option when you're changing a blob's tier from a warmer tier to a cooler one.

  Примечание.

  You can't rehydrate an archived blob to an online tier by using lifecycle management policies.

• Чтобы скопировать BLOB-объект с одного уровня на другой, вызовите операцию копирования BLOB-объекта. Calling Copy Blob is recommended for most scenarios where you're rehydrating a blob from the archive tier to an online tier, or moving a blob from cool or cold to hot. Копирование BLOB-объект позволяет избежать штрафа за преждевременное удаление, если требуемый интервал хранения исходного BLOB-объекта еще не истек. However, copying a blob results in capacity charges for two blobs, the source blob and the destination blob.

Changing a blob's tier from a warmer tier to a cooler one is instantaneous, as is changing from cold or cool to hot. Rehydrating a blob from the archive tier to an online tier such as the hot, cool, or cold tier can take up to 15 hours.

Keep in mind the following points when changing a blob's tier:

• You can't use Set Blob Tier to archive a a blob that uses an encryption scope. You can only use Set Blob Tier to move between online access tiers. Дополнительные сведения об областях шифрования см. в разделе Области шифрования для хранилища BLOB-объектов.

• If a blob is explicitly moved to the cool or cold tier and then moved to the archive tier, the early deletion charge applies.

Blob lifecycle management

Blob storage lifecycle management offers a rule-based policy that you can use to transition your data to the desired access tier when your specified conditions are met. Вы также можете использовать управление жизненным циклом, чтобы удалить данные по окончании их жизненного цикла. Чтобы узнать больше, ознакомьтесь с разделом Оптимизация затрат путем автоматизации уровней доступа к хранилищу BLOB-объектов Azure.

You can't rehydrate an archived blob to an online tier by using lifecycle management policies. Data stored in a premium block blob storage account cannot be tiered to hot, cool, cold or archive by using Set Blob Tier or using Azure Blob Storage lifecycle management. To move data, you must synchronously copy blobs from the block blob storage account to the hot tier in a different account using the Put Block From URL API or a version of AzCopy that supports this API. API Put Block From URL синхронно копирует данные на сервере, то есть вызов завершается только после того, как все данные перемещены из исходного расположения сервера в расположение назначения.

Действия хранилища

Хотя управление жизненным циклом помогает перемещать данные между уровнями в одной учетной записи, вы можете использовать задачу хранения для выполнения этой задачи в масштабе нескольких учетных записей. Задача хранения — это ресурс, доступный в Azure Storage Actions; бессерверная структура, которую можно использовать для выполнения общих операций с данными для миллионов объектов в нескольких учетных записях хранения. Дополнительные сведения см. в материале «Что такое Azure Storage Actions?».

Сводка параметров уровней доступа

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

¹ Объекты на холодном уровне в учетных записях общего назначения версии 2 имеют минимальную длительность хранения в течение 30 дней. Objects in the cold tier on general-purpose v2 accounts have a minimum retention duration of 90 days. For Blob Storage accounts, there's no minimum retention duration for the cool or cold tier.

² When rehydrating a blob from the archive tier, you can choose either a standard or high rehydration priority option. Каждый из них имеет разные временные задержки извлечения и стоимость. For more information, see Overview of blob rehydration from the archive tier.

³ Дополнительные сведения об избыточности в службе хранилища Azure см. в разделе Избыточность в службе хранилища Azure.

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

All storage accounts use a pricing model for block blob storage that is based on a blob's tier. Помните о том, что необходимо учитывать особенности выставления счетов, описанные в следующих разделах.

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

Затраты на емкость хранилища

Плата за хранение данных зависит не только от их объема, но и от уровня доступа. The per-gigabyte capacity cost decreases as the tier gets cooler.

Затраты на доступ к данным

Data access charges increase as the tier gets cooler. For data in the cool, cold and archive access tier, you're charged a per-gigabyte data access charge for reads.

Плата за транзакции

A per-transaction charge applies to all tiers and increases as the tier gets cooler.

Затраты на передачу данных при георепликации

Эта плата применяется только к учетным записям с настроенной георепликацией, включая GRS, RA-GRS и GZRS. При передаче данных георепликации взимается плата за гигабайт данных.

Стоимость передачи исходящих данных

Исходящая передача данных (данные, передаваемые из региона Azure) приводит к выставлению счетов за использование пропускной способности на основе объема в гигабайтах. Дополнительные сведения о ценах на исходящий трафик см. на странице с ценами на пропускную способность.

Изменение уровня доступа по умолчанию в учетной записи

Changing the account access tier results in tier change charges for all blobs that don't already have a tier explicitly set. For more information, see the following section, Changing a blob's access tier.

Changing a blob's access tier

Keep in mind the following billing impacts when changing a blob's tier:

• Когда объект передается или перемещается между уровнями, плата начисляется по соответствующему тарифу в момент передачи или изменения уровня.
• When a blob is moved to a cooler tier, the operation is billed as a write operation to the destination tier, where the write operation (per 10,000) and data write (per GB) charges of the destination tier apply.
• When a blob is moved to a warmer tier, the operation is billed as a read from the source tier, where the read operation (per 10,000) and data retrieval (per GB) charges of the source tier apply. Early deletion charges for any blob moved out of the cool, cold or archive tier may apply as well.
• While a blob is being rehydrated from the archive tier, that blob's data is billed as archived data until the data is restored and the blob's tier changes to hot, cool, or cold.

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

Changing the access tier for a blob when versioning is enabled, or if the blob has snapshots, might result in more charges. Сведения о больших двоичных объектах с включенным управлением версиями см. в разделе Цены и выставление счетов в документации по управлению версиями больших двоичных объектов. For information about blobs with snapshots, see Pricing and billing in the blob snapshots documentation.

Cold tier

Для холодного уровня требуются следующие минимальные версии REST, пакетов SDK и средств.

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

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

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

• Настройка уровня доступа блоба
• Архивировать блоб
• Оптимизация затрат путем автоматического управления жизненным циклом данных
• Best practices for using blob access tiers