RoboCopy を使用して Azure ファイル共有に移行する

この移行に関する記事では、RoboCopy を使用してファイルを Azure ファイル共有に移動または移行する方法について説明します。 RoboCopy は、移行に適した機能セットを備えた、信頼できるよく知られているファイル コピー ユーティリティです。 これには SMB プロトコルが使用されます。そのため、SMB をサポートする任意のソースとターゲットの組み合わせに幅広く適用できます。

  • データ ソース: SMB プロトコルをサポートする任意のソース。ネットワーク接続ストレージ (NAS)、Windows または Linux サーバー、別の Azure ファイル共有、その他多数
  • 移行経路: ソース ストレージ ⇒ Windows マシン (RoboCopy 使用) ⇒ Azure ファイル共有

ソースとデプロイのさまざまな組み合わせに応じて、異なる多数の移行経路があります。 移行ガイドの表を参照して、ご自身のニーズに最適な移行を見つけてください。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS はい いいえ
Standard ファイル共有 (GPv2)、GRS/GZRS はい いいえ
Premium ファイル共有 (FileStorage)、LRS/ZRS はい いいえ

AzCopy と RoboCopy

AzCopy と RoboCopy の 2 つは、基本的に異なるファイル コピー ツールです。 RoboCopy には、任意のバージョンの SMB プロトコルが使用されます。 AzCopy は、ターゲットが Azure Storage 内にある場合に限ってデータの移動に使用できる "クラウド内で生まれた" ツールです。 AzCopy は REST プロトコルに依存します。

RoboCopy は、信頼できる Windows ベースのコピー ツールとして、完全な忠実性を維持してファイルをコピーすることについては優れた優位性があります。 RoboCopy を使用すると、豊富な機能セットがあってファイルとフォルダーを完全な忠実性を維持してコピーできるため、多くの移行シナリオがサポートされます。 可能な最大限の忠実性を維持してファイルをコピーすることの重要性について詳細は、移行の概要に関する記事にあるファイルの忠実性に関するセクションを参照してください。

一方、AzCopy は最近になって、一定の忠実性を維持したファイル コピーをサポートするように拡張され、移行ツールとして検討対象になるために必要な最初の機能が追加されたばかりです。 ただし、まだ差があり、AzCopy フラグと RoboCopy フラグを比較するときに機能について誤解が生じやすいと言えます。

たとえば、RoboCopy /MIR を使用すると、ソースがターゲットにミラー化されます。つまり、追加、変更、削除されたファイルが考慮されます。 AzCopy -sync との重要な違いは、ソース上で削除されたファイルはターゲット上で削除されないという点です。 これにより、不完全な差分コピー機能セットが作成されます。 AzCopy は常に進化しています。 Azure ファイル共有をターゲットとする移行シナリオの場合、現時点では、AzCopy は推奨されるツールではありません。

移行の目標

目標は、既存のファイル共有の場所から Azure にデータを移動することです。 Azure を使用すると、Windows Server を必要とせずに使用できるネイティブの Azure ファイル共有にデータが格納されます。 この移行は、運用データの整合性と、移行中の可用性が保証される方法で行う必要があります。 後者については、ダウンタイムを最小限に抑えて、通常のメンテナンス期間に収まるか、わずかに超えるだけで済むようにする必要があります。

移行の概要

移行プロセスは、いくつかのフェーズで構成されます。 Azure ストレージ アカウントとファイル共有をデプロイする必要があります。 さらに、ネットワークを構成し、DFS 名前空間のデプロイ (DFS-N) を検討したり、既存のものを更新したりします。 実際にデータをコピーするときになったら、ダウンタイムを最小限に抑えるために、差分 RoboCopy を繰り返し実行することを検討する必要があります。最後に、新しく作成された Azure ファイル共有にユーザーをカットオーバーします。 以下のセクションでは、移行プロセスの各フェーズについて詳しく説明します。

ヒント

この記事に戻った場合は、右側にあるナビゲーションを使用して、中断した移行フェーズに移動してください。

フェーズ 1:必要な Azure ファイル共有の数を特定する

この手順では、必要な Azure ファイル共有の数を決定します。 1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。

