N Apacheサーバー間で着信Webトラフィックのバランスをとるにはどうすればよいですか?


12

Heartbeat / Squid / Varnish / etcのようなものを使用して、内部Apacheインスタンス間で着信トラフィックの量のバランスを取りたいと考えています。私のものはすべてVPSで実行されるので、これはハードウェアではなくソフトウェアでなければなりません。この分野での経験はあまりないので、用語を誤用して間違ったパッケージを選択しているとすみません。

私は自分が何を求めているかを説明するために何かを作成しました。緑の側は初期設定の外観であり、青の側はトラフィックの増加によりApacheインスタンスを追加した後の外観です。これはこれらの動作の方法ではないかもしれませんが、理想的にはドメインのDNSにバランサーのIPを追加します。次に、バランサーは各Apacheインスタンス上にある接続の数を確認し(内部IPまたは外部IPの構成リストを介して)、接続を均等に分配します。青色には、2番目のバランサーがあります。ある時点で、バランサーにも助けが必要になると確信しています。

たぶん私はこれについて間違っていますが、「バランサー」がどうあるべきかについての助けと、それらを設定する方法のベストプラクティスを探しています。

どんな助けも素晴らしいでしょう。 代替テキスト


1
申し訳ありませんが、あなたの絵にはどのプログラムを使用しましたか?

