アカウント名:
パスワード:
不適切な帯域制限をかけてるのに気づかないまま（ネットワーク）ストレージシステムの更新作業をしちゃったので、半月近く時間がかかっちゃったよ(ﾃﾍｯって事かな？
＃発防止策を見る限り、「不適切な設定」をしてしまってそれに長時間気づけなかった事が今回の障害の主要因なのかな･･･
ストレージサーバ間の帯域制限のかけ忘れかな？よくわからない。
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickeyhttps://www.publickey1.jp/blog/18/zenlogic_1.html [publickey1.jp]
不適切な帯域制限はストレージシステムの入れ替え作業後に、設定変更実施だから違うような。そもそも適切なキャパシティプランに変更していれば発端である事象Aが起こらなかったんじゃないかな。再発防止策でキャパシティプランの見直しと性能指標の取り方教えてもらってるみたいだし。問題起きるまでほったらかし管理手法だったんじゃないかな。
# しかし、『システム全体への影響を最小限にするために外部ネットワークとの接続を遮断』って、# 『毒が全身に回らないようにトドメ刺しといた。何とか瀕死ですんだぜ』みたいな感じかな。
> 問題起きるまでほったらかし管理手法だったんじゃないかな。一番の問題はそこだよね。この報告が出るまで、公表されている再発防止は「システムが落ちたらまた付け焼き刃でシステム増設する」とかいう絶望的な内容だったし…
ストレージ直結の部分の帯域制限はかけたものの、それよりも手前では制限なしに流れるようにしたからドロップが発生して輻輳したとかいうオチかもね。
詳細はわからないが、設定ミスがあったってことを半月も特定できないのはちょっとね～。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
なるほどわからん (スコア:0)
不適切な帯域制限をかけてるのに気づかないまま（ネットワーク）ストレージシステムの更新作業をしちゃったので、半月近く時間がかかっちゃったよ(ﾃﾍｯ
って事かな？
＃発防止策を見る限り、「不適切な設定」をしてしまってそれに長時間気づけなかった事が今回の障害の主要因なのかな･･･
Re:なるほどわからん (スコア:1)
ストレージサーバ間の帯域制限のかけ忘れかな？よくわからない。
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey
https://www.publickey1.jp/blog/18/zenlogic_1.html [publickey1.jp]
Re: (スコア:0)
不適切な帯域制限はストレージシステムの入れ替え作業後に、設定変更実施だから違うような。
そもそも適切なキャパシティプランに変更していれば発端である事象Aが起こらなかったんじゃないかな。
再発防止策でキャパシティプランの見直しと性能指標の取り方教えてもらってるみたいだし。
問題起きるまでほったらかし管理手法だったんじゃないかな。
# しかし、『システム全体への影響を最小限にするために外部ネットワークとの接続を遮断』って、
# 『毒が全身に回らないようにトドメ刺しといた。何とか瀕死ですんだぜ』みたいな感じかな。
Re: (スコア:0)
> 問題起きるまでほったらかし管理手法だったんじゃないかな。
一番の問題はそこだよね。
この報告が出るまで、公表されている再発防止は「システムが落ちたらまた付け焼き刃でシステム増設する」とかいう絶望的な内容だったし…
Re: (スコア:0)
ストレージ直結の部分の帯域制限はかけたものの、それよりも手前では
制限なしに流れるようにしたからドロップが発生して輻輳したとかいう
オチかもね。
詳細はわからないが、設定ミスがあったってことを半月も特定できない
のはちょっとね～。