データとストレージを集中的に使用するワークロードを Azure に移行すると、スケーラブルでセキュリティで保護されたクラウド ストレージにアクセスできるため、急速なイノベーションと成長が可能になります。 このドキュメントでは、ブロック、ファイル、およびオブジェクト ストレージのシームレスな移行を実現するのに役立つ、明確で実用的なガイダンスを提供します。 さまざまな考慮事項の概要を説明し、主要なメトリックを提供し、関連する Azure ストレージ サービスについて説明し、ツールの選択を支援します。
バックグラウンド
このセクションを展開または縮小する場合に選択します
さまざまなビジネス要件と技術要件によって、全体的な Azure 移行戦略が決まります。 適切なアーキテクチャと技術的な設計上の決定を行うことができるようにユース ケースの特定の要件をキャプチャするために、 Microsoft Well-architected Framework (WAF) には、すべてのワークロードとサービスの移行に関する重要なガイダンスセットが含まれています。 その後、このプロセスは信頼性、セキュリティ、コストの最適化、オペレーショナル エクセレンス、およびパフォーマンス効率に対処します。 推奨されるベスト プラクティスには、WAF ガイダンスと次の情報の両方を確認して、特定のアプリケーションとサービスの包括的な移行アプローチを構築することが含まれます。
注
以下のガイダンスには、Azure Storage サービスへの非構造化データの移行に固有の情報が含まれています。 SQL、Oracle、テーブルなどの構造化データを含むシナリオについては、このドキュメントでは説明しません。
このガイダンスでは、非構造化データを Azure Storage サービスに移行することに重点を置いています。 コンテンツはデータ移行中心のアプローチを採用しているため、オペレーショナル エクセレンスやコストの最適化などの主題では、個別の詳細な議論が必要になる場合があります。 SQL、Oracle、Tables などの構造化データを含むシナリオでは、アプリケーションによって異なる追加の考慮事項が導入されています。
次のコンテンツは、他の公式の Microsoft ドキュメントに記載されている手法、フレームワーク、または推奨事項を置き換えたり無効にしたりすることはありません。
移行ステージとアクティビティ
完全な移行は 、評価、ターゲットの選択、計画、ツールの選択、移行の実行など、 さまざまな段階で構成されます。段階的なアプローチに従うことで、ダウンタイムとリスクを軽減してデータを Azure に移行できます。 各ステップでは、必要なすべてのパラメーターが確実にカバーされ、 ディスク、 ファイル、 およびオブジェクト データに最適な方法が選択されます。
評価
このセクションを展開または縮小する場合に選択します
このステージでは、サーバー メッセージ ブロック (SMB) 共有、ネットワーク ファイル システム (NFS) ボリューム、オブジェクト名前空間など、移行する必要があるすべてのソースを決定し、インベントリを作成します。 通常、プロセス全体には次のものが含まれます。
- すべてのデータ資産とデータ ソースのカタログ (インベントリ) を作成する。
- データ型とアクセス パターンの識別と理解。
- データの信頼性、パフォーマンス、ビジネス要件を理解する。
- レプリケーション、変更率、回復性とダウンタイムの許容度を評価する。
- セキュリティとコンプライアンスの要件について。
このフェーズは、手動で実行することも、自動化されたツールを使用することもできます。 評価フェーズに役立つ、独立系ソフトウェア ベンダー (ISV) から入手できる商用ツールがいくつかあります。 詳細については、 比較マトリックス の記事を参照してください。
評価ステージのアクティビティの詳細を参照してください。
ターゲットの選択
このセクションを展開または縮小する場合に選択します
評価段階で特定された要件を満たすことができる使用可能なオプションを理解することが不可欠です。 Microsoft Azure には、仮想マシン (VM) 用の Azure Files、Blob Storage、Azure NetApp Files、Managed Disks などの複数のストレージ サービスが用意されています。 さらに、コア ストレージ サービスに基づいて構築されたブロック、ファイル、オブジェクトワークロード用のオンプレミス ストレージ プラットフォームのソフトウェア定義バージョンを提供する ISV パートナーも存在します。
このステージには、主に次のアクティビティが含まれます。
- 最適なターゲット Azure ストレージ サービスを特定するための技術的要件の評価
- 特定されたストレージ ソリューションを使用して(アプリケーションまたはワークロードに基づいて) 適切なターゲット ソリューション アーキテクチャを確立する。
- 移行とターゲット ソリューションに関連する価格とコストの評価
ターゲット選択ステージのアクティビティの詳細を参照してください。
移行戦略の計画
このセクションを展開または縮小する場合に選択します
移行戦略を計画するには、データを Azure に移動するための適切な方法を特定する必要があります。 また、特定のワークロード、データの性質、または関連するアプリケーションに適したその他の考慮事項も含まれる場合があります。 次の一覧に、これらの考慮事項の例をいくつか示します。
- オンライン転送とオフライン転送
- リフト-アンド-シフト移行の実現可能性
- データ変更率とデータ階層化
- ハイブリッド ストレージのニーズとデータ移動
- 戦略としてのレプリケーション
- 移行戦略としてのバックアップと復元
移行計画戦略の詳細を参照してください。
移行ツールの選択
移行の実行に役立つさまざまな移行ツールがあります。 たとえば、AzCopy、robocopy、xcopy、rsync などの一部のオープン ソース ツールがあります。 Microsoft では、Azure Storage Mover、Azure Data box、Azure File Sync、Azure Migrate、Data Box Gateway などのマネージド ツールを提供しています。 他にも多くの商用の Microsoft 以外のツールも利用できます。 利用可能な商用ツールの一覧は、 比較マトリックス の記事で入手できます。この記事では、ツール間の比較も提供しています。
次の表に、参照用のシナリオベースの移行ツールの選択を示します。 実行可能な代替手段はケースバイケースで存在する可能性がありますが、次の例が最も適しているものと見なされます。
| シナリオ | 推奨されるツール |
|---|---|
| - 1 つの管理ウィンドウ (Azure) を備えた、フル マネージドの自動化された回復性のあるツールが必要です。 - 小さな転送を超えるファイルまたはファイル共有の移行 (通常は 1 TB のデータを > し、数百万のファイルまたはオブジェクトにスケールアップする) - オンプレミス NAS からのリフト アンド シフトや継続的同期 - Azure File Sync がインストールされていない、または既に構成されている Windows ファイル サーバー - 以下を含む Azure への移行: - SMB (2.x、3.x) から Azure BLOB (ホット/コールド) または HNS (階層型名前空間サービス) が有効になっている ADLS へ - SMB (2.x、3.x) から Azure Files (SMB のみ) - HNS が有効になっている Azure BLOB (ホット/コールド) または ADLS への NFS (v3、v4.1) (NFS v3 のみ) - 1 回または継続的 (マルチクラウド環境を含む) - S3 から Azure BLOB (ホット/コールド) または ADLS (階層型名前空間) - ファイルの内容のないファイル メタデータまたは構造のコピーのみを必要とする "メタデータのみ" コピー機能 (たとえば、アクセス許可のシード処理やドライラン移行の実行) |
Azure Storage Mover |
| - オフライン データ転送 (低帯域幅またはネットワーク接続なし、リモート サイト) - オンプレミスの SMB/NFS 共有/NAS ソースから Azure Blob、Files、ADLS に直接、特定のレベルにコピーします。これには、別のリージョン (ソースの国/リージョン外) への直接インポートが含まれます。 - Azure Files、Premium FileStorage、BLOB (ホット/コールド) からオンプレミスへのオフライン転送 - オンプレミス HDFS から Azure BLOB (ホット/コールド) または ADLS (HNS が有効) へのオフライン転送 |
Azure Data Box |
| - オフラインとオンラインの両方のソリューションを通じて、短期間で大量のデータを転送する必要があります。 - ネットワーク制約とそれに続く差分同期による初期一括データのオフライン シード処理。 |
差分同期に Azure Storage Mover を使用したシード処理用の Azure Data Box |
| - 物理マシン、VM、および接続されているディスク。Hyper-V、VMware、AWS、GCP で実行されている VM。 | Azure Migrate |
| - Azure へのまたは Azure からの高速、1回限りまたは増分的な小規模から中規模のデータ転送 (通常はジョブあたり 1 TB<) - サービス間の転送 (ファイルからファイルへ、ファイルからBLOBへなど) を Azure バックボーン (Azure内) 経由で行う - スクリプト機能の要件 (フィルター条件、メタデータの更新、変換など) と、そのような転送の正確な制御 - 何百万ものファイルやオブジェクトの転送は含まれません - Azure へのローカル ファイル システム、SMB、NFS マウント - S3 から Azure BLOB (通常は < 1 TB) - AWS EFS または AWS FSx for Windows から Azure Files へ - Google Cloud Storage (S3、GCS API) から Azure Storage (BLOB)、ADLS (HNS が有効) |
AzCopy (常に HTTPS REST API を使用) |
| - Windows File Server ソース (SMB 2.x または 3.x から Azure Files) - リバースまたは双方向のファイル同期を使用したハイブリッド データ同期 - オンプレミスのキャッシュとクラウドの階層化を使用した一元化されたファイル サーバー管理 - ブランチアウト展開でのコラボレーションとチームワーク (マルチサイト アクセスと同期) - ビジネス継続性とディザスター リカバリーを使用したクラウド側バックアップとオンプレミスのキャッシュ プレゼンス - Azure File Sync が既にデプロイおよび構成されている 1 回限りのファイル共有の移行ニーズ |
Azure File Sync |
| - オンプレミス キャッシュを使用した Azure Storage (BLOB) への継続的なインジェストとクラウドの階層化の要件 - ソースがオンプレミス (NFS v3、4.1、SMB 2.x、3.x) での一方向同期、または手動同期を使用した Azure との双方向同期のいずれかの場合。 - 同期されたデータの複数のオンプレミス コピーは必要ありません (一方向) |
Azure Data Box Gateway |
| - カスタム スクリプトによる小規模な 1 回限りの転送、または Linux/Windows CLI ベースの移行 | AzCopy、rsync、Robocopy |
| - Azure ネイティブ ツール機能以外の複雑なデータ管理、分析、階層化、またはサポートされていないユース ケースとターゲット (ANF や Lustre など) | ISV ツール (Komprise、Cirata、Data Dynamics、Atempo) |
| - オンプレミスのテープから Azure Storage への大規模なアーカイブ データの移行 | テープ移行ガイドを参照し、Tape Ark などのパートナー ソリューションを調べる |
| - ISV ソリューション (Commvault、Veeam、RUbrik など) を使用した大規模なオンプレミス バックアップまたはアーカイブ - バックアップ ツールを使用した差分同期を用いたオフラインでのシード作成。 |
パートナー固有の推奨事項を使用する。 ISV ソリューションを使用した Azure Data Box |
| - 次のようなその他のシナリオ: - オンプレミスの NAS から Azure Files へ（ただし、Data Box データコピーサービスを介した場合は除く） - オンプレミスの Linux から Azure Files NFS - AWS EFS/FSx/S3 から Azure Files - GCP FileStorage から Azure Files へ |
-
ISV ツール (Komprise、Cirata、Data Dynamics、Atempo) OR - クライアントにソースをマウントし、Azure Storage Mover または AzCopy を使用する |
移行ツールと選択肢について詳しくは、こちらをご覧ください。
移行の実行
このセクションを展開または縮小する場合に選択します
移行フェーズは、最後の移行手順です。 この手順では、データ移動と移行の操作を実行します。 通常、移行フェーズは、初期レプリケーションまたは一括移行で構成され、その後、最終的なカットオーバーの前にいくつかの増分同期イテレーションが行われます。 一般に、この方法では、よりスムーズで効率的な切り替えが実現されます。
非構造化データ移行の期間は、いくつかの側面によって異なります。 選択した方法以外では、最も重要な要因は、データの合計サイズとファイル サイズの分布です。 合計データ セットが大きいほど、移行に必要な時間が長くなります。 平均ファイル サイズが小さいと、移行に必要な時間が長くなります。 多数の小さなファイルがある場合は、移行時間の合計を短縮するために、大きなファイル (.tarまたは .zip ファイルに圧縮) 内にアーカイブすることを検討してください 。可能な場合は、それらのファイルをアーカイブします。
移行の実行について詳しくは、こちらをご覧ください。
ブロックベース デバイスの移行
このセクションを展開または縮小する場合に選択します
通常、ブロックベースのデバイスの移行は、仮想マシンまたは物理ホストの移行の一環として行われます。 移行が完了するまでブロック ストレージの決定を遅らせるのは一般的な間違いです。 ワークロード要件を十分に理解して事前にこれらの決定を行うと、クラウドへの移行がスムーズになります。
ブロック ベースのデバイスの移行は、次の 2 つの方法で実行できます。
- 完全な仮想マシンと基になるブロックベースのデバイスの移行。
- ブロック ベースのデバイスのみの移行。
基になるブロック デバイスを使用して VM を移行する方法については、 Azure Migrate のドキュメントを参照してください。 より複雑なユース ケースでは、 Cirrus Migrate Cloud を使用します。
移行に適したワークロードとその適切なアプローチについては、 ディスク ストレージ製品のページ と Azure Disk の種類 に関する記事を参照してください。 要件に最も適したディスクと、 ディスク バーストなどの最新の機能について学習できます。