あるAnonymous Coward 曰く、理化学研究所（理研）などのスーパーコンピュータを結んだネットワーク「HPCI」でデータが破損・消失するトラブルが発生していたそうだ（日経新聞）。データ保存を行っていた拠点の1つである東工大のデータセンターで昨年8～10月に障害が発生していたとのこと。これにより、ほかの拠点にデータのコピーが保存されていなかった約1072件のデータが消失したという。この障害はシステム更新の過程で修復されたとされており、今年3月に指摘されるまで問題が発生していたことに気付かなかったという。
時系列でまとめてみる (スコア:5, 参考になる)
産経の記事やreoさんのコメントなどを基にまとめてみます。ただ、詳しい資料があまりないので今回の障害に詳しい方、もしよろしければ補足をお願いします。
1. 昨年7月に落雷事故。関連がある可能性はあるが確証は得ていない。
2. 昨年8月から10月まで障害が発生。影響を受けたデータは15万件。
3. ほとんどのデータはコピーが無事だったので復旧できた。約1072件はコピーも破損したので消えた。
(4. この際コピーの破損を検測できず、または検測せずに全データを復旧したと思い込んだ？)
5. その後、半年に渡って気づかれなかった。原因は不明。(推測ですが、破損したデータの利用頻度が低い、または自前のソフトのバグだと思って再計算したら直ったので無視した？)
6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。
7. 産経の取材で今発表する。
Re:時系列でまとめてみる (スコア:5, 参考になる)
> 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 チェックサムと比較する体制になったと聞いています。
Re:時系列でまとめてみる (スコア:3, 参考になる)
一点書き忘れていたので補足します。
>> 6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。
>
> reo氏が指摘した経緯はたぶんそれで合ってるんだと思いますが（ただし私は詳しい経緯は知りません）
reo氏のようにデータのハッシュを自分で記録しておかなくても、データを先頭から全域アクセスすれば、
checksum error がユーザーに返るので分かる状態でした。 (ただし、FUSE 経由のアクセスの場合は、
<errno.h> に checksum error がないため、EIO すなわち Input/output error に見えます)
reo 氏以前に気づいた人がいなかったのは、正常な方の複製データへアクセスしていたため
ではないかという気がします。
壊れている複製しかないファイルは 1072/15万=0.7% だけですし。
Re:時系列でまとめてみる (スコア:2)
詳しい解説どうもありがとうございます。
大変勉強になりました。
# そしてお詫び。8月に取材したのは産経ではなく日経。
Re: (スコア:0)
障害の発生していたストレージがマスターとなって複製されたとのことですが、
これってレプリケーション前でマスターしかないタイミングだったのか
バグったデータで正常なデータが上書きされたのか。
後者だったら対策されたんでしょうか。
Re: (スコア:0)
> これってレプリケーション前でマスターしかないタイミングだったのか
> バグったデータで正常なデータが上書きされたのか
前者です。
既にデータがあるのに上書きして再度複製処理をするのは無駄ですから、
そもそもそういう処理は起きません。
Re: (スコア:0)
了解です。
だとすると、「コピーも破損した」でなく「正常なコピーが存在しなかった」のような。
Re: (スコア:0)
> なぜこの時期になって取材があったのかは私も知りたいです。
先日のGoogle落雷関連で再注目されたんでしょうかね。
Re: (スコア:0)
> HPCIの場合、この種の問題への対策として、新規作成ファイルについて、作成後しばらく
> たってから、データを読み込み直して md5 チェックサムと比較する体制になったと聞いています。
原因の把握とプロアクティブな対応策をセットで揃えてるのは素晴らしいと思った。(小並感)
reoさーん！ (スコア:1)
これ発見したのスラドでもおなじみreoさん [srad.jp]こと、大阪大学助教の柏崎礼生氏 [osaka-u.ac.jp]だそうです。
http://b.hatena.ne.jp/entry/263681623/comment/reo_kashiwazaki [hatena.ne.jp]
３月に指摘した者です。手元で全データのハッシュを保存しておいたので気付くことができました。
だそう。間違いなくこの人ならよく分からん部分も教えてくれそうなんですけど。
だれかreoさん召喚してくれ。
Re:reoさーん！ (スコア:1)
召喚されているとは全く気付かず放置していてすみません。
ほとんど #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
分散並列フォールトトレラントファイルシステム (スコア:1)
近年障害の起きているファイルシステムのほとんどが分散並列フォールトトレラントファイルシステム [wikipedia.org]なのですが、何か関係あるのでしょうかね?
SourceForge.netの障害→Ceph [opensource.srad.jp]
Googleの雷の件→GoogleFS [it.srad.jp]
今回→Lustre
仕組み的な問題があるのでしょうか? それとも、ベストプラクティスが足りないだけ?
Re:分散並列フォールトトレラントファイルシステム (スコア:1)
同じようなアーキテクチャのストレージで一回データロストに遭遇したけど、
その時は異常(死にかけ)なノードを検知してクラスタから切り離すのに失敗、て感じだった。
今回の原因は#2871069の人が書いてるようなやつだと該当ノードは正常なフリして動き続けるんで
切り離す対象とみなされなかったんでしょう。
正常に切り離せれば当然書き込みの対象にもならんし元からそこにあったデータも
レプリカから再度複製されるんだけどね。
発生頻度としてはノードになるサーバを買い足せば簡単に容量を増やせる仕組みなだけに
台数が増えるぶん単体障害が発生しやすいてとこじゃないかな。
スケールアウトしやすいんでDCでの採用例が増えてるから目立つだけかもしれん。
Re: (スコア:0)
今回はLustreではなくgfarmの問題じゃないの？
なんか強烈な違和感 (スコア:0)
障害が修復されたらダメでしょ。取り除くか解消しなきゃ。
Re: (スコア:0)
???
障害は修復するもの。
「障害を復元」とかと勘違いしていないか？
「障害を復旧」は「てにをは」を間違っている感はあるけど。
Re: (スコア:0)
障害は正常時に存在しないもの。
何らかの原因によって障害が発生するのであって、発生した障害を解消するのが障害対応。
システムを修復するのであって障害を修復するんじゃないよ。
Re:なんか強烈な違和感 (スコア:1)
「畳の傷を修復する」
前者が正しいのかも知れないが、どちらも使っている気がする。
通常は齟齬が無いので、あまり気にしないのだろう。
「日経平均株価 -900円の下落」は、株価が上がったのか下がったのか?
あっ、完全に本題と関係無いや。
Re: (スコア:0)
>「日経平均株価 -900円の下落」は、株価が上がったのか下がったのか?
これはいつも思う
経済系の記者は違和感を感じないんだろうか
Re: (スコア:0)
お湯を沸かすのは水を加熱するのかお湯を加熱するのか
Re:なんか強烈な違和感 (スコア:2)
川が流れる→流れたから川やろ！
穴をあける→あけたから穴やろ！
なんて場合に使われます。
関係薄いけど、親コメの-900円の下落、ってのも-900円の、したがって下落
みたいな省略とか言い直しの類だと解釈してます。
Re: (スコア:0)
下落自体は株証券の「価値が下がりました」という報告。
円相場なら 8円安みたいな表現になるけど、株そのものはお金じゃないので。
# と、もっともらしいことを言ってみましたが想像です。
Re: (スコア:0)
# でもそんな言い方は聞かないなぁ
Re: (スコア:0)
いや、障害を修め復するのだから、「障害を修復する」で良いでしょう。
Re:なんか強烈な違和感 (スコア:1)
言葉を省略するので、こういう行き違いも出ますね。
知ってる人はわかるんですが、知らない人は「暗黙の省略」を展開できないので。
「障害(の原因及び、これにより発生した損傷)を修復する」
知ってる人は括弧内の「暗黙の省略」がわかりますね。
Re: (スコア:0)
日本語的には「文が省略されている」のではなく、
「詳しく書き下していない」という印象だなぁ…
日本語では一つの文に大量の情報を付け加えることもできるけど、
「省略しない」と「追加する」の明確な境界が有るわけでもないし。
Wikipedia/日本語#文の構造 [wikipedia.org]あたりで紹介されてる題述構造とか主語廃止論の解釈が分かりやすいけど、
「修復する」という本題があって、それ以外は全てヒントだと思えば良い。
Re: (スコア:0)
damage recoveryやmalfunction recoveryでもそれなりにヒットしますよ
壊れたことに半年も気づかないようなデータ (スコア:0)
そういうものは無駄にスペースを消費するだけなので、消えてくれたほうがすっきりする。
Re:壊れたことに半年も気づかないようなデータ (スコア:2, おもしろおかしい)
おまえんちのバックアップデータが全部消えますように
Re: (スコア:0)
うちは3回くらい消えたな……
これって (スコア:0)
レプリケーションに失敗していて障害がおきたときに気がついたということ？
なるほどわからん (スコア:0)
読んで、あいかわらずはいろむの記事は意味がわからんな（偏見）と思ってソースを見たが、やっぱり意味がわからんかった・・・
7月 落雷により停電
8月頃 復旧作業の時に、保存データを壊すバグが混入
（8月～10月データ消失）
10月 システムの更新時に、修復されてバグが消失
って事かな？
整合性検査 (スコア:0)
コピー後に一度ベリファイ取ったものがその後も無事だとは限らないし、定期的に全部舐めて整合性検査するもんじゃないの？
Re: (スコア:0)
物理的な破損については、複製ファイルやRAIDを使った回復ができるのであれば、
そこまでやらなくてもいいかもしれませんね。
firmwareやOSのバグの場合、確かに定期的に全部読み直した方が、安全性が
上がる気がします。
大容量のファイルサーバーだと、全部読み直すだけでも結構な負荷でしょうけど、
定期的に全部読み直すような運用しているところって、どれくらいの割合なんで
しょう？自分の回りだと、そこまでやってるファイルサーバーはないです。
Re: (スコア:0)
分散ストレージシステムレベルでは壊れてなかったんじゃないかな。
そっちでもチェックは入るから最初に書き込むときに成功してれば、
ユーザーレベルのチェックサム検査を定期実行する必要は無い、筈。
Re: (スコア:0)
内容を理解してないなら、無理してコメントしなくていいのよ
Re:またしても (スコア:1)
俺も障害の内容が全く理解出来ないのだが、これだけの情報で内容を理解出来る人は居るのだろうか？
Re: (スコア:0)
> 一体どこのソリューション会社
国内でスパコンと言ったら，富士通しかありませんよ．
「スパコン 京」でググってください．
Re: (スコア:0)
いや、この手の奴は日立とか東芝とかNECとか大体全部噛んでる/たよ。
京の基本設計事業者は富士通だけどね。
Re: (スコア:0)
で、実際はどこの下請けが主体なのか？
受注できる企業はそんなに多くはないですよね？
Re: (スコア:0)
よく知らんがタレコミと記事見る限りトラブったのはデータセンタじゃないの？
Re: (スコア:0)
多分 TSUBAME だったら日本ヒューレット・パッカードから直です。
こういうのは「プレスリリース」で検索しないと。
大規模なものは値引交渉の関係上ハードベンダー直契約がほとんどですね。
安くする代わりに不利な情報の公開は控えるようにってのが入ってる
でしょうからこれ以上の情報は出ないと思います。
Re: (スコア:0)
HPCIのストレージは、TSUBAME本体とは別のマシン使ってると思います。
どこのベンダーのかまでは知りませんが。
Re:またしても (スコア:1)
ストレージは主要部分はDDNのようですね。
http://tsubame.gsic.titech.ac.jp/hardware-architecture [titech.ac.jp]
Re:利用率の問題なのでは？ (スコア:3, 参考になる)
調べりゃすぐ出る。
http://www.aics.riken.jp/jp/k/machine-status/node/ [riken.jp]
利用率が100%になっていないのは、異なる形状・粒度の計算を同時にスケジューリングしているからであって、
空いているわけではないので注意。
上記のサイトでは公開されていないけど、キューには、常に「京」の処理能力の倍くらいのジョブが溜まっている状態。
ジョブを投入して実行されるまでに一週間かかったり。大変混雑しております。
Re: (スコア:0)
＞開発することでメーカだけが潤って、利用されないのは問題ですよね
自分で変な仮定をして妄想で問題視って、どっかで流行ってるんですかね？
Re: (スコア:0)
あんなに揉めたのに、国立競技場より安いなんて！
Re: (スコア:0)
状況からみて Hadoop という、Google の検索エンジンに似たシステムを使っていたと思われます。
数十台以上のマシンで検索処理が実施され、その集計結果がユーザに返されるという物です。
Hadoop 自体がマシンが何台か壊れていても動くシステムで、障害を気にしてはいけないのが
原因だとおもいます。
Re: (スコア:0)
計算した大量のデータそのままが最終的な結果として必要でもないし、
京を使う人がみんなそれらの今までの蓄積データ全てを必要としてるわけでもないでしょ。
Re: (スコア:0)
今回の生涯は東工大のストレージシステムなのに、
なんでここでスパコン京の利用率の話しがでてくるのか、
と思ったら、本文の最初にこんなことが書いてあるんですね。
> 理化学研究所（理研）などのスーパーコンピュータを結んだネットワーク「HPCI」でデータが破損・消失するトラブルが発生していたそうだ（日経新聞）。
次の文ではちゃんとこう書いてあるのに。
> データ保存を行っていた拠点の1つである東工大のデータセンターで昨年8～10月に障害が発生していたとのこと。