【東証トラブル】富士通「メモリー障害時に冗長化が機能しないようファームウエアを設定してた」

1モアイ(東京都) [US]2020/10/08(木) 14:45:50.67ID:wn4xBL570

東京証券取引所で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/

2: ウェーブくん(群馬県) [US]2020/10/08(木) 14:46:36.22ID:wy+b27o/0
はい

3: カバガラス(滋賀県) [ニダ]2020/10/08(木) 14:47:27.06ID:BN8QwkNi0
メモリーと言っているのに、目盛と思うジジ嫌い

4: ばっしーくん(大阪府) [CN]2020/10/08(木) 14:47:37.54ID:XM1qxnnQ0
定期点検してないの?
テストは?

155: エコンくん(東京都) [ニダ]2020/10/09(金) 00:51:49.69ID:xsZFjGHt0
>>4

テストはした、だけどテストの想定パターンにはなかった
よくある事だよ

冗長化してても切り替わらないとか、切り替わったけどアプリが動かなくなるなんてことはある

5: (茸) [US]2020/10/08(木) 14:50:25.00ID:pzZjeDp/0
ハード障害を想定したテスト項目の抽出漏れ、だよな。
テスト工数貰えなかったのかい?

184: マコちゃん(大阪府) [AU]2020/10/09(金) 02:36:09.03ID:MFoj+LiT0
>>5
こんなデカイ規模でもらえらないわけねーだろ

