はじめてのAWS Snowcone – (6) NFSサーバーのセットアップ

2021.12.25

しばたです。

本記事ではSnowconeデバイスでNFSサーバーを有効にして利用するまでの手順を解説します。

目次

免責事項

本シリーズは実際にSnowconeを試すことで理解を深めることを目的としています。
このため執筆時点ではAWS Snowconeの仕組みや仕様について誤解している部分がある可能性があります。

記事の内容に誤りがあった場合は随時修正していく予定ですが、記事の内容が100%正しいことを保証できない点はご了承ください。

NFSサーバーの有効化

SnowconeのNFSサーバーは「Amazon S3 へのインポート」ジョブの場合のみ使用可能です。

本記事ではAWS OpsHubを使いNFSサーバーを有効にする方法を説明します。
AWS OpsHubのインストールとデバイスの初期設定については以下の記事を参考にしてください。

以降の作業はAWS OpsHubにサインインした状態からはじめます。

1. NFSサーバーの有効化 (クイックセットアップ)

AWS OpsHubにサインインし対象デバイスの詳細画面を開きます。
画面にある「NFSを使用してデータを転送」の「有効化と開始」ボタンをクリックします。

これだけで直ちに有効化の処理が開始されます。

有効化の最中はデバイスの電源を落とさない様にしてください。

私の環境(Windows 10)だとインストール作業中に以下の様なエラーメッセージが出てしまいました。

どうやらAWS OpsHubは裏でNFSクライアント(mountコマンド)を使用する様です。このためWindows環境では事前にNFSクライアントをインストールしておくと良いでしょう。

(Windows 10でNFSクライアントを追加する場合は機能を有効にする。詳細は割愛)

NFSクライアントをインストールした後で改めてAWS OpsHubに接続しなおすとこの様な感じの画面となります。

NFSサーバーのIPアドレスが192.168.9.152と仮想NICが割り当てられていることがわかります。
(DHCPが使える環境だと自動でDHCPを有効にする模様)

2. NFSサーバーの設定

NFSサーバー状態欄にある「手動で設定する」をクリックすると詳細設定画面に遷移します。

NFSサーバーのエンドポイントは

  • /buckets : ストレージ全体のルート
  • /buckets/[S3バケット名] : 指定S3バケットのルート (この配下の内容がS3にロードされる)

の2つ存在します。
基本的には/buckets/[S3バケット名]の方を使うことになります。

また、NFSサーバーに接続可能なホストについてはOpsHubのあるクライアントからの接続を許可する設定を自動で用意してくれる様です。
(192.168.10.78がOpsHubのあるクライアント。172.25.208.1は正体不明。Snowcone内部のネットワークっぽい?)

【補足】手動セットアップをしたい場合

より詳細な初期セットアップをしたい場合はこの詳細画面から一度NFSサーバーを無効にしたうえで改めて「有効化と開始」をする必要があります。

(クイックセットアップしてる場合は一旦NFSを無効にする)

すると下図の様により詳細な初期設定画面が表示されますので環境に合わせてよしなに設定してください。

今回はNFSサーバーをこんな感じに設定しました。

NFSファイルストレージの利用

AWS OpsHubからNFSサーバーのエンドポイントをマウントして利用することが可能です。

上図の場合だとZ:ドライブにアクセスすることでNFSサーバーを使えます。

ちゃんと8TBで認識されています。

OpsHub以外の環境からはmountコマンドを使ってマウントしてください。

Windows環境であれば「NFSクライアント」のオプション機能を有効にしてmount.exeを使える様にしたうえで以下の様にマウント可能です。

# rsize, wsize は環境に応じてよしなに変更してください
mount.exe -o nolock rsize=128 wsize=128 mtype=hard <NFSサーバー名/IPアドレス>:<NFSエンドポイント> <マウントポイント>

実行例)

# Zドライブにマウントする実行例
C:\> mount.exe -o nolock rsize=128 wsize=128 mtype=hard 192.168.9.155:/buckets/shibata-snowcone-test-2021 Z:\
Z: は 192.168.9.155:/buckets/shibata-snowcone-test-2021 に正常に接続しました

