アカウント名:
パスワード:
産経の記事やreoさんのコメントなどを基にまとめてみます。ただ、詳しい資料があまりないので今回の障害に詳しい方、もしよろしければ補足をお願いします。1. 昨年7月に落雷事故。関連がある可能性はあるが確証は得ていない。2. 昨年8月から10月まで障害が発生。影響を受けたデータは15万件。3. ほとんどのデータはコピーが無事だったので復旧できた。約1072件はコピーも破損したので消えた。(4. この際コピーの破損を検測できず、または検測せずに全データを復旧したと思い込んだ？)5. その後、半年に渡って気づかれなかった。原因は不明。(推測ですが、破損したデータの利用頻度が低い、または自前のソフトのバグだと思って再計算したら直ったので無視した？)6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。7. 産経の取材で今発表する。
> 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 チェックサムと比較する体制になったと聞いています。
一点書き忘れていたので補足します。
>> 6. reo氏はデータのハッシュをローカル保存したので今年3月にデータ破損を発見、指摘。>> reo氏が指摘した経緯はたぶんそれで合ってるんだと思いますが（ただし私は詳しい経緯は知りません）
reo氏のようにデータのハッシュを自分で記録しておかなくても、データを先頭から全域アクセスすれば、checksum error がユーザーに返るので分かる状態でした。 (ただし、FUSE 経由のアクセスの場合は、<errno.h> に checksum error がないため、EIO すなわち Input/output error に見えます)reo 氏以前に気づいた人がいなかったのは、正常な方の複製データへアクセスしていたためではないかという気がします。壊れている複製しかないファイルは 1072/15万=0.7% だけですし。
詳しい解説どうもありがとうございます。大変勉強になりました。
# そしてお詫び。8月に取材したのは産経ではなく日経。
障害の発生していたストレージがマスターとなって複製されたとのことですが、これってレプリケーション前でマスターしかないタイミングだったのかバグったデータで正常なデータが上書きされたのか。
後者だったら対策されたんでしょうか。
> これってレプリケーション前でマスターしかないタイミングだったのか> バグったデータで正常なデータが上書きされたのか
前者です。既にデータがあるのに上書きして再度複製処理をするのは無駄ですから、そもそもそういう処理は起きません。
了解です。だとすると、「コピーも破損した」でなく「正常なコピーが存在しなかった」のような。
> なぜこの時期になって取材があったのかは私も知りたいです。先日のGoogle落雷関連で再注目されたんでしょうかね。
> HPCIの場合、この種の問題への対策として、新規作成ファイルについて、作成後しばらく> たってから、データを読み込み直して md5 チェックサムと比較する体制になったと聞いています。
原因の把握とプロアクティブな対応策をセットで揃えてるのは素晴らしいと思った。(小並感)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
時系列でまとめてみる (スコア: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 チェックサムと比較する体制になったと聞いています。
原因の把握とプロアクティブな対応策をセットで揃えてるのは素晴らしいと思った。(小並感)