ロードバランサーの背後にある2つのサーバー間の一方向の同期に対するいくつかの構成変更をテストしたいと思います（これはすべてRackspace Cloudインフラストラクチャの参考情報です）。私が持っている問題は、与えられたIPが常にロードバランサーのIPであるため、どのサーバーに負荷分散されているのかわからないことです。
実際にどのサーバーにリダイレクトされたかを確認する簡単な（またはそれほど簡単ではない）方法はありますか？技術者以外のチームメンバーも比較的簡単に問題を報告できるため、ブラウザの何かが理想的ですが、これに対する最善のアプローチについてのアイデアはありがたいです。
追加情報：両方のサーバーでApacheが実行され、ロードバランサーでセッションの永続性が構成されています。
回答:
目立たないようにしたい場合は、WebサーバーにServer:応答ヘッダー（RFC 2616 Sec 14.38）で自分自身を識別させるだけです。たとえば、Apacheでは、そのヘッダーで返される情報はServerTokensディレクティブによって制御されます。次に、Firebug、Chrome DevTools、またはSafari Web Inspectorタイムラインで応答ヘッダーを検査するだけです。
露骨に明白にしたい場合は、Webアプリケーションでサーバー名を可視テキストとして生成するページに埋め込むことができます。サーバー名をHTMLコメントで報告することもできます。これには、ソースの表示が必要です。
あなたはあなたが使っているプロトコルを述べていないので、私たちはhttpsを話していると仮定しています。
各バックエンドはおそらくそれ自体についていくつかの情報を知っており、そのバックエンドを一意に識別します。ホスト名またはユニキャストIPアドレスの可能性があります。バックエンドはその情報を適切な場所に含めることができます。各ページのフッターに含めることができます。または、それがあまりにも目立つと思われる場合は、ユーザーが通常の状況ではアクセスしないページにのみ含めます。エラーページ（404、500など）には常にバックエンドIDを含める必要があります。
ロードバランサーがロードバランシングのみで他に何も実行していない場合は、バックエンドでhttpsを終了することになります。TCP接続が閉じてクライアントが再接続すると、クライアントが別のバックエンドに転送される可能性があります。
ロードバランサは、同じバックエンドをほとんどの時間再利用するために、過去1時間以内に確認されたすべてのクライアントIPアドレスに対して最後に使用されたバックエンドを記憶することができます。CookieやユーザーIDなどのより詳細な情報はロードバランサーには届かないため、ユーザーを同じバックエンドに維持するためにそれを使用できませんでした。
これは、ユーザーが問題を経験したときと使用しているバックエンドを見つけたときの間でユーザーがバックエンド間を移動していた可能性があるため、ユーザーが使用しているバックエンドを特定するには、塩の粒を使用する必要があることを意味します。しかし、ほとんどの場合、関連するログをより早く見つけるのに役立つため、それは依然として貴重な情報です。