Fusion-IO ioDriveの障害例と調査方法

インフラエンジニアに永遠につきまとう、月曜出社直後の障害報告と調査依頼。
今回はioDrive搭載サーバのMySQLが急に落ちましたということで、調査してみました。

これまで、ioDriveは不滅です。的なことばかり書いていましたが、まぁいつかは何か起きますよね・・・ってことで、ホクホクしながらioDriveのネガキャン、ではなく、こんな障害例がありましたよ、こんな感じで調べましたよという紹介をします。



月曜朝のスタート地点

依頼主からもらった情報。
  • あるioDrive搭載サーバのMySQLが急に落ちました
  • 障害時間は 2012/09/29 03:30 です
  • ioDriveのマウント先 /fio が利用できない状態です
  • もうこのサーバは使っていないので好きに調査してください

  • 今回は無償で受けてあげました。
    それでは調査開始!


    ドライバなどのバージョン確認

    2.2.3 を利用していることを確認。


    マウント先の確認

    全くアクセス出来ないことを確認。

    この時点で、MySQLが原因である可能性がほぼゼロと判断し、ioDriveのVSLか、ioDriveかマザボが物理的に逝ったか、と予想し始める。


    記念uptime

    ioDriveが起因での障害とすればとても珍しいので記念にuptimeとかメモっちゃう。

    snmpdのグラフを見たら、使い始めてから250日超えてたくらい。


    /dev/md0 XFSの確認

    xfs_repairで直ることなんてザラだから一応チェックするもダメ。



    認識デバイスの確認

    fdiskで見るとどうなってるかな~、で死亡確認。


    fio-status の確認

    信頼と実績のfio-statusはどうなってるかな~、で死亡確認。めったに見られない表示ですね。


    いじくる調査の前にfio-bugreport取得


    fioデタッチ処理

    色々と無理だと悟って、再起動無しに直せるか試す方向へ。


    detachできていないけどフォーマットしてみる

    当然無理で、ドライバreloadしてみなさいと言われたので次。


    iomemory-vsl ドライバを無効 -> 有効にしてみる

    ここで俺たちの夏が終わったので再起動ソリューションと化す。


    OS再起動から確認

    そしてfio-statusの確認で元気なのを確認。


    再度 fio-bugreport を取得


    調査のまとめ

    ここまでの詳細と簡単なまとめをしつつ、
  • ストライピングの片方逝ったからデータ領域アクセス不可でMySQLが死んだ
  • 管理コマンドのみで復旧することは不可能と判断
  • 一見、/dev/fct1 または PCIe の物理的故障と見受けられる
  • 再起動によりとりあえず復旧したことを確認
  • このまま使い続けて良いかはだいぶ不安

  • あとはしかるべきところへ報告。
    報告先も調べてくれた上で、たいていは迅速な筐体交換、そして必要があればバックグラウンドでFusion-IO社へも報告されます。


    fio-bugreport について

    Fusion-IO社の調査では fio-bugreport の結果を必要とするため、あらかじめ取得しておくと早いです。

    ただ私は過去に、fio-util:2.2.3 と、ある筐体において、fio-bugreport 実行時にOSが強制ダウンする例も何回か経験しており、/usr/bin/fio-bugreport を覗いて検証すると、/dev/ 以下からの cat 読み取りをトリガーとして落ちることがわかっています。

    この件はだいぶ前に報告済みで、
  • ioDriveドライバ
  • カーネルバージョン
  • 筺体(RAID関連など)
  • あたりの相性の問題で起きているだろう、というところまではわかっています。

    なので危ないため、ひと通り他の調査を済ませてから実行するのが無難です。



    ioDriveは運用を始めてから、ほんとに全然問題が起きなく、珍しいので記録しておきましたが、今回紹介した調査内容はどちらかというとこれから導入する人が色々触ってみる時に役立つかもしれません。