アカウント名:
パスワード:
働き蟻の何割かは常に怠けていて、その何割かを取り除くと、今まで働いていた蟻が怠け始めると言う話を思い出した。昏睡状態のサーバーも、なくしたつもりが新たに発生したりして。
不当マイナスモデしたい。別コメントにあるとおり、この無駄は人間の設計力の限界なんじゃないだろうか。
>この無駄は人間の設計力の限界なんじゃないだろうか。
そらまあ、その通りで、可用性を確保する手段として冗長化する(無駄を作る)事を選択したというのは(理屈では)可用性を確保する手段として一番合理的なのがそれだったという事で、それ以外の手段を用意するには人知を超える設計力が必要という意味では人間の限界ではあるよ。
言い換えると、未来に対しての正確な予測を行なって、それに対して過不足ない設計を行う事は神様にしかできん。
今回の「昏睡」の定義なら、冗長構成で昏睡サーバ0は、人智の範囲で実現可能なのでは?例えば、一台当り稼働率60%の(物理)サーバ三台でシステムを構成すれば、一台故障時に他の二台で肩代わりしても、一台当たりの稼働率80%で、システム全体の仕事量はこなせてる計算。
ま、実際にはそう上手くいく場合ばかりではないわけですが。
未来の予測に関しては、もちろん同意。人智では完全な予測は不可能。
ロードバランスに参加しないバックアップ(フェイルオーバー用の各種スタンバイ)はほぼ全てゾンビですよ。コールドスタンバイは無論、ホットスタンバイや試験用のサーバも通常状態なら配信無しにカウントされうる。メンテナンス時の作業用空きラックに交換用の予備機とか詰めたらそっちもそれだけで昏睡にカウントされます。大規模なシステム更新後に一定期間残すだろう旧システムなんかも当然カウントされる。ゼロは無理でしょう。
ホットスタンバイ以外をDCから追い出したところで「トヨタは在庫を持たない代わりに道路を倉庫代わりに使っている」みたいに別のところにそのバックアップが押し付けられたり、有事の際に毎回長時間システムが止まるようになってもねぇ…
全バックアップをロードバランスに参加させるとかリスキーにしか思えない。形だけの参加とかもエコ云々含め本末転倒
ロードバランスに参加しないバックアップ(フェイルオーバー用の各種スタンバイ)はほぼ全てゾンビですよ。
その通りですね。
で、私の主張は、物理サーバレベルであれば、ロードバランスに参加しないバックアップサーバをゼロにすることができる、と言うものです。よく読んでみてください。
メンテナンス時<<略>>ゼロは無理でしょう。
この辺りはおっしゃる通り。私が
と書いた理由の一部がそれらです。
ちがうちがう、冗長性を確保する設計という意味ではなく、人間の仕事は必ず2,3割は無駄になるということ。その無駄は、保険や計画性のあるものではなく、頑張って効率的に設計したけれども、あてが外れて無駄になったもの。
で、そのあてが外れたを許容しないというのは神様にしかできんだろうと。#ユダヤ教かな?それ以上にキツイ神様っているかな?
ちょっと話がずれますが、
冗長性のために用意した○○の量の無駄の○○%が意味のない無駄だと断言するという事は、そのシステムが許容するリスクを算定した結果、100-○○%しか必要ないはずだとその人が判断するという事で、いや、そのシステムの担当者の仕事をしていただいてありがとうございます。という話です。#それを判断できるのは個々のシステムに対しての責任者しかいないはず##提言までならありかな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
何割かは必ず怠ける (スコア:2, おもしろおかしい)
働き蟻の何割かは常に怠けていて、
その何割かを取り除くと、今まで働いていた蟻が怠け始めると言う話を思い出した。
昏睡状態のサーバーも、なくしたつもりが新たに発生したりして。
Re: (スコア:0)
不当マイナスモデしたい。
別コメントにあるとおり、この無駄は人間の設計力の限界なんじゃないだろうか。
Re:何割かは必ず怠ける (スコア:1)
>この無駄は人間の設計力の限界なんじゃないだろうか。
そらまあ、その通りで、可用性を確保する手段として冗長化する(無駄を作る)事を選択したというのは(理屈では)可用性を確保する手段として一番合理的なのがそれだったという事で、
それ以外の手段を用意するには人知を超える設計力が必要という意味では人間の限界ではあるよ。
言い換えると、未来に対しての正確な予測を行なって、それに対して過不足ない設計を行う事は神様にしかできん。
#存在自体がホラー
Re:何割かは必ず怠ける (スコア:1)
今回の「昏睡」の定義なら、冗長構成で昏睡サーバ0は、人智の範囲で実現可能なのでは?
例えば、一台当り稼働率60%の(物理)サーバ三台でシステムを構成すれば、一台故障時に他の二台で肩代わりしても、一台当たりの稼働率80%で、システム全体の仕事量はこなせてる計算。
ま、実際にはそう上手くいく場合ばかりではないわけですが。
未来の予測に関しては、もちろん同意。
人智では完全な予測は不可能。
Re: (スコア:0)
ロードバランスに参加しないバックアップ(フェイルオーバー用の各種スタンバイ)はほぼ全てゾンビですよ。
コールドスタンバイは無論、ホットスタンバイや試験用のサーバも通常状態なら配信無しにカウントされうる。
メンテナンス時の作業用空きラックに交換用の予備機とか詰めたらそっちもそれだけで昏睡にカウントされます。
大規模なシステム更新後に一定期間残すだろう旧システムなんかも当然カウントされる。ゼロは無理でしょう。
ホットスタンバイ以外をDCから追い出したところで「トヨタは在庫を持たない代わりに道路を倉庫代わりに使っている」
みたいに別のところにそのバックアップが押し付けられたり、有事の際に毎回長時間システムが止まるようになってもねぇ…
全バックアップをロードバランスに参加させるとかリスキーにしか思えない。形だけの参加とかもエコ云々含め本末転倒
Re:何割かは必ず怠ける (スコア:1)
ロードバランスに参加しないバックアップ(フェイルオーバー用の各種スタンバイ)はほぼ全てゾンビですよ。
その通りですね。
で、私の主張は、物理サーバレベルであれば、ロードバランスに参加しないバックアップサーバをゼロにすることができる、と言うものです。
よく読んでみてください。
メンテナンス時<<略>>ゼロは無理でしょう。
この辺りはおっしゃる通り。私が
ま、実際にはそう上手くいく場合ばかりではないわけですが。
と書いた理由の一部がそれらです。
Re: (スコア:0)
ちがうちがう、冗長性を確保する設計という意味ではなく、
人間の仕事は必ず2,3割は無駄になるということ。
その無駄は、保険や計画性のあるものではなく、
頑張って効率的に設計したけれども、あてが外れて無駄になったもの。
Re:何割かは必ず怠ける (スコア:1)
で、そのあてが外れたを許容しないというのは神様にしかできんだろうと。
#ユダヤ教かな?それ以上にキツイ神様っているかな?
ちょっと話がずれますが、
冗長性のために用意した○○の量の無駄の○○%が意味のない無駄だと断言するという事は、
そのシステムが許容するリスクを算定した結果、100-○○%しか必要ないはずだとその人が判断するという事で、いや、そのシステムの担当者の仕事をしていただいてありがとうございます。という話です。
#それを判断できるのは個々のシステムに対しての責任者しかいないはず
##提言までならありかな
#存在自体がホラー