クラウドVM間ディスク共有

基盤:さてそれでは、ライトセール上の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間ではアーカイブかバックアップ置き場程度に、という感じでしょうか。

基盤:では、当社世界5拠点間での/pubなデータの共有を設定しておきます。

* * *

基盤:ということで、作業終了しました。まず東京本部からの視点。

基盤:オレゴン支部から。

基盤:フランクフルト支部から。

基盤:以下略。ネーミングは暫定です。

開発:これでいちいちscpとかしなくて良くなって、仕事がやりやすくなりますね。

社長:あとは、ミツツボアリをどう作るかということですね。

-- 2020-0716 SatoxITS

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です