イントロ #
プロキシ サービスは、7 つ以上のサービスへのクライアントの接続を透過的に管理し、アプリケーション レベル (OSI モデルの第 XNUMX 層) で高度なデータまたは接続処理を提供するように設計されたソフトウェアです。これを実現するために、プロキシ サービスはクライアントとの接続を XNUMX つ確立し、サーバーとの接続をもう XNUMX つ確立して、それらの間のシームレスな接続を確保することを目指します。
プロキシサービス（実質的にリバースプロキシとして機能する）を介して負荷分散を実装する場合、スムーズな接続を実現するためにタイムアウトをカスタマイズすることが重要です。クライアントやアプリケーションサービスの特性によっては、デフォルトのタイムアウト値では不十分な場合があります。タイムアウト関連のエラーは、次のシステムログに記録されます。 / var / log / syslogそのため、潜在的な問題がないかこのファイルを確認することが重要です。
この記事では、プロキシ サーバーでよくあるタイムアウトの問題を分析および特定するための洞察を提供します。調査する重要な情報は、タイムアウトがバックエンド側で発生するか、クライアント側で発生するかです。この区別ができたら、適切なタイムアウト調整を適用できます。
バックエンド側のタイムアウト #
バックエンド側でタイムアウトが発生している場合は、対応するメッセージが次のように表示されます。
21 月 09 日 23:06:01 noid-ee-01 ポンド: noid-proxy-farm-01、サービス noid-service-10.100.200.10、バックエンド 443:7、(830ff85700b21) エラー コピー サーバー 継続: 接続がタイムアウトしました 09 月 23 日 06:01:01 noid-ee-01 ポンド: noid-proxy-farm-10.100.200.11、サービス noid-service-443、バックエンド 7:832、(8ff700d21b09) エラー コピー サーバー 継続: 接続がタイムアウトしました 23 月 16 日 01:01:01 noid-ee-10.100.200.10 ポンド: noid-proxy-farm-443、サービス noid-service-7、バックエンド 799926700:21、 (09ff23) エラー コピー サーバー 継続: 接続がタイムアウトしました 18 月 01 日 01:01:10.100.200.10 noid-ee-443 ポンド: noid-proxy-farm-7、サービス noid-service-830、バックエンド 6700:21、(09ff23bc19) エラー コピー サーバー 継続: パイプが壊れています 01 月 01 日 01:10.100.200.10:444 noid-ee-7 ポンド: noid-proxy-farm-15、サービス noid-service-5、バックエンド 8:700、(21f09f23a24c01) connect_nb: ポーリングがタイムアウトしました 01 月 01 日 10.100.200.11:443:7 noid-ee-79 ポンド: noid-proxy-farm-9、サービス noid-service-7700、バックエンド21:09、(23ff24a01a01) エラー コピー サーバー 継続: 接続がタイムアウトしました 01 月 10.100.200.10 日 443:7:79 noid-ee-28 ポンド: noid-proxy-farm-700、サービス noid-service-XNUMX、バックエンド XNUMX:XNUMX、(XNUMXffXNUMXaXNUMXbXNUMX) エラー コピー サーバー 継続: 接続がタイムアウトしました
これらのバックエンドタイムアウトエラーは、関連する ファーム, サービス, バックエンド エラーに関連付けられている情報。この情報により、問題にリンクされているバックエンドが明確に識別されます。複数のファーム、サービス、またはバックエンドがタイムアウトの問題に関係している場合は、潜在的なネットワークの問題を調査するために、追加情報を収集する必要がある場合があります。
ファーム ログを有効にすると、以下のログの抜粋に示すように、特定のバックエンドが最初は迅速に応答したが、突然タイムアウトの問題に遭遇したインスタンスが明らかになることがあります。
25 月 19 日 57:04:01 noid-ee-01 ポンド: noid-proxy-farm-185.106.182.130、my.service.com 25 - - [2024/Jan/19:57:04:0000 +1.1] "GET /myserv/ HTTP/200" 9 3.0 "" "Mozilla/01 (compatible; ...)" (noid-service-10.100.200.10 -> 443:XNUMX) 0.039秒 25 月 19 日 57:04:01 noid-ee-01 ポンド: noid-proxy-farm-88.111.111.111、my.service.com 25 - - [2024/Jan/19:57:04:0000 +1.1] "GET /myserv/ HTTP/200" 9 3.0 "" "Mozilla/01 (compatible; ...)" (noid-service-10.100.200.10 -> 443:XNUMX) 0.035秒 25月19日 57:04:01 noid-ee-01 ポンド: noid-proxy-farm-01、サービス noid-service-10.100.200.10、バックエンド 443:7、(8fcd0eb700fXNUMX) connect_nb: ポーリングがタイムアウトしました 25 月 19 日 57:04:01 noid-ee-01 ポンド: noid-proxy-farm-01、サービス noid-service-10.100.200.10、バックエンド 443:7、(8fcd0eb700f10.100.200.10) バックエンド 443:25 接続: 接続がタイムアウトしました 19 月 57 日 04:01:01 noid-ee-7 ポンド: noid-proxy-farm-8、(0fcd700eb10.100.200.10f443) バックエンド 01:25 がファーム内で停止 (強制終了) しました: 'noid-proxy-farm-19'、サービス: 'ocp-ocuco-com' 57 月 04 日 01:01:01 noid-ee-10.100.200.10 ポンド: noid-proxy-farm-443、サービスnoid-service-7、バックエンド 8:0、(700fcdXNUMXebXNUMXfXNUMX) バックエンドが停止しました (強制終了)
この動作は、バックエンドが接続制限に達し、追加の接続を妨げていることを示している可能性があります。または、バックエンドが接続を十分な速さで解放していないためにボトルネックが発生していることを示している可能性があります。この問題に対処するには、バックエンドを監視し、より多くの接続を許可したり、バックエンドを追加してサービスをスケーリングしたりするなどの最適化を実装することをお勧めします。
同じサービス内で特定のバックエンドのみにタイムアウトの問題が発生している場合は、その特定のバックエンドに、アプリケーションの配信が遅い、またはネットワークの問題に関連する問題がある可能性があります。これらのエラーの解決策または軽減策を以下に概説します。
クライアント側のタイムアウト #
逆に、クライアントのタイムアウトは、 syslog 次の形式で：
18 月 07 日 31:38:01 noid-ee-01 ポンド: noid-proxy-farm-7、(8862187700f12.91.1.78) 18 から読み取りエラー: 接続がタイムアウトしました 07 月 31 日 43:01:01 noid-ee-7 ポンド: noid-proxy-farm-8863、(71700f12.2.1.105c18) 07 から読み取りエラー: 接続がタイムアウトしました 32 月 03 日 01:01:7 noid-ee-886275 ポンド: noid-proxy-farm-700、(12.41.1.58f18e07) 32 から読み取りエラー: 接続がタイムアウトしました 07 月 01 日 01:7:8880 noid-ee-84700 ポンド: noid-proxy-farm-12.88.1.67、 (18f07d32) 16 から読み取りエラー: 接続がタイムアウトしました 01 月 01 日 7:8880933700:12.3.1.158 noid-ee-XNUMX ポンド: noid-proxy-farm-XNUMX、(XNUMXfXNUMX) XNUMX から読み取りエラー: 接続がタイムアウトしました
ログにファームまたはサービスの情報がない場合、クライアントの要求がプロキシに正しく到達しなかったことを示します。クライアントは HTTP 要求の実行に長い時間がかかり、プロキシは要求元のサービスを認識しません。IP アドレスの配列は、問題が内部ネットワーク、外部クライアント、または特定のファイアウォールを介して到着するクライアントに関係するかどうかを識別するのに役立ちます。
さらに、外部クライアントの場合、その正当性を確認することが重要です。AbuseIP サービスを利用すると、そのような情報の収集に役立ちます。
さらに、クライアント タイムアウトの問題に対処するには、プロキシが接続を途中で終了していないことを確認することが重要です。プロキシによる接続の早期切断を回避するには、接続タイムアウトとバックエンド タイムアウトの合計がクライアント タイムアウトよりも小さいことを確認してください。
これらのエラーに対処または軽減するための情報については、以下を参照してください。
バックエンド側のタイムアウトを修正 #
ネットワーク層検証 #
まず、ネットワーク層の安定性を確認し、重複パケット、パケット損失、またはレイテンシの大幅な変動がないことを確認することが重要です。ネットワーク層の検証を実行するには、次の手順に従います。
1. ロードバランサーからバックエンドに ping を実行し、数分間実行させます。
root@noid-ee-01:~# 10.100.200.10 にpingを実行します
2. 実行中の ping 応答を観察します。
PING 10.100.200.10 (10.100.200.10) 56(84) バイトのデータ。 64 からの 10.100.200.10 バイト: icmp_seq=1 ttl=64 time=0.395 ms 64 からの 10.100.200.10 バイト: icmp_seq=2 ttl=64 time=0.626 ms 64 からの 10.100.200.10 バイト: icmp_seq=3 ttl=64 time=0.178 ms [...] 64 からの 10.100.200.10 バイト: icmp_seq=21 ttl=64 time=0.502 ms 64 からの 10.100.200.10 バイト: icmp_seq=22 ttl=64 time=0.638 ms 64 バイト10.100.200.10: icmp_seq=23 ttl=64 time=0.573 ms ^C --- 10.100.200.10 ping 統計 --- 送信パケット 23 個、受信パケット 23 個、パケット損失 0%、時間 140 ミリ秒、rtt 最小/平均/最大/平均偏差 = 0.178/0.539/0.8540.141/XNUMX ミリ秒
この応答は、ネットワークが安定しており、パケットの損失や遅延の問題がないことを示しています。ネットワーク層の信頼性を確認するには、ping テスト中に異常がないことを確認してください。
さらに、問題が再現されたときに tcpdump を実行すると、ネットワーク トラフィックを分析して、通信が遅延したり、特定のパケットが失われたりした特定の瞬間を正確に特定できます。次のコマンドを使用します。
root@noid-ee-01:~# tcpdump -i 任意の TCP ポート PORT とホスト BACKENDIP -w /tmp/capture.pcap
このコマンドは、 /tmp/キャプチャ.pcapこれは、Wireshark を使用して分析できます。大量のトラフィックをキャプチャすると、このファイルが急速に大きくなる可能性があるので注意してください。
プロキシタイムアウトの調整 #
さまざまなタイムアウトを調整する ファームの高度な構成 これにより、特にリクエストごとに追加の時間が必要な場合やネットワーク パフォーマンスが低い場合に、アプリケーション サーバーのニーズに合わせてプロキシの動作を調整できます。次の推奨事項を考慮してください。
バックエンド接続タイムアウト: 最大時間を設定する 接続（） 選択したバックエンドに対する操作。 「connect_nb: ポーリングがタイムアウトしました」 が検出された場合は、この値をデフォルトの 20 秒から 30 秒または 40 秒に増やすことを検討してください。タイムアウトが他の根本的な問題に対処している可能性があることを念頭に置き、観察された結果に基づいて値を徐々に増やしてください。
バックエンド応答タイムアウト: メッセージが 「エラー コピー サーバー 継続: 接続がタイムアウトしました」 が識別されます。同様に、このようなメッセージの減少が見られるまで、この値を徐々に増やします。ただし、バックエンド側の根本的な問題が隠れてしまう可能性があるため、この値を過度に増やさないように注意してください。デフォルト値は 45 秒なので、エラーがないかどうかを監視しながら 60 秒以上に増やすことを検討してください。
復活したバックエンドをチェックする頻度: ネットワークまたはアプリケーション サーバーの問題により断続的に HTTP 503 エラー (サービス バックエンドが利用できないことを示す) が発生し、タイムアウトを長くする必要がある場合は、この値を 10 秒から 5 秒に減らすことを検討してください。この調整により、タイムアウトによってバックエンドがダウンしていると誤検出される可能性が軽減されます。プロキシ ロード バランサーは、このコンテキストで特定の問題を軽減できるため、タイムアウトが通常の制限内であるかどうかを分析します。
タイムアウトの正常性を判断するために徹底的な分析を実施してください。プロキシ ロード バランサには、特定のタイムアウト関連の問題に対処し、軽減する機能があります。
詳細については、次の記事を参照してください。
ヘルスチェックを構成する #
Farm Guardian は、バックエンドの可用性に基づいて、バックエンドをアクティブ化または非アクティブ化する目的で使用されます。このシナリオでは、Farm Guardian を活用することで、バックエンドの実際の可用性を確認できます。このプロセスはプロキシとは独立して並行して実行されるため、バックエンドの問題が実際にバックエンド側のボトルネックの原因になっているかどうかを確認する手段となります。さらに、バックエンドがダウンしているとマークされたときにバックエンドの統計を調べることで、そのサーバーによって処理される接続の数を判別し、各バックエンドの接続制限を特定できます。
TCP の FarmGuardian チェックを構成すると、バックエンドとのハンドシェイクに関する問題を特定できます。これは、システムまたは Web サーバー レイヤーのボトルネックを示している可能性があります。一方、HTTP の FarmGuardian チェックを構成すると、バックエンドとのアプリケーション レイヤーの問題を特定し、アプリケーションまたはデータベース レイヤーの潜在的なボトルネックを指摘するのに役立ちます。
クライアント側のタイムアウトを修正する #
ネットワーク層検証 #
ネットワークの安定性を検証するには、別のサーバーまたはマシンから、負荷分散ファームに設定された仮想 IP の IP アドレスに ping テストを実行します。これにより、外部からの視点が確保され、ネットワークの信頼性を確認するのに役立ちます。
正当なクライアントの検証 #
タイムアウトの問題が正当なクライアント、ロボット、または潜在的な攻撃者と関連しているかどうかを識別するために、安全なツールを使用します。タイムアウトが権限のないユーザーと関連している場合は、IPDS ブラックリストや DoS 保護を実装してサービスを保護し、有効で正当なユーザーのみに配信されるようにします。
プロキシタイムアウトの調整 #
さらに、ロードバランサー経由でサービスに接続するクライアントの性質に合わせてプロキシタイムアウトを調整することを検討してください。たとえば、モバイルベースのクライアント、ファイアウォールの問題、または低速ネットワークが応答時間の延長の原因となっている場合は、 クライアント要求のタイムアウト 内のオプション 詳細設定 LSLBファームのデフォルト値は 30 seconds; 特定の要件に応じて、60 秒以上に増やすことができます。クライアント タイムアウト値は、接続タイムアウトとバックエンド応答タイムアウトの合計を超える必要があります。
詳しい情報については、次の記事を参照してください。