現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。 このシナリオを理解する最も簡単な方法は、1:1 で Azure ファイル共有にマップするオンプレミスの共有を想像することです。 1 つの Windows Server インスタンスの共有数が 30 以下と十分に少ない場合は、1 対 1 のマッピングをお勧めします。

共有の数が 30 を超える場合、通常オンプレミスの共有を 1 対 1 で Azure ファイル共有にマッピングする必要はありません。 次のオプションを検討してください。

共有のグループ化

たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。 1 つの Azure ファイル共有にオンプレミスの共有を複数格納しても、ローカルの Windows Server インスタンスに通常の 15 個の SMB 共有を作成できます。 これは、単にこれらの 15 個の共有のルート フォルダーを共通フォルダーの下のサブフォルダーとして整理することを意味します。 その後、この共通フォルダーを Azure ファイル共有に同期します。 そうすることで、このオンプレミスの共有グループに必要なのは、クラウド内の 1 つの Azure ファイル共有のみとなります。

ボリュームの同期

Azure File Sync では、ボリュームのルートを Azure ファイル共有に同期することをサポートしています。 ボリューム ルートを同期した場合、すべてのサブフォルダーとファイルは同じ Azure ファイル共有に格納されます。

ボリュームのルートを同期することが常に最適なオプションであるとは限りません。 複数の場所に同期することには利点があります。 たとえば、そうすることで、同期スコープあたりの項目数を少なく抑えることができます。 Azure ファイル共有と Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダ) を保持できるようテストされています。 ただし、ベスト プラクティスとしては、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 Azure File Sync に含める項目数を少数に設定することは、ファイルの同期にとって有益というだけではありません。項目の数が少ないと、次のようなシナリオでも利点があります。

  • クラウド コンテンツの初期スキャンの完了までの時間が短くなり、その結果、Azure File Sync 対応のサーバーに名前空間が表示されるまでの待機時間が短縮されます。
  • Azure ファイル共有スナップショットからのクラウド側の復元が高速になります。
  • オンプレミスサーバーのディザスター リカバリーが大幅にスピードアップされます。
  • Azure ファイル共有 (同期以外) で直接行われた変更が、より高速に検出、同期されます。

ヒント

ファイルとフォルダーの数が不明な場合は、JAM Software GmbH の TreeSize ツールをぜひご利用ください。

デプロイ マップへの構造化アプローチ

後の手順でクラウド ストレージをデプロイする前に、オンプレミス フォルダーと Azure ファイル共有の間にマップを作成することが重要です。 このマッピングを行うと、プロビジョニングする Azure File Sync の "同期グループ" リソースの数と名称が通知されます。 同期グループは、Azure ファイル共有とサーバー上のフォルダーを連携させ、同期接続を確立します。

必要な Azure ファイル共有の数を決めるには、次の制限事項とベストプラクティスをレビューしてください。 そのことが、マップの最適化に役立ちます。

  • Azure File Sync エージェントがインストールされているサーバーは、最大 30 個の Azure ファイル共有と同期できます。

  • Azure ファイル共有は、ストレージ アカウント内にデプロイされます。 この配置により、このストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。

    理論的には、1 つの標準 Azure ファイル共有により、ストレージ アカウントが提供できる最大パフォーマンスが飽和状態になる可能性があります。 1 つのストレージ アカウントに複数の共有を配置することは、これらの共有について IOPS とスループットの共有プールを作成することを意味します。 これらのファイル共有への Azure File Sync のみのアタッチを計画している場合は、複数の Azure ファイル共有を同じストレージ アカウントにグループ化しても問題は発生しません。 関連メトリックの詳細については、Azure ファイル共有のパフォーマンス ターゲットを参照してください。 これらの制限は、パフォーマンスが明示的にプロビジョニングされ、各共有に対して保証される Premium Storage には適用されません。

    Azure ファイル共有をネイティブで使用する Azure にアプリをリフトする場合は、Azure ファイル共有のパフォーマンスをさらに上げる必要があります。 将来的にでもこのように使用することが考えられる場合は、1 つの標準の Azure ファイル共有を独自のストレージ アカウントに作成するのが最善です。

  • 1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージ アカウント数は 250 に制限されています。

