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

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

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

適用対象

ファイル共有の種類	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 ストレージ アカウントとその中の SMB Azure ファイル共有をプロビジョニングします。

Azure ファイル共有は、Azure ストレージ アカウントのクラウドにデプロイされることに注意してください。 Standard ファイル共有の場合、この配置により、ストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。 単一のストレージ アカウントに複数のファイル共有を配置すると、これらの共有について IOPS とスループットの共有プールを作成することになります。

原則として、アーカイブ共有がある場合、またはそれらの中での日常のアクティビティが少ないことが予想される場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。 しかし、非常にアクティブな共有 (多くのユーザーやアプリケーションによって使用される共有) がある場合は、それぞれ 1 つのファイル共有があるストレージ アカウントをデプロイする必要があります。 これらの制限は、パフォーマンスが明示的にプロビジョニングされ、各共有に対して保証される FileStorage (Premium) ストレージ アカウントには適用されません。

ストレージ アカウントをデプロイする際のもう 1 つの考慮事項は冗長性です。 「Azure Files の冗長性」を参照してください。

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

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

次に、「SMB ファイル共有を作成する」の手順に従って、適切な数の Azure ファイル共有を含む適切な数の Azure ストレージ アカウントをデプロイします。 ほとんどの場合、各ストレージ アカウントのリージョンが同じであることを確認する必要があります。

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

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

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

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

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

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

フェーズ 3: RoboCopy

次の 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> 

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

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

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

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

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

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

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

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

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

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

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

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

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

スレッドが多くなるほど、1 TiB などの小さなファイルは、スレッドが少ない場合よりもかなり高速にコピーされます。 一方、1 TiB 分の大きなファイルにリソースを追加投資しても、相応のメリットは得られない場合があります。 スレッド数が多いと、ネットワーク経由で大きなファイルを同時により多くコピーしようとします。 この追加のネットワーク アクティビティによって、スループットまたはストレージ 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 ジョブで再試行されます。 多くの場合、使用中であることまたはタイムアウトの問題が原因で失敗したファイルは、最終的にこの方法でコピーされる可能性があります。

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

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

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

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

発生するトランザクションの数をより正確に理解するために、独自のデータに対していくつかの初期テストを実行することをお勧めします。 これにより、ファイル移行によって生成される可能性があるトランザクションの合計数をより適切に把握できます。

次のステップ

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

• Azure Files とは
• 移行の概要
• バックアップ: Azure ファイル共有スナップショット
• Azure Files で DFS 名前空間を使用する方法