クラシック デプロイ モデルから Azure Resource Manager へのストレージ アカウントの移行について理解する

Azure クラシック デプロイ モデルから Azure Resource Manager デプロイ モデルへストレージ アカウントを移行するプロセスについて詳しく見ていきましょう。 Azure Platform 上の 2 つのデプロイメント モデルの間で、どのようにリソースが移行されるかを理解できるように、リソースと機能レベルでリソースについて説明していきます。 詳細については、サービスお知らせの記事「クラシック ストレージ アカウントを Azure Resource Manager へ 2024 年 8 月 31 日までに移行する」を参照してください

データ プレーンと管理プレーンについて理解する

最初に、Azure Storage の基本的なアーキテクチャを理解しておくと便利です。 Azure Storage には、Blob Storage、Azure Data Lake Storage、Azure Files、Queue Storage、Table Storage など、データを格納するサービスが用意されています。 これらのサービスと公開される操作は、Azure Storage の "データ プレーン" で構成されます。 Azure Storage では、Azure Storage アカウントと関連リソース (冗長性 SKU、アカウント キー、特定のポリシーなど) を管理するための操作も公開されています。 これらの操作は、"管理" または "コントロール" プレーンで構成されます。

Diagram showing the Azure Storage data and management plane architecture.

移行プロセス時に、Microsoft がストレージ アカウント リソースの表現を、クラシック デプロイ モデルから Azure Resource Manager のデプロイ モデルに変換します。 したがって、新しいツール、API、SDK を使って移行後のストレージ アカウントと関連リソースを管理する必要があります。

データ プレーンは、クラシック デプロイ モデルから Azure Resource Manager モデルへの移行による影響を受けません。 アプリケーションは、移行プロセス全体を通じて、引き続きストレージ アカウントからデータの読み取りと書き込みができます。

移行エクスペリエンス

クラシック ストレージ アカウントは、Azure portal、PowerShell、または Azure CLI を使用して移行できます。 アカウントを移行する方法については、「クラシック ストレージ アカウントを Azure Resource Manager に移行する」を参照してください。

移行を開始する前に:

移行プロセスには、次の図に示すように 4 つの手順があります。

Screenshot showing the account migration workflow.

  1. 検証する。 検証フェーズ中に、Azure はストレージ アカウントを調べて、移行できることを確認します。

  2. 準備する。 準備フェーズでは、Azure によって新しい汎用 v1 ストレージ アカウントが作成されて、発生したかもしれないあらゆる問題についての警告が表示されます。 新しいアカウントは、クラシック アカウントと同じリージョンの新しいリソース グループに作成されます。

    この時点では、クラシック ストレージ アカウントがまだ存在します。 問題が報告された場合は、修正するか、移行プロセスを中止することができます。

  3. 手動で確認する。 新しいストレージ アカウントの手動チェックを行って、出力が期待どおりであることを確認するのがよいでしょう。

  4. コミットするか中止する。 移行が成功したことを確認したら、移行をコミットすることができます。 移行をコミットすることで、クラシック ストレージ アカウントは完全に削除されます。

    移行をコミットする前に、Azure Storage リソース プロバイダー API を使用するようにクライアント アプリケーションを更新することをお勧めします。 その後、クラシック アカウントがまだ存在している間に、移行されたストレージ アカウントに対して更新されたコードをテストできます。

    移行に問題がある場合は、移行をコミットするのではなく、この時点で移行を中止できます。 中止を選択した場合、新しいリソース グループと新しいストレージ アカウントは削除されます。 クラシック アカウントは引き続き使用できます。 問題があれば対処して、もう一度移行を試みることができます。

Note

以降のセクションで説明する操作はすべてべき等です。 サポートされていない機能や構成エラー以外の問題が発生した場合、準備、中止、またはコミットの操作を再試行してください。

検証

検証手順は、移行プロセスの最初の手順です。 この手順の目的は、クラシック デプロイ モデルから移行したいリソースの状態を分析することです。 検証手順では、リソースを移行できるかどうか (成功か失敗か) を評価します。 クラシック ストレージ アカウントを移行できない場合、その理由が Azure によって一覧表示されます。

検証手順では、クラシック デプロイ モデルにおけるリソースの状態を分析します。 クラシック デプロイ モデルにおいてストレージ アカウントの構成が異なるためのエラーやサポートされていないシナリオがないかを調べます。

検証手順では、ストレージ アカウントに関連する可能性のある VM ディスクについては調べません。 ストレージ アカウントに VM ディスクが含まれているかどうかを調べるには、手動で確認する必要があります。 詳細については、次の記事を参照してください。

移行中に Azure Resource Manager スタックによってストレージ アカウントに課される可能性があるすべての制約について調べることは不可能であることを念頭に置いておいてください。 一部の制約については、移行に続く手順 (準備手順) でリソースに変換が行われるときにだけチェックされます。

準備