ヒント

この情報を考慮して、ボリューム上の複数のトップレベル フォルダーを共通の新しいルート ディレクトリにグループ化することがしばしば必要になります。 次に、この新しいルート ディレクトリと、その中にグループ化したすべてのフォルダーを、1 つの Azure ファイル共有に同期します。 この手法を使用すると、サーバーあたり 30 個の Azure ファイル共有同期の制限内に抑えることができます。

共通のルートの下でのこのグループ化は、データへのアクセスにはいっさい影響しません。 ACL はそのまま維持されます。 今ここで共通のルートに変更したローカル サーバー フォルダー上に必要共有パス (SMB 共有や NFS 共有など) がある場合に限り、その調整が必要となります。 それ以外の変更はありません。

重要

Azure File Sync の最も重要なスケール ベクターは、同期が必要な項目 (ファイルとフォルダー) の数です。 詳細については、「Azure File Sync のスケール ターゲット」を確認してください。

ここでのベストプラクティスは、同期スコープあたりの項目数を少なくしておくことです。 これは、フォルダーを Azure ファイル共有にマッピングする際に考慮する必要がある重要な要素です。 Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダー) を使用して検証済みです。 ただし、多くの場合、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 これらの数値を超え始めた場合は、名前空間を複数の共有に分割します。 これらの数値をほぼ下回っている場合、複数のオンプレミスの共有を同じ Azure ファイル共有にグループ化することを続行できます。 この方法により、拡大する余地が得られます。

状況によっては、一連のフォルダーが同じ Azure ファイル共有に論理的に同期される可能性があります (前述の新しい共通のルート フォルダーのアプローチを使用します)。 ただし、1 つの Azure ファイル共有ではなく 2 つに同期されるように、フォルダーを再グループ化することをお勧めします。 このアプローチを使用すると、ファイル共有あたりのファイルとフォルダーの数をサーバー間に分散させることができます。 オンプレミスの共有を分割し、より多くのオンプレミス サーバー間で同期させることもできます。これにより、追加のサーバーごとに 30 を超える Azure ファイル共有と同期することができます。

マッピング テーブルを作成する

マッピング テーブルの例を示す図。この画像に記されている内容を体験して使用するには、以下のファイルをダウンロードしてください。

前述の情報を使用して、必要な Azure ファイル共有の数を決定し、既存のデータのどの部分がどの Azure ファイル共有に格納されるかを判断します。

必要に応じて参照できるように、自分の考えを記録しておく表を作成します。 一度に多数の Azure リソースをプロビジョニングするときは、マッピング計画の詳細がおろそかになりがちなので、情報が整理された状態を維持することが重要です。 次の Excel ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。


Excel icon that sets the context for the download. 名前空間マッピング テンプレートをダウンロードします。

フェーズ 2: Azure ストレージ リソースをデプロイする

このフェーズでは、フェーズ 1 のマッピング テーブルを参照し、それを使用して、適切な数の Azure ストレージ アカウントと、その中のファイル共有をプロビジョニングします。

Azure ファイル共有は、Azure ストレージ アカウントのクラウドに格納されます。 ここでは、また別のレベルのパフォーマンスに関する考慮事項が適用されます。

高度にアクティブな共有 (多くのユーザーやアプリケーションによって使用される共有) がある場合、2 つの Azure ファイル共有がストレージ アカウントのパフォーマンス制限に達する可能性があります。

ベスト プラクティスは、それぞれ 1 つのファイル共有を持つストレージ アカウントをデプロイすることです。 アーカイブ共有がある場合、またはそれらの中での日常のアクティビティが少ないことが予想される場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。

これらの考慮事項は、Azure File Sync より、(Azure VM 経由での) クラウドへの直接アクセスの場合によりいっそう当てはまります。これらの共有で Azure File Sync のみを使用する場合は、いくつかのものを 1 つの Azure ストレージ アカウントにグループ化するのが適切です。

共有のリストを作成してある場合は、各共有を、それらが配置されるストレージ アカウントにマップする必要があります。

