1

私の質問には、haproxy に関する 2 つの部分があります。

質問1：

私が扱っているサービスは、大量の XML ドキュメントのアップロードと、かなり大きな結果のダウンロードを扱っています。アップロードされた XML ドキュメントは、後でワーカーからダウンロードできる応答を生成するためにワーカーによって使用されます。大まかな設定は次のとおりです。

--request--> www.domain.com --> worker(1 または 2).domain.com

www.domain.com は静的コンテンツ サーバーであり、haproxy が常駐する場所でもあります。すべてのリクエストは、最初にここに送信されます。静的コンテンツ (html、画像など) は、www.domain.com で nginx によって提供される必要があります。

ただし、www.domain.com/[upload]/[id1] や www.domain.com/[download]/[id1] などの特定の URL を含むリクエストは、ワーカー自身が処理する必要があります。ここでの追加の問題は、転送が URL に基づいてスティッキーである必要があることです。

例えば：

XML ファイルが www.domain.com/upload/123 にアップロードされたとします。haproxy は、URL にアップロードが含まれていることを確認し、worker1.domain.com または worker2.domain.com にリクエストをルーティングします。後で、www.domain.com/download/123 への GET 要求が行われると、最初に同じ ID (123) でアップロード要求を処理したワーカーにルーティングするために haproxy が必要になります。基本的に、特定の ID のアップロード リクエストを worker1 に送信し、同じ ID のダウンロード リクエストを worker2 に送信することはできません。haproxyを使用すると、このようなことが可能になりますか?

質問2：

ファイルを www.domain.com/upload にアップロードし、haproxy がそれを worker1.domain.com にルーティングした場合、ファイル全体が haproxy を通過しますか? つまり、worker1.domain.com はファイルを受信しますが、転送を行っているため、haproxy も同じ帯域幅を使用しますか?

どうもありがとうございました！

4

1 に答える 1

0
  1. このソリューションには、ワーカーごとに 1 つのバックエンドと負荷分散バックエンドが必要です。
    • haproxy はすべての通常のリクエストを一般的なバックエンドに送信します
    • ワーカーはクライアントに Cookie を設定します
    • 後続のリクエストは、(hdr_sub(Cookie) を使用して) Cookie を検査することにより、ワーカー固有のバックエンドに送信されます。たとえば、use_backend worker1 if { hdr_sub(Cookie) SRV=1 }
  2. はい、ファイル全体が haproxy を通過します。ワーカーがクライアントをワーカーに直接リダイレクトできるようにすることができます。その場合、クライアントは引き続きワーカーを使用します。ただし、ワーカーがダウンした場合、クライアントは別のワーカーを見つける方法がありません。ユースケースによっては、ファイル全体に haproxy プロキシを使用しても問題はありませんが、非常にパフォーマンスが高くなります。

テーブルを使用してバックエンドの選択を行うことができるかもしれませんが、その方法はわかりません。ただし、バックエンドでテーブルに保存し、フロントエンドで読み取ることができます。

于 2012-01-31T17:19:11.537 に答える