Apacheを予算内で負荷分散しますか？

何百万人ものユーザーに途方もない速度を提供するための負荷分散ではなく、物事がうまくいかないときにユーザーを幸せに保つために、可用性と冗長性を確保する負荷分散の概念を理解しようとしています。

私たちは予算に余裕があり、十分な知識があるものに固執しようとしているので、Ubuntu VPSでApacheを実行することは、有名な検索エンジンが私たちを獲得するまでの戦略のようです（土曜日の皮肉が含まれています、注意してください）。

少なくとも私にとっては、利用可能なさまざまなソリューションの完全なジャングルです。Apacheが所有するmod_proxyとHAproxyは、Googleのクイック検索で見つけた2つですが、負荷分散の経験がゼロであるため、私たちの状況に適切なもの、または解決するソリューションを選択する際に何を検討するのかわかりません可用性の問題。

私たちにとって最良の選択肢は何ですか？予算内で高い可用性を実現するにはどうすればよいですか？

私が使用し、VPSで簡単に実装できるソリューションは次のとおりです。

• DNSは、6つの異なる有効なIPアドレスにラウンドロビン（sp？）されます。
• 同じ構成のロードバランサーが3つあり、corosync / pacemakerを使用して6つのIPアドレスを均等に分散しています（各マシンに2つのアドレスが割り当てられます）。
• 各ロードバランサーには、nginx + ワニス構成があります。Nginxは、接続の受信、書き換え、静的なサービスの提供、および負荷分散とキャッシングを行うVarnishへの返送を処理します。

私の意見では、このアーチには次の利点があります。

1. corosync / pacemakerは、LBの1つが失敗した場合にIPアドレスを再配布します。
2. nginxを使用すると、キャッシュを使用せずに、ファイルシステムまたはNFSから特定のタイプのファイルを直接SSL（ビッグビデオ、オーディオ、またはビッグファイル）に提供できます。
3. Varnishは、重量、バックエンドのヘルスチェックをサポートする非常に優れたロードバランサーであり、リバースプロキシとして優れた仕事をします。
4. トラフィックを処理するためにより多くのLBが必要な場合は、クラスターにマシンを追加するだけで、すべてのマシン間でIPアドレスが再調整されます。自動的に行うこともできます（ロードバランサーの追加と削除）。3台のマシンに6つのipを使用して、成長のためのスペースを確保するのはそのためです。

あなたの場合、VPSを物理的に分離することは良い考えですが、IP共有をより困難にします。目標は、耐障害性のある冗長システムと、ロードバランシング/ HAエンドのいくつかの構成を台無しにして、単一障害点（すべてのトラフィックを受信する単一のロードバランサーなど）を追加することです。

また、あなたがApacheについて質問したことも知っていますが、当時はその仕事により適した特定のツール（nginxやニスなど）があります。バックエンドでアプリケーションを実行し、他のツールを使用してアプリケーションを実行するには、Apacheを残します（apacheは良好な負荷分散またはリバースプロキシを実行できないことではなく、ジョブのさまざまな部分をより多くのサービスにオフロードして各部分がうまくいくという問題です）共有です）。

HAproxyは良い解決策です。構成はかなり単純です。

少なくとも2つの他のVPSの前に別のVPSインスタンスが必要です。したがって、ロードバランシング/フェイルオーバーには、最低3つのVPSが必要です。

考慮すべきこともいくつかあります：

1. SSL終了。HTTPS：//を使用する場合、その接続はロードバランサーで終了する必要があり、ロードバランサーの背後ですべてのトラフィックを暗号化されていない接続で渡す必要があります。

2. ファイルストレージ。ユーザーが画像をアップロードした場合、どこに行くのですか？1台のマシンに座っているだけですか？何らかの方法でマシン間でファイルを即座に共有する必要があります-AmazonのS3サービスを使用してすべての静的ファイルを保存するか、ファイルサーバーとして機能する別のVPSを使用することができますが、冗長で非常に安価なのでS3をお勧めします。

