タグ付けされた質問 「haproxy」

ssl、ローカルセッション、および負荷分散に関して、相互に関連していると思われる質問がたくさんあります。そのため、この質問については、事前にお詫び申し上げます。 ファイルベースのセッションを使用するWebサイトがあります。サイトの性質はほとんどがhttpですが、一部のセクションはsslです。現在、ファイルベースのセッションのため、sslリクエストは以前のhttpリクエストと同じサーバーにヒットする必要があります。 時間の制約のため、増加したhttpおよびsslトラフィックの負荷を分散するために、可能な限り簡単なことをしたいと考えています。 スティッキーロードバランシングアルゴリズムには2つのオプションがあるようです。 IPベース クッキーベース IPベースのソリューションはおそらく機能しますが、ハッシュアルゴリズムは、サーバーがダウンしたり追加されたときにユーザーが移動するサーバーを変更する可能性があります。これは、現在のファイルベースのセッション設定では望ましくありません。また、ユーザーがWebサイトを閲覧しているときに、IPを合法的に変更することは技術的には可能だと思います。 cookieベースのアルゴリズムはより良いように見えますが、sslで暗号化されたときにcookieを検査できないことは、それ自体に問題があるようです。 私はsslを負荷分散する方法の例を探していましたが、cookieベースの負荷分散を実行でき、別のsslデコーダーを追加することで増加したssl負荷を処理できる設定の明示的な例を見つけることができません。 私が見たほとんどの明示的な例では、ブラウザークライアントとロードバランサーの間にsslデコーダー（通常はハードウェア、apache_mod_ssl、またはnginx）があります。通常、例には次のようなものがあります（http://haproxy.1wt.eu/download/1.3/doc/architecture.txtから変更）。 192.168.1.1 192.168.1.11-192.168.1.14 ------- + ----------- + ----- + ----- + ----- + | | | | | +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | LB1 | | A | | B | | C | | D | + ----- + …

9 ssl  nginx  load-balancing  haproxy 

私たちは最近、stackoverflow.comにHAProxyを実装しました。TProxyを使用して、接続するクライアントのソースアドレスを維持することを決定したため、クライアントのIPアドレスに依存するログやその他のIISモジュールを変更する必要はありません。したがって、パケットは外部インターネットIPアドレスから送信されたかのようになりすまし、実際にはローカルネットワークのローカル192.168.xx HAProxy IPから送信されます。 どちらのウェブサーバーにも2つのNICがあります。1つは静的IP、DNS、デフォルトゲートウェイを備えたパブリックインターネット上のルーティング可能なクラスBアドレスで、もう1つはHAProxyのプライベートIPでポイントされるデフォルトゲートウェイで構成された1つのプライベートなルーティングできないクラスCアドレスです。HAProxyには2つのインターフェース（1つはパブリック、もう1つはプライベート）があり、インターフェース間でパケットを透過的にルーティングし、適切なWebサーバーにトラフィックを転送するジョブを実行します。 イーサネットアダプターインターネット： 説明。。。。。。。。。。。：ネットワークカード＃1 DHCP有効。。。。。。。。。。。： 番号 自動構成が有効。。。。： はい IPv4アドレス。。。。。。。。。。。：69.59.196.217（推奨） サブネットマスク 。。。。。。。。。。。：255.255.255.240 デフォルトゲートウェイ 。。。。。。。。。：69.59.196.209 DNSサーバー。。。。。。。。。。。：208.67.222.222 208.67.220.220 NetBIOS over Tcpip。。。。。。。。：有効 イーサネットアダプタープライベートローカル： 説明。。。。。。。。。。。：ネットワークカード＃2 DHCP有効。。。。。。。。。。。： 番号 自動構成が有効。。。。： はい IPv4アドレス。。。。。。。。。。。：192.168.0.2（推奨） サブネットマスク 。。。。。。。。。。。：255.255.255.0 デフォルトゲートウェイ 。。。。。。。。。：192.168.0.50 NetBIOS over Tcpip。。。。。。。。：有効 各Webサーバーの自動メトリックを無効にし、ルーティング可能なパブリッククラスBにメトリック10、プライベートインターフェイスにメトリック20を割り当てました。 また、これらのレジストリキーの両方を設定しました。 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "DeadGWDetectDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "EnableDeadGWDetect"=dword:00000000 1日に約2回、Webサーバーの1つがDNSに接続できない、またはパブリックインターネット上の他のサーバーに接続できないという問題が発生します。 デッドゲートウェイの検出により、パブリックゲートウェイの停止が誤って検出され、すべてのトラフィックが、現時点でDNSアクセスがなく、これを確認する方法がないプライベートゲートウェイに切り替えられていると考えられます。 デッドゲートウェイの検出が実行されているかどうか、またはWindows 2008サーバーのオプションであるかどうかを確認する方法はありますか？ もしそうなら、Windows 2008サーバーでデッドゲートウェイ検出を無効にする方法はありますか？ DNSを解決できない、または短時間接続できないという他の理由がないのでしょうか。

