ファイルとフォルダー ストレージのクラウド移行の基本
すべての移行は、ビジネス ニーズから始まります。 クラウド移行では、依存するファイルとフォルダーを移動することでワークロードが変換されます。 ワークロードは、アプリケーションまたは直接ユーザー アクセスのいずれかである場合があります。 どちらの場合も、ワークロードはクラウドに移行するストレージに依存します。 また、ワークロードはクラウドに移行したり、その場所に留まる可能性がありますが、新しいクラウド ストレージの場所を指定すために構成の変更が必要になります。 これらの詳細は、ストレージ セクションがある "クラウド ソリューション設計" に記録されます。
この記事の目的は、ストレージのクラウド ソリューション設計を実現できるように、Azure へのストレージ移行を実現する方法を理解する手掛かりを与えることです。
ファイルとフォルダーをクラウドに移行するには、最適な結果を得るために慎重な計画と多くの検討が必要です。 Azure Storage Mover には、ユーザーの体験をサポートする多くの機能と移行シナリオが用意されています。 この記事では、移行の一般的なタスクをフェーズに分け、それぞれのセクションで説明します。
フェーズ 1: 検出
検出フェーズでは、移行プロジェクトに含めるソースの場所を決定します。 Azure Storage Mover では、ソースの場所はファイル共有の形式で処理されます。 これらの場所は、ネットワーク接続ストレージ (NAS) やサーバー、またはワークステーション上に存在する可能性もあります。 ファイル共有の一般的なプロトコルは、SMB (サーバー メッセージ ブロック) と NFS (ネットワーク ファイル システム) です。
ワークロードで直接接続ストレージ (DAS) を使用している場合でも、Azure Storage Mover ではほとんどの場合、クラウド移行を支援できます。 ローカル フォルダー パスにファイル共有を作成し、ローカル ネットワーク経由で場所を共有できる場合もあります。 適切なアクセス許可と、ネットワークに関する検討を行うことにより、アプリケーションでローカル パスを使用している場合でも、この場所を Azure に移行できるようになります。
まず、ワークロードが依存するすべての共有の一覧を作成します。 クラウド ソリューションの設計を参照して、どの共有がオンプレミスに残り、どの共有がクラウド移行のスコープ内にあるかを確認します。 移行プロジェクトのスコープをできるだけ絞り込みます。 最終的に、ワークロードはクラウドの場所にフェールオーバーする必要があります。 ソースの場所の数が少ないほど、ワークロードのフェールオーバーが簡単になります。
複数のワークロードのストレージをほぼ同時に移行する必要がある場合は、これらを別々の移行プロジェクトに分割する必要があります。
重要
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 サービスでは、ソースとターゲットの各ペアをジョブ定義として記録できます。 ジョブ定義は、以前に作成した移行プロジェクトに入れ子になっています。 ソースとターゲットのペアごとに、新しい個別のジョブ定義が必要になります。
Note
Azure Storage Mover のこのリリースでは、ジョブ定義を作成する前にターゲット ストレージが存在している必要があります。 たとえば、ターゲットが Azure BLOB コンテナーの場合は、新しいジョブ定義を作成する前にデプロイする必要があります。
計画フェーズの結果は、ソース共有と Azure ターゲットの場所のマッピングです。 ターゲットがまだ存在しない場合は、Azure Storage Mover サービスに移行計画を記録する前に、次のフェーズ 「デプロイ」を完了する必要があります。
フェーズ 4: デプロイ
移行計画が完成したら、ストレージ アカウントやコンテナーなどのターゲット Azure Storage リソースがデプロイされていることを確認する必要があります。 Azure Storage Mover 内の各ソース/ターゲット ペアのジョブ定義として移行計画を記録するには、まずこのデプロイを完了する必要があります。
Azure Storage Mover は現在、ターゲット リソースのデプロイに役立ちません。 Azure ストレージをデプロイするには、Azure portal、Azure PowerShell、Azure CLI、または Bicep テンプレートを使用できます。
重要
Azure Storage をデプロイする場合、Azure Storage Mover のサポート ソースとターゲットのペアの組み合わせを確認し、サポートされていないシナリオを構成していないことを確認します。
フェーズ 5: 移行
Azure ターゲットの場所にファイルとフォルダーをコピーする作業は、移行フェーズ内で行われます。
移行フェーズでは、主要な考慮事項が 2 つあります。
- ワークロードのダウンタイムを最小限に抑えます。
- 正しい移行モードを決定する。
ダウンタイムを最小限に抑える
移行中は、ワークロードが依存しているストレージにアクセスできない期間が発生する場合があります。 多くの場合、これらの期間を最小限に抑えることが必要です。 このセクションでは、ワークロードのダウンタイムを最小限に抑えるための一般的な方法について説明します。
集中型の n パス移行
この方法では、ソースからターゲットに複数回コピーします。 これらのコピーの反復中、ソースはワークロードへの読み取りと書き込みに引き続き利用できます。 最後のコピーの反復の直前に、ソースをオフラインにします。 最後のコピーは、最初に行ったコピーより速く完了することが予想されます。 最後のコピーの後、ワークロードがフェールオーバーされ、Azure の新しいターゲット ストレージが使用されます。
Azure Storage Mover では、必要な頻度でのソースからターゲットへのコピーがサポートされています。 ジョブ定義には、ソース、ターゲット、移行の設定が格納されます。 ジョブ定義を実行するように移行エージェントに指示すると、ジョブが実行されます。 このリンクされた記事では、Storage Mover のリソース階層について詳しく学習できます。
移行モード
ファイルをソースからターゲットにどのようにコピーするかは、ファイルをどこからコピーするかと同じくらい重要です。 移行シナリオによって、異なる設定が必要になります。 移行中は、ダウンタイムを最小限に抑えるために、ソースからターゲットに複数回コピーする可能性があります。 コピーの反復から次の反復までの間にファイルまたはフォルダーが変更されると、コピー モードによって移行エンジンの動作が決まります。 移行中に名前空間に対して予想される変更に基づいて、適切なモードを慎重に選択してください。
次の 2 つのコピー モードがあります。
| Copy mode | 移行の動作 |
|---|---|
| ミラー ターゲットはソースと同じようになります。 |
- ソースに存在しない場合、ターゲット内のファイルは削除されます。 - ターゲット内のファイルとフォルダーは、ソースと一致するように更新されます。 |
| 結合 ターゲットにはソースよりも多くのコンテンツがあり、追加し続けます。 |
- ソースに存在しない場合でも、ファイルはターゲット内に保存されています。 - 名前とパスが一致するファイルは、ソースと一致するように更新されます。 - コピー間でフォルダー名を変更すると、ターゲット内のコンテンツが重複する可能性があります。 |
フェーズ 6: 移行後のタスク
移行のこのフェーズでは、ワークロードのフェールオーバーとデータの保護を可能にする他の構成とサービスについて考える必要があります。
たとえば、ワークロードをフェールオーバーするには、Azure ストレージに安全にアクセスするためのネットワーク パスが必要です。 移行中に Azure ストレージ アカウントのパブリック エンドポイントを使用した場合は、ストレージ アカウントのプライベート エンドポイントを構成し、パブリック エンドポイント経由のデータ要求をファイアウォール規則で無効にするを有効にすることを検討してください。
以下に、推奨事項をさらにいくつか示します。
次のステップ
これらの記事は、クラウド移行に Azure Storage Mover を利用するのに役立ちます。