次の方法で共有

BLOB 層の設定

  • [アーティクル]

Set Blob Tier 操作では、BLOB のアクセス層が設定されます。 この操作は、Premium Storage アカウントのページ BLOB と、BLOB ストレージまたは汎用 v2 アカウント内のブロック BLOB で許可されます。 Premium ページ BLOB の層 (P4/P6/P10/P15/P20/P30/P40/P50/P60) によって、BLOB の許可されるサイズ、IOPS、帯域幅が決まります。 ブロック BLOB の層によって、ストレージの種類 Hot/Cool/Cold/Archive 決まります。 この操作では、BLOB の ETag は更新されません。

ブロック BLOB レベルの階層化の詳細については、「ホット、クール、アーカイブ ストレージ層を参照してください。

依頼

Set Blob Tier 要求は次のように構築できます。 HTTPS を使用することをお勧めします。 myaccount をストレージ アカウントの名前に置き換え、myblob 層を変更する BLOB 名に置き換えます。

方式 要求 URI HTTP バージョン
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=tier HTTP/1.1

URI パラメーター

要求 URI には、次の追加パラメーターを指定できます。

パラメーター 形容
snapshot 随意。 スナップショット パラメーターは不透明な DateTime 値であり、存在する場合は、階層を設定する BLOB スナップショットを指定します。 BLOB スナップショットの操作の詳細については、「BLOB のスナップショットを作成する」を参照してください。
versionid バージョン 2019-12-12 以降では省略可能です。 versionid パラメーターは不透明な DateTime 値であり、存在する場合は、階層を設定する BLOB のバージョンを指定します。
timeout 随意。 timeout パラメーターは秒単位で表されます。 詳細については、「Blob Storage 操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

必須の要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

要求ヘッダー 形容
Authorization 必須。 承認スキーム、ストレージ アカウント名、および署名を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。
Date または x-ms-date 必須。 要求の世界協定時刻 (UTC) を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。
x-ms-access-tier 必須。 BLOB に設定する層を示します。 許可される Premium ページ BLOB 層の一覧については、「VMの高パフォーマンス Premium Storage とマネージド ディスク」を参照してください。 BLOB ストレージまたは汎用 v2 アカウントの場合、有効な値は Hot、Cool、Cold、および Archiveです。 注:Cold レベルは、バージョン 2021-12-02 以降でサポートされています。 標準的な BLOB アカウントの BLOB レベルの階層化の詳細については、「ホット、クール、アーカイブストレージ層を参照してください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「Azure Storage Servicesのバージョン管理の 」を参照してください。
x-ms-client-request-id 随意。 ストレージ分析ログが有効な場合に分析ログに記録される 1 kB 文字の制限を持つ、クライアント生成の不透明な値を提供します。 クライアント側のアクティビティをサーバーが受信した要求と関連付ける場合は、このヘッダーを使用することを強くお勧めします。 詳細については、「Storage Analytics ログのについて」を参照してください。
x-ms-rehydrate-priority 随意。 アーカイブされた BLOB のリハイドレートに使用する優先度を示します。 ブロック BLOB のバージョン 2019-02-02 以降でサポートされています。 有効な値は High/Standardです。 優先度は、2020-06-12 より前のバージョンに対して 1 回だけ BLOB に設定できます。このヘッダーは、後続の要求では無視されます。 既定の優先度設定は Standardです。

バージョン 2020-06-12 以降では、リハイドレート優先度は、以前に設定した後に更新できます。 優先度の設定は、Standard から High に変更できます。このヘッダーを High に設定 BLOB 層の設定 を呼び出し、x-ms-access-tier を以前に設定した値に設定します。 優先度の設定を High から Standardに下げることはできません。

この操作では、指定した条件が満たされた場合にのみ、条件付きヘッダーを使用して BLOB を階層化することもできます。 詳細については、「Blob Storage 操作の条件付きヘッダーを指定する」を参照してください。

要求本文

何一つ。

応答

応答には、HTTP 状態コードと一連の応答ヘッダーが含まれます。

状態コード

正常に実行されると、新しいレベルがすぐに有効になった場合は状態コード 200 (OK) が返され、新しいレベルへの移行が保留中の場合は状態コード 202 (Accepted) が返されます。

Premium Storage アカウントの場合、ページ BLOB 操作は状態コード 200 (OK) を返します。

ブロック BLOB の場合、BLOB の現在の層と要求された層に基づいて返される HTTP 状態コードを次の表に示します。