6: マップチュ(千葉県) [US]2020/10/08(木) 14:51:32.37ID:15En4WiF0
冗長化という日本語を何とかしろや
わけわからんわ(´・ω・`)

14: けんけつちゃん(東京都) [US]2020/10/08(木) 14:57:50.85ID:7cD65G1L0
>>6
あえて無駄を受け入れる
って意味だしそこまで難しいこ言葉か?

154: ヱビス様(東京都) [US]2020/10/09(金) 00:49:39.24ID:Y6oSSJZu0
>>6
リダァンダァンシィ

8: 緑山タイガ(奈良県) [US]2020/10/08(木) 14:52:13.95ID:FRMY/V4B0
なるほど、つまり要約すればコンセントに足を引っかけた、と

24: フジ丸(長野県) [ニダ]2020/10/08(木) 15:03:47.45ID:PSFsoTcO0
>>8
掃除のおばちゃんの不注意か、それじゃしょうがないな

9: チューちゃん(SB-iPhone) [US]2020/10/08(木) 14:52:22.73ID:m78/1TTs0
まともな投資家は米国株しか触らんからね
日本株なんてどうでもいい

13: マルちゃん(東京都) [ニダ]2020/10/08(木) 14:56:46.48ID:gbO3gQaH0
>>9
バフェット「日本株買うわメッチャ買うわ」

34: キキドキちゃん(埼玉県) [US]2020/10/08(木) 15:17:45.96ID:Tyq1X4p30
>>9
よう中卒引きこもり

121: 都くん(岡山県) [US]2020/10/08(木) 19:01:03.98ID:BbEm3CqG0
>>9 まともな投資家っていったい?

10: しまクリーズ(大阪府) [US]2020/10/08(木) 14:54:21.21ID:l6k2vl540
冗長とは無駄なもの。
機能してしまっては冗長化とはいえない

101: レオ(東京都) [US]2020/10/08(木) 17:11:02.67ID:FOFIU2Jm0
>>10
なるほど筋が通っているような気がするな

115: ぼっさん(公衆電話) [US]2020/10/08(木) 18:37:00.53ID:UthnM1jK0
>>10
何金言言ってんの。

11: 星ベソパパ(茸) [ニダ]2020/10/08(木) 14:55:29.46ID:mF5Vb9b50
アクティブアクティブなら
1号2号同じ仕事してたのか

19: あんしんセエメエ(東京都) [IT]2020/10/08(木) 15:01:52.96ID:bwftPPUc0
>>11 その単語だけではそうとは限らないかな
非同期でもAAはあり得るけど同じとは言えないし、同期AAなら同じと言える

16: mi−na(兵庫県) [US]2020/10/08(木) 14:59:23.63ID:GEtQuwkL0
富士通の責任じゃん

21: KEIちゃん(東京都) [CN]2020/10/08(木) 15:02:51.00ID:oV/h7VrJ0
>>16
そうは言えない。そんなこと考慮しなくていいから早くプロジェクト進めって東証が要請していた可能性もある

27: あんしんセエメエ(東京都) [IT]2020/10/08(木) 15:05:37.75ID:bwftPPUc0
>>21 古い契約でも1年以内の納品物だしその言い訳は通用しないだろw
瑕疵を逃げる事はできんよ

23: あんしんセエメエ(東京都) [IT]2020/10/08(木) 15:03:37.68ID:bwftPPUc0
>>16 それは確実
つうか自社の同システム環境で納期に間に合わない試験は逐次やるべきだった
どうせかなりボッタな保守組んでるはずなのに1日はさすがに叩かれてもしょうがない

156: エコンくん(東京都) [ニダ]2020/10/09(金) 00:54:04.74ID:xsZFjGHt0
>>16

どうかな
その試験で受け入れはのは東証だろ
責任は東証にあって保守範囲でどこまで富士通がサポートしているかだろね

160: モモちゃん(東京都) [ニダ]2020/10/09(金) 01:05:02.46ID:bgPm8pZ60
>>156
障害テストまで受入側の責任かよ
クソだな

168: auシカ(ジパング) [US]2020/10/09(金) 01:36:11.21ID:QGI0u7+m0
>>160

当たり前だろ
そのシステム買ってきて自分の資産にしてるんだったらその運用責任は東証だよ
受け入れ試験やって受け入れたんだろ
その受け入れ試験に穴があったってこと

25: スピーディー(庭) [US]2020/10/08(木) 15:05:23.98ID:7cADU/j50


26: アヒ(愛知県) [US]2020/10/08(木) 15:05:27.27ID:/m7Blgja0
片方死んでもええように2つ動かしてたのに片方死んだだけで止まったとかギャグやん
NASも今まで何してたんだって思うやろ

29: ヨドくん(SB-iPhone) [US]2020/10/08(木) 15:11:02.62ID:rEdK2hZV0
>>26
普通冗長化試験だとNICのリンクダウンやプロセス断の切り替わり位しかテストせんからな
メモリは流石にECCだろうし1箇所潰れても動き続けるやろ程度だったんじゃね?
むしろ両activeという恐ろしい事態は避けたいだろうし

35: あんしんセエメエ(東京都) [IT]2020/10/08(木) 15:18:58.18ID:bwftPPUc0
>>29 メモリエラーで片方誤情報でAAとか怖くてしょうがないよねw
2台冗長+チェックサム専用の3台体制かと思ってた

中途半端に冗長化しても今回の様なメモリ不整合で動作されて停止遅れも困るし
フェイルオーバー運用って本当にシステム屋泣かせだよね

といっても、ボッタクリ監視でも良いので両方のNASのモニタリングして付き合わせれば
いいだけだとは思うけど・・・(人がやるか機械にやらせるかはあるけど

81: ラビピョンズ(福島県) [US]2020/10/08(木) 16:38:32.18ID:ggoFeA9Q0
>>35
メルキオール、バルタザール、 カスパールの3台で

171: auシカ(ジパング) [US]2020/10/09(金) 01:38:37.52ID:QGI0u7+m0
>>35

当面マンパワーかけて対応しますってのはつまりそういうことだろ
結局はそこまでの費用を東証が払って維持するかって問題だよ

31: あんしんセエメエ(東京都) [IT]2020/10/08(木) 15:12:52.19ID:bwftPPUc0
>>26 まぁ理想ではそうなんだけど物理冗長は成功例が少ないからね
仮想冗長がようやく絵になって来たけど、物理冗長は「論理的には・・・」だよ

クリティカルな運用なら実機だ! って人多いからね

30: フライング・ドッグ(SB-Android) [DE]2020/10/08(木) 15:11:27.65ID:rROQG7u10
サーバを二重化させたシステムって、こういう故障はだいたい切り替わらないよね。
死活監視をnicだけでやってると、本当に切り替わらない。

41: エンゼル(東京都) [US]2020/10/08(木) 15:26:40.75ID:f7qMZMIo0
>>30
そりゃあ切り替わらない事例しか報道されないからな
無事に切り替わってるシステムについてはそもそも語られない

48: うずぴー(東京都) [US]2020/10/08(木) 15:42:17.79ID:ud/GGr8T0
>>41 いやいやw たんにエラーが起きないだけだよw

33: どんぎつね(東京都) [CN]2020/10/08(木) 15:16:49.55ID:tlUCQ0440
active-active構成だったの?

話がつながらないけど

38: なーのちゃん(栃木県) [US]2020/10/08(木) 15:21:19.97ID:rqtLTGO20
>>33
最初の会見の時点でうまく切り替わらなかったので故障したほうのdisk装置を手動で切り離したって言ってたじゃん
active-activeなら整合してる

39: しまクリーズ(徳島県) [ニダ]2020/10/08(木) 15:22:26.05ID:1Ywo0kwy0
設定ミスではないと思う

そもそものテスト仕様の漏れ
テストの項目にメモリ障害があって切り替わるかどうかのテストをしていないだけ

47: どんぎつね(東京都) [CN]2020/10/08(木) 15:37:53.00ID:tlUCQ0440
>>39
富士通はテストがうまくいくようにテスト項目を設定する会社なので

49: どんぎつね(東京都) [CN]2020/10/08(木) 15:43:27.77ID:tlUCQ0440
>>39
テストをやらなかったからバグを見つけられませんでしたって言うSEはレベルが低い

51: うずぴー(東京都) [US]2020/10/08(木) 15:49:02.42ID:ud/GGr8T0
>>49 つっても、SEがNASを設計するわけじゃなく
NAS屋が 冗長性をアピール したのを信じて選定してるだけだからな
んで、NASの内部メモリの故障なんて現象を作り出せるかはNAS屋に依頼するしかないが
たぶんそんなエラー(偽トラブル)は頼んでも無理だと思う

ただ、確かに導入した製品を信用せずに他社NASも使った試験やそもそも異機種NASでの
冗長化にしたほうがよかったのかもしれんが そんなのはベテランのSEでも無理だろうね

こういう不具合に有って初めて「再発防止対策」としてそういう案がでてくる感じ

だからもしもNASメモリのエラーなら、エスパーSE でもない限り予見は不可能だよw

54: どんぎつね(東京都) [CN]2020/10/08(木) 15:55:37.01ID:tlUCQ0440
>>51
NAS屋が富士通だけどね

59: ミドリちゃん(SB-Android) [ニダ]2020/10/08(木) 15:59:50.31ID:edJzgd8f0
>>51
そのNAS屋が富士通
まあ東証システム構築部隊とは違う
ストレージ販売部隊なんだろうけども

これ初期設定から誤ってたということだから
全エターナス製品に波及するねえ

66: デンちゃん(神奈川県) [JP]2020/10/08(木) 16:07:29.18ID:yzCKsTxC0
>>51
富士通がNASも作ってるんですよ…

https://www.fujitsu.com/jp/products/computing/storage/

実際は製品ラインナップには他社のOEMも含めてるけど

40: 柿兵衛(東京都) [BG]2020/10/08(木) 15:26:09.48ID:TiPEEFnu0
メモリ障害を想定したテストってできるのかな

42: エンゼル(東京都) [US]2020/10/08(木) 15:27:57.50ID:f7qMZMIo0
>>40
「メモリ障害が発生したらハードからこういうアラートが上がるからそれを擬似して試験する」が関の山だろうなあ

46: 狐娘ちゃん(神奈川県) [US]2020/10/08(木) 15:37:42.27ID:9syVg0VY0
>>42
それで十分や

53: 柿兵衛(東京都) [BG]2020/10/08(木) 15:55:13.86ID:TiPEEFnu0
>>42
そっかー
やっぱsnmpなりログ監視なりで気づくしかなさそうだけど今回はそれじゃ拾えなかったんかね

164: せんたくやくん(東京都) [CH]2020/10/09(金) 01:26:35.05ID:LA0091XF0
>>42
例えば海外ルーターのiosならtest crashでメモリの擬似エラーとかもできるけど
日本製品だとこういうところの作り込みは甘いよね

57: ひかりちゃん(東京都) [FR]2020/10/08(木) 15:57:59.87ID:yXxoqEj60
ファームのデフォルト設定がコレなの?

78: ガブ、アレキ(長野県) [US]2020/10/08(木) 16:31:59.60ID:sM4HCD1A0
>>57
デフォルトかどうかでもだいぶ印象変わるよな

62: ヨドくん(SB-iPhone) [US]2020/10/08(木) 16:04:06.01ID:rEdK2hZV0
大規模導入プロジェクトはユーザーと逐一意識あわせする
基本設計や詳細設計は全部ユーザーの承認を受ける
冗長設計も冗長試験手順も全部承認されてたら富士通だけの責任ではない
とはいえ日本文化的に富士通が謝るのが美しい幕引き

67: ミドリちゃん(SB-Android) [ニダ]2020/10/08(木) 16:08:55.12ID:edJzgd8f0
>>62
ユーザー(受注元)の承認は逐一受けるけども
ユーザー自身が>>1を見抜けないような程度のザルチェックしかしないからねえ
責任は東証にもあるが、まあ突っ込まれないだろう

68: らぴっどくん(静岡県) [ニダ]2020/10/08(木) 16:09:36.54ID:dgIiyHiP0
>>62
外資系だとその辺をガチでやり合っちゃうんだよなw

71: かほピョン(千葉県) [IN]2020/10/08(木) 16:21:11.01ID:sky551m40
下請技術者の低レベル化が激しくね?
言われなくても忖度してチェックとかするだろ

72: うずぴー(東京都) [US]2020/10/08(木) 16:22:26.26ID:ud/GGr8T0
>>71 無理だな
メモリエラーはどのメーカーも検証もチェックもしていないと思うぞ

147: りそな一家(鹿児島県) [US]2020/10/08(木) 22:53:16.97ID:MtNHyPu10
>>72
syslogで網張るぐらいかな?

165: せんたくやくん(東京都) [CH]2020/10/09(金) 01:30:06.76ID:LA0091XF0
>>72
ECCエラーのトラップぐらいやってるよ

海外ストレージのnetappならシングルビットエラーはログ表示のみでリカバリ続行
マルチビットエラーはパニックリブートかかって切り替わる
https://kb-ja.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_to_troubleshoot_correctable_memory_errors_on_FAS_and_AFF_systems

メモリエラーで切り替わりませんとかどんだけしょぼいんだか
国産はこれだから。

73: ウリボー(神奈川県) [ヌコ]2020/10/08(木) 16:24:41.19ID:siupxMc40
>>71
忖度するデメリットがメリットを大幅に上回ってるのにやるわけないだろ
相応のカネ払えよ

74: あるるくん(やわらか銀行) [AR]2020/10/08(木) 16:28:00.90ID:kerYWRrh0
本番環境で切り替えのテストやってなかったの?
そんなマヌケな事ってあるのか

77: ほっしー(SB-Android) [US]2020/10/08(木) 16:31:51.73ID:Fk+KLWWi0
>>74
単純な切り替え程度ならやってる

79: あるるくん(やわらか銀行) [AR]2020/10/08(木) 16:33:02.58ID:kerYWRrh0
>>77
要するにテストケース漏れじゃん

82: きょろたん(茸) [US]2020/10/08(木) 16:40:36.73ID:d6tlmKfL0
クリティカルなシステムにNAS使ってんの?
SANじゃなくて??

85: ヨドくん(SB-iPhone) [US]2020/10/08(木) 16:47:39.41ID:rEdK2hZV0
>>82
ヘッド分けて裏側でSAN動かしてても総称でNASやで

83: ドンペンくん(愛知県) [US]2020/10/08(木) 16:41:18.64ID:+f+Nyfex0
わかってるのか!?3兆だぞ3兆!!お前のせいで損失したんだ。土下座のひとつもしたまえ!」 半沢「3兆を取り戻せばいいんですね。もし取り戻す事ができたら今回の件、土下座して詫びてもらいます!

119: しんちゃん(東京都) [JP]2020/10/08(木) 18:59:19.93ID:zbDxwkvL0
>>83
3兆円って、取引額だろう。
益が出ればいいけど、損が出たら神風で助かったってことになる。
実際、次の日何もなかったように取引を終了。外資もどこも気にしてない。
後進国日本だからそんな影響なし。おまえが脱腸なだけ。

151: レンザブロー(愛知県) [NL]2020/10/09(金) 00:22:15.69ID:JgrY6apI0
>>119
ナッツの株主は全員死んだな

84: 和歌ちゃん(SB-Android) [BR]2020/10/08(木) 16:46:17.39ID:r89/Xjv90
うーん、ハード故障に関する記事ばっかりだなあ。
そんなものは午前中になんとかなってる。
後場向けにシステム再起動できなかった事情の方が大事なんだが。

86: ポケモン(茸) [US]2020/10/08(木) 16:48:31.99ID:/BMOQJWC0
>>84
場中の再起動なんて証券会社のシステムが対応できません

118: 和歌ちゃん(SB-Android) [BR]2020/10/08(木) 18:59:07.26ID:r89/Xjv90
>>86
そうそう。
つまり根本的な対策は東証だけではできない。
証券会社など各プレーヤーと協同して対策する必要がある。
なのに東証や富士通の問題ばかり記事が出てるみたいでなあ。

91: エンゼル(東京都) [US]2020/10/08(木) 16:52:40.83ID:f7qMZMIo0
>>84
まあ「大事をとって」なんじゃないの
トラブル発生後とにかく復旧を早くと言う顧客よりも「動かして本当に問題がないか明らかにしてから動かせ」という顧客の方が多いよ
「そのために試験やってるんだろ」という意見はもっともではあるが、そもそもその試験をすり抜けてトラブルが発生した時点で
顧客もベンダも疑心暗鬼になるから決断しにくい

103: ユートン(ジパング) [ニダ]2020/10/08(木) 17:17:42.87ID:hOjfoz+p0
>>84
ゲーム感覚だとそうなるよね

166: せんたくやくん(東京都) [CH]2020/10/09(金) 01:31:00.58ID:LA0091XF0
>>84
まあそれはもはや政治判断の領域だし

95: フレッシュモンキー(神奈川県) [ニダ]2020/10/08(木) 17:02:07.12ID:W1VcXqWJ0
redundancy

96: みったん(愛知県) [AT]2020/10/08(木) 17:08:04.15ID:hnxCKbXw0
>>95
ありがと
英語で冗長性をなくす
to eliminate redundancy
ってスパゲッティプログラムを最適化することじゃないのだな白目

106: どんぎつね(東京都) [CN]2020/10/08(木) 17:38:32.07ID:tlUCQ0440
装置単体のフェールオーバーではなくシステム全体のフェールオーバーを考えてないからこうなる

107: あんしんセエメエ(東京都) [IT]2020/10/08(木) 17:39:49.49ID:bwftPPUc0
>>106 AWSやAzureにも同じこと言ってやれ!
AWSなんてつい最近やぞw

110: どんぎつね(東京都) [CN]2020/10/08(木) 17:45:51.38ID:tlUCQ0440
>>107
AWSに金融の基幹系システムは載せられないね
情報系システムならいいけど

113: ニック(茸) [US]2020/10/08(木) 18:17:55.44ID:xoaJLcHg0
実際問題としてメモリ異常を検知して切り替わるシステムって難しくね?

114: モアイ(東京都) [US]2020/10/08(木) 18:19:56.65ID:wn4xBL570
>>113
ECCエラー出たらBIOSが物理的に切り替えはるんとちゃうか?
よーしらんけど

167: せんたくやくん(東京都) [CH]2020/10/09(金) 01:33:10.21ID:LA0091XF0
>>113
ECCで余裕で検出できる
無論マルチビットエラーなら偶然検知できないビットパターンの化け方をする可能性もあるが
東証がメモリエラーと言ってることからECC検知はきちんとできてたと思われる

124: プイ(埼玉県) [US]2020/10/08(木) 19:14:08.54ID:PimeApin0


なんだかこういうの想像する

129: セーフティー(埼玉県) [TW]2020/10/08(木) 19:45:08.49ID:dMmBiUK30
ファームの設定ミスは言い訳で死活監視でPING返す壊れ方を想定してなかっただけだろ
ファームでメモリエラー検知したらシャットダウンするって設定をしてたらカバーできてたってだけで

130: なるこちゃん(神奈川県) [US]2020/10/08(木) 20:17:22.15ID:h7l5V1Hq0
>>129
実際、こうなっていたのかもしれない

[ファームウェアの設定]
 L[メモリエラー検出時]
   L シャットダウンしますか:いいえ、とんでもない
   L 通知しますか:いいえ
   L 何もしませんか:はい、放置で

169: せんたくやくん(東京都) [CH]2020/10/09(金) 01:36:28.52ID:LA0091XF0
>>130
まあECCは普段から太陽フレアとかでシングルビットエラー報告がたまに出るからね。
東証が「いちいちうるさいからオフにしろ」と言った可能性は否定できないが
可能性的には低い。

単にメモリの回復不能エラー発生時にパニックするような作り込みを
富士通のストレージ部門がやってなかっただけかと。

139: シャブおじさん(兵庫県) [ニダ]2020/10/08(木) 21:25:15.83ID:/ikXxzkT0
ETERNUSのNASでActive-ActiveってことはNetAppか?OEMの。
ただ、設定不備って言ってもそんなの制御出来るパラメータあったかな。。

180: いっちゃん(大分県) [CA]2020/10/09(金) 02:23:14.63ID:9J3uZ4780
>>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に設定しても自動ギブバックは実行されません。
クライアントのアクセスが中断されます。

146: シャブおじさん(兵庫県) [ニダ]2020/10/08(木) 22:07:54.39ID:/ikXxzkT0
仮にNetAppだとしたら、Tintriにしろなんにしろ富士通はとことんOEMに恵まれねえな
というか、Failoverする時にあんなにIO Wait発生するストレージを金融取引のシステムに使うかね?cDOTはLIFを上手いこと制御してやれば7modeの時みたいなIO Waitは無いんだっけか?

170: せんたくやくん(東京都) [CH]2020/10/09(金) 01:38:24.53ID:LA0091XF0
>>146
netappじゃないほうでしょ
netappはこんな間抜けな壊れ方はしないかと

182: いっちゃん(大分県) [CA]2020/10/09(金) 02:23:49.71ID:9J3uZ4780
>>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/

148: よむよむくん(ジパング) [FR]2020/10/08(木) 23:07:06.68ID:3pYAOmnw0
SYSLOG吐きまくるので出力のレベル上げていいっすか(´・ω・`)

