NetAppストレージ領域のls結果が遅かった話続き

なんちゃって技術者のなまくらです。みなさま、いかがお過ごしでしょうか。

ちょっと前にこんな記事を書きました。
ls結果が遅すぎる！どうなってんだNetApp！？

ことの顛末を書いていなかったのと、現在も結論が出ていない事実があるので書いておこうと思いますまる。

発生事象おさらい

NetApp をFAS3160からFAS2750にリプレース。NFSボリュームはそのまま移行。その中のとあるディレクトリにファイルが26,000弱存在していた。その領域をSolaris9(古っ！)とCentOS6で両方ともマウントし、lsコマンドをたたいたところ、Solaris9は2分半かかり、CentOS6ではその1/5（30秒）ほどでした。

マウントオプションの違い

どうしてそんなに大きな差となって表れたのか、わかっている人にとってはえらく単純で、マウント時にnoacのオプションを付けたかどうか、です。
このオプションをつけないとOS側でキャッシングをしなくなるので、lsの要求(特にgetattr)はすべてNetApp側に投げることになります。

手元にあるCentOS6.6にてman nfsを叩き、ac/noacオプション部分を抜粋します。

Selects whether the client may cache file attributes. If neither option is specified (or if ac is specified), the client caches file attributes.

クライアントがファイル属性をキャッシュできるかどうかを選択します。どちらのオプションも指定されていない場合（またはacが指定されている場合）、クライアントはファイル属性をキャッシュに入れます。

To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server's version of each file's attributes for  updates.
Changes  that  occur  on  the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server.

パフォーマンスを向上させるために、NFSクライアントはファイル属性をキャッシュします。数秒ごとに、NFSクライアントは更新のために各ファイルの属性のサーバーのバージョンをチェックします。
これらの短い間隔でサーバー上で発生した変更は、クライアントがサーバーを再度チェックするまで検出されません。 noacオプションを指定すると、クライアントはファイル属性をキャッシュできなくなり、アプリケーションはサーバー上のファイルの変更をより迅速に検出できます。

In addition to preventing the client from caching file attributes, the noac option forces application writes to become synchronous so that local changes to a file become visible on the server immediately.  That way, other clients can quickly detect recent writes when they check the file's attributes.

クライアントがファイル属性をキャッシュしないようにすることに加えて、noacオプションはアプリケーションの書き込みを強制的に同期化して、ファイルに対するローカルの変更がサーバー上ですぐに見えるようにします。このようにして、他のクライアントはファイルの属性をチェックするときに最近の書き込みを素早く検出できます。

Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty.  As such, judicious use of file locking is encouraged instead.  The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs. 

noacオプションを使用すると、同じファイルにアクセスするNFSクライアント間でキャッシュの一貫性が向上しますが、パフォーマンスが大幅に低下します。そのため、代わりにファイルロックを慎重に使用することをお勧めします。データとメタデータのコヒーレンスのセクションでは、これらのトレードオフについて詳しく説明しています。

 なんだ、manに解答が全部書いてあるじゃんw

なんでnoacオプションを使用しているのか

前のmanから抜粋の最後のほうにも書いてあるんですが、ファイル読み取りの一貫性を保証したかったからです。一貫性というと( ﾟДﾟ)ﾊｧ?？なんのこっちゃと思うかもしれません。
今回問題が発生したサーバは負荷分散装置の下に2台構成でぶら下げているサーバで発生したものです。ファイルキャッシュを有効にすると、2台の間のファイルの状態に差が生じてしまうなどの問題が発生することがあるからです。

良いリンク見つけました。
nfs利用時のmountオプションについて

リンク切れ怖いのでここから転載するとキャッシュを効かせると、速度的に大きなアドバンテージが得られる代わりに、以下のデメリット(一貫性、安全性)も生じます。

• マウントしているクライアント側がローカルにキャッシュを持つのでnfsサーバ側と差分が出ることがある(LB配下の場合はクライアント間でも発生する)。
• 同期しないので書き込み完了したつもりでも、DISKに反映されてない事がある
• IOをキャッシュするので突発ダウン時にDISK書き込んでいないデータが消失する

キャッシュのON/OFFについてのトレードオフ関連の話については長くなりそうなのでまたにしましょう。今回は速度面のところにフォーカスあててるのでこの辺で切り上げます。

プラスしての悪条件

で、mountのnoacオプションのことについては理解できましたが、今回の事案ではこの影響に拍車をかけた環境がありました。

