2011-06-30 9 views
4

リバースプロキシまたはロードバランサとして使用する2つのWebサーバーと1台のサーバーがあります。 2つのWebサーバーには、ロードバランサと同様に、実在IPとパブリックIPがあります。ロードバランササーバーはまだ構成されていません。これは、Webアプリケーションに最適なオプションを決定しなかったためです。私は、1つのロードバランサが危険であることを認識しています。なぜなら、「単一障害点」があるからです。3台のサーバーでPHP Webアプリケーションをロードバランシング

2つのWebサーバーが同じドメインと異なるサブドメインを持つ複数のPHPアプリケーション/バーチャルホスト(Apacheの+のFastCGIの)が含まれています。彼らはすべてセッション、クッキーを使用し、SSLを必要とするものもあります。私の主な目標は、着信接続を純粋に半分に分割し、それらを2つのWebノードに転送することです。 1つのWebノードがオフラインになると、もう1つのノードはすべての接続を受け入れる必要があります。そして必要ならMemcacheとのセッション共有もできると思います。

私はnginxの、HaProxyと私はネット上で見つけることができる任意の他のアプリケーションについて読みました。しかし、私はので、決めることができません。

1)私は、ロードバランサとして使用することができます1つのサーバーを持っているが、私はネット上で見つかったすべての設定は、2ロードバランサノードを必要とします。 2)SSL証明書をロードバランサまたはWebノードにどこにインストールすればよいかわからないし、HTTPS接続を使用しているときにはどのソリューションが最適なのかわからない。

ご協力いただきありがとうございます。

+0

lightyについても考えてみてください - http://www.lighttpd.net/ – Brian

答えて

4

私は同様のセットアップでHAProxyを使用していると私は非常にそれをお勧めします。 1台のサーバーで非常にうまく動作し、高可用性が必要な場合に備えて負荷分散に2台のサーバーが必要です。

あなたが求める構成でそれを設定する方法についての詳細な説明を提供するようthisなど多くのチュートリアルがあります。

1

私はちょうど昨日2 PHP-FPMサーバ、1つのMemcacheのサーバと1台のMySQLサーバが存在している背後に、ロードバランサとしてnginxのサーバーの構成を作成しました。 nginxのはUpstreaming機能を使用して構成され、関連の設定行は次のようなものです:

html { 

    ... 

    # loadbalancing   
    upstream myLoadBalancer { 
     ip_hash; # makes sure same user uses the same server, not 100% effective - application 
       # should handle this; in my case 1 Memcached and 1 MySQL servers commonly used 
       # by all App-servers work just fine. I store sessions in Memcache, so Session 
       # management isn't a problem at all. Its shared across all App-servers. 
     server 192.168.1.10:9000; # location of my first php-fpm server 
     server 192.168.1.11:9000; # second php-fpm server 
     # server aaa.bbb.ccc.ddd:80; # let's say, an Apache server 
    } 

    #vhost 
    server { 
     listen 80; 
     server_name mydomain.com; 
     index index.php; 

     location ~* \.php$ { 
      gzip on; 
      try_files $uri =404; 
      include fastcgi_params; 
      fastcgi_pass myLoadBalancer; 
      fastcgi_index index.php; 
      fastcgi_param SCRIPT_FILENAME /path/to/webdir$fastcgi_script_name; 
      fastcgi_param PATH_INFO $fastcgi_script_name; 
     } 
    } 
} 

HTTPS:私は間違っていないよなら、彼らはnginxのロード・バランサにインストールする必要がありますは - 自分を試したことがありません。クライアントの要求がApp-serverに渡されると、その要求は処理され、要求がフェッチされてNGINXに返されます。 NGINXは、クライアントに応答を中継する前に、コンテンツを暗号化します。もちろんその理論。しかし、私は100%正当ですNGINXはSSLをかなり簡単に処理できます。これは、さまざまなCLIのFASTCGI機能と組み合わせると、最も高速で最も強力なプロキシ/バランサーであり、優れたWebサーバーです。

注:これは運用環境ではなく、テストケースのシナリオです。プロダクション環境には、多くの安全な設定が必要です。次のリソースが使用の可能性:あなたが1台の以上のWebサーバーにHTTPSをしたいどのような状況で

0

、あなたの理想的なソリューションは、nginxのは、目の前にインストールされていることであろうあなたのWebサーバー。ロードバランシングにも使用できますが、より複雑な設定オプションが必要な場合は、NginxリクエストをHAProxyインスタンスに転送することをお勧めします。どちらのサービスも最小限のリソースしか使用しないため、両方を実行することについて心配する必要はありません。

私は、3台のサーバーしか持たず、冗長ロードバランサを必要としないという考え方に精通しています。私は実際にスケーリングアーキテクチャ用のeBookを作成しました.23-4台のサーバと1台のロードバランサを持ついくつかの例があります。たぶんそれはより多くの情報を提供し、あなたが始めるのを助けることができます。

0

ただ1つのHAProxyノードで必要な作業を行うことができます(ただし、単一障害点が残ります)。

私はtutorial for installing HAProxy on Rackspace Cloudを書いています。これは、Ubuntuの設定に合わせることができます。 cookieオプションを使用すると、セッションの永続性を強化することもできます。ボックス間でセッションを共有する必要はなく、セッションが途中でダウンするとセッションが失われます。

HAProxyで標準HTTPトラフィックのバランスをとったら、mode tcpオプションを使用してSSLを送信することができます。これにより、リクエストにCookieを挿入することはできませんので、sourcebalanceモードを使用してください。これはユーザーのIPに基づいてバランスが取れますので、追加のノードを追加しない限り、セッションの途中では変更されません。

SSL証明書は、HAProxyがTCPトラフィックのバランスをとっているため、両方のWebノードにインストールされます。ちなみに、実際の高可用性ソリューションのMySQL接続を含め、TCP経由のものであればこのバランスモードを使用できます。

関連する問題