すべての移行は、ビジネス ニーズから始まります。 クラウド移行では、依存するファイルとフォルダーを移動することでワークロードが変換されます。 ワークロードには、アプリケーションまたは直接ユーザー アクセスのいずれかを指定できます。 どちらの場合も、ワークロードはクラウドに移行するストレージに依存します。 また、ワークロードはクラウドに移行したり、その場所に留まる可能性がありますが、新しいクラウド ストレージの場所を指すために構成の変更が必要になります。 これらの詳細は、ストレージ セクションがある クラウド ソリューション設計 に記録されます。
この記事の目的は、ストレージのクラウド ソリューション設計を実現できるように、Azure へのストレージ移行を実現する方法に関する分析情報を提供することです。
ファイルとフォルダーをクラウドに移行するには、最適な結果を得るために慎重な計画と多くの考慮事項が必要です。 Azure Storage Mover では、体験をサポートする機能と移行シナリオの一覧が増え続けています。 この記事では、移行の一般的なタスクを、それぞれが独自のセクションを持つフェーズに分割します。
フェーズ 1: 検出
検出フェーズでは、移行プロジェクトに含まれるソースの場所を決定します。 Azure Storage Mover は、ファイル共有の形式でソースの場所を処理します。 これらの場所は、ネットワーク接続ストレージ (NAS)、サーバー、またはワークステーション上に存在する可能性があります。 ファイル共有の一般的なプロトコルは、SMB (サーバー メッセージ ブロック) と NFS (ネットワーク ファイル システム) です。
ワークロードで Direct Attached Storage (DAS) を使用している場合、ほとんどの場合、Azure Storage Mover はクラウドの移行を支援できます。 ローカル フォルダー パスにファイル共有を作成し、ローカル ネットワーク経由で場所を共有できる場合があります。 適切なアクセス許可とネットワークに関する考慮事項により、アプリケーションでローカル パスを使用している場合でも、この場所を Azure に移行できるようになりました。
まず、ワークロードが依存するすべての共有の一覧を作成します。 クラウド ソリューションの設計を参照して、どの共有がオンプレミスに残り、どの共有がクラウド移行のスコープ内にあるかを確認します。 移行プロジェクトのスコープをできるだけ絞り込みます。 最終的には、ワークロードをクラウドの場所にフェールオーバーする必要があります。 ソースの場所の数が少ないほど、ワークロードのフェールオーバーが容易になります。
複数のワークロードのストレージをほぼ同時に移行する必要がある場合は、それらを個別の移行プロジェクトに分割する必要があります。
Von Bedeutung
1 つの移行プロジェクトに複数のワークロードを含めるのはお勧めしません。 各ワークロードには、独自の移行プロジェクトが必要です。 この方法でプロジェクトを構成すると、移行管理とワークロードのフェールオーバーが大幅に簡略化されます。
検出フェーズの結果は、Azure に移行する必要があるファイル共有の一覧です。 ワークロードごとに個別のリストが必要です。
Azure Storage Mover には、個々のリストを作成して格納するための 移行プロジェクト が用意されています。 一般的な方法は、移行するワークロードの後に移行プロジェクトに名前を付ける方法です。 この方法により、計画手順と移行の進行状況の監視が簡略化されます。
フェーズ 2: 評価
Azure には、さまざまな種類のクラウド ストレージが用意されています。 Azure へのファイル移行の基本的側面の 1 つは、お使いのデータに適した Azure ストレージ オプションを見極めることです。 ファイルとフォルダーの数、ディレクトリ構造、アクセス プロトコル、ファイルの忠実性などの側面は、完全なクラウド ソリューション設計への重要な入力です。
評価フェーズでは、発見した共有や候補として絞り込んだ共有を調査し、クラウド ソリューション設計に適した Azure ターゲット ストレージを選択できたことを確認します。
移行の重要な部分は、ファイルを現在のストレージの場所から Azure に移動するときに必要なファイルの忠実性をキャプチャすることです。 さまざまなファイル システムとストレージ デバイスがファイルの忠実性情報の配列を記録するため、Azure でその情報を完全に保持または保持する必要はありません。 シナリオに必要なファイルの忠実性と、Azure のストレージ オファリングでサポートされる忠実度は、Azure で適切なストレージ ソリューションを選択するのにも役立ちます。 従来、汎用ファイル データは、少なくとも一部のファイル メタデータに依存します。 アプリ データはそうではない場合があります。
ファイルの基本的なコンポーネントは次の 2 つです。
- データ ストリーム: ファイルのデータ ストリームには、ファイルの内容が格納されます。
-
ファイル メタデータ: ファイル メタデータには、次のサブコンポーネントがあります。
- ファイル属性 ( 読み取り専用など)
- NTFS アクセス許可、ファイルおよびフォルダー アクセス制御リスト (ACL) などのファイルのアクセス許可
- タイムスタンプ、特に作成および最終更新タイムスタンプ
- 代替データ ストリーム。これは、より大量の非標準プロパティを格納する領域です。
移行におけるファイルの忠実性は、次の機能として定義できます。
- ソースから必要なすべてのファイル情報を読み取る。
- 移行サービスまたはツールを使用してファイルを転送します。
- 移行先のターゲット ストレージにファイルを格納する。
評価フェーズの出力は、ソース共有にある側面の一覧です。 これらの側面には、次のようなデータが含まれる場合があります。
- 共有サイズ
- 名前空間項目の数、またはファイルとフォルダーの組み合わせ数。
- Azure ストレージ ターゲットに保持する必要がある忠実度のレベル。
- Azure ストレージ ターゲットでネイティブに動作し続ける必要がある忠実度のレベル。
この分析情報は、ストレージ用のクラウド ソリューション設計に対する重要な入力です。
フェーズ 3: 計画
計画フェーズでは、検出されたソース共有と Azure のターゲットの場所を組み合わせます。
計画フェーズでは、各ソース共有を特定の宛先 (Azure BLOB コンテナーや Azure ファイル共有など) にマップします。 これを行うには、ターゲット リソースを含む Azure サブスクリプションとストレージ アカウントを計画して記録する必要があります。
Azure Storage Mover サービスでは、各ソースとターゲットのペアを ジョブ定義として記録できます。 ジョブ定義は、先ほど作成した移行プロジェクトに組み込まれています。 ソースとターゲットのペアごとに、新しい個別のジョブ定義が必要です。
注
このリリースの Azure Storage Mover では、ジョブ定義を作成する前にターゲット ストレージが存在している必要があります。 たとえば、ターゲットが Azure BLOB コンテナーの場合は、新しいジョブ定義を作成する前にデプロイする必要があります。
計画フェーズの結果は、ソース共有と Azure ターゲットの場所のマッピングです。 ターゲットがまだ存在しない場合は、Azure Storage Mover サービスに移行計画を記録する前に、次のフェーズ 「デプロイ」を完了する必要があります。
フェーズ 4: デプロイ
移行計画を完了したら、ストレージ アカウントやコンテナーなどのターゲット Azure Storage リソースがデプロイされていることを確認する必要があります。 Azure Storage Mover 内の各ソース/ターゲット ペアのジョブ定義として移行計画を記録するには、このデプロイを完了する必要があります。
現在、Azure Storage Mover はターゲット リソースのデプロイに役立てません。 Azure Storage をデプロイするには、Azure portal、Azure PowerShell、Azure CLI、または Bicep ファイルを使用できます。
Von Bedeutung
Azure Storage をデプロイするときは、Azure Storage Mover のサポート ソースとターゲットのペアの組み合わせを確認 し、サポートされていないシナリオを構成していないことを確認します。
フェーズ 5: 移行
Azure ターゲットの場所にファイルとフォルダーをコピーする作業は、移行フェーズ内で行われます。
移行フェーズには、次の 2 つの主な考慮事項があります。
- ワークロードのダウンタイムを最小限に抑えます。
- 正しい移行モードを決定します。
ダウンタイムを最小限に抑える
移行中は、ワークロードが依存しているストレージにアクセスできない期間が存在する場合があります。 多くの場合、これらの期間を最小限に抑えることが必要です。 このセクションでは、ワークロードのダウンタイムを最小限に抑えるための一般的な戦略について説明します。
集中型の n パス移行
この戦略では、ソースからターゲットにデータを複数回コピーします。 これらのコピーイテレーション中、ソースはワークロードに対する読み取りと書き込みに使用できます。 最後のコピーイテレーションの直前に、ソースをオフラインにします。 最終的なコピーは、最初のコピーよりも速く完了することが予想されます。 最終的なコピーの後、ワークロードはフェールオーバーされ、Azure の新しいターゲット ストレージが使用されます。
Azure Storage Mover では、必要な頻度でソースからターゲットへのコピーがサポートされます。 ジョブ定義には、ソース、ターゲット、および移行の設定が格納されます。 ジョブ定義を実行するように移行エージェントに指示すると、ジョブが実行されます。 このリンクされた記事では、 Storage Mover リソース階層の詳細を確認できます。
移行モード
ソースからターゲットへのファイルのコピー方法は、ファイルのコピー元とコピー元の場所と同様に重要です。 移行シナリオが異なると、異なる設定が必要になります。 移行中は、 ダウンタイムを最小限に抑えるために、ソースからターゲットに複数回コピーする可能性があります。 コピーイテレーション間でファイルまたはフォルダーが変更されると、 コピー モード によって移行エンジンの動作が決まります。 移行中に名前空間に予想される変更に基づいて、適切なモードを慎重に選択します。
次の 2 つのコピー モードがあります。
| コピー モード | 移行の動作 |
|---|---|
|
鏡 ターゲットはソースと似ています。 |
-
ターゲット内のファイルは、ソースに存在しない場合は削除されます。 - ターゲット内のファイルとフォルダーは、ソースと一致するように更新されます。 |
|
マージ ターゲットにはソースよりも多くのコンテンツがあり、それに追加し続けます。 |
-
ファイルは、ソースに存在しない場合でも、ターゲットに保持されます。 - 名前とパスが一致するファイルは、ソースと一致するように更新されます。 - コピー間でフォルダー名を変更すると、ターゲット内のコンテンツが重複する可能性があります。 |
フェーズ 6: 移行後のタスク
移行のこのフェーズでは、ワークロードのフェールオーバーとデータの保護を可能にする他の構成とサービスについて考える必要があります。
たとえば、ワークロードをフェールオーバーするには、Azure Storage に安全にアクセスするためのネットワーク パスが必要です。 移行中に Azure ストレージ アカウントのパブリック エンドポイントを使用した場合は、 ストレージ アカウントのプライベート エンドポイントを 構成し、 パブリック エンドポイント経由のデータ要求を無効にするファイアウォール規則を有効にすることを検討してください。
その他のいくつかの推奨事項を次に示します。
次のステップ
次の記事は、クラウド移行に Azure Storage Mover を利用するのに役立ちます。