3. セッション情報。ロードバランサー設定の各マシンは、ユーザーのセッション情報にアクセスできる必要があります。これは、どのマシンがヒットするかわからないためです。

4. db-別のdbサーバーはありますか？現在マシンが1台しかない場合、新しいマシンがdbサーバーにアクセスできるようにするにはどうすればよいでしょうか？また、別のVPS dbサーバーであれば、それはどの程度冗長ですか。高可用性Webフロントエンドと1つのdbサーバーでの単一障害点を持つことは必ずしも意味がありません。ここで、dbレプリケーションとスレーブプロモーションも考慮する必要があります。

だから、私はあなたの靴の中にいました、それは実際の操作に1日に数百ヒットを行うウェブサイトの問題です。すぐに複雑になります。考えてみてください。

私の投票は、ロードバランサーとしてのLinux Virtual Serverに対するものです。これにより、LVSディレクターは単一障害点とボトルネックになりますが、

1. 私の経験では、ボトルネックは問題ではありません。LVSのリダイレクト手順はレイヤー3であり、非常に（計算上）安価です。
2. 単一障害点は、Linux HAによって制御される2番目のディレクタを持つことで対処する必要があります。

最初のディレクターを最初のLVSノードと同じマシンに配置し、2番目のディレクターを2番目のLVSノードと同じマシンに配置することで、コストを抑えることができます。3番目以降のノードは純粋なノードであり、LVSまたはHAの影響はありません。

また、リダイレクトはアプリケーション層の下で行われるため、好みのWebサーバーソフトウェアを自由に実行できます。

このチェーンはどうですか？

ラウンドロビンdns>両方のマシンのhaproxy>静的ファイルを分離するnginx> apache

おそらく、ucarpまたはハートビートを使用して、haproxyが常に応答するようにします。あなたもSSLが必要な場合、Stunnelはhaproxyの前に座っていました

適切なクラスタリングソフトウェアの使用を検討することをお勧めします。RedHat（またはCentOS） Cluster SuiteまたはOracleのClusterWare。これらは、アクティブ/パッシブクラスターのセットアップに使用できます。また、サービスの再起動に使用でき、深刻な問題がある場合はノード間で失敗します。これは本質的にあなたが探しているものです。

これらのクラスタソリューションはすべて、それぞれのOSライセンスに含まれているため、おそらくコスト面で優れています。NFSマウント、またはクラスター化されたファイルシステムを持つ両方のノードからアクセスされる物理ディスクのいずれかの共有ストレージが必要です。後者の例は、OCFS2またはGFSでフォーマットされた、複数のホストアクセスが許可されたSANディスクです。これにはVMWare 共有ディスクを使用できると思います。

クラスタソフトウェアは、ノード上で常に実行される「サービス」を定義するために、またはそのノードが「アクティブ」な場合にのみ使用されます。ノードはハートビートを介して通信し、それらのサービスも監視します。障害が発生した場合は再起動でき、修正できない場合は再起動できます。

基本的に、トラフィックの宛先となる単一の「共有」IPアドレスを構成します。次に、Apache、およびその他の必要なサービスも定義でき、アクティブなサーバー上でのみ実行できます。共有ディスクは、すべてのWebコンテンツ、アップロードされたファイル、およびApache設定ディレクトリに使用されます。（httpd.confなどを使用）

私の経験では、これは非常にうまく機能しています。

• DNSラウンドロビンやその他の単一障害点ロードバランサーは不要です。すべてが1つのIP / FQDNにヒットします。
• ユーザーがアップロードしたファイルはその共有ストレージに保存されるため、マシンがフェイルオーバーしても問題ありません。
• 開発者は、追加のトレーニングなしで、その単一のIP / FQDNにコンテンツをアップロードします。フェイルオーバーした場合、常に最新の状態になります。
• 管理者は、オフラインマシンを取り出し、パッチを適用し、再起動するなどして、アクティブノードをフェールオーバーできます。アップグレードのダウンタイムを最小限に抑えます。
• 古くなったノードはしばらくの間パッチを適用しないでおくことができ、フェールバックも同様に簡単なプロセスになります。（VMWareスナップショットよりも速い）
• Apacheの構成への変更は共有されるため、管理者がオフラインボックスで変更を加えるのを忘れたため、フェイルオーバー中に奇妙なことは起こりません。

