Azure Data Box または Azure Data Box Heavy を使用して適切な Azure Storage BLOB 層にデータを送信する

[アーティクル]
03/25/2023

Azure Data Box は、独自のストレージデバイスをユーザーに提供して、大量のデータを Azure に移動できるようにするものです。ユーザーはこのデバイスにデータを格納して、返却します。 Data Box のデータは、ストレージアカウントに関連付けられている既定の層にアップロードされます。このデータは、別のストレージ層に移動できます。

この記事では、Data Box を使用してアップロードしたデータをホット、クール、またはアーカイブ BLOB 層に移動する方法について説明します。この記事は Azure Data Box と Azure Data Box Heavy の両方に該当します。

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

データに対する適切なストレージ層を選択する

Azure storage では、非常にコストパフォーマンスに優れた方法で、ホット、クール、またはアーカイブという 3 つの異なる層にデータを保存できます。ホットストレージ層は、頻繁にアクセスされるデータを保存するのに最適です。ホットストレージは、クールストレージとアーカイブストレージに比べてストレージコストが高くなるものの、アクセスコストが最も低くなります。

クールストレージ層は、30 日以上保存する必要がある、頻繁にはアクセスされないデータに適しています。クール層のストレージコストは、ホットストレージ層よりも低くなります。ただし、データアクセス料金は、ホット層と比べて高くなります。

Azure アーカイブ層はオフラインであり、ストレージコストは最も低くなりますが、アクセスコストは最も高くなります。この層は、180 日以上アーカイブストレージに残るデータを保存することを目的としています。それぞれの層および価格モデルの詳細については、「ストレージ層の比較」を参照してください。

Data Box または Data Box Heavy のデータは、ストレージアカウントに関連付けられているストレージ層にアップロードされます。ストレージアカウントの作成時、アクセス層をホットまたはクールとして指定できます。このデータは、ワークロードのアクセスパターンとコストに応じて、既定の層から別のストレージ層に移動できます。

オブジェクトストレージデータの階層制御は、BLOB ストレージアカウントまたは General Purpose v2 (GPv2) アカウントでのみ可能です。 General Purpose v1 (GPv1) アカウントは階層制御をサポートしていません。データに対して適切なストレージ層を選択するには、Azure Blob Storage: Premium、ホット、クール、アーカイブのストレージ層のページに記載されている考慮事項を確認してください。

既定の BLOB 層を設定する

既定の BLOB 層は、Azure portal 内でストレージアカウントを作成するときに指定します。ストレージタイプを GPv2 または BLOB ストレージとして選択すると、アクセス層の属性を指定できます。既定では、ホット層が選択されています。

Data Box または Data Box Heavy の注文時にアカウントの新規作成を試みた場合は、この層を指定できません。アカウントを作成した後、ポータル内でアカウントを変更して、既定のアクセス層を設定できます。

あるいは、最初にストレージアカウントを作成するときに、アクセス層の属性を指定することもできます。 Data Box または Data Box Heavy を注文するときは、既存のストレージアカウントを選択します。ストレージアカウントの作成時に既定の BLOB 層を設定する方法の詳細については、Azure portal でのストレージアカウントの作成に関するページを参照してください。

既定以外の層にデータを移動する

Data Box デバイスのデータを既定の層にアップロードした後、そのデータを既定以外の層に移動することもできます。データを既定以外の層に移動するには、2 つの方法があります。

Azure BLOB ストレージライフサイクル管理 - ポリシーベースのアプローチを使用して、データを自動的に階層制御したり、ライフサイクル終了時に期限切れにしたりできます。詳細については、「Azure Blob Storage のライフサイクルの管理」を参照してください。
スクリプト - Azure PowerShell でスクリプトを使用して、BLOB レベルの階層制御を有効にできます。 BLOB に対する層を設定するには、SetBlobTier 操作を呼び出します。

Azure PowerShell を使用して、BLOB 層を設定する

次の手順は、Azure PowerShell スクリプトを使用して、BLOB 層をアーカイブ (Archve) に設定する方法を示しています。

管理者特権の Windows PowerShell セッションを開きます。実行している PowerShell が 5.0 以降であることを確認します。型:

$PSVersionTable.PSVersion
Azure PowerShell にサインインします。

Login-AzAccount

ストレージアカウント、アクセスキー、コンテナー、およびストレージコンテキストの変数を定義します。

$StorageAccountName = "<enter account name>"
$StorageAccountKey = "<enter account key>"
$ContainerName = "<enter container name>"
$ctx = New-AzStorageContext -StorageAccountName $StorageAccountName -StorageAccountKey $StorageAccountKey

コンテナー内のすべての BLOB を取得します。

$blobs = Get-AzStorageBlob -Container "<enter container name>" -Context $ctx

コンテナー内のすべての BLOB の層をアーカイブ (Archive) に設定します。

Foreach ($blob in $blobs) {
$blob.ICloudBlob.SetStandardBlobTier("Archive")
}

サンプル出力を次に示します。

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\WINDOWS\system32> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      17763  134
PS C:\WINDOWS\system32> Login-AzAccount

Account          : gus@contoso.com
SubscriptionName : MySubscription
SubscriptionId   : subscription-id
TenantId         : tenant-id
Environment      : AzureCloud

PS C:\WINDOWS\system32> $StorageAccountName = "mygpv2storacct"
PS C:\WINDOWS\system32> $StorageAccountKey = "mystorageacctkey"
PS C:\WINDOWS\system32> $ContainerName = "test"
PS C:\WINDOWS\system32> $ctx = New-AzStorageContext -StorageAccountName $StorageAccountName -StorageAccountKey $StorageAccountKey
PS C:\WINDOWS\system32> $blobs = Get-AzStorageBlob -Container "test" -Context $ctx
PS C:\WINDOWS\system32> Foreach ($blob in $blobs) {
>> $blob.ICloudBlob.SetStandardBlobTier("Archive")
>> }
PS C:\WINDOWS\system32>

ヒント

取り込み時にデータをアーカイブする場合は、既定のアカウント層をホットに設定します。既定の層がクールの場合、データが直ちにアーカイブに移動すると、30 日早期削除ペナルティが課されます。

次のステップ

ライフサイクルポリシールールを使用して一般的なデータ階層制御シナリオに対処する方法を学びます。