前のフェーズで、共有の適切な数を決定しました。 この手順では、ファイル共有へのストレージ アカウントのマッピングを行いました。 次に、適切な数の Azure ファイル共有が含まれている適切な数の Azure ストレージ アカウントをデプロイします。

ご利用の各ストレージ アカウントのリージョンが、いずれも同じであり、既にデプロイしているストレージ同期サービス リソースのリージョンと一致していることを確認します。

注意事項

上限が 100 TiB の Azure ファイル共有を作成する場合、その共有で使用できるのは、ローカル冗長ストレージまたはゾーン冗長ストレージの冗長オプションのみとなります。 100 TiB のファイル共有を使用する場合は、事前にご自分のストレージ冗長のニーズを検討してください。

既定では、Azure ファイル共有は引き続き 5 TiB の上限で作成されます。 大きなファイル共有を作成するには、「Azure ファイル共有を作成する」の手順に従ってください。

ストレージ アカウントをデプロイする際のもう 1 つの考慮事項は、使用する Azure ストレージの冗長性です。 詳細については、「Azure Storage 冗長オプション」を参照してください。

ご利用のリソースの名前も重要です。 たとえば、人事部の複数の共有を Azure ストレージ アカウントにグループ化する場合は、そのストレージ アカウントに適切な名前を指定する必要があります。 同様に、使用する Azure ファイル共有に名前を付けるときは、オンプレミスの対応するものに使用したのと同じような名前を使用する必要があります。

フェーズ 3: Azure ファイル共有を使用するための準備

このフェーズの情報を使用すると、Azure のサーバーとユーザーが Azure ファイル共有を利用できるようにする方法を決めることができます。 最も重要な決定事項は次のとおりです。

  • ネットワーク: ネットワークで SMB トラフィックをルーティングできるようにします。
  • 認証: Kerberos 認証用に Azure ストレージ アカウントを構成します。 AdConnect とドメインがストレージ アカウントに参加すると、アプリとユーザーが認証に AD ID を使用できるようになります。
  • 承認: Azure ファイル共有ごとに共有レベルの ACL を使用すると、AD ユーザーとグループが特定の共有にアクセスできるようになり、Azure ファイル共有内でネイティブ NTFS ACL が引き継がれます。 ファイルとフォルダーの ACL に基づく承認は、オンプレミスの SMB 共有の場合と同様に機能します。
  • ビジネス継続性: 既存の環境への Azure ファイル共有の統合には、多くの場合、既存の共有アドレスを保持することが伴います。 まだ DFS 名前空間を使用していない場合は、環境内でそれを確立することを検討してください。 ユーザーとスクリプトが使用する共有アドレスを変更せずに維持できます。 DFS-N でクライアントを Azure ファイル共有にリダイレクトすると、SMB の名前空間ルーティング サービスが提供されます。

このビデオは、簡単な 5 つのステップでインフォメーション ワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。
ビデオでは、いくつかのトピックに関する専用のドキュメントが参照されています。

Azure ファイル共有のマウント

RoboCopy を使用する前に、Azure ファイル共有に SMB 経由でアクセスできるようにする必要があります。 最も簡単な方法は、ローカル ネットワーク ドライブとして、RoboCopy に使用する予定の Windows Server に共有をマウントすることです。

重要

Azure ファイル共有をローカル Windows Server に正常にマウントする前に、「フェーズ 3: Azure ファイル共有を使用するための準備」を完了しておく必要があります。

準備ができたら、「Windows で Azure ファイル共有を使用する」のハウツー記事をご確認ください。 それから、RoboCopy を開始する Azure ファイル共有をマウントします。

フェーズ 4: RoboCopy

次の RoboCopy コマンドを実行すると、ソース ストレージから Azure ファイル共有に差分 (更新されたファイルおよびフォルダー) のみがコピーされます。

