【東証トラブル】富士通「メモリー障害時に冗長化が機能しないようファームウエアを設定してた」
■ このスレッドは過去ログ倉庫に格納されています
東京証券取引所で2020年10月1日に起きたシステム障害の全容が徐々に見えてきた。障害の原因は、富士通が納入したNAS（Network Attached Storage）のファームウエアの設定不備にあった。
2台構成のNASでメモリー故障に起因する障害パターンが発⽣した際、NASの冗長化が機能しない設定になっていた。
東証で10月1日に起きたシステム障害は、全銘柄の売買を終日停止するという未曽有の事態を招いた。
東証が取引を全面的にシステム化した1999年以降、システム障害で全銘柄の売買を終日止めたのは初めて。これにより、3兆円規模の売買機会が失われた。
NASのメモリー故障が発端
システム障害の発端は、東証の株式売買システム「arrowhead（アローヘッド）」のNASに搭載したメモリーの故障にあった。
業務サーバーで使うユーザー情報などを格納するNASは2台あり、Active-Active構成で冗長化していた。
このうちの1台のメモリーが故障し、本来なら1台のみの運用に自動で切り替わるはずが、うまくいかなかった。
原因はNASのファームウエアの切り替え用設定値の不備にあった。
東証はarrowheadを2019年11月に刷新する際、事前のテストで2台のNASの死活監視を途絶えさせて、自動で切り替わることを確認していた。
だがその際、今回の設定不備は見抜けなかった。設定作業そのものは富士通が実施していたという。
この記事は有料会員限定です。次ページでログインまたはお申し込みください。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/04693/
https://cdn-xtech.nikkei.com/atcl/nxt/column/18/00001/04693/ph02.jpg ハード障害を想定したテスト項目の抽出漏れ、だよな。
テスト工数貰えなかったのかい？ 冗長化という日本語を何とかしろや
わけわからんわ(´・ω・｀) なるほど、つまり要約すればコンセントに足を引っかけた、と まともな投資家は米国株しか触らんからね
日本株なんてどうでもいい 冗長とは無駄なもの。
機能してしまっては冗長化とはいえない アクティブアクティブなら
1号2号同じ仕事してたのか >>6
あえて無駄を受け入れる
って意味だしそこまで難しいこ言葉か？ >>11 その単語だけではそうとは限らないかな
非同期でもAAはあり得るけど同じとは言えないし、同期AAなら同じと言える >>16
そうは言えない。そんなこと考慮しなくていいから早くプロジェクト進めって東証が要請していた可能性もある >>16 それは確実
つうか自社の同システム環境で納期に間に合わない試験は逐次やるべきだった
どうせかなりボッタな保守組んでるはずなのに1日はさすがに叩かれてもしょうがない >>8
掃除のおばちゃんの不注意か、それじゃしょうがないな 片方死んでもええように2つ動かしてたのに片方死んだだけで止まったとかギャグやん
NASも今まで何してたんだって思うやろ >>21 古い契約でも1年以内の納品物だしその言い訳は通用しないだろｗ
瑕疵を逃げる事はできんよ >>26
普通冗長化試験だとNICのリンクダウンやプロセス断の切り替わり位しかテストせんからな
メモリは流石にECCだろうし1箇所潰れても動き続けるやろ程度だったんじゃね？
むしろ両activeという恐ろしい事態は避けたいだろうし サーバを二重化させたシステムって、こういう故障はだいたい切り替わらないよね。
死活監視をnicだけでやってると、本当に切り替わらない。 >>26 まぁ理想ではそうなんだけど物理冗長は成功例が少ないからね
仮想冗長がようやく絵になって来たけど、物理冗長は「論理的には・・・」だよ
クリティカルな運用なら実機だ！ って人多いからね 鯖管「ようやく俺たちの必要性が認知される時が来たか……」
これからは肉眼で異常を監視するのが鉄板になる active-active構成だったの?
話がつながらないけど >>29 メモリエラーで片方誤情報でAAとか怖くてしょうがないよねｗ
2台冗長＋チェックサム専用の3台体制かと思ってた
中途半端に冗長化しても今回の様なメモリ不整合で動作されて停止遅れも困るし
フェイルオーバー運用って本当にシステム屋泣かせだよね
といっても、ボッタクリ監視でも良いので両方のNASのモニタリングして付き合わせれば
いいだけだとは思うけど・・・（人がやるか機械にやらせるかはあるけど >>33
最初の会見の時点でうまく切り替わらなかったので故障したほうのdisk装置を手動で切り離したって言ってたじゃん
active-activeなら整合してる 設定ミスではないと思う
そもそものテスト仕様の漏れ
テストの項目にメモリ障害があって切り替わるかどうかのテストをしていないだけ >>30
そりゃあ切り替わらない事例しか報道されないからな
無事に切り替わってるシステムについてはそもそも語られない >>40
「メモリ障害が発生したらハードからこういうアラートが上がるからそれを擬似して試験する」が関の山だろうなあ 任意のタイミングでメモリを故障させられるゴッドハンドしかそんなテスト無理や 要するにバックアップシステムが働かない設定にしてたんだろ。
バカやん。売買機会失った株主に弁償しろ。 >>39
富士通はテストがうまくいくようにテスト項目を設定する会社なので >>41 いやいやｗ たんにエラーが起きないだけだよｗ >>39
テストをやらなかったからバグを見つけられませんでしたって言うSEはレベルが低い 正直に足引っ掛けてコンセント抜いちゃったって言っちゃいなよ >>49 つっても、SEがNASを設計するわけじゃなく
NAS屋が 冗長性をアピール したのを信じて選定してるだけだからな
んで、NASの内部メモリの故障なんて現象を作り出せるかはNAS屋に依頼するしかないが
たぶんそんなエラー（偽トラブル）は頼んでも無理だと思う
ただ、確かに導入した製品を信用せずに他社NASも使った試験やそもそも異機種NASでの
冗長化にしたほうがよかったのかもしれんが そんなのはベテランのSEでも無理だろうね
こういう不具合に有って初めて「再発防止対策」としてそういう案がでてくる感じ
だからもしもNASメモリのエラーなら、エスパーSE でもない限り予見は不可能だよｗ >>42
そっかー
やっぱsnmpなりログ監視なりで気づくしかなさそうだけど今回はそれじゃ拾えなかったんかね 冗長ってのは本来無駄があるって意味だから、これは真の意味での冗長化で間違い無いよ。 >>51
そのNAS屋が富士通
まあ東証システム構築部隊とは違う
ストレージ販売部隊なんだろうけども
これ初期設定から誤ってたということだから
全エターナス製品に波及するねえ >>54 SEの話と富士通の話をごっちゃにするなよ
自社マークのついてるハードの仕様なんてSEが感知するわけがないぐらい判るだろ・・・ 原因を追求するの面倒だから設定間違えましたというオチだろ 大規模導入プロジェクトはユーザーと逐一意識あわせする
基本設計や詳細設計は全部ユーザーの承認を受ける
冗長設計も冗長試験手順も全部承認されてたら富士通だけの責任ではない
とはいえ日本文化的に富士通が謝るのが美しい幕引き そうかな？意図的に日本で売買させたくなかった勢力がいたとは考えられないだろうか？ >>62
ユーザー(受注元)の承認は逐一受けるけども
ユーザー自身が>>1を見抜けないような程度のザルチェックしかしないからねえ
責任は東証にもあるが、まあ突っ込まれないだろう >>62
外資系だとその辺をガチでやり合っちゃうんだよなｗ 認知症の新しい呼び名かと思った
メモリー障害児
認知症は「児」じゃないだろ、と思って気付いた 下請技術者の低レベル化が激しくね？
言われなくても忖度してチェックとかするだろ >>71 無理だな
メモリエラーはどのメーカーも検証もチェックもしていないと思うぞ >>71
忖度するデメリットがメリットを大幅に上回ってるのにやるわけないだろ
相応のカネ払えよ 本番環境で切り替えのテストやってなかったの？
そんなマヌケな事ってあるのか 具体的にどういう設定なのか知りたいな
それを見ないとなんとも言えない >>57
デフォルトかどうかでもだいぶ印象変わるよな もしかして民生のサーバ用マザボ・メモリ以下の信頼性なの？ >>35
メルキオール、バルタザール、 カスパールの3台で クリティカルなシステムにNAS使ってんの？
SANじゃなくて？？ わかってるのか！？3兆だぞ3兆！！お前のせいで損失したんだ。土下座のひとつもしたまえ！」 半沢「3兆を取り戻せばいいんですね。もし取り戻す事ができたら今回の件、土下座して詫びてもらいます！ うーん、ハード故障に関する記事ばっかりだなあ。
そんなものは午前中になんとかなってる。
後場向けにシステム再起動できなかった事情の方が大事なんだが。 >>82
ヘッド分けて裏側でSAN動かしてても総称でNASやで >>84
場中の再起動なんて証券会社のシステムが対応できません 共技かインフラがエターナスのopc設定しくっちゃってて、とかかな >>54
NASも富士通だから富士通の責任ではあるんだけどハード作ってる部隊とシステム作ってる部隊はもはや別会社みたいなもんだからなあ
システム開発の是非の話とハードの品質の是非の話はまた別だ >>84
まあ「大事をとって」なんじゃないの
トラブル発生後とにかく復旧を早くと言う顧客よりも「動かして本当に問題がないか明らかにしてから動かせ」という顧客の方が多いよ
「そのために試験やってるんだろ」という意見はもっともではあるが、そもそもその試験をすり抜けてトラブルが発生した時点で
顧客もベンダも疑心暗鬼になるから決断しにくい もっと隅々まで検証済みなのかと思ってたけど
雑なものだな
大企業の製品で値段が高いから良いものだろうというイメージで売ってるだけで >>60
金融基幹系システムをインテグレーションしているベンダーがそれを言ったらおしまいよ
そんな事だから、富士通の勘定系システムが消滅するわけで >>95
ありがと
英語で冗長性をなくす
to eliminate redundancy
ってスパゲッティプログラムを最適化することじゃないのだな白目 これを想定してテストしなければならないという事はそれぞれのハード全てが故障するパターンも検証しないとなぁ >Active-Active構成
なんでしょうこれは。 >>94 データドメインと組んでるDELL系SEでも無理だと思うけど？ SEはコントローラーの抜き差しか電源オンオフぐらいまでなら確認するかもしれないけど、ファームのバグまでは確認できん。 装置単体のフェールオーバーではなくシステム全体のフェールオーバーを考えてないからこうなる >>106 AWSやAzureにも同じこと言ってやれ！
AWSなんてつい最近やぞｗ >>107
AWSに金融の基幹系システムは載せられないね
情報系システムならいいけど >>1
なんでどうして
「うごかなくする設定項目」があるの？
誰が作った項目なの？ 石原さとみ、結婚発表でメモリロスしたんだ。
大物芸能人の時は東証危険日。 実際問題としてメモリ異常を検知して切り替わるシステムって難しくね？ >>113
ECCエラー出たらBIOSが物理的に切り替えはるんとちゃうか？
よーしらんけど 見かけ上マルチで動いてるように見せて、金だけもらうんだよ。
これは設計を依頼する側から言われる。そのもっと上に安心を売るためだ。
実際仕組み的には機能するのだろう。しかし、保証ができない。エラーが起きた瞬間のデータがどうなったのか、検証できない。
一円の狂いも許されないシステムにおいて、事故時の保証もせよと言われりゃ復旧不可能と逃げたくもなる。 >>86
そうそう。
つまり根本的な対策は東証だけではできない。
証券会社など各プレーヤーと協同して対策する必要がある。
なのに東証や富士通の問題ばかり記事が出てるみたいでなあ。 >>83
３兆円って、取引額だろう。
益が出ればいいけど、損が出たら神風で助かったってことになる。
実際、次の日何もなかったように取引を終了。外資もどこも気にしてない。
後進国日本だからそんな影響なし。おまえが脱腸なだけ。 下請けに丸投げした設定マニュアルが間違ってただけだもんね！ 二重化なんか逆に信用できないから三重化の多数決方式でおながいします 中国人ってITリテラシー低いんだな
そもそもの問題点を理解できてないのか PCのBIOS設定全項目を確認してから使ってる人だけが、富士通に石を投げなさい ハードのファームレベルの不具合かよ
こんなのシステム設計する現場SEには分かるわけないし
冗長性も担保されてる前提でテストするからテストでバグ検出ができるはずもない
富士通は同じ製品納入してる取引先全部に頭下げることになるな
こりゃ大変だわ ファームの設定ミスは言い訳で死活監視でPING返す壊れ方を想定してなかっただけだろ
ファームでメモリエラー検知したらシャットダウンするって設定をしてたらカバーできてたってだけで >>129
実際、こうなっていたのかもしれない
［ファームウェアの設定］
L［メモリエラー検出時］
L シャットダウンしますか：いいえ、とんでもない
L 通知しますか：いいえ
L 何もしませんか：はい、放置で NASのエラーなんて、通信のタイムアウトでしか検出出来ないと思うがな。そっからリカバリーできるのかね。 なんでそんな設定があるんだw
なんか噓吐いてるだろw 原因はわかったから今後同じトラブルは起きないし、他の富士通のシステムもチェックされるから安心できると言っていい？ >>1
なんていうか
こんなレベルがIT屋気取ってんのこの国？
これさ、普通のサーバでも、Fに頼みたくないわｗ >>136
それが正解
脆弱なのに何の責任も取らない
実の伴わない無意味なブランドに金を払うことはない 富〇通は出入り禁止にすべき
ていうか、社長以下社員全員切腹しろ ETERNUSのNASでActive-ActiveってことはNetAppか？OEMの。
ただ、設定不備って言ってもそんなの制御出来るパラメータあったかな。。 ファームウエアを設定した理由があるはず、多分メモリ内容が異なるので
切り替えをさせないようにしているのではないかな、それが本当の原因なら
ファームの設定を変更したら更に危険な事になるんじゃないか システムログを監視していないのか、システムログへの出力が無かったのか 仮にNetAppだとしたら、Tintriにしろなんにしろ富士通はとことんOEMに恵まれねえな
というか、Failoverする時にあんなにIO Wait発生するストレージを金融取引のシステムに使うかね？cDOTはLIFを上手いこと制御してやれば7modeの時みたいなIO Waitは無いんだっけか？ SYSLOG吐きまくるので出力のレベル上げていいっすか(´・ω・`) >>148
そうしなよ
でないとSYSLOGでディスクフルになって、なにかが起きる
テストしてないだろうし
何が起きるか知ってる人は経験者だから守秘義務で黙して語らない 富士通に発注する奴は、
電化製品もハイアールとか買ってそう。
値段だけで決めるバカ。
安物買いの銭失い。
自業自得。 >>4
テストはした、だけどテストの想定パターンにはなかった
よくある事だよ
冗長化してても切り替わらないとか、切り替わったけどアプリが動かなくなるなんてことはある >>16
どうかな
その試験で受け入れはのは東証だろ
責任は東証にあって保守範囲でどこまで富士通がサポートしているかだろね ハード部位に対する試験考慮漏れ
そしてそもそもメモリの疑似故障を発生させられるのかって言う話もあるが。
検討したが現実的に出来ないのでテストしないでよし
に倒したか 川崎方面の品質保証部内は責任逃れと
口裏合わせで大変なことになってそう >>156
障害テストまで受入側の責任かよ
クソだな 調べたら過去にこんな記事もあったで。
https://www.publickey1.jp/blog/12/post_208.html
電源障害発生、原因は基盤に塵や埃が付着したこと
日経コンピュータの報道によると、障害が起きたのは館林データセンターで1995年に開設され、主にアウトソーシングサービスを提供するA棟。ここで、館林データセンター全体の7％に相当する範囲で電力供給が途絶えたとのこと。
1台の無停電電源装置（UPS）が故障した際に、予備のUPSへ切り替えるための「出力分岐盤」が正常に機能せず、サーバへ電力を分配する分電盤へ電力供給が絶たれ、その結果サーバへの電力供給も途切れたのが大規模な障害につながったと説明されています。
そしてその原因は、「プリント基板とリレーのすき間に導電性の塵埃が付着したことによって、リレーの誤作動が生じた」と富士通広報。2013年3月までには信頼性を高めた新たな機器を導入するそうです。 >>161
配電盤にネズミやゴキブリが住み着くアレか 同一機種のNASを導入してる全ユーザに対する
ファームアップ巡業が開始されます。
他の基幹系システムで起こったらヤベぇ >>42
例えば海外ルーターのiosならtest crashでメモリの擬似エラーとかもできるけど
日本製品だとこういうところの作り込みは甘いよね >>113
ECCで余裕で検出できる
無論マルチビットエラーなら偶然検知できないビットパターンの化け方をする可能性もあるが
東証がメモリエラーと言ってることからECC検知はきちんとできてたと思われる >>160
当たり前だろ
そのシステム買ってきて自分の資産にしてるんだったらその運用責任は東証だよ
受け入れ試験やって受け入れたんだろ
その受け入れ試験に穴があったってこと >>130
まあECCは普段から太陽フレアとかでシングルビットエラー報告がたまに出るからね。
東証が「いちいちうるさいからオフにしろ」と言った可能性は否定できないが
可能性的には低い。
単にメモリの回復不能エラー発生時にパニックするような作り込みを
富士通のストレージ部門がやってなかっただけかと。 >>146
netappじゃないほうでしょ
netappはこんな間抜けな壊れ方はしないかと >>35
当面マンパワーかけて対応しますってのはつまりそういうことだろ
結局はそこまでの費用を東証が払って維持するかって問題だよ テスト項目不備か、まあ故障のテストは難しいからな。 全然業界違うがCPUの温度トラップを試験しろと言われたときは泣いたな
納品機材のヒートシンク外して加熱再現しろってことかよとw
無理ですとなんとか泣きついて許してもらったが
「温度トラップ出なかったら責任取れよ」と客から
ネチネチ言われる始末。 >>176
トラップの警告温度下げてテストするだけじゃね?50度とかに >>178
単体テストとしてはそれでいいかも知らんがシステムテストとしてはどうだろね
結局は、そこまでやりますか？その費用払いますか？
って話で >>139 設定不備って言ってもそんなの制御出来るパラメータあったかな。。
>>165 マルチビットエラーはパニックリブートかかって切り替わる
恐らくパニック発生時に自動テイクオーバーが実施されない設定
になっていたんだと思われる。あくまでも推測です。
https://library.netapp.com/ecmdocs/ECMP1659142/html/GUID-47D7B568-112B-4C02-A92C-FF671658568E.html
自動テイクオーバーの制御用コマンド
storage failover modify ‑node nodename‑onpanic true
Data ONTAP 8.3
storage failover modify
https://library.netapp.com/ecmdocs/ECMP1610202/html/storage/failover/modify.html
[-onpanic {true|false}] - Takeover on Panic Enabled
This optionally specifies whether the node automatically takes over for its partner node
if the partner node panics. The default setting is true.
Changing this parameter on one node automatically makes the same change on its partner node.
これはオプションで、パートナーノードに障害が発生した場合にノードがパートナーノードを
自動的に引き継ぐかどうかを指定します。デフォルト設定はtrueです。このパラメーターは、
上級特権レベル以上でのみ使用できます。
日本語版？
https://library.netapp.com/ecmdocs/ECMP1659142/html/GUID-AFB3A95A-AB57-4179-94A6-E6740175F310.html
-onpanicパラメータをfalseに設定した場合は、テイクオーバーが実行されません。
そのため、-auto-giveback-after-panicパラメータをtrueに設定しても自動ギブバックは実行されません。
クライアントのアクセスが中断されます。 サーバだったら、蓋開けて通電したままメモリ引っこ抜く的なテストはすることあるけど
ストレージはそんなことできるのかね? >>170 netappじゃないほうでしょ
https://xtech.nikkei.com/atcl/nxt/column/18/00001/04693/
この内容だとNASのようなので中身はnetappのNASと思われる。
富士通のストレージはSANベースのDXシリーズとNASベースのNR1000Fシリースがある。
どちらもETERNUSと呼んでいるのでややこしい。
ETERNUS NR1000F series
https://www.fujitsu.com/jp/products/computing/storage/disk/nas/ >>179
うーん顧客次第ということですな、渋られたらやらないか >>5
こんなデカイ規模でもらえらないわけねーだろ ここの書き込みを見るだけでつくづく富士通のクソ加減が分かるな >>185
保守契約してるからってなんでもやってくれるわけねえだろ
東証のシステムは東証が仕様を切ってるんだろうからその責任はあくまで東証
ベンダーはその仕様に合う製品を納入して東証は受け入れてんだろ
保守の仕様も東証が切ってるだろ HDDやメモリだけはテストしそうなものに。
大事なところはPCとおなじじゃんね。 >>187
その書き込みで富士通は一切使わないと決めたよ
多分君の本心なんだろうから勝手にすれば良い
カネ払う価値なし >>187
こんなクソがこそこそ書き込みをするのが富士通という会社 そんなだったら最初からECCメモリ使わないで
冗長ビットない安いの使えばいいじゃんｗ 東証でこれでは一般企業のシステムなんてどれだけ程度の低い仕事をしてるのか想像もつかんわ
とっととつぶれろ無責任企業富士通 >>187
システム開発して納入したのが富士通だから
設定ミスしてちゃ保守責任以前の問題 >>195
フェイルセーフの設定実動作に至るまで全て受け入れ側がテストしなくてはならないらしいぞw
ひょっとして機器の寿命もかな
それはテストするまでもねーかある意味w 富嶽も似たような故障で、世界の物笑いの種に成るのか。オホホ！
蓮坊砲が炸裂。
弐番じゃ駄目なんですか。Bクラスの弁明。 >>187
東証はITのプロではないのだから、RFI/RFPや要件定義、ユーザービリティの範囲で受け入れテストはするだろうね
ハード障害の責任は、設計から結合テストまでやってるベンダーの責任だよ
ITのプロとして入札して受注してるわけだしね
IBMかどっかでも判例あったと思うけど メモリ障害のテストは再現するのも難しそうだな
ガワ取っ払って稼働中にメモリ引っこ抜くとかしなきゃならんのかな？ 軍事研究疎かにすると、ぶっ壊れ前提での冗長性とか考え無くなるよね 東証のCIOが富士通は機器を納入してるだけだから責任はうちにあるって会見で言ってたのになんで富士通ｶﾞｰやってんの？
東証のCIOより契約内容に詳しいの？ まぁ今回の件で富士通は倒産、担当SEは引っこ抜かれて一生コキ使われる奴隷だろうな。
昇進なんてしないで死ぬまで365日24時間保守責任負わされる。 時々、ものすごく詳しい知識ある人がレスしてるけど、
そろそろ中の人のレスは来ないかしら？ >>202
全部見たけどそんな言い方じゃなかったけどな
このスレはいちいち細かいウソを吐く奴が多いね 新人のころバグ１つでたら３０個見つけろとかアホなこと言われたな >>165
確実にキャッチ出来るのは2bitエラーでそれ以上はキャッチ出来ない場合があると言うか見分けがつかないパターンがある >>199
引っこ抜いたらECCの訂正と割り込みのテストが出来ない
ピンポイントで1bitとか2bit壊してちゃんとキャッチするかテストすんだけど
昔のメモリならテスト下駄が使えたけど今の速いメモリは下駄はかすとそれが原因で不具合が起こるから結構大変なんだよ 故障モードなんて星の数、1,0で壊れてくれると監視し易いんだけど。 >>180
ええええええええええ
こんなの絶対いじらないパラメータだよ。わざわざpriv setしてfalseになんかするか？
万が一そうしたとしたら、客の指示がなきゃ絶対やらんわな。 未だにNAS使う意味がわからん
素直にSAN使っとけでは >>213
メンテでfalseにして戻し忘れたとか。 事前のテストで判明しなかったとかテストに問題があるだろ BIOS今はUEFIって言うんだっけ
の設定ミスだな
ネット上がりのSEあるあるだな
ハードの知識皆無的な
ECCメモリって、粗悪なやつだと、ECCあるからええやんって、フツーのメモリよりエラー多いやつ有るよな
それで無知が運用して設定ミスじゃあもう滅茶苦茶だな
なんか嘘臭いけど、小説より奇なりかね 大阪、名古屋、福岡、札幌いずれかをBCPにすべし。
障害が起きても学習経験しながらソフト更新して、信頼性の高いものにしていくしかない。 宝くじは継続購入してると当たらなくなる
この理由が解る人はFXとかやってないと思う いやいや、何か故障が起こっっときはシャットダウンが正解だろ >>218
スレすら読めない低能
お前さんが語れるレベルの低次元の話じゃねえからこれ >>180
default trueの物をいじるか〜？
パニック時に切り替えないとかリスクしかないじゃん >>226 default trueの物をいじるか〜？
普通はいじらないですね。
ですが、この装置は、active-standbyではなく、active-active運用なので
フェイルオーバーが自動的に実行されると不都合が生じる場合があります。
そういう場合は、自動でフェイルオーバーさせずに手動で切り替えるようにします。
パニックはメモリ故障の時だけでなくファームの不具合や資源枯渇など
の理由により、ストレージの稼働が困難になるとパニックが発生します。
default設定時(-onpanic true)の動作
パニックリブート発生⇒自動テイクオーバー(切り替え)⇒
パニックリブートから復帰⇒自動ギブバック(切り戻し)⇒元の運用に戻る。
また、テイクオーバーが発生すると、片系のコントローラーで２クラスタ分の処理を行う
事になり、その分負荷が高くなります。
用途・時間帯によっては、負荷のかかった状態で運用する事が好ましくなかったり、
不要なテイクオーバー/ギブバックを減らす為に、切り替えや切り戻しが自動で実行
されないようにする場合もあります。
※NETAPPでは、フェイルオーバー/フェイルバックの事をテイクオーバー/ギブバック
と呼んでいる。 >>84
素人意見だが、日次処理的に後場からの稼動開始って
可能なんだろうか
なんとなくだが、時間起動しているバッチ処理
との整合性が取れているか確認が大変な気がするのだが いままで正常稼動してたから気が付かなかったってのが凄いことなんだけどなw 優秀な下請確保しとけよ
飴と鞭で縛りつけるんだよ
2000年代はみんなそうやってシステム上手く作ってたぞ 2000年代か・・・
豊洲にあったD社の不夜城で頑張っていた頃だな
何もかもが懐かしい NASの片方が死んだら切り替わるようにしていたけど
怪我して頑張ってたから切り替わらなかったって感じかな
怪我したら強制的に休ませる設定になっていなかったと
新型コロナとかインフルにかかっても無理して出社するような感じか？ >>229
当日に慌てて確認しようとしたら大変でしょうね。
おそらくはそんな感じで再起動に難色を示した大手プレーヤーだか証券会社だかがいたと思われる。
でも本来的には、こういう緊急時の再起動に備えてない方が悪い。 データの保証したくないから障害で終わらせただけだよ。
切り替えの絶妙なタイミングの取引を全部保証しろ、なんて詰められて逃げたんだろ。 >>238
まぁそれはシステムを使用してる証券側がメインで動かなきゃいけない話だからな
もっと言えばそれを想定してアプリ設計と発注を富士通に依頼しなきゃいけない
使う方が能無しだから備えることが出来ないんだ >>6
それぐらいわかれよ、陰性陽性よりわかるだろ ■ このスレッドは過去ログ倉庫に格納されています