-クリストファー・カレル

最適な負荷分散は非常に高価で複雑になる可能性があります。基本的な負荷分散では、各サーバーがいつでもほぼ同じ数のヒットを処理していることを確認するだけです。

最も単純な負荷分散方法は、DNSに複数のAレコードを提供することです。デフォルトでは、IPアドレスはラウンドロビン方式で構成されます。これにより、ユーザーはサーバー間で比較的均等に分散されます。これは、ステートレスサイトに適しています。ステートフルサイトがある場合は、もう少し複雑な方法が必要です。

ステートフル要件を処理するには、リダイレクトを使用できます。各Webサーバーにwww1、www2、www3などの代替アドレスを与えます。最初のwww接続をホストの代替アドレスにリダイレクトします。この方法でブックマークの問題が発生する可能性がありますが、それらはサーバー全体に均等に分散する必要があります。

または、別のパスを使用して、どのサーバーがステートフルセッションを処理しているかを示すと、ホストを元のサーバーに切り替えたセッションをプロキシできます。これは、障害が発生したサーバーのセッションが、障害が発生したサーバーから引き継いだサーバーに到着したときに問題になる可能性があります。ただし、クラスタリングソフトウェアがなければ、状態は失われます。ブラウザーのキャッシュにより、サーバーを変更する多くのセッションが発生しない場合があります。

障害が発生したサーバーのIPアドレスを引き継ぐようにサーバーを構成することにより、フェールオーバーを処理できます。これにより、サーバーに障害が発生した場合のダウンタイムが最小限に抑えられます。クラスタリングソフトウェアがなければ、サーバーに障害が発生するとステートフルセッションが失われます。

フェイルオーバーがない場合、ユーザーはブラウザーが次のIPアドレスにフェイルオーバーするまで遅延が発生します。

ステートフルセッションではなく、Restfulサービスを使用すると、フロントエンドでのクラスタリングの問題を解決できます。ストレージ側のクラスタリングの問題は引き続き適用されます。

サーバーの前にロードバランサーがある場合でも、サーバーの前にラウンドロビンDNSがある可能性があります。これにより、すべてのロードバランサーが確実に利用されます。彼らはあなたの設計に別の層を追加し、さらに複雑さと別の障害点を追加します。ただし、いくつかのセキュリティ機能を提供できます。

最適なソリューションは、関連する要件によって異なります。

画像、CSSファイル、その他の静的コンテンツなどのコンテンツを提供する画像サーバーを実装すると、アプリケーションサーバーの負荷を軽減できます。

私は通常、同一のOpenBSDマシンのペアを使用します。

• 負荷分散、Webサーバーの監視、および失敗したWebサーバーの処理にRelayDを使用します
• ロードバランサー自体の高可用性のためにCARPを使用します。

OpenBSDは軽量で安定しており、非常に安全です-ネットワークサービスに最適です。

• http: //www.openbsd.org-メインサイト
• http://www.openbsd.org/faq/pf/carp.html-コイのドキュメント
• https://calomel.org/relayd.html-RelayDに関するハウツー情報のまともなセット

開始するには、layer3セットアップをお勧めします。合併症ファイアウォール（PF）のセットアップを回避します。以下に、バックエンドWebサーバーを監視する単純なリレーロードバランサーのセットアップを示す/etc/relayd.confファイルの例を示します。

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

cloudfoundryまたはElastic Beanstalkを使用してec2を提供しましたか、それとも単純に古いAWSが思考を自動スケーリングしましたか。私はそれを使用してきましたが、非常にうまくスケーリングし、弾力性があるため、人間の介入なしにスケールアップ/ダウンできます。

負荷分散の経験がゼロであるとあなたが言うとすれば、これらのオプションは起動するのに最小限の脳の「フライ」を必要とするため、これらのオプションをお勧めします。

それはあなたの時間のより良い使用かもしれません。