robocopy /MT:128 /R:1 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 
Switch 説明
/MT:n Robocopy をマルチスレッドを実行できるようにします。 n の既定値は 8 です。 スレッドの最大数は 128 です。 最初の実行では、スレッド数を多くしてください。 スレッド数を多くすると、利用可能な帯域幅が飽和しやすくなります。 後続 /MIR の実行は、使用可能なコンピューティングと使用可能なネットワーク帯域幅の影響を徐々に受けます。 後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数とより厳密に一致させます。 実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。
/R:n 最初の試行でコピーに失敗したファイルの最大再試行回数です。 ファイルのコピーが完全に失敗するまでの再試行の最大数 (n) を指定することにより、RoboCopy 実行の速度を向上させることができます。 このスイッチは、RoboCopy がさらに実行されることが既に明らかである場合に動作します。 現在の実行でファイルのコピーが失敗した場合は、次の RoboCopy ジョブで再試行されます。 この方法を使用すると、使用中でまたはタイムアウトの問題が原因で失敗したファイルが、最終的にコピーされる可能性があります。
/W:n 前の試行時に正常にコピーされなかったファイルのコピーを試行する前に、RoboCopy が待機する時間を指定します。 n は再試行の間の待機時間 (秒数) です。 /W:n は、多くの場合、/R:n と共に使用されます。
/B バックアップ アプリケーションが使用するのと同じモードで Robocopy を実行します。 このスイッチを使用すると、現在のユーザーがアクセス許可を持っていないファイルを、Robocopy によって移動できます。
/MIR (ソースをターゲットにミラーリング。) RoboCopy でソースとターゲット間の差分のみをコピーします。 空のサブディレクトリがコピーされます。 変更された、またはターゲットに存在しない項目 (ファイルまたはフォルダー) がコピーされます。 ターゲットに存在する一方でソースには存在しない項目は、ターゲットから消去 (削除) されます。 このスイッチを使用する場合は、ソースとターゲットのフォルダー構造を正確に一致させます。 "一致" とは、正しいソースおよびフォルダー レベルから、コピー先の一致するフォルダー レベルにコピーすることを意味します。 その場合にのみ、"キャッチ アップ" コピーを正常に実行することができます。 ソースとターゲットが一致しない場合に /MIR を使用すると、大規模な削除と再コピーが行われます。
/IT 特定のミラー シナリオで、忠実性が維持されることを保証します。
たとえば、Robocopy を 2 回実行する間に、ファイルで ACL の変更と属性の更新があった場合、非表示とマークされます。 /IT を使用しない場合、ACL の変更が Robocopy で見逃されて、ターゲットの場所に転送されない可能性があります。
/COPY:[copyflags] ファイル コピーの忠実性。 既定値:/COPY:DAT。 コピー フラグ: D = データ、A = 属性 T = タイムスタンプ、S = セキュリティ = NTFS ACL O = 所有者情報、U= 監査情報。 監査情報を Azure ファイル共有に格納することはできません。
/DCOPY:[copyflags] ディレクトリのコピーの忠実性。 既定値:/DCOPY:DA。 コピーフラグ: D = データ A = 属性、T = タイムスタンプ。
/NP 各ファイルとフォルダーのコピーの進行状況を表示しないよう指定します。 進行状況を表示すると、コピーのパフォーマンスが大幅に低下します。
/NFL ファイル名をログに記録しないことを指定します。 コピーのパフォーマンスを向上させます。
/NDL ディレクトリ名をログに記録しないことを指定します。 コピーのパフォーマンスを向上させます。
/UNILOG:<file name> 状態を Unicode 形式でログ ファイルに書き込みます。 (既存のログを上書きします)。
/L テスト実行の場合のみ
ファイルは一覧表示されるだけです。 コピーも削除もされず、タイム スタンプも付きません。 コンソール出力には /TEE とよく使用されます。 テスト結果を適切に文書化するには、サンプル スクリプトのフラグ (/NP/NFL/NDL など) の削除が必要になる場合があります。
/LFSM 階層型ストレージを持つターゲット専用
RoboCopy を "低空き領域モード" で動作するよう指定します。 このスイッチは、Robocopy が完了する前にローカル容量が不足する可能性がある、階層型ストレージを持つターゲットにのみ有効です。 これは、Azure File Sync のクラウドの階層化が有効なターゲットで使用するために特別に追加されました。 これは、Azure File Sync とは別に使用できます。このモードでは、ファイルのコピーによって宛先ボリュームの空き領域が "床" 値よりも小さくなるたびに、Robocopy が一時停止します。 この値は /LFSM:n のフラグ形式で指定できます。 パラメーター n は、ベース 2: nKBnMB、またはnGB で指定します。 明示的な床値を示さずに /LFSM を指定した場合、床は宛先ボリュームのサイズの 10% に設定されます。 低空き領域モードは、/MT/EFSRAW/B または /ZB では利用できません。
/Z 慎重に使用すること
再起動モードでファイルをコピーします。 このスイッチは、ネットワーク環境が不安定な場合にのみ、使用することをお勧めします。 追加のログ記録が原因で、コピーのパフォーマンスが大幅に低下します。
/ZB 慎重に使用すること
再起動モードが使用されます。 アクセスが拒否された場合、このオプションではバックアップ モードが使用されます。 このオプションでは、チェックポイント処理が原因で、コピーのパフォーマンスが大幅に低下します。