150: ナルナちゃん(神奈川県) [US]2020/10/09(金) 00:15:22.83ID:Mi5QpwSw0
>>148
そうしなよ
でないとSYSLOGでディスクフルになって、なにかが起きる
テストしてないだろうし
何が起きるか知ってる人は経験者だから守秘義務で黙して語らない

161: あいピー(茸) [EU]2020/10/09(金) 01:05:43.09ID:DapW45Al0
調べたら過去にこんな記事もあったで。

https://www.publickey1.jp/blog/12/post_208.html

電源障害発生、原因は基盤に塵や埃が付着したこと
日経コンピュータの報道によると、障害が起きたのは館林データセンターで1995年に開設され、主にアウトソーシングサービスを提供するA棟。ここで、館林データセンター全体の7%に相当する範囲で電力供給が途絶えたとのこと。

1台の無停電電源装置(UPS)が故障した際に、予備のUPSへ切り替えるための「出力分岐盤」が正常に機能せず、サーバへ電力を分配する分電盤へ電力供給が絶たれ、その結果サーバへの電力供給も途切れたのが大規模な障害につながったと説明されています。

そしてその原因は、「プリント基板とリレーのすき間に導電性の塵埃が付着したことによって、リレーの誤作動が生じた」と富士通広報。2013年3月までには信頼性を高めた新たな機器を導入するそうです。

