アカウント名:
パスワード:
DCだと、水で消火するわけにいかないので火災検知→窒息消火(ハロンガス？)作動→空調停止→機器温度上昇→サーバ停止→障害発生
という流れだった、みたいなことをどこかで見た。
http://k-tai.impress.co.jp/docs/news/20150713_711403.html [impress.co.jp]
待機系と本番系を極力リスク分散するってのが、一番大事ですね。火災原因は分かりませんが、またオゾン層が破壊されたという事実だけは間違い無さそうです。
排煙のために火災を検知したら空調を止めることが多いですが、データセンタの場合、空調が強力なので、ガスでの消火や酸素の供給を止めるためにも、空調を止めざるを得ません。ガス消火もかなり強力なので、放出時の振動でストレージがやられることがあります。無事だったとしても、空調が止まるとものすごく暑くなるので、サーバは、運がよければシャットダウン、悪ければ熱暴走します。サーバの消費電力と同じくらいの電力を空調でくってるので、空調停止は致命的です。
なので、火災を検知した時点で、火災に規模によらず、そのセンタは大規模障害確定なんですよ。
同一センタ内で、本番系と待機系のロケーションを分ける意味はあまりないです。センタの障害を想定するなら、異なるセンタにサーバを立ててください。
古いセンタだと、実際に火災が発生していなくても、火災の誤検知で同様の障害が発生する可能性があります。年1回運用訓練できる電源系とちがって、火災の運用訓練は机上でしかできないから、この手の障害の影響って、知らない人多いんですよ。
火災シミュレーション関連のイベントに行くと、従来の建築設計屋か研究者ばかりだったんだが、最近コンピュータ屋さんを見かけるのはそのせいか。
非常時の運営がちゃんとできてるとこなら、バックアップ拠点や縮退モードへの移行やらは自動的に実行されるはずなんだけどなぁ。爆発事故や意図的なテロにやられたとかならともかく、ボヤや小規模火災程度で丸一日も停止したんじゃインフラとしては失格レベル。
#2847371で貼られたニュース記事 [impress.co.jp]によれば、予備系統が発火して停止→消火設備作動・空調停止→温度上昇で同じ室内にあった本系統が停止、と言う流れのようです。…遠隔地に設置どころか同一地域内分散ですら無く、同一施設の同一室内ってどうなってるんだよ！
施設単位で起きる電源障害や空調障害や回線障害には耐えられない。天災では間違いなく死ぬ。インフラの一種なのにシステム単独の障害にしか対応できない体制ってよくそれでやってこれたな…
災害とか火事よりも機械の故障のほうがはるかに発生確率が高いので、稼動系の横に待機系を置くのは普通の構成ですよね。
ミッションクリティカルなシステムは、そこから更に遠隔地にDR系を置く感じですよね。
リアルタイムに同期かけてるとRTTが性能に直結するからねえ。フロア冗長という折衷案もあるけど火事だと微妙か。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
空調停止→温度上昇→停止 らしい (スコア:3)
DCだと、水で消火するわけにいかないので
火災検知→窒息消火(ハロンガス？)作動→空調停止→機器温度上昇→サーバ停止→障害発生
という流れだった、みたいなことをどこかで見た。
Re:空調停止→温度上昇→停止 らしい (スコア:1)
http://k-tai.impress.co.jp/docs/news/20150713_711403.html [impress.co.jp]
待機系と本番系を極力リスク分散するってのが、一番大事ですね。
火災原因は分かりませんが、またオゾン層が破壊されたという事実だけは間違い無さそうです。
Re:空調停止→温度上昇→停止 らしい (スコア:1)
排煙のために火災を検知したら空調を止めることが多いですが、データセンタの場合、
空調が強力なので、ガスでの消火や酸素の供給を止めるためにも、空調を止めざるを得ません。
ガス消火もかなり強力なので、放出時の振動でストレージがやられることがあります。
無事だったとしても、空調が止まるとものすごく暑くなるので、サーバは、運がよければ
シャットダウン、悪ければ熱暴走します。サーバの消費電力と同じくらいの電力を空調で
くってるので、空調停止は致命的です。
なので、火災を検知した時点で、火災に規模によらず、そのセンタは大規模障害確定なんですよ。
同一センタ内で、本番系と待機系のロケーションを分ける意味はあまりないです。
センタの障害を想定するなら、異なるセンタにサーバを立ててください。
古いセンタだと、実際に火災が発生していなくても、火災の誤検知で同様の障害が
発生する可能性があります。年1回運用訓練できる電源系とちがって、火災の運用訓練は
机上でしかできないから、この手の障害の影響って、知らない人多いんですよ。
Re: (スコア:0)
火災シミュレーション関連のイベントに行くと、従来の建築設計屋か研究者ばかりだったんだが、
最近コンピュータ屋さんを見かけるのはそのせいか。
Re: (スコア:0)
非常時の運営がちゃんとできてるとこなら、バックアップ拠点や縮退モードへの移行やらは自動的に実行されるはずなんだけどなぁ。
爆発事故や意図的なテロにやられたとかならともかく、ボヤや小規模火災程度で丸一日も停止したんじゃインフラとしては失格レベル。
Re:空調停止→温度上昇→停止 らしい (スコア:3, 参考になる)
#2847371で貼られたニュース記事 [impress.co.jp]によれば、
予備系統が発火して停止→消火設備作動・空調停止→温度上昇で同じ室内にあった本系統が停止、と言う流れのようです。
…遠隔地に設置どころか同一地域内分散ですら無く、同一施設の同一室内ってどうなってるんだよ！
施設単位で起きる電源障害や空調障害や回線障害には耐えられない。天災では間違いなく死ぬ。
インフラの一種なのにシステム単独の障害にしか対応できない体制ってよくそれでやってこれたな…
Re:空調停止→温度上昇→停止 らしい (スコア:2)
災害とか火事よりも機械の故障のほうがはるかに発生確率が高いので、稼動系の横に待機系を置くのは普通の構成ですよね。
ミッションクリティカルなシステムは、そこから更に遠隔地にDR系を置く感じですよね。
Re:空調停止→温度上昇→停止 らしい (スコア:1)
リアルタイムに同期かけてるとRTTが性能に直結するからねえ。
フロア冗長という折衷案もあるけど火事だと微妙か。