やらかしてしまったので備忘録がてら書こうかと思います。
作業概要
古いNetApp(7-mode)を新しいもの(cDOT)にリプレースするという作業。前提
サーバはNFSでNetAppのボリュームをマウントしている旧NetApp:FAS3160A(7-mode)
新NetApp:FAS2750A(cDOT 9.5P1)
クォータ(Quota)の種類:ユーザクォータ(User Quota)
NFSのエクスポートのIPは旧NetAppから乗っとる方式
作業概要
- FAS3160AからFAS2750Aに日次でSnapMirrorを実施しておく
- 夜間にメンテナンス時間を設けて切り替え前にサービスを閉じてディスク更新静止点を作る
- サーバでNFSのumount実施
- SnapMirrorの最終同期実施
- FAS3160AのInterfaceをDOWN、FAS2750AのLIFをUP
- サーバでNFSのmount実施
- FAS2750Aでユーザクォータの設定を流し込み、Quota設定を反映
最後の7.でしくじったことでサービスの大障害になりました。
というか、まだ障害が収束していないものもあって、対応継続中です。
ただ、原因はわかったので、あとは解決に向けて解消方法を決定して作業をすることになると思います。
さて7.のユーザクォータ設定でのしくじりなのですが、問題は2つでした。
- デフォルトクォータを設定する予定ではないのに設定されてしまった。しかも制限値が2MB!
- クォータの設定数が多すぎて、quota reportのコマンドレスポンスが遅すぎる
まず1つ目。これはそもそも明らかに設定業者のミス(デフォルトクォータ設定しないことになっていた)なんですが、クォータ設定コマンドのファイルを事前に確認しておけばよかったんですが、大丈夫だろうということでスルーしてしまいました。
結果どうなったかというと、明示的にクォータ設定していなかった一般ユーザ(httpユーザやmysqlも含まれる)がファイルが書き込めなくなり、mysqlのデータベースが壊れました…
次に2つ目。これはサービスのクォータの設定値を取得して表示する画面が遅すぎて使い物にならなくなりました。
今回入力した設定数は90000行。まちがいではありません。9万行です。これだけクォータ設定を入力すると、volume quota reportコマンドを使って設定を取得するまでに20秒以上かかるようになってしまいました。FAS3160のときはすぐにレスポンスされていました。そもそもクォータ設定の方法が違うので、値を取得するときのメカニズムも違うのだと想像されます。
ちなみに、シミュレータで実験してみたところ、設定数に比例してレスポンスタイムが悪化していくようで、設定数5000件だと概ね1.5秒くらいでレスポンスされていました。
以上より、今回得られた知見は2点だと思っています。
- デフォルトクォータはなるべく設定するな!設定する場合も最初から設定値を低くし過ぎるな!
- クォータの設定は実際に利用しているユーザの数だけ設定しろ!横着してまとめて設定するとクォータ状況を取得する機能を使い場合速度劣化の原因になる!
復旧のために、23:00の夜勤出社から退社が翌日の24:00となりました。25時間勤務。さすがに疲れました。
今回はこのへんで。それではまた。
0 件のコメント:
コメントを投稿