コマンドは正常に終了しました。

アンマウントする際はumountコマンドを使います。

# 全マウントポイントをアンマウントする場合
umount.exe -a

あとは環境に合わせてよしなにNFSサーバーをご利用ください。

補足 : AWS Snowcone NFSサーバーの性能指標

FAQにも記載されていますが、SnowconeのNFSサーバーへのファイル転送はファイルサイズが大きいものほど高パフォーマンスになります。

Snowcone は、大きなファイルが転送されるときに最高のパフォーマンスを発揮します。Snowcone は、サイズが 5 MB 以下の多数の小さなファイルの転送のために最適化されていません。
この制限は、メタデータと暗号化の処理に伴うオーバーヘッドが原因です。5 MB 未満の多数のファイルをコピーする場合は、Snowcone デバイスにコピーする前に、tar、zip、または同様のユーティリティを使用して小さなファイルをまとめることが推奨されます。
Snowcone は、書き込みワークロード (Snowcone へのデータのコピー) または読み取りワークロード (Snowcone からのデータのコピー) のために使用される場合に最高のパフォーマンスを発揮し、両方に使用される場合には最高のパフォーマンスは発揮できません。読み取りと書き込みが混在しているシナリオでは、パフォーマンスを保証できません。

より具体的な性能指標はユーザーガイドに記載されています。

小さいファイルが大量にある環境では予めZip等で圧縮してまとめることを強く推奨します。

実例1 : 最悪のファイルコピー

性能評価ではなく仕様確認のために「SnowconeのNFSサーバー上の1つのディレクトリに最大何ファイル保存可能か」を試したのですが、上記を証明する非常に面白い結果になったので共有します。

「とりあえず10万ファイル保存できるか」を確認しようと下図の様なsample-nnnnnn.txt (nnnnnnは連番)を1万ファイル単位で合計10万用意し、NFSサーバー上の1ディレクトリに逐次コピーをしました。

ファイルの中身は10桁の連番を入れ全ファイル12Byte *1です。
これを1万ファイル単位でコピーした結果が次の表になります。

ファイル数 コピー時間(秒)
1 - 10000 348
10001 - 20000 911
20001 - 30000 1544
30001 - 40000 2202
40001 - 50000 3167
50001 - 60000 4086
60001 - 70000 5332
70001 - 80000 6470
80001 - 90000 7172
90001 - 100000 8659
総コピー時間 39891 (約11時間)

10万ファイルのコピーに11時間もかかってしまいます...環境・手法の問題もあるでしょうが本当に最悪の結果です。
ちなみにこの10万ファイルを予め1つのZipファイルに圧縮しておくと、

  • 10万ファイル(約1MB)のZip圧縮 : 約1分
  • Zipファイルのコピー : 0.2秒

でした。

1分 vs 11時間、Snowcone(というかNFSサーバー)へのデータ転送方法は慎重に決めると良いでしょう。

(とりあえずNFSサーバーの1ディレクトリに10万ファイルは保存可能でした...絶対に推奨しませんが)

実例2 : 巨大ファイルのコピー

もう一つの補足として手元にあったいくつかの巨大ファイルのコピー結果を記載しておきます。

ファイル ファイルサイズ コピー時間(秒) MB/sec
Windows 10のISOファイル (.iso) 5.79GB 95 62.4
手元にあったWindows ServerのVHDファイル (.vdhx) 30.9GB 514 61.5

チューニングを目的としてないためrsize=128 wsize=128で雑に計測していますし、ネットワーク環境も正直いいかげんです。
Snowconeでは60MB/secが保証されるという話では無いですし、また、チューニングによってはこれ以上の性能がでる可能性もあります。

「ファイルの種類によっては雑にこの程度のオーダーである」という事にすぎませんのでその点はご承知おきください。

終わりに

今回はここまでです。
つぎはSnowcone内でのEC2の利用について解説する予定です。

脚注

  1. 本当は10Byteファイルを作る予定がうっかり改行コードを混ぜてしまい2Byte余計に...