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

適用対象: ✔️ SMB ファイル共有

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

AzCopy と RoboCopy

AzCopyとRoboCopyは根本的に異なるツールです。 RoboCopyはSMBを使用し、ファイルを完全な忠実度でコピーするため、移行に適しています。 ファイル忠実度の詳細については 「移行の基本 」を参照してください。 AzCopyはRESTを利用したクラウドネイティブツールです。

挙動上の主な違いは、 RoboCopy /MIR がソースからターゲットにミラーリングするということです。 ファイルの追加、変更、削除も処理します。 AzCopy同期は、ソースから削除されたファイルはターゲットから削除されず、移行シナリオでは不完全になります。 このため、Azureファイル共有をターゲットにした移行シナリオにはAzCopyは使わないでください。

Azure ファイル共有をマウントする

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

「Windows で Azure ファイル共有を使用する」を確認し、RoboCopy を開始する SMB Azure ファイル共有をマウントします。

RoboCopy を使用して Azure ファイル共有にファイルをコピーする

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

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

RoboCopy は、データ転送が不要な場合でもファイルがコピーされたことを報告する場合があります。 この動作は、robocopy が出力の生成時にファイル データとメタデータの変更の両方を評価するためです。

結果を正しく解釈するには、コマンド出力でファイルの状態を確認します。

• 新しい: ファイルデータはコピー先にコピーされます。
• 変更: メタデータのみが更新されます。ファイル データは再コピーされません。

どちらの場合も、RoboCopy はデータが転送されたかのようにバイト数を報告する場合があります。 この動作は、コピー操作を検証するときに混乱を招く可能性があります。

移行の切り替えを完了してください

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

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

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

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

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

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

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

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

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

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

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

このカテゴリーでは、 ソースストレージ、 ターゲットストレージ、そしてそれらをつなぐ ネットワーク を考えます。 これら3つのコンポーネントの中で最も遅い方が最大スループットを決定します。

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

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

RoboCopy では、/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は指定した名前空間を経由し、各ファイルやフォルダを初期実行時およびその後のキャッチアップ実行時の両方でコピーの有無を評価します。 これらの繰り返し実行はダウンタイムを最小限に抑え、移行ファイルの成功率を向上させます。

帯域幅が必ずしも最も制限される要素とは限りません。 多数の小さなファイルを持つ大規模な名前空間では、名前空間列挙速度がスループットよりも総コピー時間に大きな影響を与えることがあります。 小さなファイルの1 TiBをコピーするのが、大きなファイルの1 TiBをコピーするよりもかなり時間がかかります。 この違いが予想されます。

RoboCopyは /MT:n オプションを通じてマルチスレッドコピーをサポートしており、 n は使用するスレッド数を表します。 RoboCopy用にマシンをプロビジョニングする際は、プロセッサコア数(ほとんどのCPUは1コアに2スレッドを提供します)と、並列に実行する予定のRoboCopyジョブ数を考慮してください。

スレッドが多いと小さなファイルのコピーはかなり速くなりますが、大きなファイルに対しては比例した効果が得られないかもしれません。 大きなファイルに対してスレッド数が多いと、スループットやIOPS制約の可能性が高まります。

初回のRoboCopy実行では、利用可能なネットワーク帯域幅を飽和させるために高いスレッド数を使いましょう。 以降の /MIR 実行で変更が少ない場合は、処理速度がボトルネックになるため、スレッド数をプロセッサのコア数に合わせてください。 本番サーバー上の他のタスクのためにコアを予約する必要があるかどうかを検討してください。

移行時の名前空間の変更を避ける

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

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

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

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

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

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

Robocopy を使用して Azure Files スナップショットからローカル ドライブにファイルをコピーする

Robocopy を使用して、SMB Azure ファイル共有のスナップショット ビューからローカル ドライブにファイルとフォルダーをコピーできます。 詳細については、「 共有スナップショットからのローカル ドライブへのデータのコピー」を参照してください。

ストレージ トランザクション料金の見積もり

Azure Files への移行を開始すると、RoboCopy によってファイルとフォルダーが Azure にコピーされます。 Azure Files の課金モデルによっては、トランザクション料金が適用される場合があります。 「課金について」をご覧ください。

HDD (標準) の Azure ファイル共有で従量課金制課金モデルを使用している場合、移行によって生成されるトランザクションの数を見積もるのは困難な場合があります。

• ソースの使用されたストレージ容量に基づいてトランザクションの数を見積もることはできません。 トランザクションの数は、サイズではなく、移行される名前空間項目 (ファイルとフォルダー) とそのプロパティの数に応じてスケーリングされます。 たとえば、小さなファイルの 1 GiB を移行するには、より大きなファイルの 1 GiB を移行するよりも多くのトランザクションが必要です。
• ダウンタイムを最小限に抑えるために、ソースからターゲットまでコピー操作を複数回実行する必要があるかもしれません。 各コピー操作はすべてのソースアイテムとターゲットアイテムを処理しますが、その後の実行はより速く完了します。 最初の操作の後、コピーの実行間で導入された差異のみがネットワーク経由で転送されます。 転送されるデータは少なくなりますが、必要なトランザクションの数は変わらない可能性があることを理解することが重要です。
• 同じファイルを 2 回コピーしても、トランザクションの数が同じにならない可能性があります。 前回のコピー実行で移行された項目を処理すると、読み取りトランザクションがわずかしか発生しない場合があります。 これに対し、コピーの実行間でメタデータまたはコンテンツを変更する場合、ターゲットを更新するために、より多くのトランザクションが必要になる場合があります。

自分のデータで初期テストを行い、ファイル移行でどれだけのトランザクションが発生するかをよりよく理解しましょう。

次のステップ

以下の記事は、詳細オプションやベスト プラクティスの理解に役立ちます。

• Azure Files とは
• 移行の概要