【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/ なんだなんだ？範囲限定極小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の感想
検出しきれずチェックツールがウソ返しやがる
正常に読み書き出来てるようで出来てない壊れ方する >>200
無い
インテルだろうがサムスンだろうがマイクロンだろうがどこでも起きた
チェックツール上では正常だと返してくるのに
なんで動かないか悩んで交換したら直るのが何度かあった
修理対応時は交換用SSD持っていくのが必須 フラッシュの書き込み(実際は消去)の深さが閾値近くに落ちちゃってるんじゃない？
そうなると読みこみの値はランダムになるけど
アクセスパターン依存もあるかも たまにしか起きないものが同時には起こるのは別の理由が必ずある
同時に2つの地震があったとか言いうのもそうだ >>196
いやー、ストレージ業界とか、最近は狭い業務分担が流行りだけども、
私は、そういうのは気にしないし、どうしても作ってくれと言われるものしか作らないんだよ
そして、大規模な仕事が多いのでね
ろくなＤＢも使えないような、利益が出ない案件には興味がないんだよ
金がないならアキラメロン
業界が糞なら転職するかフリーになれ
どんな箇所でも手を入れていいし、予算も潤沢にある、どこかのSierに２回依頼したけども完成しなかった、というのはいい仕事になる >>199
インテルのデータセンター用のでもそうなの？
何千回も強制電源断しても壊れなかったから、信用してたんだが
ちょっと詳しく教えてくれないかい
修理専門の人の話なら信じられるから >>202
フラッシュは劣化するわけだけども、常にコントローラーがチェックしてるし、劣化も温度等の物理特性で傾向があるから
それを十分に考慮した耐久性と残りの稼働可能時間がわかる仕組み
ギリギリの状況で使って、読めなかった、などはしないんだよ、普通は
データセンター用じゃないものを、強制電源断したら、もちろん高負荷中に、だいたいこわれる
何回かやるとね なんとかＰＲＯみたいなものもダメ
そうじゃなく、データセンター用のが壊れるかどうかはとても興味がある 三菱のATM
手 認証 ２０回ぐらいやって認証する 同一ロットで、同じような使われ方してたら死期は似てくるらしいよ。 >>212
読めなくなったから、サルベージしてファイル回収したい、ようなのはあるよ
raid-zが壊れてサルベージする話は見たな
その時に、故障状況見れるって話でしょ
ファクトリーコマンドとか使って >>210
いやいや俺半導体専門だけど
もともと不良セルだったら予想外の故障しても何も不思議はないよ
それはフラッシュに限らずどんな半導体セルにも言えることだけど
ただフラッシュはロジックなんかと比べて閾値のレベルがシビアだから
突然中間に落ちて読めなくなったたとかよく聞く話
コントローラなんて所詮ロジックでフラッシュセルの状態なんてモニタしてないでしょ
つまり半導体はあなたの言う普通はないという壊れ方をよくするし
フラッシュはその点特に繊細だということ 半導体がやっかいなのはある時故障してても
負荷をかけてやると復活しちゃうものがあったりと
とにかく不安定な状態の故障モードが多数あること
実際何が起こってるかなんて切ってみないと分からんw >>215
プロセスやってるの？ それとも物性？
フラッシュは容量増やすためにかなり無理なことをしてるけど、結局エラー訂正で直すしかないよね。
単セルの信頼性など求められてなくて、もちろん多値を盛り込んだりで、エラーありきで、検出して直すじゃない。
大昔のEEPROMじゃないわけだし。
それで、いろんなパラメーターからフローティングゲート周りの状況が解明できて、寿命予測が当たるようになってきたって話だと思ったけども。
私は半導体専門でもないし、現在フラッシュのセルの設計をしているわけでもないけどもね。
まあ、基本は理解してるし、いろんなことをやったから、半導体がどう動いて、どう壊れて、何を何が担保しているのかは押さえているよ。
いくつか作らせてももらえたしね。
もし詳しいなら、コントローラーの訂正と寿命予測について書いてくれないか。
いろんなコントローラーがあるが、各社独自でね。謎な所が多いんだよね。
突然変な壊れ方をする、だけじゃあ、そりゃあらゆる物が予想外に壊れることもあるだろうさ、って一般論と変わらない。
フラッシュに限らずHDDもだけど、エラー訂正ありきで容量を稼いでる時代が長くなったね。
HDDのスクラブどうのって言ってた人がいたけども、フラッシュはコントローラーが勝手にスクラブして、勝手に直すんだよね。
だから、電源が入って無いと、どんどん壊れる。時間経過でも壊れるし、アクセスしても壊れるし、隣接の線をいじっても壊れるし、
ありとあらゆる操作がダメージを与えるし、スクラブしなきゃ話にならないしでね。
各社コントローラーに腐心してるが、それゆえに、情報が少ないんだよ。 >>216
まあ、そういうデータを多数集めて、コントローラーに反映しているんだろうなー、と思って、
インテルのデータセンター用のは信用することにしたんだよ。
とある膜がどのくらい劣化して、どのくらいいらない電子が滞留しているかなんてのは、各社の秘中の秘だろう？
テスト用にいろんなパラメーターを変えて、実験して、解析して、最後は断面見てとかやっても、
量産でマスクはズレるし、だいたい動いたら売らなきゃいけないしで、いちいち一品物を作るわけにもいかないから、
結局、ものすごく沢山あるセルを確率的に壊れるものとして、大雑把に数学的に、これくらいの訂正でいいかな、とやって、
ユーザーに長時間使わせて、合ってた、合ってなかった、とやるしかないんじゃないの。 ああ、あとね
HDDのロットどうのこうの言ってる人が多いけど、そういう人に聞きたいのは、
SDDでもロット分ける？
メインメモリーでもロット分ける？
CPUやマザーボードもロット分ける？
LANケーブルや電源もロット分ける？
言いたいことわかるよね
DRAMはペアで使うから、同一ロット品が安心
このロットのCPUはクロック耐性が高いから云々
で、HDDケーブルがビローンって垂れていたりする
短くしろよ
シールドしろよ
電源に気を使えよ
いろいろ面倒なら、製造業を信用しろよ（確率的に）
大昔は、複数のHDDを並べて密集させる場合には、円盤の回転を同期させてたんだよね
そういう同期用の端子があったから
HDDを密集させて同じ金属板に固定する意味を理解している人がどこまでいるのか知らないけどもさ >>197
ゴミクズIBMだと10の選択肢がねーんだわ 半導体の話だけど上で解説されてることは全くその通りで
壊れるの前提でエラー訂正するしコントローラも設計する
俺が言いたかったのは製造欠陥の話でもともと不良セルだったものが
ある程度動いてたけど負荷によって突然中間値に落ちたりしたんじゃってだけのこと
あらゆるものが予想外に壊れるってのはその通りだけど
半導体が面白いのはフラッシュの場合広い閾値のレンジと
あまりにも多すぎる故障モードだと思う
それゆえ壊れてるのに正しく動いているように見えるなんてのはよくある
特に特定の手順で操作したときだけ故障が顕在化するなんてこともある
だからチェックツールでパスしても実際は壊れてるなんてのは
半導体の世界では当たり前すぎる話でしょってことだけが言いたかった
チェックツールにウソと言われてもねえ…
これ以上はスレ違いかな これは5台でRaid0を組んで3グループでRaid1にしてた感じ？
そして2グループ死んでるのに気づかずにそのまま運用してたとか？ >>69
プロは大変だな
オレのはポエムばかりだから消えたら脳内再生するさとたかｗ >>221
ほー、面白いな。フラッシュ。
HDDの場合だけど、壊れてるセクターがあって、何度も何度も、例えば１０回読むと、エラー訂正できたりする。
微妙に磁石が狂ってて、不安定なのが、０か１かどっちかに転んだタイミングで、セクターが読め、予備に転送できる。
なので、しくこく読み続けてたら、１００セクターくらい回収できた。
フラッシュでも、同じこと出来るだろうね。
やっぱり心配なので、最終的には多重化するけども、根本的な仕組みには興味あるわ。 >>223
個人用の大量のデータを思い切って捨てたら、すっきりした。
ミニマリスト最高だよ ■ このスレッドは過去ログ倉庫に格納されています
