DataBox を使用してネットワーク接続ストレージ (NAS) から Azure ファイル共有に移行する

[アーティクル]
11/21/2023

これは、NAS および Azure DataBox のキーワードが関係する移行に関する記事の 1 つです。この記事がご使用のシナリオに当てはまるかどうかを確認してください。

データソース: ネットワーク接続ストレージ (NAS)
移行ルート: NAS ⇒ DataBox ⇒ Azure ファイル共有
オンプレミスでファイルをキャッシュしない: 最終目標はクラウドで Azure ファイル共有を直接使用することであるため、Azure File Sync を使用する予定はありません。

自分のシナリオが異なる場合は、移行ガイドの表を参照してください。

この記事では、NAS アプライアンスから機能している Azure ファイル共有に移行するために必要な計画、デプロイ、およびネットワークの構成について詳しく説明します。このガイドでは、一括データ転送 (オフラインデータ転送) に Azure DataBox を使用します。

適用対象

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

移行の目標

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

移行の概要

移行プロセスは、いくつかのフェーズで構成されます。 Azure ストレージアカウントとファイル共有をデプロイし、ネットワークを構成する必要があります。次に、Azure DataBox と RoboCopy を使用してファイルを移行し、変更内容でキャッチアップします。最後に、新しく作成された Azure ファイル共有にユーザーとアプリをカットオーバーします。以下のセクションでは、移行プロセスの各フェーズについて詳しく説明します。

ヒント

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

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

この手順では、必要な Azure ファイル共有の数を決定します。現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。クラウドに移行するファイル共有の数に応じて、1 対 1 のマッピングと共有のグループ化のどちらを使用するかを選択できます。

1 対 1 のマッピングを使用する

共有の数が少ない場合は、1 対 1 のマッピングをお勧めします。このシナリオを理解する最も簡単な方法は、1:1 で Azure ファイル共有にマップするオンプレミスの共有を想像することです。

ファイル共有の数が多い場合は、共有のグループ化を検討してください。たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。そうすることで、このオンプレミスの共有グループに必要なのは、クラウド内の 1 つの Azure ファイル共有のみとなります。

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

このフェーズでは、Azure ストレージアカウントとその中のファイル共有をプロビジョニングします。

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

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

Note

1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージアカウント数は 250 に制限されています。クォータの引き上げにより、リージョンごとに最大 500 個のストレージアカウントを作成できます。詳細については、「Azure Storage アカウントのクォータを増やす」を参照してください。

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

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

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

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

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

フェーズ 3: 必要な Azure DataBox アプライアンスの数を決定する

前のフェーズを完了したときにのみ、この手順を開始してください。この時点で、Azure ストレージリソース (ストレージアカウントとファイル共有) が作成されているはずです。 DataBox を注文するときに、DataBox でのデータの移動先となるストレージアカウントを指定する必要があります。

このフェーズでは、前のフェーズからの移行プランの結果を、使用可能な DataBox オプションの制限にマッピングする必要があります。これらの考慮事項は、選択する必要がある DataBox オプションと、それらのうちいくつが NAS 共有を Azure ファイル共有に移動するために必要になるかについて計画を立てるのに役立ちます。

必要なデバイスの種類と数を決定する際、次の重要な制限事項を考慮してください。

すべての Azure DataBox は、最大 10 個のストレージアカウントにデータを移動できます。
DataBox の各オプションには、それら独自の使用可能な容量があります。「DataBox のオプション」を参照してください。

作成することを決定したストレージアカウントの数とそれぞれの共有については、移行プランを参照してください。次に、NAS 上でそれぞれの共有のサイズを確認します。この情報を組み合わせることで、どのアプライアンスからどのストレージアカウントにデータを送信するかを最適化し、決定することができます。 2 つの DataBox デバイスから、ファイルを同じストレージアカウントに移動することはできますが、1 つのファイル共有のコンテンツを 2 つの DataBox に分割しないでください。

DataBox のオプション

標準的な移行の場合、次に示す 2 種類の DataBox のオプションから、いずれか、または組み合わせて選択する必要があります。

DataBox: これが最も一般的なオプションです。 NAS と同様に機能する、耐久性のある DataBox アプライアンスがお客様に発送されます。使用可能な容量は 80 TiB です。詳細については、DataBox のドキュメントをご覧ください。
DataBox Heavy: このオプションは、NAS と同様に機能する、耐久性のある車輪付きの DataBox アプライアンスで、容量は 1 PiB です。暗号化とファイルシステムのオーバーヘッドにより、使用可能な容量は約 20% 少なくなります。詳細については、DataBox Heavy のドキュメントを参照してください。

警告

