【IT】三菱UFJニコスのシステム障害の原因が判明、3個のHDDが同時に故障
■ このスレッドは過去ログ倉庫に格納されています
三菱UFJニコスは2018年2月7日、2017年末に発生したシステム障害の原因や影響範囲などについて発表した。同社のクレジットカード「NICOSカード」の基幹システムで、ハードディスク（HDD）が3個故障したのが原因だ。2018年1月末時点で一部の会員に対する請求が遅れているなど、事態を収束しきれていない。
マスターデータから中間加工ファイルを作成するバッチ処理のシステムでHDDが故障し、障害が発生した。三菱UFJニコスによれば、HDD15個で一連の機能を果たしており、そのうち3個が同時に故障した。「2個までの同時障害は自動復旧可能な仕組みを設けていたが、3個の故障は想定外だった」（広報）。同社はシステムやHDDの開発企業を明らかにしていないものの、「発生確率は極めて低いとの報告を受けている」という。
故障したHDDは、障害が発生した2017年12月26日中に交換したが、利用会員の売上データ処理などに遅れが発生した。一部の利用会員に2重請求が発生したほか、請求が遅れるなどの事態につながった。同社はシステム機器の監視体制を強化するなどして対策を講じるという。
http://itpro.nikkeibp.co.jp/atcl/news/17/020803126/ ストレージのロットを分けるとか基本的なことすらしないのかよ これは、巨額の引き落としを阻止するための、テロかもしれない。
内部犯行あるで 三基同時トラブルってどういう天文学的数字だよ
負荷が半端なかったのかな
実はリビルト失敗だったりして 自動復旧か2台同時までって言い方ならデータ自体の破損はしてないのかな。
データか失われて復旧できなくなるまで壊れるにはもう1、2台余力あるんじゃね？
ってpdfよくみたらデータの一部が毀損したって書いてあったわ。 保守用として大昔のHDDがいまだに・・・
とか有るからMaxtorだなｗ >>68
ただの三重書きじゃ同時に3台壊れるとデータが飛ぶのだが HDDが同時に3個壊れる確率より共通部分の不良の確率が高いよね。
電源とかRAIDコントローラーあたりも交換しないと同じトラブルが
起きそう。 SEAGATEかな？
ここのはタイマーが付いてるかのように狙った時期に壊れる
RAID組んだらおおよそ全滅する ３個とも同じメーカー同じ品種のHDDを使っていたという落ちじゃね？ >>5
同じラインで製造されたものはだいたい同じ時期に逝くんだよね。
まぁSamsungかseagateだわな。 ただ監視してる君は悪くないよ設計構築した奴らが悪い
だから糞みたいな仕事させられてる監視要員は気に病むな 素人 多すぎﾜﾛｽ
レスしてる奴の95%くらい的外れだよ。 2001年ごろウェスタンデジタルがやらかしてデータセンターがひどいことになってたわ たぶん、この会社もシステム構築時の現場担当者は判っていたと思われ
ても、上がバカだとこういう事になる
システム担当重役が名前だけで権限がないとか、素人同然でコスト重視だと、
安全設計にまでコスト節減するんだよね いまどきのストレージってどういうハードウェア構成なのかな
昔で言う ultra enterprise 450 + Solaris + ZFS みたいな？
raid6(raidz2) + hotspare でリカバリ中に死んだんか >>109
そうだね、ただの３重書きじゃね
普通のサイズというのも変だが、何十、何百とＨＤＤを使うよね、１０００台もあるだろうね
それらに分散させるんだよ 細かいブロックというかパーティションというかで、
もちろんデータセンターは物理的に離れた、隣町にでも別の建物を用意し、電源なども全部別々。
容量に空きがあれば、４重にすればいいし、全体の容量が足りなければＨＤＤを増やせばいい
正確に３重ではなく、常に最低３重にしておくわけ
ＨＤＤが１台死んだ瞬間に、その死んだＨＤＤを例えば８ＴＢだかを再現するのではなく、どこかのＨＤＤに分散されてデータが３つある状態にすればいい
８ＴＢをホットスペアで再現しようと負荷かけたら、ベリファイしていない死んでるセクターがあって、そこで２台目の故障、
つまり本来は１台壊れていて、２台目のリビルド時にやっと気が付くってのがRAID6の最悪な所
そして、今回のように２個壊れている状況でリビルドに失敗すると、飛ぶ
これが結構あるんだよな
２個までは大丈夫な設計なのに死んだ、同時に３台壊れたからだってのは、実はこういう仕組み
何十、何百というＨＤＤのどこかに物理的に同じではないＨＤＤに３重のデータが格納されていて、余っているどこかに、
生き残った２個、あるいは１個でもいい、のデータを負荷をかけずに配置する、のが今のやり方
何十・何百とあるＨＤＤのうち１個や２個死んでも全体の負荷、つまりリビルドの負荷は増えないし、
ＨＤＤを１本丸ごと再現するために残りのＨＤＤ全てを高負荷にして、通常処理が重くなるのも愚かなやり方
そしてなにより、RAID6じゃ、別の建屋に分散収容できないね
そのラックが死んだら終わりじゃんか
旧時代的すぎるよ
１０００台も使ってたら、毎日何個かは死ぬんだから、そのたびにリビルド負荷高かったら、やってられない
１０００台のうち特定の３台が完全に同時に死ぬなんてことはあり得ない確率だし、心配なら４重にすればいい
書くの面倒なので、今時の分散ファイルシステムで検索しておくれ >>118
それな、ほんとかウソか知らんが
大量のラックが並んでいるような所は厳重にカギがかかっているし、そもそも掃除する必要が無いんだよね
ガンガン空調が回ってるから、ほこりとかは空調に全部行っちゃう
入れるのは何個かのドアを通過できる訓練された要員だけだよ
空調のメンテにしても、妙なことにならないか見てるし
寒いしうるさいし、特別な用事が無い限り入りたいとも思わないんじゃないの なんだなんだ？範囲限定極小EMPにでも
やられたんか？ 同じロットは購入しないのはデータ保守の鉄則だろww
そんな事も知らないのか? 今のガキは >>81
保守がショボい場合どこの保守に責任があるかって話もあるからなあ
・保守監視設計が悪い→担当したベンダが悪い
・保守運用が無視してた→担当した会社（発注元のシステム部門or保守担当ベンダ）が悪い
・検出後の対応を怠った→担当した会社（発注元のシステム部門or保守担当ベンダ）が悪い バックアップ取ってるだろ。普通は翌日には復旧できるよ。 HDD3台死んだだけで業務が止まるとか職務怠慢だろ。企業としてアウト。 2個同時に壊れるとかよく聞くので、3個壊れても別に不思議じゃない。 なんか日本って想定してなかったとか言い訳する馬鹿ばっかだな
壊れる前に定期的にメンテ期間作って取り替えとけばいいだけだろ >>129
金払うから保守よろしくって言って、全部他人任せにした発注者が悪いね
どのように保守したのかのチェックさえ丸投げだったんだろう
ベンダーが何を設計して、何を担保してくれるのかさえ分かってないケースだな
下の者は各人の領域で完璧に仕事をしたし、仕様通りに完全な仕事をしたので、隕石が頭にぶつかるような確率の不幸でしたねってなだめてる最中じゃないの
RAID6はダメだから、RAID7にしましょう、とか誰かプレゼン資料作ってるんじゃないの
某大手金融業に見る失敗事例
５では当然ダメ、６でもダメ、これからは我が社の７を
→ 故障確率１０００年に一度、これで安心 パチパチ いわゆる｢稀によくある｣ってやつだな
自転車で他の人は何もないのに、俺だけ普通の道路で数キロおきに四回連続パンクしたことある >>21
海門は故障じゃなくて設計から不良だったしな >>36
RAID10でデータの保証ができるのは1台故障までだよ
2台以上だと無事なケースとそうでないケースが出てくる >>135
監視設計しても監視した結果出てきたアラームが報告されて来なくて、サービス影響が出る障害に繋がってから連絡来たときはお前ら真面目に仕事しろよと思ったわ…
障害起きたことについてはそりゃ謝罪するけど今後もその杜撰な予兆監視のやり方だと保守がろくに回るわけないっつーの 天下のUFJ様のクレジットカードがHDD３個逝っただけで業務停止
NICOSカードなんてマイナーなカードは控えるべきだな >>141
まあ真っ先に想像されるのはそれだよねw 電源をHDD毎に独立させろよ
電源が死ねばそれに繋がっているHDDは一緒に死ぬぞ >HDD15個で一連の機能を果たしており、そのうち3個が同時に故障した。
SeaGateなんか使うから・・・ これHDDの故障じゃなくてシステムのバグが原因で一部のデータが破壊されたとかだったりして >>5
経験上、このような壊れ方はRAIDコントローラかバックプレーンの不具合の場合が多い。
あとはレアケースでHDDが同じロットで、そのロットごと不具合があった場合ぐらいか。 故障確率が低くても、それがいつ発生するかまでは把握できて
ないのが痛いね。 初期故障が無ければ、あとは時間経過とともに
故障確率は上がって行くと思うけど、それの変化カーブを元に
ＨＤＤを定期交換するとシステム停止は回避できると思うよ。 2個故障したのに気付かず、ついに3代目も故障したのでは？ どこかにSPFがあるんだろう。アホが設計するとありがちだ。 中間ファイル用だからと思って適当にやってたら、思ったよりクリティカルだったと raidって障害出たときにサービスしたままリカバリ入るから、別のHDDにまで負荷かかって連鎖的に逝くこと多すぎだよね。 ＨＤＤの起源は
ゴキブリ韓国（ゴキ韓）
ニダ！<*｀∀´> RAIDが死ぬのはよくある話
そのためのバックアップなんだけどね SSDはもっと厄介だぞ
壊れてないようで壊れてたりする奇妙な挙動起こす
システムからのチェックでは検出出来ないパターンがある 今時分、朝一冷えきったのを起動するのって
ドキドキだね！ 状況が理解できないがニコスともあろうものがたった１５台のHDDで業務を回してたってことか？ >>30
それを言うなら探究心
実務かかってるのに研究心はないわ HDDの話でなくて申し訳ないけど、サーバーのメモリーが起動してから日が経つにつれて、使用量が増えていくけど何でなの？ >>124
悪意を持ったおばちゃんを想定していない
やり直し >>166
メモリリークしてるんだろ
あとはメモリの確認法によるがlinuxならファイルキャッシュに空きメモリ使えるだけ使うからsarとかで単純に見ると増え続けるように見えるよ >>144
HDD毎に別電源ユニットってことはさすがにないけど、電源系統は多重化されているのが普通
電源にユニットが1台壊れても各HDDへの給電は続くよ 同時に3台故障した可能性よりも気づかない間に2台壊れていて3台目の故障がトドメになった可能性の方が高いと思うわ
普段あまりアクセスされないセクタがいつの間にか壊れていて
リビルドの際にセクタ不良が顕在化したとか >>158
今回のがそれなら「同時に」とは書かないと思う
コントローラが派手に逝ったか、もしくは監視漏れの馬鹿障害だな。 >>146
ＨＤＤ１５個だと１か月に１回くらいリビルドが走ったよ
ちなみにそこに付けたのは箱買いしたＷＤ
１６台接続のRAID6で、ホットスペア１個、稼働するの１５個
どこもご家庭にもあるこのRAIDゆにっとが・・・
みたいなしょぼい感じ
録画ＮＡＳ作ってる個人と変わらないレベルだよなあ
せめてデータセンター用のＳＳＤにしろと >>148
RAIDカードのファームウエアを変更する時の恐怖
バージョン履歴に、安定性の向上とか書いてあったら、もうね >>162
それどこの？
こっちの経験則だと、ＳＳＤの寿命予測と実際の寿命があまり変わらず、ＳＳＤは凄いなと思ったんだけども
ＳＳＤの電源を入れている限り、ファームが自動的に壊れてる箇所が無いか検査して、スペア領域を消費してる印象だったけどな >>167
全角を要求されるケースがあって、もちろん相手は文系だ、
更に、文字が小さい、めっちゃ小さくなるモニター入れてから全角も悪くないなと思った >>173
詳しく説明したところで理解されないから適当に広報しとこうくらいのなんちゃって広報の感触がある >>179
中の人もちゃんと理解してるか怪しいような >>105
リビルド失敗の典型例。
勘定系でここまでしょぼいのは業務改善命令出ても仕方ない。2時間ルール違反。 >>178
全半角バラバラだからその言い訳は通らない >>122
> ８ＴＢをホットスペアで再現しようと負荷かけたら、ベリファイしていない死んでるセクターがあって、そこで２台目の故障、
> つまり本来は１台壊れていて、２台目のリビルド時にやっと気が付くってのがRAID6の最悪な所
これはない。 通常の Hardware RAID ならそれを回避するのも含めてスクラブかかるから。
スクラブは定期的に HDD なめて、単体HDDでのECCによるエラー訂正や、それでダメなら
RAIDのパリティでのチャンク単位のエラー訂正する処理な。
寧ろ問題なのは RAID-5 や 6 を使うのにバッテリ付きキャッシュ搭載の RAID カード使わない場合。
なぜ RAID-Z が作られたかを勉強するべき。
君の言う障害が発生した要因はバッテリがヘタってるか RAID カード壊れているかであって RAID-6
の問題ではない。
あと、えらく分散ファイルシステムを持ち上げてくれちゃってるが、HDFSやハイパーコンバージドシステム
が速いのは大して更新がすくないディスクに対してのみ。
だからWeb検索とかのビッグデータや仮想マシンのＯＳ側ディスクだけにしか使えない。
トランザクショナルＤＢを分散ファイルシステムに置いてしまうと応答速度面で致命的に遅くなる。
やるにしてもトランザクションログをレプリケーション先にリアルタイムで同期するぐらいだ。
RAID10 や RAID6、RAID60、Luster系分散ファイルシステム、クラウド向けの分散ファイル
システム、ビッグデータ系分散ファイルシステムそれぞれ何が長所で何が短所か、何が得意
なのかを勉強してくれ。 >>185
定期スクラブはもちろん毎日や毎週行うべきだけども、容量を全てスキャンするにはかなりの時間と負荷がかかる
そして、この際にアラートが出ても、１個だから平気などと運用される事例は見る。
どうせ自動的に修復されると信じてしまっている運用はあり得る。
２日連続、あるいは２回連続でアラートが出たら、真剣に交換しよう等とね
運用中にスクラブをするということは、ＨＤＤのヘッドを激しく移動させることになる
最近の大容量ＨＤＤはヘッドの平均移動距離が短いから、もしヘッドが大移動を繰り返した結果、
プラッターに傷がつくと、そこからカスが生じ、すぐにダメになる
なので、スクラブ中に他の所が壊れるメカニズムはある
RAID-5 や 6 を使うのにバッテリ付きキャッシュ搭載の RAID カード使わない、というのは私には想像できない。
もし、バッテリーに問題が生じるような設計をしたならば、設計欠陥を指摘され、致命的なミスと叩かれるだろう。
RAID-Zについては使っているし、その利点も欠点も、長期の運用での状況もある程度押さえているが、
安全に使える環境の問題から、避ける人もいる。
分散ファイルシステムを使うのはとても高速な専用の線を用いて、高速なSSDを使うことが前提として要求されるのは言うまでもない。
性能が足りなければ、どこかで工夫をしなければならない。
ネットワーク越しの書き込みに対しＨＤＤの回転を待つことがいかに長いかを考えるのは前提。
ＤＢはＤＢそのもので分散機能を持っているものがあるだろう？
それをまず検討すべきで、ファイルシステムに全てをゆだねるなどはしない
まあ、どの程度の費用をかけ、どの程度の信頼性を得るか、そして、その流れの方向は押さえておいたほうがいいだろう
例え、今現在、性能が足りないとしても
だいたいのケースにおいて性能が問題になる場合には、根本的にＤＢの設計が腐ってる場合が多いね
妥協に妥協を加えて、これくらいはいいだろう等と、手を抜いた結果が階層的に積みあがると、腐ってくる
ＤＢが本質的に何をして、どのような処理が行われるのかを理解せずに、ＳＱＬを投げたり、
安易にＤＢの最適化機能に頼ろうとすると、ものすごく遅くなる
そもそも、ＤＢに何を入れるべきかが真剣に検討されていないものが多いからね
言われるまでもないことだろうが・・・あなたにとっては SeagateとSamsung
買った後にフォームウェアのバクとか知った後の絶望感 普通は複数の物理サーバで仮想化してるから
HDDが同時に3個壊れようがRAIDカードに不具合があろうが問題にならない
これだけのシステムを素人が設計・運用するとも思えないので
コストをケチって敢えて脆弱な構成にしたか
コストをケチって敢えてHDD障害を放置する運用体制にしたとしか考えられない
まあ無能な経営者揃いの三菱らしくていいんじゃない?w 重要なシステムは、ホットスワップ付きRAID5ストレージを２台ミラーリングするもんだ
また、メインストレージが飛んでも、バックアップデータとログから再実行して復元できるようにしとくもんだ >>1
今の企業ってどこも 壊れるまで使うっていうのが糞みたいな当たり前の話だからな
だから絶対に障害は生じるわけだよ 壊れなくても定期交換するのがリスク回避
そういう極当たりまえの経営判断をできないのが 日本の企業経営者 事案が発生しようが
責任はぜーぶん現場のせいにする 見てみなよ 神戸製鋼 東芝 日産 スバル 三菱マテリアル 全部そうだろｗ 昔IBM製のHDDが立て続けに2台逝った事のある身としてはよく分かる >>191
ＲＡＩＤ５やホットスワップは気休め。
万能じゃない。
このスレに「ＲＡＩＤにしとけよ」とか言っている人がたくさんいるが、
ファイルサーバー程度しか作ったことがない人なのだろう。
ＲＡＩＤにより、データ損失はないかもしれないが、パリティからの
データ自動回復で一気にシステムが遅滞する。
ファイルサーバーや静的なコンテンツ参照のWebサイトなら
それでもなんとかなる。
だけど、オンライントランザクションシステムやバッチ処理システムだと、
自動回復が始まったとたんに急速にレスポンスが低下する。
さらに、パリティからデータ自動回復をやりながらシステムを動かすと、
回復と処理の負荷で、他のディスクまで壊れるということもたまにある
というのが俺の実経験。
三菱ＵＦＪニコスで起きたのも、そういうことなんだろう。
玉突き事故を、「（ほぼ）同時」と言っているのだと思われる。
オンラインやバッチ系のシステムでは、ＲＡＩＤはさらなるディスク故障を
招く原因になることもある。
それを防ぐには
・機械部品の動作がないオールフラッシュのストレージにする
・そんな金がないなら、パリティからのデータ回復がはじまったら
すみやかにシステムを停止するか、処理を書き込みがない
参照オンリーにシステムの設定を変更する。
ホットスワップはあくまで、即時システムダウンしないための
一時しのぎであると理解し、「ホットスワップがあるから動かし続けよう」
ではなく、まずはシステムを止めることを優先する
と理解すべきだ。 まぁ究極的には運頼みだな。
技術的な事情はほとんど公開されてないのに、バカだの素人だのこき下ろせる人がいるのが不思議だ。
自分んとこのシステムは盤石だと信じられるのは、勝手に自分の責任範囲を線引きしてるか、
それこそバカと素人だけではないだろうか。 >>186
> 定期スクラブはもちろん毎日や毎週行うべきだけども
長文だなーって思ったけど、しょっぱなのここですでにアウトだわ。
> ２日連続、あるいは２回連続でアラートが出たら、
RAID-5 カード使わないのが想像できない人がこんなことは言わない。
> ネットワーク越しの書き込みに対しＨＤＤの回転を待つことがいかに長いかを考えるのは前提。
なんでバッテリ付きなのかわかってないね、君は。
あと処理には同期書き込みと非同期書き込みがある事を全く考慮していないな。
> ＤＢはＤＢそのもので分散機能を持っているものがあるだろう？
予算という物があってだね、全てのプロジェクトで Oracle Exadata が使えるわけじゃないんだよ。
ストレージ業界で生きてないなら知ったかやめてくれ、ほんとに。 >>191
業務用途の場合は RAID6 か RAID60、RAID6だと物足りないという客向けにここ最近で
トリプルパリティが出てきた。 RAID51 なんてやってる/客に薦めるところなんて聞いたことが無いな。
どこの何て言う製品を使ってるんだ？
やるにしても製品固有の機能での別筐体／別拠点への非リアルタイム系同期で RAID51相当／
RAID61相当にするぐらいだわ。
あと、ログから再実行ってトランザクショナルＤＢのロールフォワードの事を言っているんだと思うが、
データベースの時点で RAID10 一択で RAID5,6 はあり得んよ。 >>191
ミラーリング＋３ndがよいとされていね
RAIDカードがやられたときにも対処できるように
ソフトRAIDも併用するとか >>177
何台も扱った修理専門のCEの感想
検出しきれずチェックツールがウソ返しやがる
正常に読み書き出来てるようで出来てない壊れ方する ■ このスレッドは過去ログ倉庫に格納されています