準備手順は、移行プロセスの 2 番目の手順です。 この手順の目的は、クラシック デプロイ モデルから Azure Resource Manager デプロイ モデルへのストレージ アカウントの変換をシミュレートすることです。 準備手順では、クラシック デプロイ モデルのストレージ アカウントと Azure Resource Manager の移行後のストレージ アカウントを比較することもできます。

重要

この手順では、クラシック ストレージ アカウントは変更されません。 この手順で安全に移行を試すことができます。

ストレージ アカウントを移行できない場合は、移行プロセスが停止され、準備手順が失敗した理由が一覧表示されます。

ストレージ アカウントが移行できる場合、Azure によって移行中のストレージ アカウントの管理プレーン操作がロックされます。 たとえば、準備フェーズの進行中は、ストレージ アカウント キーを再生成できません。 その後、新しいリソース グループがクラシック ストレージ アカウントとして作成されます。 新しいリソース グループの名前は、 パターン <classic-account-name>-Migrated に従います。

Note

移行したストレージ アカウント用に作成されるリソース グループの名前を選択することはできません。 ただし、移行の完了後には、Azure Resource Manager の移動機能を使って、移行したストレージ アカウントを別のリソース グループに移動することは可能です。 詳細については、リソースを新しいサブスクリプションまたはリソース グループに移動するに関する記事をご覧ください。

最後に、Azure は、ストレージ アカウントとその構成を、クラシック ストレージ アカウントと同じリージョンにある Azure Resource Manager の新しいストレージ アカウントに移行します。 この時点では、クラシック ストレージ アカウントがまだ存在します。 準備手順中に報告された問題がある場合は、それを修正するか、プロセスを中止することができます。

手動で確認する

準備手順が完了すると、両方のアカウントがサブスクリプションに存在するため、移行前の状態のクラシック ストレージ アカウントと Azure Resource Manager のクラシック ストレージ アカウントを確認・比較することができます。 たとえば、新しいアカウントを Azure portal 経由で調べて、ストレージ アカウントの構成が期待どおりであることを確認することができます。

移行のコミットや中止が必要になるまでの期間は設定されません。 チェック フェーズには、必要なだけ時間を取ることができます。 ただし、管理プレーン操作は、中止するかコミットするまで、クラシック ストレージ アカウントでロックされます。

中止

変更をクラシック デプロイ モデルに戻すには、移行を中止することを選択できます。 移行を中止すると、新しいストレージ アカウントと新しいリソース グループは削除されます。 移行の中止を選択しても、クラシック ストレージ アカウントは影響を受けません。

注意事項

移行をコミットした後に、移行を中止することはできません。 コミットする前に、移行したストレージ アカウントにエラーがないかをよく確認してください。

Commit

移行をコミットする前に、Azure Storage リソース プロバイダー API を使用するようにクライアント アプリケーションを更新することをお勧めします。 その後、クラシック アカウントがまだ存在している間に、移行されたストレージ アカウントに対して更新されたコードをテストできます。 問題がある場合は、コミットを中止できます。

クラシック ストレージ アカウントが正常に移行され、クライアント アプリケーションが新しいアカウントに対して動作していることを確認したら、移行をコミットできます。 移行をコミットすると、クラシック ストレージ アカウントが削除されます。 あなたのデータは、Resource Manager デプロイ モデルに新しく移行されたアカウントでのみ使用できるようになりました。

警告

移行をコミットすることで、クラシック ストレージ アカウントは完全に削除されます。 移行をコミットする前に、移行されたストレージ アカウントとクライアント アプリケーションを十分にテストします。

移行をコミットすることは、べき等性の操作です。 失敗した場合、操作を再試行してください。 失敗が続く場合は、サポート チケットを作成するか、Microsoft Q&A で質問してください。

移行後

移行が完了すると、新しいストレージ アカウントを使用できるようになります。

移行されたアカウントの種類

移行が完了すると、新しいストレージ アカウントは汎用の v1 ストレージ アカウントになります。 Azure Storage が提供するセキュリティ、データ保護、ライフサイクル管理などの最新機能を活用するには、汎用の v2 アカウントにアップグレードすることをお勧めします。 汎用の v2 ストレージ アカウントにアップグレードする方法については、「汎用 v2 ストレージ アカウントにアップグレードする」を参照してください。

アカウントのプロパティ

クラシック ストレージ アカウントに設定されているすべてのプロパティは、その値とともに新しいストレージ アカウントに移行されます。

RBAC ロールの割り当て

クラシック ストレージ アカウントをスコープとしている RBAC ロール割り当ては、移行後も維持されます。

アカウント キー

アカウント キーは、移行中に変更されたりローテーションされたりすることはありません。 移行の完了後にアカウント キーを再生成する必要はありません。 移行後に、アカウント キーを使用しているアプリケーションで接続文字列を更新する必要はありません。

ポータルのサポート

移行したストレージ アカウントは Azure portal で管理できます。 移行したストレージ アカウントを管理するためにクラシック ポータルを使用することはできなくなります。

関連項目