Data Box Disk は、Azure ファイル共有への移行にはお勧めできません。 Data Box Disk では、アクセス許可 (ACL) やその他の属性といったファイルメタデータは保持されません。

フェーズ 4: 一時的な Windows Server をプロビジョニングする

Azure DataBox が到着するのを待っている間に、RoboCopy ジョブを実行するために必要な 1 つ以上の Windows Server を既にデプロイすることができます。

これらのサーバーの 1 回目の使用では、ファイルを DataBox にコピーします。
これらのサーバーの 2 回目の使用では、DataBox が輸送中に NAS アプライアンスで発生した変更をキャッチアップします。この方法では、ソース側のダウンタイムが最小限に抑えられます。

RoboCopy ジョブが動作する速度は主に次の要因に依存します。

ソースストレージとターゲットストレージの IOPS
それらの間で使用可能なネットワーク帯域幅
詳細については、「トラブルシューティング」セクションの「IOPS と帯域幅に関する考慮事項」をご覧ください
名前空間内のファイルとフォルダーをすばやく処理する機能
詳細については、「トラブルシューティング」セクションの「処理速度」を参照してください
RoboCopy 実行間の変更数
詳細については、「トラブルシューティング」セクションの「不要な作業を回避する」をご覧ください

一時的な Windows Server に提供する RAM とスレッド数を決定する際には、参照される詳細を念頭に置くことが重要です。

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

時間を節約するには、DataBox が到着するのを待っている間、このフェーズを続行してください。このフェーズの情報を使用すると、Azure のサーバーとユーザーが Azure ファイル共有を利用できるようにする方法を決めることができます。最も重要な決定事項は次のとおりです。

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

このビデオは、簡単な 5 つのステップでインフォメーションワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。
このビデオでは、次のトピックに関する専用のドキュメントが参照されています。 Azure Active Directory は Microsoft Entra ID になりましたので注意してください。詳細については、「Azure AD の新しい名前」を参照してください。

フェーズ 6: ファイルを DataBox にコピーする

DataBox が到着したら、NAS アプライアンスにスムーズにネットワーク接続できるように DataBox を設定する必要があります。注文した種類の DataBox のセットアップドキュメントに従ってください。

DataBox の種類によっては、DataBox コピーツールが使用できる場合もあります。現時点では、これらはファイルを完全な忠実性で DataBox にコピーするものではないため、Azure ファイル共有への移行には推奨されません。代わりに RoboCopy を使用してください。

DataBox が届くと、注文時に指定したストレージアカウントごとに事前プロビジョニングされた SMB 共有が利用できます。

ファイルが Premium の Azure ファイル共有に配置される場合は、Premium の "ファイルストレージ" のストレージアカウントごとに 1 つの SMB 共有が存在します。
ファイルが Standard ストレージアカウントに配置される場合、Standard の (GPv1 および GPv2) ストレージアカウントごとに 3 つの SMB 共有が存在します。 _AzFiles で終わるファイル共有のみが、移行に関連します。すべてのブロックおよびページの BLOB 共有を無視します。

Azure DataBox のドキュメントの手順に従ってください。

リンクされた DataBox ドキュメントには、RoboCopy コマンドが指定されています。ただし、このコマンドは、ファイルとフォルダーの完全な忠実性を維持するのに適していません。代わりに次のコマンドを使用します。

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>

個々の RoboCopy フラグの詳細については、後の RoboCopy セクションの表をご覧ください。
スレッド数 /MT:n を適切にサイズ変更する方法、RoboCopy 速度を最適化する方法、および RoboCopy をデータセンターの良好な近傍にする方法の詳細については、RoboCopy のトラブルシューティングセクションをご覧ください。

ヒント

Robocopy の代替として、Data Box にデータコピーサービスが作成されました。このサービスを使用すると、Data Box にファイルを完全に忠実に読み込むことができます。このデータコピーサービスのチュートリアルに従って、正しい Azure ファイル共有ターゲットを設定してください。

フェーズ 7: NAS からのキャッチアップ RoboCopy を実行する

すべてのファイルとフォルダーが計画された Azure ファイル共有に配置されたことを DataBox が報告したら、このフェーズに進むことができます。キャッチアップ RoboCopy は、DataBox のコピーが開始されてから、NAS 上のデータが変更されている可能性がある場合にのみ必要です。アーカイブの目的で共有を使用する特定のシナリオでは、移行が完了するまで、NAS での共有の変更を停止することができます。移行中に NAS 共有を読み取り専用に設定することによって、ビジネス要件に対応することもできます。

移行中に共有を読み取り/書き込み可能にする必要があり、小規模なダウンタイム期間で行う必要がある場合、このキャッチアップ RoboCopy の手順は、ユーザーが Azure ファイル共有に直接フェールオーバーする前に完了することが重要です。

