アカウント名:
パスワード:
> 冗長化構成を取っているパケット交換機の故障により稼働している側にトラフィックが集中、これにより問題が発生した
冗長化構成って、冗長化している部分の一部が壊れても、全体に影響がないようにしてある構成を言うと思っていたんだけどそれは思い違い?それとも、完全に冗長化構成の設計ミス?もしくは想定外なほど一気に大量に壊れた?
設計当初はN+1だったんでしょう。
ユーザ増加による負荷の変化を甘く見てて、気づいたらN+0.3とかになってた
N+1 → Standby専用機があるはずだ という発想かな?5台分のキャパシティが必要だから、6台分で負荷分散&冗長化というのも、立派なN+1ですよ。
待機系を無くすことで、万一、想定キャパシティ(5台)を超えた場合でも、一時的に凌げるという利点があります。
"N+1" において "N=0" や "N=-1" という場合はありやなきや
Nは自然数(1, 2, 3, …)ですがね。日本なら義務教育である中等教育で習うハズ。
#自然数に0を含めるかという数論的議論はある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
教えて偉い人 (スコア:0)
> 冗長化構成を取っているパケット交換機の故障により稼働している側にトラフィックが集中、これにより問題が発生した
冗長化構成って、冗長化している部分の一部が壊れても、全体に影響がないようにしてある構成を言うと思っていたんだけど
それは思い違い?それとも、完全に冗長化構成の設計ミス?もしくは想定外なほど一気に大量に壊れた?
Re: (スコア:3, 興味深い)
設計当初はN+1だったんでしょう。
ユーザ増加による負荷の変化を甘く見てて、気づいたらN+0.3とかになってた
Re:教えて偉い人 (スコア:1)
N+1の冗長化構成をとっていたにもかかわらず、1台(系統?)壊れただけでサービス障害が発生するのは明らかに設計ミスだと思います。が、それはキャパシティプランニングの問題ではなく、冗長化構成の仕組みに問題があります。実は障害は二つ発生しており、1.機器が故障した、2.正しく冗長化構成が発動せず待機機器が稼働しなかった、と言うことになります。そもそも気づいたらN+0.3になっているような構成ってどういうつくりなんだろう?当初N+1の冗長化構成だったのをもったいないからNの負荷分散にしたのなら理解できるけれど。というか昨今のトラフィック増加にともなって、冗長化やめて負荷分散にしてしまえってdocomoが思っているのであればかなりまずい状況かと。
で、最初の質問に戻ると、冗長化構成としてはn重化(おそらくn=2かな?)の縮退冗長の設計になっていたため、通信しにくくなるのはシナリオどおりだったんじゃないかな?と想像する。なので、サービスへの影響がどのレベルまで許容できるかを決めたかで、サービス提供のされかたが変わってきますから、冗長化だからと言って理論上サービス障害が発生しない訳ではないと。
ただ、会社が千代田区にあるのですが、午前中はまったくつながらず、壊れたんじゃないかとあせりました。気づいたのが9時頃で、まわりのdocomoユーザは使えるとかいわれ。docomoのサイトには障害の一報もなく。自分の携帯だけを考えるならば、完全に止まっていたので冗長化してるのにひどいんじゃない?とは思いますが。
余談だが試しに嫁さんに電話したら、こちらはコールが聞こえないのにどういうわけか相手には2コールはできてそこで断。あまりにも短いコールだったのでビックリしてかけてくれたらしいんだが「電源が切れているか電波が届かない」と言われたそうな。嫁さん曰く「なんか不思議と思ったんよ」と、そこは心配してくれてもいいんじゃない?という二次災害に見舞われています・・・。
職業としてのプログラマ
Re: (スコア:0)
N+1 → Standby専用機があるはずだ という発想かな?
5台分のキャパシティが必要だから、6台分で負荷分散&冗長化というのも、立派なN+1ですよ。
待機系を無くすことで、万一、想定キャパシティ(5台)を超えた場合でも、一時的に凌げるという利点があります。
Re: (スコア:0)
"N+1" において "N=0" や "N=-1" という場合はありやなきや
Re: (スコア:0)
Nは自然数(1, 2, 3, …)ですがね。
日本なら義務教育である中等教育で習うハズ。
#自然数に0を含めるかという数論的議論はある。