基盤：さてそれでは、ライトセール上のVM間のディスク共有を行いたいと思います。
開発：性能的にどうですかね。
基盤：レスポンス的には、pingでのrttが、リージョン内では 0.5ms、遠いリージョン間では 150ms 〜 250ms といったところで、2桁以上の違いがあります。一方でスループット的には、ファイル転送がリージョン内では60MB/s、リージョン間では6MB/s といったところで、1桁程度の違いです。
開発：引っ越し時の大量転送は別として、6MB/s というのは昔のHDDと同等の性能ですから、まあ使い物にはなりますね。ですが、RTT 250ms だと、たとえば1ファイルを作るのに1秒とかかかったりしそうだし、作業用にランダムアクセスするのも厳しそうです。もっとも、RAMでバッファしてくれればそこそこ吸収できるのかも知れません。
基盤：で、リモートファイルアクセスのプロトコルですが。
開発：まずはNFSじゃないですかね。一番軽そうだし。設定も、nfsd 側で exportfs して、クライアント側で mount.nfs するだけだし。もともと公開しているファイルを共有するだけなので、セキュリティについては特に考慮する必要はありません。アクセス元をIPアドレスで制限すれば十分と思います。
基盤：では、まず nfsd 側を設定します… /etc/exports… 空っぽですね。 / とだけ書けば良いのかな。で、/usr/sbin/rpc.nfsd… ああ、なんか怒られてます。ではおおせにしたがって /proc/fs/nfsd をマウント。おもしろい考え方ですね。/usr/sbin/rpc.nfsd。netstat -a|grep LISTEN。sunrpc立ち上がった模様。で、mkdir /nfs/localhostして、mount.nfs localhost /nfs/localhost… なんか怒られてますね。mount.nfs4 -v localhost:/ /nfs/localhost …。Connection refused。あれ？サーバプロセス数を指定しないといけないみたいですね。/usr/sbin/rpc.nfsd 4。netstat -a|grep LISTEN。ps ax|grep nfsd。nfsd 受付開始です。ふたたび sudo mount.nfs4… おっと、Permission denied が出ました。/etc/exports を / * にして exportfs -ra… 変わらないですね。/var/lib/nfs/etab を見る…
開発：ぶぶー。タイムアウトです。ぐぐりましょう。amazon linux nfs ...。ああ、service nfs start で起動するみたいですよ。
基盤：sudo service nfs start。mount.nfs4… 繋がりました。
基盤：1時間ばかりロスしてしましました。
社長：教訓としては、①昔のUnixと違ってサーバを管理するコマンドがある。②意地を張らずにググる。ですね。
基盤：では、共有用のフォルダを /pub とかなんとかにして。exports に加えて exportfs -ra。で、他のマシンから mount.nfs ...。ああ、ファイアウォールを通さないといけないですね。111番 TCP？だめ。2049番 TCP？通りました。シドニー・ムンバイ間開通です。
基盤：東京ーシドニー間でも接続。mountしてファイルをtar xf ... やはり1ファイル作成に1秒というところですね。いつもの time openssl rand 100000000 > 100MB… スループット的には6MB/s 〜 10MB/s ですね。
社長：これTCPモードみたいですが、UDPでやったらどうなりますかね。あ、でもその前にお昼に行きますか。
＊ ＊ ＊
基盤：ふぁあ。よく寝た。さてまず、NFSのパケットを覗いてみましょう。tcpdump あれ、ないんですね。yum install tcpdump。あった。では。クライアント側で echo > x。
開発：55.67 に最初のパケットが来て、56.42 のackで終わってますね。0.75秒。
基盤：UDPでつなぐにはどうすればいいんですかね… man mount… udp というマウントオプションがあるような。… そんなオプションは無いって言われますね。NFSv4ではTCPがデフォになったそうで、UDPをどう扱うかは実装次第なのかも知れません。
開発：うーん… そうですか。まあ理想的に1往復で行ったとしても 250msの壁は超えられないわけですしね。結果を待たないという意味では async オプションが良いのかな？
基盤：async でマウント。echo > x。
基盤：変わらないですね。
開発：まあ、クライアント側が待たないだけですからね。連続上書きしたり、書いて速攻同じものを読んだ時にどうなるかとか。
社長：因果は高速を超えられませんからね。RTT 250ms の世界で頑張っても仕方がないかな。ローカルならHDDでも10ms以下ですからね。
開発：並列化とかパイプラインをやらないとダメそうですね。上のレイヤでもっと処理をまとめて通信往復回数を少なくするか… バッファリングかキャッシュか。だいぶ昔に iSCSI というのが流行ったと思うんですが、あれは一体どうなってたんでしょうね？？
基盤：しかしこれだけ通信が遅いと、暗号化処理がネックになることはなさそうですね。大きなファイルの転送のスループットで言えば、scp でも cp/NFSでも同速度。
基盤：大きなファイルの上書きではやはりrsyncですね。
社長：sshは、まあコンフィギュレーション次第なのかも知れませんが、ネゴシエーションのための行き来が多すぎる。リモートに高速に貼ったり切ったりするものでは無いですよね。
開発：NFSもTCP上でって言うなら、SSLで通せば簡単ですね。
社長：まあそういうことで、100msを超えるRTTの世界というのを久しぶりに見た気分です。使い方的には、ローカルなVM間ではアクティブなファイルの共有に、リモートなVM間ではアーカイブかバックアップ置き場程度に、という感じでしょうか。
基盤：では、当社世界５拠点間での/pubなデータの共有を設定しておきます。
＊ ＊ ＊
基盤：ということで、作業終了しました。まず東京本部からの視点。
基盤：オレゴン支部から。
基盤：フランクフルト支部から。
基盤：以下略。ネーミングは暫定です。
開発：これでいちいちscpとかしなくて良くなって、仕事がやりやすくなりますね。
社長：あとは、ミツツボアリをどう作るかということですね。
-- 2020-0716 SatoxITS