この手順では、共有を DataBox.にフォークした時点よりも後に NAS の最新の変更内容を使用してクラウド共有をキャッチアップするために、RoboCopy ジョブを実行します。このキャッチアップ RoboCopy は、NAS 共有で発生したチャーンの量によって、短時間で終了したり、しばらく時間がかかったりすることがあります。

Windows Server ターゲットフォルダーへの最初のローカルコピーを実行します。

NAS アプライアンス上で最初の場所を特定します。
一致する Azure ファイル共有を特定します。
Azure ファイル共有を一時的な Windows Server のローカルネットワークドライブとしてマウントする
次のように、RoboCopy を使用してコピーを開始します。

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

重要

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

準備ができたら、「Windows で Azure ファイル共有を使用する」のハウツー記事を確認し、NAS のキャッチアップ RoboCopy を開始する Azure ファイル共有をマウントします。

RoboCopy

次の RoboCopy コマンドを実行すると、NAS ストレージから 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>

Switch	説明
`/MT:n`	Robocopy をマルチスレッドを実行できるようにします。 `n` の既定値は 8 です。スレッドの最大数は 128 です。スレッド数が多いと使用可能な帯域幅を飽和させるのに役立ちますが、スレッド数が多ければ必ず移行が速くなるというわけではありません。 Azure Files を使ったテストでは、8 から 20 の間で、最初のコピー実行のパフォーマンスのバランスが取れていることが示されています。後続 `/MIR` の実行は、使用可能なコンピューティングと使用可能なネットワーク帯域幅の影響を徐々に受けます。後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数とより厳密に一致させます。実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。 Azure Files を使ったテストでは、最大 64 スレッドで良好なパフォーマンスが得られますが、プロセッサがそれらを同時に維持できる場合のみです。
`/R:n`	最初の試行でコピーに失敗したファイルの最大再試行回数です。 Robocopy では、実行中にファイルが完全にコピーに失敗するまで `n` 回試行します。実行のパフォーマンスを最適化することができます。過去にタイムアウトの問題で失敗したと思われる場合は、2 または 3 の値を選んでください。これは、WAN リンク上でより一般的である可能性があります。ファイルが使用中であったためにコピーに失敗したと思われる場合は、[再試行しない] または 1 の値を選びます。数秒後に再試行しても、ファイルの使用中の状態が変更されるのに十分な時間がない場合があります。ファイルを開いているユーザーまたはアプリには、さらに時間がかかることがあります。このような場合、ファイルがコピーされていないことを受け入れ、その後に予定されている Robocopy の実行のいずれかで試行すれば、最終的にファイルを正常にコピーするのに成功する可能性があります。これにより、再試行のタイムアウトを過ぎてもファイルが開いているために、最終的にコピー失敗の大部分を占めることになる多数の再試行で長引かせることなく、現在の実行をより短時間で完了することができます。
`/W:n`	前の試行時に正常にコピーされなかったファイルのコピーを試行する前に、RoboCopy が待機する時間を指定します。 `n` は再試行の間の待機時間 (秒数) です。 `/W:n` は、多くの場合、`/R:n` と共に使用されます。
`/B`	バックアップアプリケーションが使用するのと同じモードで Robocopy を実行します。このスイッチを使用すると、現在のユーザーがアクセス許可を持っていないファイルを、Robocopy によって移動できます。バックアップのスイッチは、管理者特権のコンソールまたは PowerShell ウィンドウで Robocopy コマンドを実行する場合によって異なります。 Azure Files に Robocopy を使用する場合は、ストレージアカウントのアクセスキーとドメイン ID のどちらを使用して Azure ファイル共有をマウントするかを確認します。そうしないと、エラーメッセージが直感的でなくなり、問題解決につながらないことがあります。
`/MIR`	(ソースをターゲットにミラーリング。) RoboCopy でソースとターゲット間の差分のみをコピーします。空のサブディレクトリがコピーされます。変更された、またはターゲットに存在しない項目 (ファイルまたはフォルダー) がコピーされます。ターゲットに存在する一方でソースには存在しない項目は、ターゲットから消去 (削除) されます。このスイッチを使用する場合は、ソースとターゲットのフォルダー構造を正確に一致させます。 "一致" とは、正しいソースおよびフォルダーレベルから、コピー先の一致するフォルダーレベルにコピーすることを意味します。その場合にのみ、"キャッチアップ" コピーを正常に実行することができます。ソースとターゲットが一致しない場合に `/MIR` を使用すると、大規模な削除と再コピーが行われます。
`/IT`	特定のミラーシナリオで、忠実性が維持されることを保証します。たとえば、Robocopy を 2 回実行する間に、ファイルで ACL の変更と属性の更新があった場合、非表示とマークされます。 `/IT` を使用しない場合、ACL の変更が Robocopy で見逃されて、ターゲットの場所に転送されない可能性があります。
`/COPY:[copyflags]`	ファイルコピーの忠実性。既定値:`/COPY:DAT`。コピーフラグ: `D` = データ、`A` = 属性 `T` = タイムスタンプ、`S` = セキュリティ = NTFS ACL `O` = 所有者情報、`U`= `D`監査情報。監査情報を Azure ファイル共有に格納することはできません。
`/DCOPY:[copyflags]`	ディレクトリのコピーの忠実性。既定値:`/DCOPY:DA`。コピーフラグ: `D` = データ `A` = 属性、`T` = タイムスタンプ。
`/NP`	各ファイルとフォルダーのコピーの進行状況を表示しないよう指定します。進行状況を表示すると、コピーのパフォーマンスが大幅に低下します。
`/NFL`	ファイル名をログに記録しないことを指定します。コピーのパフォーマンスを向上させます。
`/NDL`	ディレクトリ名をログに記録しないことを指定します。コピーのパフォーマンスを向上させます。
`/XD`	除外するディレクトリを指定します。ボリュームのルートで Robocopy を実行する場合、隠しフォルダー `System Volume Information` を除外することを検討してください。設計どおりに使用した場合、そこにあるすべての情報は、この正確なシステム上の正確なボリュームに固有であり、オンデマンドで再構築することができます。この情報をコピーしても、クラウドや、データを別の Windows ボリュームにコピーバックするときには役に立ちません。この内容を放置しておくことは、データ損失と見なさないようにする必要があります。
`/UNILOG:<file name>`	状態を Unicode 形式でログファイルに書き込みます。 (既存のログを上書きします)。
`/L`	テスト実行の場合のみファイルは一覧表示されるだけです。コピーも削除もされず、タイムスタンプも付きません。コンソール出力には `/TEE` とよく使用されます。テスト結果を適切に文書化するには、サンプルスクリプトのフラグ (`/NP`、`/NFL`、`/NDL` など) の削除が必要になる場合があります。
`/Z`	慎重に使用する再起動モードでファイルをコピーします。このスイッチは、ネットワーク環境が不安定な場合にのみ、使用することをお勧めします。追加のログ記録が原因で、コピーのパフォーマンスが大幅に低下します。
`/ZB`	慎重に使用する再起動モードを使用します。アクセスが拒否された場合、このオプションではバックアップモードが使用されます。このオプションでは、チェックポイント処理が原因で、コピーのパフォーマンスが大幅に低下します。