重要

少なくとも 2021 年 8 月 26 日の OS 更新プログラム KB5005103 を備えた Windows Server 2019 を使用します。 特定の RoboCopy シナリオに対する重要な修正プログラムが含まれています。

ヒント

RoboCopy が運用環境に影響を与えたり、多くのエラーを報告したり、予想どおりの速度で進行していない場合、トラブルシューティングのセクションを確認してください。

フェーズ 5:ユーザーのカットオーバー

RoboCopy コマンドを初めて実行する時点では、ユーザーとアプリケーションがまだ移行のソース上のファイルにアクセスしていて、それを変更する可能性があります。 RoboCopy で、ある 1 つのディレクトリを処理してから次に進んだ後、ソースの場所でユーザーがファイルを追加、変更、または削除する可能性があり、それは現在の RoboCopy の実行では処理されません。 これは正しい動作です。

最初の実行では、チャーンされたデータの大部分を Azure ファイル共有に移動します。 この最初のコピーには、時間がかかることがあります。 RoboCopy の速度に影響する可能性のある点の詳細については、トラブルシューティング セクションをご覧ください。

最初の実行が完了した後、コマンドを再度実行します。

同じ同期に対して RoboCopy を 2 回目に実行したときは、前回の実行以降に発生した変更のみを転送すればよいため、処理は短時間で完了します。 同じ共有に対してジョブを繰り返し実行できます。

ダウンタイムが許容可能と考えられる場合は、ソースの共有にユーザーがアクセスできないようにする必要があります。 これは、ユーザーがファイルとフォルダー構造およびコンテンツを変更できないようにするいずれの手順でも行えます。 たとえば、DFS-Namespace を存在しない場所に指定したり、各共有の ACL を変更したりすることなどです。

最後に 1 回 RoboCopy ラウンドを実行します。 それにより、漏れている可能性があるすべての変更が取得されます。 この最後の手順にかかる時間は、RoboCopy のスキャンの速度に依存します。 前回の実行にかかった時間を測定することで、(ダウンタイムに相当する) 時間を見積もることができます。

前のセクションでは、ユーザーが自分の ID で共有にアクセスするように構成し、また、ユーザーが新しい Azure ファイル共有 (DFS-N) への確立されたパスを使用するための戦略を確立しました。

異なるソースとターゲット共有の間でこれらのコピーのいくつかを並行して実行することができます。 これを行う場合は、システムに過剰に負荷がかからないようなネットワーク スループットおよびコアとスレッドの数の比率を維持してください。

トラブルシューティングと最適化

指定された RoboCopy 実行の速度と成功率は、複数の要因によって決まります。

  • ソース ストレージとターゲット ストレージの IOPS
  • ソースとターゲットの間で使用可能なネットワーク帯域幅
  • 名前空間内のファイルとフォルダーを迅速に処理する機能
  • RoboCopy 実行間の変更の数

IOPS と帯域幅に関する考慮事項

このカテゴリでは、ソース ストレージターゲット ストレージ、およびそれらを接続する ネットワーク の能力を考慮する必要があります。 達成可能な最大スループットは、これら 3 つのコンポーネントのうち、最も低速なものによって決まります。 最大能力に応じた最適な転送速度をサポートするようにネットワーク インフラストラクチャが構成されていることを確認してください。

