ロードバランサーの背後にある2つのサーバー間の一方向の同期に対するいくつかの構成変更をテストしたいと思います(これはすべてRackspace Cloudインフラストラクチャの参考情報です)。私が持っている問題は、与えられたIPは常にロードバランサーのIPであるため、どのサーバーに負荷分散されているのかわかりません。
実際にどのサーバーに転送されたかを確認する簡単な(またはそれほど簡単ではない)方法はありますか?技術者以外のチームメンバーも問題を比較的簡単に報告できることを意味しますが、ブラウザーの何かが理想的ですが、これに対する最善のアプローチについてのアイデアはありがたいです。
追加情報:両方のサーバーでApacheが実行され、ロードバランサーでセッションの永続性が構成されています。
目立たないようにしたい場合は、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などのより詳細な情報はロードバランサーには届かないため、ユーザーを同じバックエンドに維持するためにそれを使用することはできませんでした。
これは、ユーザーが問題を経験してから、使用しているバックエンドが判明するまでの間に、ユーザーがバックエンド間を移動する可能性があるため、ユーザーが使用しているバックエンドの識別は、一目でわかるはずです。ただし、ほとんどの場合、関連するログをより早く見つけるのに役立つため、それは依然として貴重な情報です。