パスワードを忘れた? アカウント作成
12479886 story
ストレージ

スパコンネットのデータ保存拠点で昨年に発生していた大規模障害、今年3月まで気付かず 55

ストーリー by hylom
気付かないのはまずい 部門より
あるAnonymous Coward 曰く、

理化学研究所(理研)などのスーパーコンピュータを結んだネットワーク「HPCI」でデータが破損・消失するトラブルが発生していたそうだ(日経新聞)。

データ保存を行っていた拠点の1つである東工大のデータセンターで昨年8~10月に障害が発生していたとのこと。これにより、ほかの拠点にデータのコピーが保存されていなかった約1072件のデータが消失したという。この障害はシステム更新の過程で修復されたとされており、今年3月に指摘されるまで問題が発生していたことに気付かなかったという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Patilise (45974) on 2015年08月26日 18時43分 (#2871044)

    産経の記事やreoさんのコメントなどを基にまとめてみます。ただ、詳しい資料があまりないので今回の障害に詳しい方、もしよろしければ補足をお願いします。
    1. 昨年7月に落雷事故。関連がある可能性はあるが確証は得ていない。
    2. 昨年8月から10月まで障害が発生。影響を受けたデータは15万件。
    3. ほとんどのデータはコピーが無事だったので復旧できた。約1072件はコピーも破損したので消えた。
    (4. この際コピーの破損を検測できず、または検測せずに全データを復旧したと思い込んだ?)
    5. その後、半年に渡って気づかれなかった。原因は不明。(推測ですが、破損したデータの利用頻度が低い、または自前のソフトのバグだと思って再計算したら直ったので無視した?)
    6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。
    7. 産経の取材で今発表する。

    • by Anonymous Coward on 2015年08月26日 19時28分 (#2871069)

      > 3. ほとんどのデータはコピーが無事だったので復旧できた。約1072件はコピーも破損したので消えた。

      あってます。
      ちなみに、このコピーは、ユーザーがとっていたものではなく、
      ストレージシステム側で、複数のサーバーに自動複製されていたものです。
      1072件については、障害の発生していたストレージがマスターとなって複製されたため、
      自動複製されたデータまで壊れていてダメだったんだと思います。

      > 5. その後、半年に渡って気づかれなかった。原因は不明。

      今回の障害は、ディスクへの書き込みは成功し、またディスクからの読み出しも成功するが
      データは化けているという、silent data corruption という種類の障害でした。
      この場合、OS レベルの障害監視では、障害を検知できません。

      > (4. この際コピーの破損を検測できず、または検測せずに全データを復旧したと思い込んだ?)

      今回の場合、ストレージシステムが、ユーザーレベルで md5 チェックサムを記録していたため、
      これと照合すれば、破損を検知することは可能でした。
      しかし、そのためには、書き込みに成功しているデータでも、カーネルが持つデータキャッシュが
      消えてから、ストレージから読み直してチェックサムを比較する必要があるわけですが、それを
      行っていなかったため、検知できませんでした。

      > 6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。

      reo氏が指摘した経緯はたぶんそれで合ってるんだと思いますが(ただし私は詳しい経緯は知りません)、
      システム側でも md5 チェックサムを保存していたため、障害発生を検知した後、全ファイルの
      md5 チェックサム比較を行い、障害規模が判明しました。

      > 7. 産経の取材で今発表する。

      障害発生については、以下のURLで以前から発表されていました。
      https://www.hpci-office.jp/info/pages/viewpage.action?pageId=28246678 [hpci-office.jp]
      初報は4月21日であり、今回発表したわけではありません。
      なぜこの時期になって取材があったのかは私も知りたいです。

      今回の問題は、RAID controller の firmware 障害の可能性が高いと聞いていますが、
      RAID controlller 以外でも、HDD 側の firmware 障害や、OS のバグにより、
      silent data corruption が起きた例があります。
      ストレージシステムの運用側としては、かなり頭の痛い問題です。

      HPCIの場合、この種の問題への対策として、新規作成ファイルについて、作成後しばらく
      たってから、データを読み込み直して md5 チェックサムと比較する体制になったと聞いています。

      親コメント
      • by Anonymous Coward on 2015年08月26日 19時49分 (#2871077)

        一点書き忘れていたので補足します。

        >> 6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。
        >
        > reo氏が指摘した経緯はたぶんそれで合ってるんだと思いますが(ただし私は詳しい経緯は知りません)

        reo氏のようにデータのハッシュを自分で記録しておかなくても、データを先頭から全域アクセスすれば、
        checksum error がユーザーに返るので分かる状態でした。 (ただし、FUSE 経由のアクセスの場合は、
        <errno.h> に checksum error がないため、EIO すなわち Input/output error に見えます)
        reo 氏以前に気づいた人がいなかったのは、正常な方の複製データへアクセスしていたため
        ではないかという気がします。
        壊れている複製しかないファイルは 1072/15万=0.7% だけですし。

        親コメント
      • 詳しい解説どうもありがとうございます。
        大変勉強になりました。

        # そしてお詫び。8月に取材したのは産経ではなく日経。

        親コメント
      • by Anonymous Coward

        障害の発生していたストレージがマスターとなって複製されたとのことですが、
        これってレプリケーション前でマスターしかないタイミングだったのか
        バグったデータで正常なデータが上書きされたのか。

        後者だったら対策されたんでしょうか。

        • by Anonymous Coward

          > これってレプリケーション前でマスターしかないタイミングだったのか
          > バグったデータで正常なデータが上書きされたのか

          前者です。
          既にデータがあるのに上書きして再度複製処理をするのは無駄ですから、
          そもそもそういう処理は起きません。

          • by Anonymous Coward

            了解です。
            だとすると、「コピーも破損した」でなく「正常なコピーが存在しなかった」のような。

      • by Anonymous Coward

        > なぜこの時期になって取材があったのかは私も知りたいです。
        先日のGoogle落雷関連で再注目されたんでしょうかね。

      • by Anonymous Coward

        > HPCIの場合、この種の問題への対策として、新規作成ファイルについて、作成後しばらく
        > たってから、データを読み込み直して md5 チェックサムと比較する体制になったと聞いています。

        原因の把握とプロアクティブな対応策をセットで揃えてるのは素晴らしいと思った。(小並感)

  • by Anonymous Coward on 2015年08月26日 18時16分 (#2871024)

    これ発見したのスラドでもおなじみreoさん [srad.jp]こと、大阪大学助教の柏崎礼生氏 [osaka-u.ac.jp]だそうです。
    http://b.hatena.ne.jp/entry/263681623/comment/reo_kashiwazaki [hatena.ne.jp]

    3月に指摘した者です。手元で全データのハッシュを保存しておいたので気付くことができました。

    だそう。間違いなくこの人ならよく分からん部分も教えてくれそうなんですけど。

    だれかreoさん召喚してくれ。

    • by reo (4042) on 2015年09月26日 9時43分 (#2889214) 日記

      召喚されているとは全く気付かず放置していてすみません。

      ほとんど #2871069 の AC 氏が書かれているので僕が述べることはほとんどないのですが、はてブのコメントに書いた「ハッシュを保存しておいたので気付くことができた」というのは遠因ではあっても直接的な気付きの要因ではありません。釣りっぽいコメントでごめんなさい :-)

      HPCI システムでは Gfarm ファイルシステムによる共用ストレージが提供されています。HPCI システムでは Gfarm ファイルシステムに対する高速なファイルコピーを実現するための高速ステージングコマンドが提供されています。これは並列にファイルコピーを行うことで短時間でコピーを終えることができるコマンドです。

      このコマンドを使ってコピーをした際、コピー元とコピー先が同一であることを確信したい要求が僕の研究にはありました。そこでローカルにあるファイルのハッシュを全て取得し、HPCI システムの共用ストレージにコピーをした結果のハッシュと突き合わせておりました。その途中でいくつかのファイルにおいて Input/output error が発生しました。

      #2871069 の AC 氏は「データのハッシュを自分で記録しておかなくても、データを先頭から全域アクセスすれば、checksum error がユーザーに返るので分かる」と述べられておりますが、この「データを先頭から全域アクセスすれば」ということは HPCI システムの利用者マニュアルには書かれておりません。初めて知りました :-)

      「壊れている複製しかないファイルは 1072/15万=0.7% だけ」という指摘がありましたが、僕の研究でのファイルの扱い方からすると 0.7 % という数字は「エラー率高すぎて恐くて使えるかよ!」というレベルです。僕は共用ストレージに約 1 万のファイルを配置しておりましたので、約 70 ファイルにアクセスできないことになるのですから。

      --
      Hiroki (REO) Kashiwazaki
      親コメント
  • by Anonymous Coward on 2015年08月27日 2時26分 (#2871252)

    近年障害の起きているファイルシステムのほとんどが分散並列フォールトトレラントファイルシステム [wikipedia.org]なのですが、何か関係あるのでしょうかね?

    SourceForge.netの障害→Ceph [opensource.srad.jp]
    Googleの雷の件→GoogleFS [it.srad.jp]
    今回→Lustre

    仕組み的な問題があるのでしょうか? それとも、ベストプラクティスが足りないだけ?

    • by Anonymous Coward on 2015年08月27日 4時39分 (#2871265)

      同じようなアーキテクチャのストレージで一回データロストに遭遇したけど、
      その時は異常(死にかけ)なノードを検知してクラスタから切り離すのに失敗、て感じだった。
      今回の原因は#2871069の人が書いてるようなやつだと該当ノードは正常なフリして動き続けるんで
      切り離す対象とみなされなかったんでしょう。
      正常に切り離せれば当然書き込みの対象にもならんし元からそこにあったデータも
      レプリカから再度複製されるんだけどね。

      発生頻度としてはノードになるサーバを買い足せば簡単に容量を増やせる仕組みなだけに
      台数が増えるぶん単体障害が発生しやすいてとこじゃないかな。
      スケールアウトしやすいんでDCでの採用例が増えてるから目立つだけかもしれん。

      親コメント
    • by Anonymous Coward

      SourceForge.netの障害→Ceph [opensource.srad.jp]
      Googleの雷の件→GoogleFS [it.srad.jp]
      今回→Lustre

      今回はLustreではなくgfarmの問題じゃないの?

  • by Anonymous Coward on 2015年08月26日 17時19分 (#2870971)

    障害が修復されたらダメでしょ。取り除くか解消しなきゃ。

    • by Anonymous Coward

      ???
      障害は修復するもの。
      「障害を復元」とかと勘違いしていないか?

      「障害を復旧」は「てにをは」を間違っている感はあるけど。

      • by Anonymous Coward

        障害は正常時に存在しないもの。
        何らかの原因によって障害が発生するのであって、発生した障害を解消するのが障害対応。
        システムを修復するのであって障害を修復するんじゃないよ。

        • by Ooty (29466) on 2015年08月26日 20時54分 (#2871111) 日記
          「畳を修復する」
          「畳の傷を修復する」

          前者が正しいのかも知れないが、どちらも使っている気がする。
          通常は齟齬が無いので、あまり気にしないのだろう。

          「日経平均株価 -900円の下落」は、株価が上がったのか下がったのか?

          あっ、完全に本題と関係無いや。
          親コメント
          • by Anonymous Coward

            >「日経平均株価 -900円の下落」は、株価が上がったのか下がったのか?

            これはいつも思う
            経済系の記者は違和感を感じないんだろうか

          • by Anonymous Coward

            お湯を沸かすのは水を加熱するのかお湯を加熱するのか

            • 前は不思議に思ってましたが、それは結果動詞というものらしいです
              川が流れる→流れたから川やろ!
              穴をあける→あけたから穴やろ!
              なんて場合に使われます。
              関係薄いけど、親コメの-900円の下落、ってのも-900円の、したがって下落
              みたいな省略とか言い直しの類だと解釈してます。
              親コメント
              • by Anonymous Coward
                -900円とか+900円は幅というか程度。
                下落自体は株証券の「価値が下がりました」という報告。

                円相場なら 8円安みたいな表現になるけど、株そのものはお金じゃないので。

                # と、もっともらしいことを言ってみましたが想像です。
              • by Anonymous Coward
                円相場なら、xセント安とか?
                # でもそんな言い方は聞かないなぁ
        • by Anonymous Coward

          いや、障害を修め復するのだから、「障害を修復する」で良いでしょう。

          • 言葉を省略するので、こういう行き違いも出ますね。
            知ってる人はわかるんですが、知らない人は「暗黙の省略」を展開できないので。

            「障害(の原因及び、これにより発生した損傷)を修復する」

            知ってる人は括弧内の「暗黙の省略」がわかりますね。

            親コメント
            • by Anonymous Coward

              日本語的には「文が省略されている」のではなく、
              「詳しく書き下していない」という印象だなぁ…
              日本語では一つの文に大量の情報を付け加えることもできるけど、
              「省略しない」と「追加する」の明確な境界が有るわけでもないし。

              Wikipedia/日本語#文の構造 [wikipedia.org]あたりで紹介されてる題述構造とか主語廃止論の解釈が分かりやすいけど、
              「修復する」という本題があって、それ以外は全てヒントだと思えば良い。

  • by Anonymous Coward on 2015年08月26日 17時30分 (#2870981)

    そういうものは無駄にスペースを消費するだけなので、消えてくれたほうがすっきりする。

  • by Anonymous Coward on 2015年08月26日 17時34分 (#2870984)

    レプリケーションに失敗していて障害がおきたときに気がついたということ?

  • by Anonymous Coward on 2015年08月26日 17時45分 (#2870992)

    読んで、あいかわらずはいろむの記事は意味がわからんな(偏見)と思ってソースを見たが、やっぱり意味がわからんかった・・・

     障害はその後システムを更新する過程で修復されたとみられ、今年3月に利用者が指摘するまで今回のトラブルに気付かなかった。
    正確な原因は分かっていないが、昨年7月に落雷による停電があり、その後の復旧作業で障害が起きた可能性があるという。

    7月  落雷により停電
    8月頃 復旧作業の時に、保存データを壊すバグが混入
    (8月~10月データ消失)
    10月 システムの更新時に、修復されてバグが消失

    って事かな?

  • by Anonymous Coward on 2015年08月27日 9時16分 (#2871332)

    コピー後に一度ベリファイ取ったものがその後も無事だとは限らないし、定期的に全部舐めて整合性検査するもんじゃないの?

    • by Anonymous Coward

      物理的な破損については、複製ファイルやRAIDを使った回復ができるのであれば、
      そこまでやらなくてもいいかもしれませんね。

      firmwareやOSのバグの場合、確かに定期的に全部読み直した方が、安全性が
      上がる気がします。

      大容量のファイルサーバーだと、全部読み直すだけでも結構な負荷でしょうけど、
      定期的に全部読み直すような運用しているところって、どれくらいの割合なんで
      しょう?自分の回りだと、そこまでやってるファイルサーバーはないです。

    • by Anonymous Coward

      分散ストレージシステムレベルでは壊れてなかったんじゃないかな。
      そっちでもチェックは入るから最初に書き込むときに成功してれば、
      ユーザーレベルのチェックサム検査を定期実行する必要は無い、筈。

typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

読み込み中...