注意事項

多くの場合、可能な限り高速にコピーすることが望ましいですが、他のビジネス クリティカルなタスクに使用されることの多いローカル ネットワークと NAS アプライアンスの使用状況を考慮してください。

可能な限り高速にコピーすることは、移行によって使用可能なリソースを独占するリスクがある場合には望ましくない可能性があります。

  • ご使用の環境において移行を実行する最適なタイミングを考慮します (日中、時間外、または週末)。
  • また、RoboCopy の速度を調整するための Windows Server のネットワーク QoS も考慮してください。
  • 移行ツールのための不要な作業を行わないようにします。

RobCopy では /IPG:n スイッチを指定することによってパケット間の遅延を挿入できます。n は、RoboCopy パケット間においてミリ秒単位で測定されます。 このスイッチを使用すると、IO が制限されたデバイスと過密したネットワーク リンクの両方でリソースの独占を回避できます。

/IPG:n は、特定の Mbps に対する正確なネットワーク調整には使用できません。 代わりに Windows Server のネットワーク QoS を使用してください。 RoboCopy では、すべてのネットワーク ニーズに関して SMB プロトコルに完全に依存します。 SMB を使用する理由は、RoboCopy がネットワーク スループット自体に影響を与えることができないためですが、使用速度が低下する可能性はあります。

同様の考えが、NAS で観察される IOPS にも当てはまります。 NAS ボリュームのクラスター サイズ、パケット サイズ、およびその他のさまざまな要因が、観察される IOPS に影響します。 多くの場合、パケット間の遅延を導入することが、NAS の負荷を制御する最も簡単な方法です。 たとえば、約 20 ミリ秒 (n = 20) からその数値の倍数まで、複数の値をテストします。 遅延を導入すると、他のアプリが期待どおりに動作できるようになったかどうかを評価できます。 この最適化戦略により、ご使用の環境内で最適な RoboCopy 速度を見つけることができます。

処理速度

RoboCopy では、指し示されている名前空間を走査し、各ファイルとフォルダーをコピーに対して評価します。 すべてのファイルは、最初のコピー中およびキャッチアップ コピー中に評価されます。 たとえば、同じソースおよびターゲット ストレージ場所に対して RoboCopy/MIR の実行が繰り返されます。 これらの繰り返される実行は、ユーザーとアプリのダウンタイムを最小限に抑え、移行されるファイルの全体的な成功率を向上させるために役立ちます。

多くの場合、既定で帯域幅を移行における最も制限の厳しい要因と見なしています。実際にそのとおりだと考えられます。 ただし、名前空間を列挙する機能により、小さなファイルを含む大規模な名前空間の場合は、コピーの合計時間に与える影響がはるかに大きくなる可能性があります。 1 TiB 分の小さなファイルをコピーする時間は、1 TiB 分の数少ない大きなファイルをコピーする時間よりもはるかに長くなることを考慮します。 他のすべての変数が同じままであることを前提としています。

この違いの原因は、名前空間内を通過するために必要な処理能力です。 RoboCopy では、/MT:n パラメーターを使用したマルチスレッド コピーがサポートされます。ここで、n は使用されるスレッドの数を表します。 そのため、RoboCopy 専用のマシンをプロビジョニングする場合は、プロセッサ コアの数と、それらが提供するスレッド数との関係を考慮します。 最も一般的なのは、コアあたり 2 つのスレッドです。 マシンのコア数とスレッド数は、指定する必要のあるマルチスレッド値 /MT:n を決定するための重要なデータ ポイントです。 また、特定のマシンで並列実行する予定の RoboCopy ジョブの数も考慮します。

スレッドが多くなるほど、1 TiB 分の小さなファイルは、スレッドが少ない場合よりも高速にコピーされます。 一方、1 TiB 分の大きなファイルにリソースを追加投資しても、相応のメリットは得られない場合があります。 スレッド数が多いと、ネットワーク経由で大きなファイルを同時により多くコピーしようとします。 この追加のネットワーク アクティビティによって、スループットまたはストレージ IOPS による制約を受ける可能性が高くなります。

