元のポートをリッスンしているサービスが応答しない場合に、トラフィックを別のポートにリダイレクトする方法はありますか?

元のポートをリッスンしているサービスが応答しない場合に、トラフィックを別のポートにリダイレクトする方法はありますか?

これはかなり具体的な質問ですが、答えを見つけることができませんでした。Ubuntu 16.04 LTS の LXC コンテナーで一連のサービス (具体的にはゲーム サーバー) を実行しています。ただし、このサービスは失敗することがわかっており、そのラッパーも同様です。そのため、サービスがハングしたり応答しなくなったりしているときに稼働時間と負荷分散を維持するには、サービスが応答しているかどうかに基づいて、UDP トラフィックと TCP トラフィックの両方をリダイレクトできる必要があります。

シナリオをわかりやすく説明すると、パブリック IP に公開されている LXC コンテナと、ネストされた別の LXC コンテナがあり、iptables によってポート 21025 のトラフィックがネストされたコンテナにリダイレクトされます。そのコンテナ内で、トラフィックを受け入れるサービス ( および ) が応答しない場合はServiceWrapperServiceMainトラフィックは別のポートの別のサービス ( ) に送信される必要がありますServiceFallback。それ以外の場合、トラフィックは予想どおり ServiceWrapper に送信され、ServiceWrapper によって に送信されますServiceMain

私が現在、この種のルーティングを実装しようと試みているのは、HAProxy を使用して と の間で負荷分散を行うことですServiceWrapperが、ServiceFallback一見すると、 と の負荷分散方法に基づいて、HAProxy が追加ポートのリダイレクトを検出または許可しないように見えます。 は、バージョン、ホスト名などのサーバー クエリを容易にするために、別のポートで UDP トラフィックを受け入れます。また、私が知る限り、HAProxy は UDP トラフィックをルーティングまたは検出しません。ServiceWrapperServiceFallbackServiceMain

これを機能させるために半ば必死です。私が実行しようとしている設定は、直接の競合相手のうちの 1 社では機能していたため、可能であることはわかっていますが、競合相手は、それを実現するために使用したパッケージさえも私と共有したがらないようです (当然ですが、まあ)。

答え1

NGINX は必要なことすべてを実行します。UDP ルーティングをサポートし、パッシブ ヘルス チェックとアクティブ ヘルス チェックの両方を備えているため、メイン サービスが実行中かどうかを判断する方法を設定できます。ヘルス チェックが失敗した場合にのみ、バックアップ サービスにフォールバックするように設定できます。

関連情報