BLOB 層の設定
この操作により Set Blob Tier 、BLOB のアクセス層が設定されます。 この操作は、Premium Storage アカウントのページ BLOB と、BLOB ストレージまたは汎用 v2 アカウントのブロック BLOB で許可されます。 Premium ページ BLOB の層 (P1P3P4/P2// など) によって、BLOB の許容サイズ、IOPS、帯域幅が決まります。 ブロック BLOB の層によってストレージの種類がHotColdArchive/Cool//決まります。 この操作では、BLOB の ETag は更新されません。
ブロック BLOB レベルの階層化の詳細については、「 ホット、クール、アーカイブ ストレージ層」を参照してください。
要求
要求は Set Blob Tier 次のように構築できます。 HTTPS を使用することをお勧めします。 myaccount をストレージ アカウントの名前に置き換え、myblob を、層を変更する BLOB 名に置き換えます。
| Method | 要求 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 以降では、リハイドレート優先度は、以前に設定した後に更新できます。 優先度の設定は、このヘッダーを に設定して HighSet Blob Tier を呼び出し、前に設定Highしたのと同じ値に設定x-ms-access-tierすることで、 から Standard に変更できます。 優先度の設定を から High に Standard下げることはできません。 |
この操作では、指定した条件が満たされた場合にのみ、条件付きヘッダーを使用して BLOB を階層化することもできます。 詳細については、「 Blob Storage 操作の条件付きヘッダーを指定する」を参照してください。
要求本文
[なし] :
Response
応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。
status code
新しいレベルがすぐに有効になった場合は状態コード 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 |
要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値 x-ms-client-request-id は、要求に存在し、値に 1,024 文字以下の ASCII 文字が含まれている場合、ヘッダーの値と同じです。 ヘッダーが x-ms-client-request-id 要求に存在しない場合、応答には存在しません。 |
承認
Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 操作は、以下で Set Blob Tier 説明するように承認できます。
Azure Storage では、Azure Active Directory (Azure AD) を使用して BLOB データへの要求を認可することがサポートされています。 Azure AD では、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、Azure AD によって認証されて、OAuth 2.0 トークンを返します。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。
Azure AD を使用した承認の詳細については、「Azure Active Directory を使用して BLOB へのアクセスを承認する」を参照してください。
アクセス許可
Azure AD ユーザー、グループ、またはサービス プリンシパルが操作を呼び出 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スナップショットは、スナップショットに再ハイドレートすることはできません。 つまり、スナップショットを またはcoolレベルにhot戻すことはできません。 スナップショットまたはバージョンからデータを取得するarchive唯一の方法は、新しい BLOB にコピーすることです。 - バージョンがルート BLOB の場合は、 または
coolにhotリハイドレートできます。 - 状態のスナップショットまたはバージョンを
archiveルートに昇格することはできません。 - バージョン管理が有効になっている場合、リハイドレートが保留中の状態の場合にルート BLOB を削除すると、リハイドレートが取り消され、バージョンは状態になります
archive。 - BLOB がリハイドレート保留中で論理的に削除された状態のときに上書きされると、リハイドレートが取り消され、論理的に削除されたスナップショットのバージョンが状態になります
archive。
サポートされているレベルの一覧は要求バージョンによって制限されず、今後新しいレベルが追加される可能性があります。
注意
ブロック BLOB レベルの階層化の詳細については、「 ホット、クール、アーカイブのストレージ層」を参照してください。
関連項目
Azure Storage への要求を承認する
状態コードとエラー コード
Blob Storage のエラー コード
Blob Storage 操作のタイムアウトを設定する