新幹線不通の原因はHDDトラブル+システムのプログラムミス 55
ストーリー by hylom
HDDクラッシュを想定していないシステムだった 部門より
HDDクラッシュを想定していないシステムだった 部門より
あるAnonymous Coward 曰く、
先月28日に東北新幹線などのダイヤが乱れるトラブルが発生したが、調査の結果トラブルの原因がポイント制御を行う端末のHDD故障と、バックアップシステムの欠陥だったことが明らかになった(JR東日本の発表資料[PDF]、NIKKEI NETの記事)。
今回のトラブルの元になったのは、東京都北区の東京新幹線車両センター内にある自動進路制御装置。装置内のHDDに故障が発生し、HDD内のデータが読み取れなかったのがトラブルの原因とのことだ。また、故障が発生した場合、通常は自動でバックアップ用のシステムに切り替わるはずだったが、今回発生した「HDDからのデータ読み取り失敗」は「通常すぐに解消する軽微な問題」として対応がプログラムされていなかったそうだ。そのためバックアップシステムへの切り替えが行われず、復旧が手間取る結果となった。
このトラブルでは、東北新幹線のほか上越、長野、山形、秋田の各新幹線に影響が発生し、76本が運休、42本が最大5時間近く遅れ、計6万8500人に影響が出たそうだ(朝日新聞の記事)。この結果を受け、JR東日本はソフトウェアの改修を順次行っていくそうだ。
ほんとかなぁ (スコア:5, すばらしい洞察)
新幹線のポイント制御のようなリアルタイムなプログラムで「HDDからのデータ読み取り失敗」が「通常すぐに解消する軽微な問題」とするのが仕様になっているとは思えない。
考慮されていなかった、というのが正しい説明かと。
Re:ほんとかなぁ (スコア:4, 参考になる)
「サービスが正常が動いてるイコール問題はない」という認識だから、機械がぶっ壊れててもサービスさえ反応していればフェイルオーバーしない。
気づいたときにはもう手遅れってパターンが多いです。
HDDのエラー状況を監視するサービスが少ないっていうのもあるんでしょうけどね。
Re:ほんとかなぁ (スコア:2, 参考になる)
まさにそれなんじゃないですかね。
「HDDはRAID(1/5/10)で組んでいるから耐障害性も高く、考慮する必要はない。
ホットスワップが可能なので、どれか1つが壊れても全体が止まる前に入れ替えれば大丈夫。」
と考えていたのではないでしょうか。
# そして RAID コントローラが壊れる、と。
Re:ほんとかなぁ (スコア:4, 興味深い)
ググってみると結構な確率で復旧に失敗しているようですRAID5って本当に安心なのか?
Re:ほんとかなぁ (スコア:3, 参考になる)
Re:ほんとかなぁ (スコア:1)
HDDが壊れたら、自動的にHot stanbyを使用したRAID再構築が始まるので、その間にCold stanbyのHDDに電源を入れ、壊れたHDDを引っこ抜き、交換用HDDを新しいCold stanby HDDを挿入。そして新しい交換用HDDを手配しつつ壊れたHDDを修理に出すなり廃棄するなり。
上の方にあったRAIDコントローラの破損に対しては、インライン型のRAIDコントローラを使っている場合バックアップ用のRAIDコントローラを用意できるものを選んでおけばRAIDコントローラの二重化である程度まで対処できます。
# 昔ストレージ屋をやっていたときは「ちゃんと」RAIDシステムを組むところにはこういうシステムを組んで納入していた。
# でもRAIDコントローラ(交換可能な専用バックアップバッテリ付き)の二重化までやった案件って……。
ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
Re: (スコア:0)
個人的経験だとHDDそのものより電源周りの方が怖くなります。
あとは冷却性能ですか。
Re:ほんとかなぁ (スコア:3, 参考になる)
Re:ほんとかなぁ (スコア:1, 参考になる)
だって壊れるまでの時間が近いロットだと同じかもしれないじゃん。
ってことは、2つ同時に壊れる確立があがるわけで…。
# うちのPCのRAIDも同時に同じ店で買ったHDDだから不安なAC
RAIDの場合は、同じHDDを用意しろというけど (スコア:2, 興味深い)
とはいうものの、RAIDを組む時は同じHDDを使ったほうがいいと言われる…
わざわざ店変えてまで買う人がどれくらいいるか??
まして、買う時期までずらす人って…
時期をずらして、たまたま同容量のHDDを買ったら同じ型番だった…
んが、見比べたら基板に載ってるICが一つだけ、どう見ても違ってる!(^^;)
Re:RAIDの場合は、同じHDDを用意しろというけど (スコア:2, 参考になる)
枯れた製品ならば製造時期がまちまちな製品が店頭に並んでいるでしようが、そうすると同一型番を同じ店で同時に複数購入してもファームウェアのバージョンが異なる製品を渡されることがありますので注意しないといけません。
ファームウェアのバージョンまでチェックしている人はそれほど多くないようですが、意外とハマる原因にもなります。
結局は購入時に店頭でシリアルやファームを確認するのが確実なのでしよう。
実装チップが異なるのはよくあることで、同一型番でも製造時期によって違ったり同一時期の製造でもランダムに別なチップが乗ってたりしますがその理由はわかりません。
某社のトラブル時もフィリップスと松下の石を乗せた基盤がランダムに混じっていて、トラブルを起こしたのはフィリップスの石を乗せた球だけでした。
ベンダーによって対応が違がったりして、フィリップスの石を乗せた球だけ交換した会社と問題の無い松下の石が乗った玉も同時に回収した会社に対応が分かれました。
回収された松下の石を乗せた玉はリース品の中古補修部品に充てられたケースが多かったようなので、異なるチップの採用はコスト面以外にもトラブルに対するリスク分散の意味合いがあるのかもしれません。
Re:ほんとかなぁ (スコア:2, 参考になる)
容量は変更になってることがあって最悪です。
しかも、後に生産されたほうが容量が小さかったり。
要注意です。
Re:ほんとかなぁ (スコア:2, 参考になる)
流通経路によっては客要望でセクタ数の違う物が出てますけどソレですか?
実はSET MAX ADDRESS掛かってるだけとか。
参考までに型番,P/N,MLC,製造時期と産地が欲しいかも。
可能ならIDENTIFY DEVICEが欲しいですけど・・・
# RAIDの片方に使用中のT7K500(HDT725050VLA360)に不良セクタが出来たので余計気になる。
# まぁ、T7K500は既に製造終了状態ですが。
Re:ほんとかなぁ (スコア:1)
#そういえば、同じ型番が長く続く気がする。
Re:ほんとかなぁ (スコア:1, 興味深い)
仕様に書かれている最低容量はどれもクリアしてる製品しか出荷されてない。
問題は、そういうHDDのありきたりな仕様をなーんも考慮せんと
「目一杯」割り当ててしまう阿呆が居るというだけのことだ。
メーカーや型番に影響されない様にRAID容量を構成するってのは
ある意味基本なんだが、そういうノウハウってのは最近の人は知らんのかな?
特にバルクはそんなもん? (スコア:1)
正直歩止まりの関係で、完全にそのままのスペックの物が確実に出せるとは限らない。
内部の媒体に不良がある、あるいはヘッドの位置関係で微妙、とか言う製品が出て、だが他の機構は大丈夫そうだ、見たいな商品が出た場合、
内部のファーム調整やら物理フォーマットの調整やらで、一部ヤバい部分を殺したorヘッド位置決め精度を調整した、格好にしてスペックダウンし出荷する。
そういうパターンもある。
恐らく日立に限らんと思う。他メーカーで一定だった、というなら恐らく「同じにしてある」と見るべきだろう。
Re:ほんとかなぁ (スコア:1, 興味深い)
「起こる可能性のあることは、いつか実際に起こる。」というマーフィーの法則そのままでした。
みなさんもくれぐれバックアップの計画は慎重に。。。
Re:ほんとかなぁ (スコア:1)
だめ。RAID6, RAID DP などをつかうべき。
信頼性がいるなら RAID1+0 も使うべきではない。
Re:ほんとかなぁ (スコア:1)
システムの二重化はしているわけですから、
個々のシステムにはRAIDなんて組んでないんじゃないですかね。
故障を検出したらまるごと障害系に切り替えればいいんだし、
間に「正常系のRAIDの復旧」なんていう段階を作ると、よけい複雑で危ないと思う。
問題は「故障の検出」ロジックが甘かったからだと言ってるわけですが、最初からHDDを信用せずにエラーが出るのは前提として
「HDDが読み取りエラーになったときは、必要なデータは上に再度問い合わせる」「エラーが増えてきたら故障と判定」
するようなシステムだったりして、
それで「読み取りに行ったらいつまで経っても応答が返ってこない」系のエラーになったりしたら、
そもそも故障検出システムそのものがちゃんと動かなくなる、なんて可能性もあるんじゃないかと思いますね。
Re:ほんとかなぁ (スコア:1)
RAIDのコントローラーもサーバ側のインタフェースも多重化されているし、
Fibre Channel のスイッチなんかも多重化されていて、
電源も別系統から取って多重化できるようにできています。
電気的に引きずられないって事でインタフェースも光だったり。
RAIDも性能と耐障害性から0+1を選択するでしょうし。
クラスタリングするとき、フェイルオーバーは導入前のテスト項目として必須ですし。
# 障害で切り替わらなかったら導入する意味ないもんな
JRの出してるPDFを見た限りでは端末が機能しないことを
検出できなかっただけのように見えますから、
ベンダのテスト漏れなんだろうなぁ、という気がします。
それにしてもこのシステムってどれくらいのものなんだろう…。
Re: (スコア:0)
で、故障時の対応にはホットスワップできないと困るとか。
#うーん、高そうだ
中途半端にお金掛けた構成が出来ちゃうのもダメな気が。
Re:ほんとかなぁ (スコア:1)
しかもあまり使われないためにいざというときに切り替わらない。
ありがちな話で泣けてきます。
Re:ほんとかなぁ (スコア:1)
ってほとんどのシステムはそうじゃないですか?
RAIDのコントローラが壊れることやRAIDの電源ラインがいかれることまで
ふつうに想定するものなんでしょうか。
Re:ほんとかなぁ (スコア:3, 興味深い)
もっと言うと、サーバですら Active / Standby で同時起動はやらんほうがいい。つーか、数ヶ月動かしたところで、 Standby だけ再起動、とかやる。
例えばLinuxの場合、2.4系列だと 497日問題と言うのがあった。Jiffies が 32bit しかなくて100Hzで更新するので、497日とちょっと経つとカウンターが一周する。softdog とかがこれに対応していなくてリブートしちゃう…なんてのがあった。
こういう問題もあるので、HDDのロットを揃えない、と言うのと同じぐらい「Active と Standby を同時起動のまま放置しない」「定期的に Active と Standby を切り替えて、今まで Active だったものを reboot」は、本来当たり前に考慮すること。製品のロットだけじゃなく起動時刻なども含めて「あらゆるものを分散させる事で、シンクロニシティを防ぎ、乱数に基づく予測どおりにシステムが故障するように誘導する」のは基本中の基本。
というか、こういう事を考えないと、逆にシステム堅牢性を無駄に高くする必要が出てしまう。Active / Standby を組んでいるのに、Standby が一度も活躍しないまま引退する…というシステムデザインは、それはそれでオーバースペック。もっと安く作ることができたはずだ。
.
と、Staples(アメリカにある、文房具とかの量販店)のシスマネの人に教わりましたよ。去年、弊社の研修を一緒に受けたときに。会社の研修よりもそっちの方がためになったって…ありがたいことでございました。
と同時に、日本のお客様ももう少し、こういう事に耳を傾けて、コスト対効果を考えてもらえんもんかなとしみじみ思いましたとさ。
fjの教祖様
何処で割り切るか (スコア:1)
ホストシステムだとSPOFを起こさないような構成にする検討は普通にしますし
部分品が障害を起こしたときに影響の評価もします。
その上で、場合によっては見なかったことにするのではなしに
そのリスクを受容した設計にします。
機械部品は電子部品より壊れやすく、電子部品でも接触に頼るものの方が直付けのものよりも
障害を起こしやすいと、じゃあ、まあ、外部インターフェースを2組持つディスクはないから
そこはそう割り切ったついでにコントローラーも1つで済ませようとというのが PCベースのサーバーの穏当な落とし所なのだと思います。
Re:何処で割り切るか (スコア:1)
PCサーバで高可用性を求める場合は、無理にディスクのRAIDレベルをあげるとか、
ディスクとのI/Oや電源の冗長化をもとめるよりも、データレプリケーションや
シェアードナッシング型のクラスタを利用してサーバごと並べる方法が
使いやすいと思います。
電源を2つ乗せられる高級サーバよりも、叩き売りサーバを2つ買う方が
一桁安いですから。
この場合でもネットワークの冗長化は必須ですが、こちらはある程度決まった型が
できあがっているのでやりやすいです。
Re:ほんとかなぁ (スコア:1)
入れることはない。完全かそうでないかでエラー処理を決めるのが当然だと思います。
ある条件ではコケたら完全に切り替えられるシステムで、「ある条件を分岐しない」
という記述をするよりも切り替えることにしておくほうが仕様も実装も簡単だし、
手動でやるべき手続きもとくにないと思う。
それとも切り替えにかなりコストがあるのかなぁ。
Re:ほんとかなぁ (スコア:1)
お金次第だと思います。
私はIT屋じゃなく制御屋なので、例えが離れてしまうのですが、宇宙に送り出す機器は電線が燃えようと、CPUが壊れようと、無線機が壊れようと、極力機能が消失しなように考えられてますしね。
発注している側はsafetyの専門家じゃないでしょうから、一次請けの会社の力不足なんでしょうね。
Re:ほんとかなぁ (スコア:1)
ふつうに想定するものなんでしょうか。
それだけのお金を出してくれるところでは想定します。(+UPSの多重化)
お金のない、或いはケチなところではそこまで想定しません。(想定しても予算がなければそれまで。)
# 電源を多重化しておきながら、どれか一つでも電源が落ちると電源の供給能力が足りずに落ちてしまうなんて言う間抜けなシステムもあった様な……
# びんぼは嫌だ
ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
Re: (スコア:0)
万全とは思わずに、フェイルオーバー/フェイルセーフを実装するくらいでないと。
この構成だと障害発生時のシミュレーションテストが非常に面倒だから、
この辺のノウハウ持ちじゃないと、まともに実装と運用ができない罠
Re:ほんとかなぁ (スコア:1)
ひとつのカラムにデータ消して書いてを繰り返していたら、特定のセクタに当たっていたんでしょうね。
マイナーなエラーが1つ、RAIDコントで検出されていましたが、リカバリーされていると出ていました。
でもOracleはそのカラムに書くことが出来なくなっていました。
RAIDコントはエラーをリカバリできたと思っている。Oracleは書き込めたと思っている。
その結果、システムが止まりました。
原因としてはRAIDコントのファームかと思うんだけど。
これも、そんな感じか?
ガチガチに障害対策したって、いまどきのシステム、出来上がっているものを組み合わせる限りは難しいんじゃないかな。
納入後にファームアップとかやるし、HDDのロット不良で数年前に泣いた人も多いんでは。
昔は回路でロジック組んで、それこそバグ(虫)が挟まって停止とかになったけど。
Re: (スコア:0)
>ふつうに想定するものなんでしょうか
逆にしないの?と尋ねたい。
インフラ周りやシステム運用・監視の設計・構築では普通考えますね。
Re:ほんとかなぁ (スコア:1)
もしかして「私(ないしはちゃんと教育を受けた人)が対応すれば『通常すぐに解消する軽微な問題』」だったりして.
よくシステム設計で出てくる「運用で回避」っていう文言は, 回避できる人が運用することが前提だってことを忘れちゃいがちなんですよね.
Re:ほんとかなぁ (スコア:1)
それゆえ、考慮されていない問題とはすなわち、通常すぐに解消する軽微な問題なのです。
1を聞いて0を知れ!
プログラムミス? (スコア:2, すばらしい洞察)
Re:プログラムミス? (スコア:4, すばらしい洞察)
そういうのは設計ミスっていうんじゃない??
Re:プログラムミス? (スコア:2, おもしろおかしい)
実際問題、ヒアリングの失敗とか、設計ミスとかが大障害の原因なのに、なんでもかんでもコーダーのプログラムミスとする風潮はなんたるものか
プログラミングミスなんて、優秀なコンパイラが、弾くよ!
弾くよ!
Re:プログラムミス? (スコア:1)
◆IZUMI162i6 [mailto]
Re:プログラムミス? (スコア:1)
ただ、だからこそいい加減なSIがあふれているんですよね。
頼む方の目が節穴ならそれに合わせた環境が構築されるのは当然で・・。
◆IZUMI162i6 [mailto]
プログラムの 40% はエラー処理 (スコア:2, 興味深い)
って話が昔読んだ本に出ていた。
それ以来、関数/手続き呼び出しで、エラー状態がチェックできるものは 全てチェックする事にしている。
そんな話じゃないの?
イマドキは処理速度が足りないなんて話はそう無いと思うし、プログラムは ロバスト側に最大限に振る位で良いのではないかな。
確かあれは Eiffel の本 [fukkan.com]だったと思う。 第 2 版が出ているが、あの厚さに負けて未読。
Re:プログラムの 40% はエラー処理 (スコア:2, 参考になる)
「為すべき処理が行える状態にあるかどうかをチェックする処理」だったりするのもよくある話で。
Re: (スコア:0)
すべてのアクセス(含メモリ)でエラー処理を行う事に。
ハードもOSも自らの処理も疑う
qmail並みに疑心暗鬼なものになる?
現実的な落とし所は難しい
Re: (スコア:0)
小心者の私は最大限にロバストにふるなんてそうそう簡単には言えません。
Re: (スコア:0)
フレーム問題というか,
要求/開発側ともになにが正しいのかを定義してないんじゃないかな?
あらゆる問題をチェックするのはそもそも何が問題かが はっきりしてないと出来ないし.
Re: (スコア:0)
ヤブ蛇の極地ですな
Re:プログラムの 40% はエラー処理 ==(追記させてもらいます)何が正しく 何が問題か。 (スコア:0)
ハード屋さんは、プログラムを処理結果で理解しようとする。
その結果、今回のような状況が発生したようにも思うのですが、
今回の設備のシステム設計・開発に携わった諸氏の中に、一人でも、この不具合を成るべくしてなったと考えておられる方がいる事を信じています。
それにしても、
制御設備では、CPU制御が当たり前になっている中で、99.9%の稼動をCPU制御で保障するって不可能なんだろうか?
今回のようなCPU制御での構成部品がトラぶった時にも確実に稼動継続できる設備なんて。
Re: (スコア:0)
なんでそんなところにHDD積んでる機器が? (スコア:1)
Re:なんでそんなところにHDD積んでる機器が? (スコア:2, 参考になる)
# 信号/ポイントを集中制御して列車の運行を管理する(JR東の場合には駅や拠点毎で管轄を分散して処理しているんだったかな?)装置が
# 各所の制御室(今回の場合は、東京新幹線車両センター内でしょう)にあるんですが、その制御室の自動進路制御装置のHDDが不調を来したんだと思いますよ。
困った・・・ (スコア:0)
またドキュメントとレビューの要求が一段と厳しくなるかと思うとやりきれません。
当然のごとく人と期間は増えません。
# 微妙に影響しそうなのでAC