Azure Data Lake Storage の機能で Azure Blob Storage をアップグレードする

[アーティクル]
09/26/2024

この記事は、階層型名前空間を有効にし、ファイルやディレクトリレベルのセキュリティや、より高速な操作などの機能を利用できるようにするのに役立ちます。これらの機能は、ビッグデータ分析ワークロードで広く使用されており、まとめて Azure Data Lake Storage と呼ばれます。

これらの機能の詳細と、このアップグレードがワークロード、アプリケーション、コスト、サービス統合、ツール、機能、ドキュメントに与える影響を評価するには、Azure Data Lake Storage の機能を使用して Azure Blob Storage をアップグレードする方法に関するページを参照してください。

重要

アップグレードは一方向です。アップグレードを実行した後で、アカウントを元に戻す方法はありません。非運用環境でアップグレードを検証することをお勧めします。

アップグレードの準備

ストレージアカウントを Data Lake Storage にアップグレードする準備をするには、次の手順を実行します。

レビュー機能のサポート
各 BLOB パスのセグメントに名前が付けられていることを確認する
ストレージアカウントへの書き込みアクティビティを禁止する

レビュー機能のサポート

お使いのストレージアカウントが、Data Lake Storage 対応アカウントでまだサポートされていない機能を使用するように構成されている場合もあります。アカウントでそのような機能を使用している場合、アップグレードの検証手順は成功しません。サポートされていない機能を識別するには、「Azure Storage アカウントにおける Blob Storage 機能のサポート」を参照してください。アカウントでそのような機能を使用している場合は、アップグレードを開始する前にそれらを無効にしてください。

以下の機能は Data Lake Storage アカウントでサポートされていますが、アップグレードプロセスではサポートされていません。

BLOB のスナップショット
暗号化スコープ
不変ストレージ
ライフサイクル管理のための最終アクセス時刻の追跡
BLOB の論理的な削除
コンテナーの論理的な削除

ストレージアカウントでこのような機能が有効になっている場合は、アップグレードを実行する前にそれらを無効にする必要があります。アップグレードの完了後に機能の使用を再開する場合は、再度有効にします。

場合によっては、アップグレード前に機能を無効にした後、クリーンアップ操作の時間を確保する必要があります。一例として、BLOB の論理的な削除機能が挙げられます。アカウントをアップグレードする前に、BLOB の論理的な削除を無効にして、すべての論理的な削除 BLOB の有効期限が切れるようにする必要があります。

重要

変更フィード機能を一度でも有効にしたことのあるストレージアカウントを Data Lake Storage にアップグレードすることはできません。変更フィードを無効にするだけでは、アップグレードを実行できません。代わりに、階層型名前空間の機能を有効にしてアカウントを作成し、データをそのアカウントに移動してから転送する必要があります。

ストレージアカウントからページ BLOB を削除する

ページ BLOB を含むストレージアカウントをアップグレードすることはできません。アップグレードを実行する前に、必ずストレージアカウントからページ BLOB を削除してください。

各 BLOB パスのセグメントに名前が付けられていることを確認する