162: エコンくん(山口県) [DK]2020/10/09(金) 01:12:27.42ID:08gDfgmk0
>>161
配電盤にネズミやゴキブリが住み着くアレか

176: せんたくやくん(東京都) [CH]2020/10/09(金) 02:02:14.05ID:LA0091XF0
全然業界違うがCPUの温度トラップを試験しろと言われたときは泣いたな
納品機材のヒートシンク外して加熱再現しろってことかよとw

無理ですとなんとか泣きついて許してもらったが
「温度トラップ出なかったら責任取れよ」と客から
ネチネチ言われる始末。

178: マルちゃん(栃木県) [US]2020/10/09(金) 02:06:01.29ID:XanJIGVN0
>>176
トラップの警告温度下げてテストするだけじゃね?50度とかに

179: auシカ(ジパング) [US]2020/10/09(金) 02:10:52.86ID:QGI0u7+m0
>>178

単体テストとしてはそれでいいかも知らんがシステムテストとしてはどうだろね
結局は、そこまでやりますか?その費用払いますか?
って話で

183: マルちゃん(栃木県) [US]2020/10/09(金) 02:26:05.52ID:XanJIGVN0
>>179
うーん顧客次第ということですな、渋られたらやらないか

SNSでもご購読できます。

コメントを残す

*