1
@Prix - Visioの(ように見えるoffice.microsoft.com/en-us/visio
malonso

回答:


4

ほぼすべての「リバースプロキシ」が、あなたが求めることを行います。

たとえば、Varnish、Pound、およびHAProxyはすべて、それらの機能に長けていますが、違いもあります。個人的には、HAProxyを使うのがベストだと思いますが、それは単なる推測です。

必要な種類を判断するのに役立つロードバランサーに関する記事を読むことをお勧めします:http : //1wt.eu/articles/2006_lb/

また、AmazonのElastic Compute Cloudでソフトウェアを実行し、Elastic Load Balancingを使用するなど、事前に構築されたサービスの使用を検討することもできます。


2

最初に、答えなければならない重要な質問があります。
ユーザーセッションをロードバランサーで処理し、常に同じWebサーバーに接続する必要があるかどうか(生きている場合)。

  • セッションは不要です。この場合、効率的なnginxプログラムをロードバランサーとして使用する必要があります。構成は簡単に設定できます。基本的には、upstream upstream_name { server1, ..., serverN }ステートメントでWebサーバーのリストを指定するだけでよく、その後、特定のドメインに対して単純なproxy_pass upstream_nameディレクティブが必要になります。Nginx wikiを
    参照してください。

  • セッションが必要です。セッションID()をホストするCookieの名前を指定するポンドの同様の設定があり、次にすべてのサーバーのリストがあります。たとえば、Pound setup exempleを参照してください。ID MYCOOKIENAMEBACKEND

複数のロードバランサーの必要性が生じた場合、heartbeat1つのバランサーのみが特定のドメインの仮想IPをマウントするように構成することをお勧めします(セッションが必要な場合、または両方をマウントし、2つのIPアドレスでDNSにフィードするインスタンス)。多分これは、必要になったときに別の質問で詳しく説明する必要があります(ツールが急速に進化するにつれて)。たとえば、このリンク
も参照してください。


1

アーキテクチャにさらなる複雑さと単一障害点を導入する非常に正当な理由が必要です。

ラウンドロビン負荷分散

  • 費用はかかりません
  • 実装と管理が簡単です
  • クライアントにフェイルオーバーを実装-障害を確実に検出できる唯一の場所
  • 暗黙的にサーバーアフィニティをサポートしますが、スティッキーセッションに関連するセッション管理の問題なしにフェイルオーバーを許可します
  • クラスターノードで追加のソフトウェア/ハードウェア/構成を必要としません

ラウンドロビンに関する誤った情報の量には驚かされます。私が冷笑的な人なら、大きな高価な負荷分散ハードウェアを製造しているベンダーと何か関係があるのではないかと思うかもしれません。

私が認める唯一のポイントは

  1. IPV4アドレスは希少になり、したがって高価になりつつありますが、それでもなお多くです。Cisco CSSを言うよりずっと安い。

  2. インターネットはますますWebサービス上で実行されます。すべての開発者が仕様に従ってDNSサポートを実装しているわけではありません。しかし、私が今まで使用したすべてのブラウザは正常に機能します


「追加のソフトウェアは必要ありません」-まあ、webappが共有セッション状態(ログイン、買い物かごなど)を持っている必要があります。また、DNS RRでは、長期間にわたって負荷分散が不均一になる可能性があります。はい、... DNS RRは、実行可能な方法であるが、それは選択肢にはほとんど明らかに優れている
ジェスパーM




0

OK、これはしばらく前に尋ねられました、そして私はパーティーに遅れています。それでも、ここに追加するものがあります。

ジャッキー、あなたはほとんどそれを釘付けしました。図は、ほとんどの小規模および中規模のインストールで負荷分散がどのように処理されるかを示しています。

NakedibleがリンクしたWilly Tarreauによるロードバランシングの概要を読んでください。それはまだ有効であり、良い入門書です。

これらがニーズにどのように適合するかを考慮する必要があります。

  • TCP / IPレベルのロードバランサー(Linux Virtual Serverなど)。接続ごとのオーバーヘッドが最も低く、最高速度で、HTTPを「見る」ことはできません。
  • HTTPレベルのロードバランサー(HAProxy、nginx、Apache 2.2、Pound、Microsoft ARRなど)。より高いオーバーヘッド、HTTPの表示、HTTPのgzip、SSLの実行、スティッキーセッションのロードバランシングの実行が可能です。
  • HTTPリバースプロキシ(Apache Traffic Server、Varnish、Squid)。キャッシュ可能なオブジェクト(一部のWebページ、CSS、JS、画像)をRAMに保存し、バックエンドWebサーバーを使用せずに後続のクライアントに転送できます。多くの場合、L7 HTTPロードバランサーと同じことを実行できます。

ある時点でバランサーにも助けが必要になると確信しているので、2番目のバランサーがあります。

まあ、確かに。ただし、負荷分散は簡単であり、多くの場合、単一のロードバランサーで高速化できます。私はこの記事にリンクします。これは、単一の近代的なサーバーが提供できるパフォーマンスの目安の単なる例として、ウェブに神経を打ちました。必要になる前に複数のLBを使用しないでください。共通のアプローチが必要な場合、最前面のIPレベルロードバランサー(またはDNSラウンドロビン)、HTTPレベルロードバランサー、プロキシおよびwebappサーバーに行きます。

「バランサー」がどうあるべきか、およびそれらの設定方法に関するベストプラクティスを支援します。

トラブルスポットは、セッション状態の処理と、ある程度の障害状態の動作です。ロードバランサー自体のセットアップは比較的簡単です。

2〜4個のバックエンドwebappサーバーのみを使用している場合、オリジンIPアドレスに基づく静的ハッシュは実行可能です。これにより、webappサーバー間でセッション状態を共有する必要がなくなります。各webappノードは全体のトラフィックの1 / Nを認識し、通常の動作では顧客からサーバーへのマッピングは静的です。ただし、大規模なインストールには適していません。

2つの最高のロードバランシングアルゴリズムは、彼らは高負荷、さらには負荷分散の下で良性の振る舞いを持っているという意味で、ラウンドロビンと真のランダム負荷分散されています。 どちらも、Webアプリケーションがwebappノードで利用可能なグローバルセッション状態を持っている必要があります。これがどのように行われるかは、webapp技術スタックに依存します。しかし、一般的にこれに利用できる標準的なソリューションがあります。

静的ハッシュも共有セッション状態も適切でない場合、一般的に選択は「スティッキーセッション」負荷分散とサーバーごとのセッション状態です。ほとんどの場合、これは正常に機能し、完全に実行可能な選択肢です。

バランサーは、各apacheインスタンス上にある接続の数を確認し(内部IPまたは外部IPの構成リストを介して)、接続を均等に分散します。

ええ、いくつかのサイトはこれを使用しています。存在する多くの異なる負荷分散アルゴリズムには多くの名前があります。ラウンドロビンまたはランダム(または重み付きラウンドロビン、重み付きランダム)を選択できる場合は、上記の理由から選択することをお勧めします。

最後に、多くのベンダー(F5、Ciscoなどのハイエンド、fx Coyote Point、Kemp Technologiesをよりリーズナブルな価格で提供)が成熟した負荷分散アプライアンスを提供ていることを忘れないでください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.