それはリプレースしたNetAppをもともとあったところとは別のロケーションに配置したことです。ロケーション間をL2ブリッジで接続していたので、セグメントは同じでしたがPingで確認したところブリッジでのレイテンシーが数ミリ秒単位で存在する状況になりました。

noacオプションでマウントした時に数100ファイルくらいであればこの遅延は体感できないくらいだったと思うのですが、万を超えるファイル数だったので、この数ミリ秒のレイテンシーが積み重なって影響を体感できるくらいになっていました。

レイテンシー発生自体は仕方がないことではあるのですが、ネットワークレイテンシーの積層効果を軽く見ていて（というか気づけなくて）、遅延事象に拍車をかけることになってしまいました。

NetAppも遅くなってる！？

ここまではNFSの仕様とその影響が増幅される場合があるよ、という話をしていましたが、調べを進めていくと、どうやらNetApp側でも若干(これが大きな原因ではないと思うが)性能低下がある可能性が出てきました。

リプレースで新製品にしたのにね(´Д｀)ﾊｧ…

今回NetAppリプレースお願いした業者さんのほうで切り分けのために各ONTAPバージョンでのlsコマンドの結果を計測してもらったところ、以下のような結果に…

lsコマンドの応答速度計測結果

条件:

NetApp社の仮想上の検証環境(LabOndemand)を使用

ファイル数26001個、すべてダミーファイル、サイズは1kb

8.2.1  7-mode 0m21.145s

8.3.2  c-mode 0m24.601s

9.1RC1 c-mode 0m23.817s

9.3RC1 c-mode 0m45.441s

9.5RC1 c-mode 1m1.573s

バージョン新しくなるごとに遅くなってる…

これについてはメーカーサポートおよびメーカーの開発部門でも同様の傾向自体は確認しているらしいです…。

バージョンが新しくなるごとに新機能が追加されていたりして便利になってはいるとは思うのですがそれのかわり基本性能の低下は許容してくれ、ではなくて、せめて基本的な性能はそのままに、プラスアルファとして機能追加等をしていただきたい、と思った次第。

でも計測して傾向が分かったとはいえ、すでに機能をインプリメントした状態で出荷してるし、根本の原因特定とかはなかなか難しいんだろうなぁ。もちろん機能の設計と実装にもよると思うけれど。

それではまた。

ls結果が遅すぎる！どうなってんだNetApp！？

自分の力ではどうにもできず、営業通じてプッシュかけるしかないエンジニアの立場ほどつらいものはないよね。

なまくらです。みなさま、いかがお過ごしでしょうか。

NetAppを7-modeからcDOTに切り替えた週明け。酷いものです。

こんな問い合わせがありました。

「FTPサーバにログインできないんだけど。」

FTPログインするディレクトリはNetAppのNFS上にあります。

かるーく調べてみました。

# ls -l | wc -l
    25868

# time ls –l

…

~snip~

…
real    2m24.813s
user    0m0.810s
sys     0m4.460s

ファイルが2.5万個あると。

おそらくそこでlsの結果が遅すぎてFTP Clientがtime outになってると。

どうやら昔からある現象みたいだぞ。

「ls」コマンドが大規模な数ファイル / フォルダとディレクトリに対する速度が低下する

回避策はないようだ。

• ファイルを一時的に別の場所に退避する
• FTP Clientのタイムアウトを長く設定する

くらいしかやることがない。

リプレース案件マジ鬼門…。AFF 8040のときはこんなことなかったのに。

まぁあっちはAll FlashだからそもそもDisk Accessで遅くならないのか…

じゃあまた。(;´д｀)トホホ

追記:

どうやら遅いのは古いSolaris9のOSだけみたいだ。CentOS6とかで比較したら5倍くらい差が。

さらに2回目のlsはキャッシュが効いて100倍くらいの差が。どういうこっちゃ。

NetAppのクォータ(Quota)設定は気をつけろ！

なまくらです。みなさま、いかがお過ごしでしょうか。

やらかしてしまったので備忘録がてら書こうかと思います。

作業概要

古いNetApp(7-mode)を新しいもの(cDOT)にリプレースするという作業。

前提

サーバはNFSでNetAppのボリュームをマウントしている
旧NetApp:FAS3160A(7-mode)
新NetApp:FAS2750A(cDOT 9.5P1)
クォータ(Quota)の種類:ユーザクォータ(User Quota)
NFSのエクスポートのIPは旧NetAppから乗っとる方式

作業概要