9 windows-server-2008  networking  tcpip  haproxy 

私は2つのサイト用にHAProxyを持っています。1つはパブリック、もう1つはプライベートです。 www.mysite.com private.mysite.com Atm、私はこのようにhaproxyを使用しています： frontend mysite_https bind *.443 ssl crt /etc/mycert.pem ca-file /etc/myca.pem verify optional no-sslv3 mode http acl domain_www hdr_beg(host) -i www. acl domain_private hdr_beg(host) -i private. acl path_ghost path_beg /ghost/ acl clientcert ssl_c_used redirect location https://www.example.com if path_ghost !clientcert redirect location https://www.example.com if !domain_www !clientcert use_backend bknd_private if …

9 ssl  haproxy  sni 

このスクリプトをさまざまな場所からまとめました。私が期待しているのは、一度実行すると次のことを行うことです： ポート80と443のすべての「新しい」httpトラフィックを一時停止します-それらを「一時停止」するだけで、エラーは発生しません すべての「処理中」の要求が完了したときにhaproxyを正常に再起動します httpトラフィックを一時停止解除し、通常どおりビジネスを継続します。 これはどのように実行されますか？何か逃したことがありますか？ipに基づく何千ものaclルールがhaproxyが参照するファイルに保存されており、毎分数回リロードする必要があります。 #!/bin/sh # hold/pause new requests iptables -I INPUT -p tcp --dport 80 --syn -j DROP iptables -I INPUT -p tcp --dport 443 --syn -j DROP sleep 1 # gracefully restart haproxy /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) # allow new requests to come …

9 iptables  bash  haproxy 

いつ使用すべきか、いつ使用すべきかについての提案はありroundrobinますleastconnか？ 私はroundrobin現在使用しており、バックエンドサーバーの負荷が均等に分散されていないことを確認しました。もちろん他の問題もあるかもしれませんがleastconn、試してみたいと思いますが、ミッションクリティカルなサーバーなので、変更する前に他の経験を参考にしたいと思います。 共有するアイデアはありますか？

9 load-balancing  high-load  haproxy 

サーバーに割り当てられた重みは、その特定のバックエンド内のバランスにのみ影響しますか？ 重みを初めて実装するときに、バックエンドのすべてのサーバーに同じ数を指定すると、重みがない場合と同じになりますか？ 特定の量でウェイトを調整して、シフトするトラフィックの量を計算するにはどうすればよいですか。例えば： サーバーweb1 10.10.10.10重み100 サーバーweb2 10.10.10.11重み100 サーバーweb3 10.10.10.12重量90 サーバーweb4 10.10.10.13重量90

9 load-balancing  haproxy 

私はHAProxy統計を有効にするために複数のWebチュートリアルを試しましたが（google haproxy統計と上位10のリンクを試してください）、これらは古いHAProxyバージョン用であると思います。Ubuntu 16.04 LTSで1.7を実行しています。 ここに私の/etc/haproxy/haproxy.cfgファイルがあります（これには、統計を有効にするためのDatadogによる指示が含まれます）。 listen ....ブロックを削除すると、正常に起動します。そこにあると、次のエラーが発生します。 sudo service haproxy stop sudo service haproxy start Job for haproxy.service failed because the control process exited with error code. See "systemctl status haproxy.service" and "journalctl -xe" for details. journalctlとsystemctlの両方の出力に「サービスの起動が速すぎます haproxy.service - HAProxy Load Balancer Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled) Active: …

8 haproxy 

