FSx のデータを DataSync でAmazon S3 に移行する その２：NFS3.x とNFS4.xの比較
前回こちらの記事でAmazon FSx for NetApp ONTAP のデータを AWS DataSync でAmazon S3 に移行する検証環境を構築しました。
今日はその環境を使ってパフォーマンスなどを見ていきます。実はDataSyncはターゲットをNFSとみなした場合とFSxとみなした場合では若干動作が異なる部分があります。具体的には利用できるNFSプロトコルのバージョンが異なります。
NFS 3.x と 4.x と DataSync
ターゲットがFSxの場合選択可能なプロトコルはNFS3のみです。一方ターゲットがNFSの場合、FSX4.1,4.0,3.xを選択可能です。
3と4の違いは以下の通りです。
特にステート管理に違いがあります。当然ステートレスで動作するNFS3の方が早いことが予想されます。
NFS3の場合、もちろんファイルコピー時に基本的なファイルの整合性は確保されるが、厳密な保証はないようです。NFS4ではより強い整合性管理がプロトコルレベルで備わっています。
一方DataSyncではファイルコピーあと、整合性管理オプションが備わっています。
これらを組み合わせた場合、ファイル整合性を維持しつつ一番パフォーマンスが高速になる組み合わせを探るのが今回の検証の目的です。
さっそくやってみる
1. NFSロケーションの登録
前回の記事では以下の通り2つのロケーションが設定されています。
新しくFSxではなくNFSと明示的に指定してロケーションをもう一つ作成します。その他設定はFSxのときと同じです。
FSxとはストレージにアクセスするプロトコルが異なるため以下の通りDataSyncAgent用EC2インスタンスのアウトバウンドセキュリティグループを以下にしておきます。
2049を新しく追記しています。
NFSバージョンは明示的に4を指定します。
前回作成したFSx用ロケーションは以下の通り3になっています。
2. テスト用ファイル作成
できれば1万個ぐらいファイルが欲しいところです。以下のスクリプトでファイルを1万個増やします。
#!/bin/bash
# コピー元のファイル
src_file="/fsx/test.txt"
# コピー先のディレクトリ
dest_dir="/fsx"
# 最大コピー数
max_copies=10000
# ループでファイルをコピー
for i in $(seq -w 1 $max_copies); do
sudo cp "$src_file" "$dest_dir/test_$i.txt"
done
echo "$max_copies 個のファイルを作成しました。"
3. シナリオテスト
検証用DataSync Agentは私の個人アカウントなのでt2.microを使っています。大きいインスタンスサイズであれば早くなるとは思いますのでその手は注意してください
つまり以下の比較は単純にプロトコル差異による比較のみで利用可能であり、実際のサイジングには使わないようにしてください
3.1 AWS CLI S3 CPコマンド
まずは一番早いと予測されるAWS CLIで時間を計測します。
DataSyncは差分移行や、帯域制御、除外条件指定による一部ファイルのみの移行など様々な機能があるため便利ですが、単純な全件移行であればAWS CLIが一番早いと予測します。
START_TIME=$(date +%s)
aws s3 cp /fsx s3://datasynctestkameoncloud/ --recursive
END_TIME=$(date +%s)
ELAPSED_TIME=$((END_TIME - START_TIME))
echo "処理時間: ${ELAPSED_TIME}秒"
66秒でした！
3.2 DataSync FSx (NFS3 + 検証なし）
え、うそ！！！はやっ！14秒でした。
なおDataSyncのタスクは作成時にENIが生成されます。さらに実行タイミングでなにがしかの初期化が走るようでその時間などは別途オーバーヘッドとして発生しますが、大量のファイル移行の場合は問題にはならないと思いますのでその時間は除いています。
3.3 DataSync FSx (NFS3 + 転送されたデータのみを検証）
転送されたデータのみを検証はDataSyncとして推奨されているオプションです。
なぜ時間が短くなるのかわかりませんが13秒でした。おそらく計測の誤差レベルでしょう。
3.4 DataSync FSx (NFS3 + すべてのデータ検証）
これはコピー後FSxとS3のそれぞれのハッシュ値を比較するモードでオーバーヘッドが一番大きくなると予想されますが・・・なんと！そうはならんだろという早さでした。
なおすべてのデータ検証はコピーが終わったあとファイルの数分だけS3へGetが走りますので注意が必要です。（このパフォーマンス的にそれが行われているかは不明ですが）
DataSyncAgentとFSxのデータ移行タスクの関係
色々調べていたらあることに気づきました。
ロケーションをNFSではなくFSxとして登録した場合、DataSyncAgentは介在していないようです。AgentがそもそもFSxをロケーションとして認識していなくてもデータ移行が完了しています。
前回の記事の追記でFSx for NetApp ONTAPはDataSyncAgentなしでもS3へ移行できると記載しましたが、それが当たり前の動作のようです
3.5 DataSync NFS (NFS4 + 検証なし）
残念ながらエラーとなってしまいました。
DataSyncAgentのメモリが小さすぎるようです。
DataSyncAgentのインスタンスをt2.midiumにして再起動して再度タスクを実行します。
13秒で完了しました。
(エラーは./vsadminという管理専用ファイルがNetApp側で作成されていないことによるエラーで無視してよいものですのでそのままにしておきます）
3.6 DataSync NFS (NFS4 + 転送されたデータのみを検証)
27秒でした！
3.7 DataSync NFS (NFS4 + すべてのデータを検証)
33秒でした！
3.8 DataSync NFS (NFS3 + 検証なし)
27秒でした！
3.9 DataSync NFS (NFS3 + 転送されたデータのみを検証)
27秒でした！
3.10 DataSync NFS (NFS3 + すべてのデータを検証)
31秒でした
まとめ
今回の検証目的とは別ですがFSx→S3の場合、DataSyncAgentを使わずに謎の高速性を発揮していました。ファイルの検証がどこ行われているかは不明です。行われてはいるのでしょうが、その時間がタスクに計上されていないようには見えます。
NFS3 vs NFS4ですが、検証なしのNFS4を除けば、気にしていたのほどの差異は発生しませんでした。
移行後ファイルの整合性検証をNFSレベルで行うのであれば、DataSyncはNFS4の検証なしオプションでタスクを実行させるのが一番早そうです。とはいえDataSyncAgent→S3側の検証は欲しいので、検証なしオプションはやっぱり厳しいかな、という感触ではあります。ステートレスプロトコルであるNFS3の検証なしモードが一番早くなると予想していたのでそれが意外でした。やってみてわかることってやっぱりありますね笑
Discussion