層 ホット 層に設定する クール層に設定する コールド 層に設定する アーカイブ層に設定する
ホット層の BLOB 200 200 200 200
クール層の BLOB 200 200 200 200
コールド層の BLOB 200 200 200 200
アーカイブ層の BLOB 202 202 202 200
アーカイブ層の BLOB(ホットにリハイドレート) 202 409 409 409
アーカイブ層内の BLOB(リハイドレートしてクールに) 409 202 409 409
アーカイブ層の BLOB(コールド層へのリハイドレート) 409 409 202 409

状態コードの詳細については、「状態コードとエラー コードを参照してください。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれます。 応答には、追加の標準 HTTP ヘッダーも含まれる場合があります。 すべての標準ヘッダーは、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー 形容
x-ms-request-id 作成された要求を一意に識別し、要求のトラブルシューティングに使用できます。 詳細については、「API 操作のトラブルシューティング」を参照してください。
x-ms-version 要求の実行に使用された Blob Storage のバージョン。 このヘッダーは、バージョン 2009-09-19 以降に対して行われた要求に対して返されます。
x-ms-client-request-id 要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、1,024 文字以下の ASCII 文字が含まれている場合、x-ms-client-request-id ヘッダーの値と同じです。 x-ms-client-request-id ヘッダーが要求に存在しない場合、応答には存在しません。

認可

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 次の説明に従って、Set Blob Tier 操作を承認できます。

大事な

Microsoft では、マネージド ID で Microsoft Entra ID を使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra ID は、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

Azure Storage では、Microsoft Entra ID を使用して BLOB データへの要求を承認できます。 Microsoft Entra ID を使用すると、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、OAuth 2.0 トークンを返すために Microsoft Entra ID によって認証されます。 その後、トークンを使用して、BLOB サービスに対する要求を承認できます。

Microsoft Entra ID を使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。

権限

Microsoft Entra ユーザー、グループ、マネージド ID、またはサービス プリンシパルが Set Blob Tier 操作を呼び出すために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

  • Azure RBAC アクション: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write を
  • 最小特権組み込みロール: ストレージ BLOB データ共同作成者

Azure RBAC を使用したロールの割り当ての詳細については、「BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

備考

Premium アカウントでページ BLOB の BLOB 層を設定するには、次の制限があります。

  • 新しい BLOB 層を既存の BLOB 層よりも低くすることはできません。
  • 新しい BLOB 層は、BLOB のコンテンツの長さに対応できる必要があります。 階層の一覧と許可されるコンテンツの長さについては、「VMの高パフォーマンス Premium Storage とマネージド ディスク」を参照してください。

Blob Storage または汎用 v2 アカウントにブロック BLOB の層を設定する場合、次の制限があります。

  • スナップショットに階層を設定することは、REST バージョン 2019-12-12 の時点で許可されます。
  • archive に階層化されたスナップショットは、スナップショットにリハイドレートすることはできません。 つまり、スナップショットを hot または cool レベルに戻すことはできません。 archive スナップショットまたはバージョンからデータを取得する唯一の方法は、新しい BLOB にコピーすることです。
  • バージョンがルート BLOB の場合は、hot または coolにリハイドレートできます。
  • archive 状態のスナップショットまたはバージョンは、ルートに昇格できません。
  • バージョン管理が有効になっている場合、リハイドレートが保留中の状態にある場合にルート BLOB を削除すると、リハイドレートが取り消され、バージョンが archive 状態になります。
  • リハイドレートが保留中で論理的に削除された状態のときに BLOB が上書きされると、リハイドレートが取り消され、論理的に削除されたスナップショットのバージョンが archive 状態になります。

サポートされているレベルの一覧は要求バージョンによって制限されず、今後新しいレベルが追加される可能性があります。

お客様が指定した暗号化を使用する BLOB の場合、バージョン 2023-08-03 以降では Set Blob Tier がサポートされます。 2023-08-03 より前のバージョンの場合、Set Blob Tier は、顧客が指定した暗号化を使用する BLOB の状態コード 409 を返します。

手記

ブロック BLOB レベルの階層化の詳細については、「ホット、クール、アーカイブストレージ層を参照してください。

請求

価格要求は、Blob Storage API を使用するクライアントから、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリから送信できます。 これらの要求には、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに発生します。 次の表に、ストレージ アカウントの種類に基づく Set Blob Tier 要求の課金カテゴリを示します。

操作 ストレージ アカウントの種類 課金カテゴリ
BLOB 層の設定 (レベルダウン) Premium ブロック BLOB
標準汎用 v2		 書き込み操作
BLOB 層の設定 (階層化) Premium ブロック BLOB
標準汎用 v2		 読み取り操作

指定された課金カテゴリの価格については、Azure Blob Storage の価格に関するページを参照してください。

関連項目

Azure Storage への要求を承認する
状態とエラー コードの
Blob Storage のエラー コード
Blob Storage 操作のタイムアウトを設定する