移行プロセスでは、BLOB のパスのセグメントごとにディレクトリが作成されます。 Data Lake Storage のディレクトリには名前が必要です。そのため、移行を成功させるには、仮想ディレクトリ内の各パスセグメントに名前を指定する必要があります。スペース文字のみを使用して名前が付けられたセグメントについても、同じ要件が当てはまります。パスセグメントに名前がない (//) 場合や、スペース文字のみを使用して名前が付けられている (_) 場合は、移行を続行する前に、これらの名前付け要件と互換性のある新しいパスにそれらの BLOB をコピーする必要があります。

ストレージアカウントへの書き込みアクティビティを禁止する

アップグレード中にアプリケーションがストレージアカウントに書き込む場合、アップグレードが失敗する可能性があります。このような書き込みアクティビティを防ぐには:

書き込み操作を実行する可能性があるアプリケーションまたはサービスを休止します。
ストレージアカウント内のコンテナーと BLOB の既存のリースを解放または中断します。

アップグレードが完了したら、作成したリースを解除して、コンテナーと BLOB への書き込みアクセスを許可するように再開します。

警告

これらのリソースに現在アクセスしているアプリケーションまたは仮想マシンを適切に無効にせずにアクティブなリースを解除すると、予期しない結果が生じる可能性があります。現在のリースを解除する前に、現在の書き込みアクティビティを休止してください。

アップグレードを実行する

Azure ポータルにサインインして、作業を開始します。
ストレージアカウントを見つけて、アカウントの概要を表示します。
[Data Lake Gen2 の移行] を選択します。

[Azure Data Lake Gen2 の機能を持つストレージアカウントにアップグレードする] 構成ページが表示されます。
[手順 1: アップグレードする前にアカウントの変更を確認する] セクションを展開し、 [変更を確認して同意する] をクリックします。
[Review account changes](アカウントの変更の確認) ページで、チェックボックスをオンにして、 [Agree to changes](変更に同意する) をクリックします。
[手順 2: アップグレードする前にアカウントを検証する] セクションを展開し、 [検証の開始] をクリックします。

検証に失敗した場合は、ページにエラーが表示されます。場合によっては、 [エラーの表示] リンクが表示されます。リンクが表示されたら、それを選択します。

次に、error.json ファイルのコンテキストメニューから、 [ダウンロード] を選択します。

ダウンロードしたファイルを開き、アカウントが検証ステップに合格しなかった理由を確認します。次の JSON は、アカウントで互換性のない機能が有効になっていることを示しています。この場合は、その機能を無効にしてから、検証プロセスを再度開始します。
```
{
 "startTime": "2021-08-04T18:40:31.8465320Z",
 "id": "45c84a6d-6746-4142-8130-5ae9cfe013a0",
 "incompatibleFeatures": [
     "Blob Delete Retention Enabled"
 ],
 "blobValidationErrors": [],
 "scannedBlobCount": 0,
 "invalidBlobCount": 0,
 "endTime": "2021-08-04T18:40:34.9371480Z"
}
```
アカウントが正常に検証された後、 [手順 3: アカウントのアップグレード] セクションを展開して、 [アップグレードの開始] をクリックします。

重要

アカウントがアップグレードされている間、書き込み操作は無効になります。読み取り操作は無効になりませんが、アップグレードプロセスが不安定になる可能性があるため、読み取り操作を中断することを強く推奨します。

移行が正常に完了すると、次のようなメッセージが表示されます。

Windows PowerShell コマンドウィンドウを開きます。
最新の Azure PowerShell モジュールがあることを確認します。「Azure PowerShell モジュールをインストールする」を参照してください。
Connect-AzAccount コマンドを使用して Azure サブスクリプションにサインインし、画面上の指示に従います。
```
Connect-AzAccount
```
自分の ID が複数のサブスクリプションに関連付けられている場合は、アクティブなサブスクリプションを設定します。
```
$context = Get-AzSubscription -SubscriptionId <subscription-id>
Set-AzContext $context
```
<subscription-id> プレースホルダーの値をサブスクリプションの ID に置き換えます。
次のコマンドを使用して、ストレージアカウントを検証します。
```
$result = Invoke-AzStorageAccountHierarchicalNamespaceUpgrade -ResourceGroupName "<resource-group-name>" -Name "<storage-account-name>" -RequestType Validation -AsJob
```
- <resource-group-name> プレースホルダーの値を、リソースグループの名前に置き換えます。
- <storage-account-name> プレースホルダーの値は、実際のストレージアカウントの名前に置き換えます。
アカウントのサイズによっては、このプロセスに時間がかかる場合があります。クライアントがブロックされないように、asJob スイッチを使用してコマンドをバックグラウンドジョブで実行できます。コマンドはリモートで実行されますが、ジョブはコマンドを実行するローカルコンピューターまたは VM 上に存在します。結果は、ローカルコンピューターまたは VM に送信されます。
ジョブの状態を確認し、ジョブのすべてのプロパティを一覧で表示するには、戻り値の変数を Format-List コマンドレットにパイプします。
```
$result | Format-List -Property *
```
検証が成功した場合、Stateプロパティは Completed に設定されます。

検証に失敗した場合、State プロパティは Failed に設定され、Error プロパティで検証エラーが表示されます。

次の出力は、アカウントで互換性のない機能が有効になっていることを示しています。この場合は、その機能を無効にしてから、検証プロセスを再度開始します。

場合によっては、Error プロパティによって error.json という名前のファイルへのパスが提供されます。そのファイルを開いて、アカウントが検証手順に合格しなかった理由を判断できます。

次の JSON は、アカウントで互換性のない機能が有効になっていることを示しています。この場合は、その機能を無効にしてから、検証プロセスを再度開始します。
```
{
 "startTime": "2021-08-04T18:40:31.8465320Z",
 "id": "45c84a6d-6746-4142-8130-5ae9cfe013a0",
 "incompatibleFeatures": [
     "Blob Delete Retention Enabled"
 ],
 "blobValidationErrors": [],
 "scannedBlobCount": 0,
 "invalidBlobCount": 0,
 "endTime": "2021-08-04T18:40:34.9371480Z"
}
```
アカウントが正常に検証された後、次のコマンドを実行してアップグレードを開始します。
```
$result = Invoke-AzStorageAccountHierarchicalNamespaceUpgrade -ResourceGroupName "<resource-group-name>" -Name "<storage-account-name>" -RequestType Upgrade -AsJob -Force
```
上記の検証例と同様に、この例では asJob スイッチを使用して、コマンドをバックグラウンドジョブで実行します。 Force スイッチによって、アップグレードを確認するプロンプトがオーバーライドされます。 AsJob スイッチを使用しない場合は、単にプロンプトに応答できるので、Force スイッチを使用する必要はありません。

重要

アカウントがアップグレードされている間、書き込み操作は無効になります。読み取り操作は無効になりませんが、アップグレードプロセスが不安定になる可能性があるため、読み取り操作を中断することを強く推奨します。

ジョブの状態を確認するには、前の手順で説明したのと同じテクニックを使用します。プロセスが実行されると、State プロパティが Running に設定されます。

移行が正常に完了すると、State プロパティが Completed に設定され、Error プロパティにエラーは表示されません。

重要

アップグレード時間にかかる大まかな推定値は、200 万 BLOB あたりおよそ 5 分から 10 分です。たとえば、アカウントに 1,000 万の BLOB がある場合、アップグレードにはおよそ 25 分から 50 分かかります。 BLOB が 200 万個未満のアカウントは、通常、10 分未満でアップグレードが完了します。

まず、Azure Cloud Shell を開きます。または、Azure CLI をローカルにインストールした場合は、Windows PowerShell などのコマンドコンソールアプリケーションを開きます。
次のコマンドを使用して、インストールされている Azure CLI のバージョンが 2.29.0 以上であることを確認します。
```
 az --version
```
Azure CLI のバージョンが 2.29.0 より前の場合は、新しいバージョンをインストールします。詳細については、「 Azure CLI のインストール」を参照してください。
自分の ID が複数のサブスクリプションに関連付けられている場合は、アクティブなサブスクリプションを設定します。
```
   az account set --subscription <subscription-id>
```
<subscription-id> プレースホルダーの値をサブスクリプションの ID に置き換えます。
次のコマンドを使用して、ストレージアカウントを検証します。
```
az storage account hns-migration start --type validation -n <storage-account-name> -g <resource-group-name>
```
- <resource-group-name> プレースホルダーの値を、リソースグループの名前に置き換えます。
- <storage-account-name> プレースホルダーの値は、実際のストレージアカウントの名前に置き換えます。
検証が成功した場合、プロセスは完了し、エラーは表示されません。

検証に失敗した場合は、検証エラーがコンソールに表示されます。たとえば、エラー (IncompatibleValuesForAccountProperties) Values for account properties are incompatible: Versioning Enabled は、アカウントで互換性のない機能 (バージョン管理) が有効になっていることを示しています。この場合は、その機能を無効にしてから、検証プロセスを再度開始します。

場合によっては、error.json という名前のファイルへのパスがコンソールに表示されます。そのファイルを開いて、アカウントが検証手順に合格しなかった理由を判断できます。

次の JSON は、アカウントで互換性のない機能が有効になっていることを示しています。この場合は、その機能を無効にしてから、検証プロセスを再度開始します。
```
{
 "startTime": "2021-08-04T18:40:31.8465320Z",
 "id": "45c84a6d-6746-4142-8130-5ae9cfe013a0",
 "incompatibleFeatures": [
     "Blob Delete Retention Enabled"
 ],
 "blobValidationErrors": [],
 "scannedBlobCount": 0,
 "invalidBlobCount": 0,
 "endTime": "2021-08-04T18:40:34.9371480Z"
}
```
アカウントが正常に検証された後、次のコマンドを実行してアップグレードを開始します。
```
az storage account hns-migration start --type upgrade -n storage-account-name -g <resource-group-name>
```
重要

アカウントがアップグレードされている間、書き込み操作は無効になります。読み取り操作は無効になりませんが、アップグレードプロセスが不安定になる可能性があるため、読み取り操作を中断することを強く推奨します。

移行が成功した場合、プロセスは完了し、エラーは表示されません。

アップグレードを停止する

移行が完了する前に、それを停止できます。

アップグレードが完了する前にそれを停止するには、アップグレードの進行中に [アップグレードの取り消し] を選択します。

アップグレードの取り消し

アップグレードが完了する前にそれを停止するには、Stop-AzStorageAccountHierarchicalNamespaceUpgrade コマンドを使用します。

Stop-AzStorageAccountHierarchicalNamespaceUpgrade -ResourceGroupName <resource-group-name> -Name <storage-account-name>

アップグレードが完了する前にそれを停止するには、az storage account hns-migration stop コマンドを使用します。

az storage account hns-migration stop -n <storage-account-name> -g <resource-group-name>

データ、ワークロード、アプリケーションを移行する

Blob service エンドポイントまたは Data Lake Storage エンドポイントを指し示すように、ワークロード内のサービスを構成します。
Windows Azure Storage Blob ドライバーまたは WASB ドライバーを使用する Hadoop ワークロードの場合は、Azure Blob File System (ABFS) ドライバーを使用するようにそれらを変更します。 Blob service エンドポイントに対して要求を行う WASB ドライバーとは異なり、ABFS ドライバーはアカウントの Data Lake Storage エンドポイントに対して要求を行います。
カスタムアプリケーションをテストして、アップグレードされたアカウントで想定どおりに動作することを確認します。

Data Lake Storage でのマルチプロトコルアクセスを使用すると、ほとんどのアプリケーションで BLOB API を変更せずに引き続き使用できます。問題が発生する場合、または API を使用してディレクトリ操作と ACL を使用したい場合は、Data Lake Storage API を使用するようにコードの一部を移動することを検討します。 .NET、Java、Python、Node.js、REST に関するガイドを参照してください。
カスタムスクリプトをテストして、アップグレードされたアカウントで想定どおりに動作することを確認します。

BLOB API の場合と同様に、スクリプトの多くは、変更を必要とせずに機能する可能性があります。ただし、必要な場合は、Data Lake Storage の PowerShell コマンドレットと Azure CLI コマンドを使用するようにスクリプトファイルをアップグレードできます。

次の方法で共有

Azure Data Lake Storage の機能で Azure Blob Storage をアップグレードする