重要

Windows Server 2022 の使用をお勧めします。 Windows Server 2019 を使う場合、最新のパッチレベルまたは少なくとも OS 更新プログラム KB5005103 がインストールされていることを確認してください。特定の RoboCopy シナリオに対する重要な修正プログラムが含まれています。

ヒント

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

ユーザーのカットオーバー

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

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

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

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

ダウンタイムを許容できる場合は、NAS ベースの共有へのユーザーアクセスを削除する必要があります。これは、ユーザーがファイルとフォルダー構造およびコンテンツを変更できないようにするいずれの手順でも行えます。たとえば、自分の DFS 名前空間を存在しない場所に指定したり、共有のルート ACL を変更します。

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

Windows Server フォルダーに共有を作成し、必要に応じて、その共有を指すように DFS-N のデプロイを調整します。 NAS SMB 共有と同じ共有レベルのアクセス許可を設定してください。エンタープライズクラスのドメイン参加 NAS を使用していた場合、ユーザーの SID は Active Directory に存在するユーザーと自動的に一致し、RoboCopy によってファイルとメタデータが完全に忠実にコピーされます。 NAS でローカルユーザーを使用していた場合は、これらのユーザーを Windows Server のローカルユーザーとして作成し直し、RoboCopy によって Windows Server に移動された既存の SID を、新しい Windows Server ローカルユーザーの SID にマップする必要があります。

これで、共通のルートまたはボリュームへの共有または共有のグループの移行は完了しました。

これらの複数のコピーを並行して実行することができます。一度に 1 つの Azure ファイル共有のスコープを処理することをお勧めします。

トラブルシューティング

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

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

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

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

注意事項

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

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

ご使用の環境において移行を実行する最適なタイミングを考慮します (日中、時間外、または週末)。
また、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 の実行は、アイテムを処理することによって徐々に影響を受けます。差分実行の変更が少ないほど、ネットワーク経由でのデータ転送が減少します。ネットワークリンク上で移動する機能よりも、名前空間項目を処理する機能によって速度が向上するようになりました。後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数と一致させます。実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。

ヒント

経験則: 最初の 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 ファイル共有のドキュメントにリンクしています。