空のターゲットへの最初の RoboCopy 中、または多数の変更されたファイルを使用した差分実行中に、ネットワーク スループットによって制限される可能性があります。 最初の実行では、スレッド数を多くしてください。 スレッド数が多いと、コンピューター上で現在使用可能なスレッドを超えても、使用可能なネットワーク帯域幅が飽和状態になります。 後続の/MIR の実行は、アイテムを処理することによって徐々に影響を受けます。 差分実行の変更が少ないほど、ネットワーク経由でのデータ転送が減少します。 ネットワーク リンク上で移動する機能よりも、名前空間項目を処理する機能によって速度が向上するようになりました。 後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数と一致させます。 実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。

ヒント

経験則: 最初の RoboCopy 実行ではより高遅延のネットワークのデータを大量に移動するため、スレッド カウントをオーバープロビジョニングすることでメリットが得られます (/MT:n)。 その後の実行ではコピーされる差異が少なくなり、おそらくは、ネットワーク スループット制約からコンピューティング制約に移行するでしょう。 こうした状況では多くの場合、RoboCopy のスレッド カウントをマシンで実際に利用できるスレッドに合わせることが推奨されます。 そのシナリオでのオーバープロビジョニングはプロセッサのコンテキスト移動を増やす場合があり、おそらくコピーが遅くなるでしょう。

不要な作業の回避

名前空間の大規模な変更は避けてください。 ディレクトリ間でのファイルの移動、プロパティの大規模な変更、アクセス許可 (NTFS ACL) の変更などです。 特に ACL の変更は、フォルダー階層の下位にあるファイルに対して変更が連鎖的に影響することが多いため、大きな影響を及ぼす可能性があります。 次のような影響が考えられます。

  • ACL の変更によって影響を受けた各ファイルおよびフォルダーを更新する必要があるため、RoboCopy ジョブの実行時間が長くなる
  • 以前に移動したデータを再利用するには、再コピーが必要になる場合がある。 たとえば、ファイルが既にコピーされた後にフォルダー構造が変更される場合、より多くのデータをコピーする必要があります。 RoboCopy ジョブでは、名前空間の変更を "再生" できません。 次のジョブで、古いフォルダー構造へ以前に転送されたファイルを削除し、新しいフォルダー構造でファイルを再度アップロードする必要があります。

もう 1 つの重要な側面は、RoboCopy ツールを効果的に使用することです。 推奨される RoboCopy スクリプトでは、エラー用のログ ファイルを作成して保存します。 コピー エラーは発生する可能性があります。それが普通です。 多くの場合、これらのエラーによって、RoboCopy などのコピー ツールを複数ラウンド実行することが必要になります。 最初の実行 (NAS からファイル、サーバーから Azure ファイル共有、など)。 コピーされなかったファイルをキャッチして再試行するための /MIR スイッチを使用した 1 回以上の追加実行。

特定の名前空間スコープに対して RoboCopy を複数ラウンドを実行する準備を整えておく必要があります。 後続の実行は、コピー対象が少なくなるので迅速に完了しますが、名前空間の処理速度によって次第に制約されます。 複数ラウンドを実行する場合は、RoboCopy の特定の実行で非合理的にすべてをコピーしようとしないようにすることで、各ラウンドを高速化できます。 これらの RoboCopy スイッチにより、大きな違いがもたらされる可能性があります。

  • /R:n n = 失敗したファイルのコピーを再試行する頻度
  • /W:n n = 再試行を待機する秒数

/R:5 /W:5 が合理的な設定ですが、自由に調整できます。 この例では、失敗したファイルは 5 回再試行され、再試行間の待機時間は 5 秒です。 それでもファイルのコピーに失敗した場合は、次の RoboCopy ジョブで再試行されます。 多くの場合、使用中であることまたはタイムアウトの問題が原因で失敗したファイルは、最終的にこの方法でコピーされる可能性があります。

次の手順

Azure ファイル共有については、さらに知るべきことがあります。 以下の記事では、高度なオプション、ベスト プラクティスについて説明します。トラブルシューティングのヘルプもあります。 これらの記事は、それぞれに対応する Azure ファイル共有のドキュメントにリンクしています。