1. FAS3160AからFAS2750Aに日次でSnapMirrorを実施しておく
2. 夜間にメンテナンス時間を設けて切り替え前にサービスを閉じてディスク更新静止点を作る
3. サーバでNFSのumount実施
4. SnapMirrorの最終同期実施
5. FAS3160AのInterfaceをDOWN、FAS2750AのLIFをUP
6. サーバでNFSのmount実施
7. FAS2750Aでユーザクォータの設定を流し込み、Quota設定を反映

最後の7．でしくじったことでサービスの大障害になりました。
というか、まだ障害が収束していないものもあって、対応継続中です。
ただ、原因はわかったので、あとは解決に向けて解消方法を決定して作業をすることになると思います。

さて7．のユーザクォータ設定でのしくじりなのですが、問題は2つでした。

1. デフォルトクォータを設定する予定ではないのに設定されてしまった。しかも制限値が2MB！
2. クォータの設定数が多すぎて、quota reportのコマンドレスポンスが遅すぎる

まず1つ目。これはそもそも明らかに設定業者のミス(デフォルトクォータ設定しないことになっていた)なんですが、クォータ設定コマンドのファイルを事前に確認しておけばよかったんですが、大丈夫だろうということでスルーしてしまいました。
結果どうなったかというと、明示的にクォータ設定していなかった一般ユーザ(httpユーザやmysqlも含まれる)がファイルが書き込めなくなり、mysqlのデータベースが壊れました…

次に2つ目。これはサービスのクォータの設定値を取得して表示する画面が遅すぎて使い物にならなくなりました。
今回入力した設定数は90000行。まちがいではありません。9万行です。これだけクォータ設定を入力すると、volume quota reportコマンドを使って設定を取得するまでに20秒以上かかるようになってしまいました。FAS3160のときはすぐにレスポンスされていました。そもそもクォータ設定の方法が違うので、値を取得するときのメカニズムも違うのだと想像されます。
ちなみに、シミュレータで実験してみたところ、設定数に比例してレスポンスタイムが悪化していくようで、設定数5000件だと概ね1.5秒くらいでレスポンスされていました。

以上より、今回得られた知見は2点だと思っています。

1. デフォルトクォータはなるべく設定するな！設定する場合も最初から設定値を低くし過ぎるな！
2. クォータの設定は実際に利用しているユーザの数だけ設定しろ！横着してまとめて設定するとクォータ状況を取得する機能を使い場合速度劣化の原因になる！

ということで。
復旧のために、23:00の夜勤出社から退社が翌日の24:00となりました。25時間勤務。さすがに疲れました。

今回はこのへんで。それではまた。

Windows10のWSLでnfsマウントできねーじゃんという話

「アプリ以外」のこと何でもかんでも頼んでくるなよ！
プログラム以外のこともちょっとは勉強しろよおまいら！なまくらです。
みなさま、いかがお過ごしでしょうか。
さて、今回はソレガシが以前書いた記事Windowsでext4のマウント(だれか良いツールしらない？)のコメントで、Windows10のWSLでならマウントできるんじゃね？ってものがあったので試してみた結果になります。
答えから行くとちょっと試してみたけど
今のところできねー
です。
成功した人いたら教えてください。試行した手順は以下。
1．こちらを参考にWSLを導入。OSはUbuntuを選択
2．マウント環境の整備
マウントするためのパッケージなかったので入れた

# aput install nfs-common
マウントポイント作る。/mnt/cがすでにマウントされているので、それと同じ所有者と権限に設定
# mkdir /mnt/x
# chown namakura:namakura /mnt/x
# chmod 777 /mnt/x
3. mountコマンド実行
以下コマンド実行結果。ちなみに192.168.128.154:/mntは確実にexportされていることを確認済み。

root@DESKTOP:/mnt# mount -t nfs 192.168.128.154:/mnt /mnt/x
mount.nfs: No such device
root@DESKTOP:/mnt#

へー。そんなデバイスないってか。うーむ。WindowsのほうではX:ドライブなんて作ってないから、そんなこと言われるのかな。
それが理由だとするとX:なんていう空のドライブレターなんて作れないから、Windows→WSLのほうはドライブをマウントできるかもしれないけれども、WSL→Windowsのほうはexportすることはできないってことなんだろうかね。
とまぁ、WSLの話はともかく、元記事のやりたいこと自体はこれも親切な方がコメントで
Ext2Fsd で ext4 パーティションをマウントできないとき
という記事を紹介してくださって、なるほど条件があったのですね…と。
でももうソレガシTeraStation(TS-IX4.0TL/R5)捨てちゃったから確かめられないのよねぇ。
Linuxにiscsiターゲット作らないと試せないな…
それではまたー。