9

EC2アーキテクチャをスケールアウトして、独自の負荷分散を管理したいところまで取り組んでいます。現在、基本的な負荷分散を行うためにHAProxyで構成された一連のマシンがありますが、新しいインスタンスをオンラインにして自動的に（またはほぼ自動的に）HAProxyに参加させる「ベストプラクティス」手段を探しています。

理想的には、システムの負荷を監視するか、数年分の分析データに基づいて大騒ぎのスケジュールを作成し、しきい値またはスケジュールされた時間に達したときに、プロセスに新しいインスタンスを起動させ、その新しいノードを作成しますHAProxyマシン上のシステムに接続して、そのホスト名を構成に書き込み、HAProxyをリロードしてプールの一部にします。

複数のゾーンカバレッジが必要になるほど大きくなった時点でAmazonのELBを検討していますが、それまでは、HAProxyからマシンを追加/削除できる簡単なセットアップが必要です。

このようなものを管理するために支払うことができるサービスがあることは知っていますが、Scalrは非常に特定のインスタンスタイプに制限しているようで、Rightscaleは高すぎるため、他の多くの場合と同様に、独自のソリューションを展開することを検討しています。

残念ながら、独自のソリューションを展開する人は、プロセスに少し戸惑うようです。

4

1 に答える 1

10

このソリューションを考えすぎる必要はありません ;)

HAProxy 構成ファイルでサーバーを「事前構成」するだけです。それらは「ダウン」しているように見え、実際にオンラインにするまでリクエストを受け取ることはありません。

オンラインのマシンが 5 台しかなく、今後 2 年間で 10 台になると予想される場合の例を次に示します。

listen web *:80
    balance source
    server  web1 192.168.0.101:80 check inter 2000 fall 3
    server  web2 192.168.0.102:80 check inter 2000 fall 3
    server  web3 192.168.0.103:80 check inter 2000 fall 3
    server  web4 192.168.0.104:80 check inter 2000 fall 3
    server  web5 192.168.0.105:80 check inter 2000 fall 3
    server  web6 192.168.0.106:80 check inter 2000 fall 3
    server  web7 192.168.0.107:80 check inter 2000 fall 3
    server  web8 192.168.0.108:80 check inter 2000 fall 3
    server  web9 192.168.0.109:80 check inter 2000 fall 3
    server  web10 192.168.0.110:80 check inter 2000 fall 3

この構成を使用すると、少なくとも 1 年間は HAProxy を再起動したり、何らかの厄介なハッキングを行ったりする必要はありません (10 個以上が必要な場合を除き、100 個を追加するだけで準備完了です)。

この構成を自動的に生成する簡単なシェル スクリプトを作成することもできます。実際、プールに 100 台のサーバーを追加する場合は、そのためのスクリプトを作成する必要があります。

于 2011-07-23T10:57:41.227 に答える