Azure の NFS ファイル共有に移行する
この記事では、Linux ファイル サーバーから Azure の NFS ファイル共有への移行の基本的な輪郭について説明します。これは Premium ファイル共有 (FileStorage アカウントの種類) としてのみ利用できます。 また、オープン ソースのファイル コピー ツールである fpsync と rsync の比較を通して、Azure ファイル共有にデータをコピーするときの、これらのツールの性能を把握します。
Note
Azure Files は NFS のアクセス制御リスト (ACL) をサポートしていません。
適用対象
| ファイル共有の種類 | SMB | NFS |
|---|---|---|
| Standard ファイル共有 (GPv2)、LRS/ZRS |  |
|
| Standard ファイル共有 (GPv2)、GRS/GZRS | |
|
| Premium ファイル共有 (FileStorage)、LRS/ZRS | |
 |
前提条件
Linux 仮想マシン (VM) にマウントされている Azure の NFS ファイル共有が少なくとも 1 つ必要です。 これを作成するには、「Azure の NFS ファイル共有を作成し、Linux VM にマウントする」を参照してください。 複数の TCP 接続を使用するには、nconnect を使用して共有をマウントすることをお勧めします。 詳細については、「NFS Azure ファイル共有のパフォーマンスを向上させる」を参照してください。
移行ツール
NFS ファイル共有へのデータ転送には、使用できる多くのオープン ソース ツールがあります。 ただし、オンプレミスのセットアップと比較して、パフォーマンス上の明確な考慮事項のある分散ファイル システムを処理する場合、それらすべてが効率的とはいえません。 分散ファイル システムでは、各ネットワーク呼び出しに、サーバー (ローカルとは限らない) へのラウンド トリップを伴います。 そのため、ネットワーク呼び出しに費やされる時間の最適化は、ネットワークを介した最適なパフォーマンスと効率的なデータ転送を実現するために極めて重要となります。
fpsync と rsync の使用の比較
rsync はシングル スレッドではあるものの、汎用性の高いオープン ソースのファイル コピー ツールです。 任意のリモート シェルを介して、またはリモートの rsync デーモンとのやり取りで、別のホストとの間のコピーをローカルで行えます。 幅広い選択肢を備え、コピーするファイルのセットを柔軟に指定できます。 一方で、fpsync はマルチスレッド アプリケーションであるため、rsync ジョブを並列で実行できる点を含め、いくつかの優位性があります。
この記事では、fpsync を使用して、Linux ファイル サーバーから Azure の NFS ファイル共有にデータを移行します。
データのコピーに、fpsync では rsync (デフォルト)、cpio、tar の各ツールを使用します。 ソース ディレクトリ src_dir/ のサブセットを計算し、同期ジョブを生成して、それを同期先ディレクトリ dst_dir/ に同期します。 ファイル システムを同時にクロールしながら、同期ジョブをオンザフライで実行することで、大規模なファイル システムの効率的な移行や、複数のファイルを含む大規模なデータセットのコピーを実行するのに便利なツールとなっています。
Note
Fpsync は、ソース ディレクトリ自体ではなく、ディレクトリの中身のみを同期します。 rsync とは異なり、fpsync はソース ディレクトリに末尾のスラッシュ (/) を強制適用します。つまり、同期後にターゲット ディレクトリ内にソース ディレクトリの名前を持つサブディレクトリは取得されていません。
fpart をインストールする
fpsync を使用するには、fpart ファイルシステム パーティショナーをインストールする必要があります。 お使いの Linux ディストリビューションに fpart をインストールします。 インストールが完了すると、 /usr/bin/ の下に fpsync が表示されます。
同期元から同期先へデータをコピーする
同期先 (ターゲット) である Azure のファイル共有が Linux VM にマウントされていることを確認します。 「前提条件」を参照してください。
完全な移行を行う場合は、次の 3 つのフェーズでデータをコピーします。
- ベースライン コピー: 同期先にデータが存在しない場合に、同期元から同期先へのコピーを行います。 ベースライン コピーの場合は、コピー ツールとして fpsync を cpio とともに使用することをお勧めします。
- 増分コピー: 同期元から同期先へ、変更のあった増分のみをコピーします。 増分同期の場合は、コピー ツールとして fpsync を rsync とともに使用することをお勧めします。 この作業は、すべての変更をキャプチャするために、複数回行う必要があります。
- ファイナル パス: 同期元に存在しない同期先のファイルをすべて削除するには、ファイナル パスが必要です。
fpsync を使用してデータをコピーするには、次のように、常にここで挙げたコマンドの何らかのバージョンが必要となります。
fpsync -m <specify copy tool - rsync/cpio/tar> -n <parallel transfers> <absolute source path> <absolute destination path>
ベースライン コピー
ベースライン コピーの場合は、fpsync を cpio とともに使用します。
fpsync -m cpio -n <parallel transfers> <absolute source path> <absolute destination path>
詳細については、「Cpio および Tar のサポート」をご覧ください。
増分コピー
増分同期の場合は、fpsync をデフォルトのコピー ツール (rsync) とともに使用します。 すべての変更をキャプチャするために、この作業を複数回実行することをお勧めします。
fpsync -n <parallel transfers> <absolute source path> <absolute destination path>
既定では、fpsync は次の rsync オプション : -lptgoD -v --numeric-ids を指定します。 fpsync コマンドに -o option を追加して、追加の rsync オプションを指定することができます。
ファイナル パス
増分同期を複数回実行した後、ファイナル パスを実行して、同期元に存在しない同期先のファイルをすべて削除する必要があります。 この作業は手動で実行する (rsync --delete を使用して /data/dst/ ディレクトリから余分なファイルを削除する) か、fpsync の -E オプションを使用して行うことができます。 詳細については、「ファイナル パス」をご覧ください。
さまざまなデータセットを用いた rsync と fpsync の比較
このセクションではさまざまなデータセットを用いて、rsync と fpsync のパフォーマンスを比較します。
データセットと構成
次の表は、異なるワークロードの元でのコピー ツールのパフォーマンスを比較するために使用したさまざまなデータセットのリストです。
| 構成番号 | コピーの種類 | ファイル数 | ディレクトリ数 | ファイル サイズ | 合計サイズ |
|---|---|---|---|---|---|
| 1.1 | ベースライン コピー | 100 万 | 1 | 0-32 KiB | 18 GiB |
| 1.2 | 増分 (差分変更) | 100 万 | 1 | 0-32 KiB | 18 GiB |
| 2 | ベースライン コピー | 191,345 | 3,906 | 0-32 KiB | 3 GiB |
| 3 | ベースライン コピー | 5,000 | 1 | 10 MiB | 50 GiB |
テストは、8 vCPU、32 GiB のメモリ、および大規模データセット用の 1 TiB を超えるディスク領域を持つ Azure Standard_D8s_v3 VM で実行されました。 ターゲットには、1 TiB を超えるプロビジョニング サイズの Azure NFS ファイル共有を構成しました。
実験と結果: rsync と fpsync の比較
上記構成の実験に基づいて、nconnect=8 を使用してマウントされた Azure NFS ファイル共有に対して、rsync を用いた 64 のスレッドと、 cpio を用いた 16 のスレッドで使用した場合の fpsync のパフォーマンスが最も良いという結果を得ました。 実際の結果は、ご使用の構成やデータセットによって異なります。
Note
Azure Files のスループットは、次のグラフで示されている値よりもはるかに高くなる可能性があります。 一部の実験は、単純化するために、意図的に小さなデータセットを使用して行われました。
Configuration 1
小さなファイルが 100 万個 (合計サイズは 18 GiB) 納められている 1 つのディレクトリに対して、ベースライン コピーと増分コピーの両方でこのテストを実行しました。
同期元から同期先へのベースライン コピーを実行した場合では、次の結果を得られました。
増分コピー (差分変更) を実行した場合では、次の結果を得られました。
Configuration 2
3,906 個のディレクトリに納められた 191,345 個の小さなファイル (合計サイズは 3 GiB) のベースライン コピーを実行した場合では、次の結果を得られました。
構成 3
1 つのディレクトリに納められた 5,000 個の大きな (10 MiB の) ファイル (合計サイズは 50 GiB) のベースライン コピーを実行した場合では、次の結果を得られました。
変更の概要
fpsync のようなマルチスレッド アプリケーションを使用すると、rsync などのシングルスレッド コピー ツールを使用した場合よりも、Azure の NFS ファイル共有に移行するときのスループットと IOPS を向上させることができます。 今回のテストで、次のことが明らかになりました。
- ディレクトリにデータを分散することは、移行プロセスの並列処理に役立ち、パフォーマンスの向上につながります。
- サイズが大きいファイルからデータをコピーする方が、サイズが小さいファイルからデータをコピーするよりもパフォーマンスが向上します。
結果を次の表にまとめています。
| 構成番号 | ファイル数 | ディレクトリ数 | ファイル サイズ | 合計サイズ | rsync 所要時間 | rsync スループット | fpsync 所要時間 | fpsync スループット | スループットの増加 |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 (ベースライン) | 100 万 | 1 | 0-32 KiB | 18 GiB | 837.06 分 | 0.33 MiB/s | 228.16 分 | 1.20 MiB/s | 267% |
| 1.2 (増分) | 100 万 | 1 | 0-32 KiB | 18 GiB | 84.02 分 | 3.25 MiB/s | 7.5 分 | 36.41 MiB/s | 1,020% |
| 2 (ベースライン) | 191,345 | 3,906 | 0-32 KiB | 3 GiB | 191.86 分 | 0.27 MiB/s | 8.47 分 | 6.04 MiB/s | 2,164% |
| 3 (ベースライン) | 5,000 | 1 | 10 MiB | 50 GiB | 8.12 分 | 105.04 MiB/s | 2.76 分 | 308.90 MiB/s | 94% |
サードパーティの情報に関する免責事項
この記事で取り上げたオープン ソースのツールは、よく知られているサード パーティのソリューションです。 これらのツールは、直接的にも間接的にも、Microsoft が開発、所有、サポートしているものではありません。 ソフトウェア ライセンスおよびサード パーティのドキュメントに規定されているサポート ステートメントを確認することは、お客様の責任となります。