それ自体が負荷分散されている複数のSSL終端Haproxyインスタンスをどのように設定しますか？
私はこれについて多くの研究と実験を行ってきました、そして私は本当に壁にぶつかっています：
高可用性環境のリバースプロキシとしてHAProxyを設定しようとしています。この環境に出入りするすべてのトラフィックはSSL暗号化されているため、元の設計では、HAProxyにSSLターミネーションを実行させ、トラフィックを平文でエンクレーブに渡し、逆に変換します。これまでのところ、とても良いので、それに関する多くの優れたドキュメントがあります。
問題はこれです。トラフィックの量が多すぎて、単一のSSL終端HAProxyボックスで処理できないため、複数のSSL終端リバースプロキシが必要になります。
さて、私はこれを高く評価し、正しい方向に進んでいるように見える多くの記事を見つけましたが、常に1つのプライマリHAProxyと1つのバックアップで終わりました（たとえば、すべてのハートビートとキープアライブソリューションなど） here および here ）として、またはSSLターミネーションを完全に無視し、ロードバランサーへのDNSラウンドロビンについて話します。
したがって、私が本当に探していたのは、複数のhaproxyssl終端ボックスが同時に負荷を共有できることだと思います。 DNSラウンドロビンの外部でこれを行う方法はありますか？
同じ仮想IPアドレスを共有し、トラフィックをすべてクラスターのように同時に分割する方法があると思いました。 1つのボックスがダウンした場合、フェイルオーバーは上記のkeepalivedメソッドまたは他の方法で対処できます。これは一般的な使用例ではないようです...それも可能ですか？
（もちろん、HAProxyプロセス間でSSLセッションを共有する方法の問題がありますが、それが不可能な場合は、この場合、新しいセッションを時々再確立することはキラーではありません。）
前もって感謝します！
2つのhaproxyインスタンスは、2つの仮想IPを使用して負荷を共有できます。各インスタンスは、そのうちの1つのマスターです。ラウンドロビンDNSは、2つの仮想IP間（したがって、2つのhaproxyインスタンス間）で大まかにバランスを取ります。この方法はSSLでも機能します。ただし、このアクティブ-アクティブ設定についてよく考える理由の1つは、1つのインスタンスがトラフィックの合計だけに対応できない場合、いずれかのインスタンスがダウンすると過負荷になるためです。基本的に、これは、予備の「無駄な」容量を用意するか、一時的なパフォーマンスヒットを受け入れることによってのみ解決できます。
または、SSL終了プロキシの前にTCPモードでhaproxyバランシングを固定することもできます。1つのTCPセッションはバックエンドに固定されるため、必要はありません。再交渉についてあまり心配します。