アカウント名:
パスワード:
見積を取ったのですが、Xeon×2+メモリ4Gのサーバ6台分ぐらいでした。
>L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
だからロードバランサやめたの。 で、その分Xeon×2+メモリ4Gのサーバを4台増強しました。 コストは2/3で、サーバはみんな遊ん
>単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
それは発想が逆。 ロードバランサがいらないように、フロントエンドはWebサーバだけにわざとしてるの。 Webサーバの一部にDBサーバも同居させてフロントエンドの処理能力をアンバランスにしておいて、それを無理矢理動かすためにロードバランサを入れる
何だか、この一連の応答で「ロードバランサ必要
>構造が単純ならいらん(w
だからさ、「最初から構造が単純だからいらない」んじゃなくて、「サーバを沢山入れて単純な構造にすればロードバランサがいらなくなる」って言ってるだんって。 ロードバランサがいらないように単純な構造にしたんだから、「単純だからいらん」のはあたりまえ。
>DNSに頼るのは本当にしょうもないor身内しか使わないようなシ
まず、何故そうやってサーバを分けなきゃいけないかを考えるべきです。 その単機能のサーバが一台だけって事はこの際無い事にして(一台だけならロードバランサなんていらんから)、複数台のフロントエンドに対応できるシステムで、他のサーバと別ける必要性は何なのかと。 ありがちな理由としては、「特定の機能は(他の機能に引きずられて)コケるとマズいから」というのがありますが、本
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
本当にアクセス数なのかな? という疑い (スコア:1, 興味深い)
中身を見たことがあるのですが…アルゴリズムがアレすぎて仕様とは
違う結果をたたき出したり、有名な方法でクラッキングが出来たりと、
ひどい物でした。
また、この生茶のサイトに関して、少なくともDNSレベルでは、負荷を
分散しようとしている形跡は見えません。
そんなわけで、本当にこれ、サー
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
出来なくなる人が出てくるのが恐いんですよね。
というわけでDNSでは分散せず箱モノのロードバランサを
入れてやるところが殆どだと思いますよ。
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
例えば、サーバがAとBの2台あるとして、
ロードバランサーならお互いの負荷を均等にできるけど、
DNSだとラウンドロビンで交互に割り振られるだけなので、
遅いクライアントが片方に集中してぶらさがったりすると、
結果として全体のパフォーマンスがガタガタになったりする。
つまり、パフォーマンスの見積もりができない。
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
やめた直接の原因はトラフィック増えてロードバランサが過負荷になったためですが、よりパフォーマンスの高いロードバランサに買い換えるぐらいなら、その金でサーバ増やして処理量自体を増やしてDNSラウンドロビンにした方がマシという結論になりました。
サーバ増やして処理量が増えれば、多少のアンバランスは問題無いですし、Xeon×2のサーバが何台も買えるような金出してロードバランサを入れても、結局処理量は増えないで、100%(に近く)処理できるようになるだけですから。
Re:本当にアクセス数なのかな? という疑い (スコア:0)
うーん、L4スイッチって高いかなぁ?
L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
>サーバがコケるより前にロードバランサがコケたとかのマヌケな話も良く聞くし。
そりは、ロードバランサがまぬけなんじゃ
Re:本当にアクセス数なのかな? という疑い (スコア:0)
見積を取ったのですが、Xeon×2+メモリ4Gのサーバ6台分ぐらいでした。
>L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
だからロードバランサやめたの。
で、その分Xeon×2+メモリ4Gのサーバを4台増強しました。
コストは2/3で、サーバはみんな遊ん
Re:本当にアクセス数なのかな? という疑い (スコア:0)
だとしたら、ロードバランサなんか検討するだけ無駄なのは当たり前だと思うけど。
私や#359783のACさんが想定している状況では話が噛み合わん(w
Re:本当にアクセス数なのかな? という疑い (スコア:0)
Re:本当にアクセス数なのかな? という疑い (スコア:0)
しかなくっても、サーバごとで別々のシステムだったりすればまた別だけど、
単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
Re:本当にアクセス数なのかな? という疑い (スコア:0)
>単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
それは発想が逆。
ロードバランサがいらないように、フロントエンドはWebサーバだけにわざとしてるの。
Webサーバの一部にDBサーバも同居させてフロントエンドの処理能力をアンバランスにしておいて、それを無理矢理動かすためにロードバランサを入れる
Re:本当にアクセス数なのかな? という疑い (スコア:0)
そもそも、フロントエンドとバックエンドでひとつのシステムでしょ。
それは「単一システム」なの。
>Webサーバの一部にDBサーバも同居させてフロントエンドの処理能力をアンバランスにしておいて、
>それを無理矢理動かすためにロードバランサを入れる
Re:本当にアクセス数なのかな? という疑い (スコア:0)
「Webサーバしか」ってのは「ロードバランシングの対象が」って意味です。
中途半端な書き方ですんません。
これで誤解解けるかな?
Re:本当にアクセス数なのかな? という疑い (スコア:0)
想定しているものが違うって言うのなら、あなたが想定しているものが何なのか書かないと話にならないでしょ。
って言うか、一般的な話をする上で、レアなアプリケーションを持ち出して「ロードバランサは絶対必要だ」って言っても全然説得力無いんですが。
特別なものには特別な仕掛けが必要。それだけでしょ。
トラフィックの分散という話の中で一般的に主要なアプリケーションとなるhttpではロードバランサは不要。
これがウチの結論。
何だか、この一連の応答で「ロードバランサ必要
Re:本当にアクセス数なのかな? という疑い (スコア:0)
>あなたが想定しているものが何なのか書かないと話にならないでしょ。
あなたの会社のネットワークは外部とhttpでしか通信しないんですか?
それはともかく、同じhttpにしても複数のシステムがロードバランサの配下にあったり、
ストリーミングサーバがあったりで、ぶっちゃけていえば通信全部ですかね。
>トラフィックの分散という話の中で一般的に主要なアプリケーションとなるhttp
想定している状況が違うっぽいって書いてるのに。
あなたが分散したいのはhttpだけなのかもしれないけど、(他のACさん
Re:本当にアクセス数なのかな? という疑い (スコア:0)
話にならん。
>構造が単純ならいらん(w
だからさ、「最初から構造が単純だからいらない」んじゃなくて、「サーバを沢山入れて単純な構造にすればロードバランサがいらなくなる」って言ってるだんって。
ロードバランサがいらないように単純な構造にしたんだから、「単純だからいらん」のはあたりまえ。
>DNSに頼るのは本当にしょうもないor身内しか使わないようなシ
Re:本当にアクセス数なのかな? という疑い (スコア:0)
Webでないもの「も」って言って欲しかったなぁ、まあいいや。
あなたのいうようなフロントが1タイプしかないシステムであればいいですが、
ログインサーバありーのパッチサーバありーのゲームサーバありーのみたいなシステムなら
L4スイッチを導入したほうが融通がききます。
もっとも、拠点分散せーやって方が早いですが。
もちろん、L4スイッチなしでやってもでき
Re:本当にアクセス数なのかな? という疑い (スコア:0)
>ログインサーバありーのパッチサーバありーのゲームサーバありーのみたいなシステムなら
まず、何故そうやってサーバを分けなきゃいけないかを考えるべきです。
その単機能のサーバが一台だけって事はこの際無い事にして(一台だけならロードバランサなんていらんから)、複数台のフロントエンドに対応できるシステムで、他のサーバと別ける必要性は何なのかと。
ありがちな理由としては、「特定の機能は(他の機能に引きずられて)コケるとマズいから」というのがありますが、本