2つの異なるSSL証明書でHAProxyを構成する必要があります www.example.com api.example.com 今、私はserverfault（Haproxyで複数のSSL証明書を構成する）の投稿から2つの証明書の使用方法を学びましたが、サーバーは両方のドメインで言及されている最初の証明書を引き続き使用します。 構成： frontend apache-https bind 192.168.56.150:443 ssl crt /certs/crt1.pem crt /certs/cert2.pem reqadd X-Forwarded-Proto:\ https default_backend apache-http backend apache-http redirect scheme https if { hdr(Host) -i www.example.com } !{ ssl_fc } redirect scheme https if { hdr(Host) -i api.example.com } !{ ssl_fc } ... URLに応じて、使用する証明書をHAProxyに指示する方法は？ 完全な設定： global log …

8 ssl  ssl-certificate  haproxy 

SSL終了を行うロードバランサーの背後でバックエンドとして実行されているnginx 1.6.2サーバーがあります。バックエンドサーバーへのすべての通信はHTTP経由で行われます。 何が起こっているかの図： /--http---> frontend:80 --\ client --+ +--http---> backend:8000 \--https--> frontend:443 --/ LOAD BALANCER BACKENDS テストのために、私は現時点で1つのバックエンドしか持っていません。ロードバランサーはHAProxy 1.5を実行します。 バックエンドのnginx構成のブロックにかなり典型的なtry_filesディレクティブがありますserver： server { server_name frontend; ... try_files $uri $uri/ =404; ... } 現在、デフォルトで、末尾にスラッシュがないディレクトリにアクセスすると、たとえばhttps://frontend/somedir、nginxはHTTP 301リダイレクトをのような絶対URLに送信しようとしますhttp://frontend:8000/somedir/。 nginxに8000のポート番号を省略させるには、を使用しport_in_redirect offます。 ただしhttp://、nginxが生成しているリダイレクトの最初にスキームを修正することはできません。私がnginxにできる最高のことは、SSLを効果的に取り除くことからhttps://frontend/somedirへのリダイレクトhttp://frontend/somedir/です！ ロードバランサーはX-Forwarded-Protoヘッダーを送信していますが、nginxがリダイレクトを作成するときにそれを参照する方法がありません。実際には、2012年の回答でnginxは完全にこれを行うことはできません。解決策はロードバランサーをnginxに置き換えることです。これは、スタックの大幅な変更を保証するのに些細なことです。 2012年以降、ここで何か変化はありますか？これらのリダイレクトをHAProxyレベルで書き直したくありません。Webアプリケーションからの実際の意図的なHTTPSからHTTPへのリダイレクトは、Location:応答ヘッダーのスキームを常に同じに書き換えると、「re-HTTPSed」になる可能性があります。リクエストが行われた。 編集： 以下は、nginxが絶対Location:URLを生成することを示す最小化された構成です。書き換えはないことに注意してください。 user nobody nobody; worker_processes auto; worker_rlimit_nofile 4096; error_log /var/log/nginx/error.log warn; pid …

8 nginx  haproxy 

誰かがこれがうまくいくかどうか確認するのを手伝ってくれることを願っていますか？3つのサブドメイントラフィックを同じhaproxyホストにルーティングしようとしています。 これが私のセットアップです 1つのインターフェースip 10.10.10.100とdns名haproxy01.mydomain.comを持つhaproxy それに関連付けられた3つのCNAMEレコード。sub1.mydomain.com、sub2.mydomain.comおよびsub3.mydomain.com 着信トラフィックはすべてポート443用です。 3つのポート8081、8082、8083でトラフィックを受け入れる2つのバックエンドアプリケーションサーバーがあるとします。 8081の場合はsub1.mydomain.com、8082の場合はsub2.mydomain.com、8083の場合はsub3.mydomain.com アプリケーションはポート8081トラフィックに対してのみSSLパススルーを必要とするため、8082および8083の他のトラフィックもSSLであるtcpモードを使用する必要があると思いますが、Haproxyで終了できますが、テストではすべてのTCPを使用しましたモード。 これを実現するための私の構成セクションは以下のとおりです。 #Application Setup frontend mytraffic bind *:443 mode tcp acl host_sub1 hdr(host) -i sub1.mydomain.com acl host_sub2 hdr(host) -i sub2.mydomain.com acl host_sub3 hdr(host) -i sub3.mydomain.com use_backend sub1_nodes if host_sub1 use_backend sub2_nodes if host_sub2 use_backend sub3_nodes if host_sub3 option tcplog backend sub1_nodes mode …

8 subdomain  haproxy 

特定の構成で、2台のバックエンドサーバーの前にHAProxyを設定しています。すべての要求はサーバーAに送信する必要があります。ただし、サーバーAが5xxエラーコードを返す場合、すべての要求はバックアップサーバーBに送られます。Aが「up」を返すと、すべての要求がAに送られます。 私はこの構成を試しています： backend example_cluster balance roundrobin option httpclose option forwardfor option httpchk HEAD /ping.html HTTP/1.0\r\nHost:www.example.com http-check disable-on-404 default-server error-limit 1 on-error mark-down redirect scheme https if !{ ssl_fc } server node1 1.2.3.4:80 check observe layer7 server node_back 5.6.7.8:443 backup ssl verify none ただし、次の2つの理由で機能しません。 node1（A）が起動している場合でも、すべてのリクエストはサーバーのnode_back（B）にルーティングされます。 サーバーAに対してhttpcheckが実行されていないようです。以上、syslogにサーバーAのダウンに関するエラーは表示されません。 「option httpchk」行とそのすぐ下の2行を削除すると、また、サーバーAの「observe layer7」も削除します。HAProxyはすべてのリクエストをノードAにルーティングすることで機能します。ただし、サーバーAが500を返す場合、HAProxyはBに切り替わりません。したがって、問題はオプションのhttpchk構成にあると想定しています。

8 proxy  load-balancing  reverse-proxy  haproxy 

64k以上のWebソケットを処理できるアーキテクチャを設計しようとしています。 私たちは最初にAmazon ELBを試しましたが、その設計では、トラフィックやWebSocketの予期しないスパイクは許可されていません。（TCPモードでWebSocketが予期せずタイムアウトする） HAProxyではこれらの制限は適用されませんが、HAとバックエンドサーバー間で維持される〜64kのWebソケットに制限されます。 頭に浮かんだ複数のソリューション： 複数のHAProxyインスタンス、DNSによる負荷分散（Route53には加重オプションがあります） Keepalived、複数の内部IPアドレスを持つ2つのHAProxyインスタンス（実行可能かどうかは不明） これを行うより良い方法はありますか？

8 domain-name-system  load-balancing  haproxy  scalability  websocket 

Webサーバー上の特定のパスに誰かがアクセスしようとした場合、HTTP 204エラーコードを返したいのですが。私は、204エラーを返すようにウェブサーバーの1つを設定し、haproxyにそれをバックエンドとしてポイントすることができました。ただし、情報が送信されていないため、これはhaproxy自体から実行できるはずだと考えました。実際のWebサーバーを気にする必要はありません。 次のように204エラーを生成するバックエンドを作成してみました。 frontend ... ... acl is_always204 path_beg /thisone use_backend always204 if is_always204 ... backend always204 errorfile 404 /etc/haproxy-shared/errors/204.http 204.httpファイルには以下が含まれます。 HTTP/1.0 204 No Content Cache-Control: no-cache Connection: close Content-Type: image/png haproxyを起動すると、次のエラーが発生します。 parsing [/etc/haproxy/haproxy:51] : status code 404 not handled, error customization will be ignored. 私はこれについて間違った方向に進んでいるのではないかと思います。誰かがhaproxyに指定されたACLの一致に対して204を強制的に返す方法を提案できますか？

8 haproxy 

HAProxy 1.5でSSL ID値に基づいてヘッダーキーを設定する方法はありますか？CookieをサポートしていないクライアントのセッションIDとしてSSL IDを使用したいと思います。

8 ssl  haproxy 

perpraクラスターのロードバランシングとIPフェイルオーバーのためにkeepalivedでhaproxyをセットアップしました。それがうまく機能するので、別のサービス/デーモンに同じlb /フェイルオーバーを使用したいと思います。 私はこのようにhaproxyを設定しました： listen my_service 0.0.0.0:4567 mode tcp balance leastconn option tcpka contimeout 500000 clitimeout 500000 srvtimeout 500000 server host1 xxx.xxx.xxx.xx1:4567 check port 4567 inter 5000 rise 3 fall 3 server host2 xxx.xxx.xxx.xx2:4567 check port 4567 inter 5000 rise 3 fall 3 ロードバランシングは正常に機能しますが、サービスはクライアントの実際のIPではなくロードバランサーのIPを認識します。httpモードでは、リモートIPに沿ってhaproxyを渡すのは非常に簡単ですが、tcpモードではどうすればよいですか？これは、負荷分散する必要のあるサービスの性質上重要です。 ありがとう！ヴィート

8 load-balancing  haproxy