10

I want to test some configuration changes to one-way synchronisation between two servers that sit behind a load balancer (this is all Rackspace Cloud infrastructure FYI). The problem I have is that I can't tell which server I've been load balanced to because the IP I'm given is always the IP of the load balancer.

Is there a simple (or even not very simple) way to tell which server I've actually been directed to. I'd ideally like something in the browser because it means non-technical team members can also report issues relatively easily but any ideas on best approaches to this would be appreciated.

Additional info: Both servers run Apache and the load balancer has session persistence configured.

200_success
  • 4,701
  • 1
  • 24
  • 42
Willl
  • 203
  • 1
  • 2
  • 7

2 Answers2

9

If you want to be discreet, just have the webserver identify itself in a Server: response header (RFC 2616 Sec 14.38). For example, in Apache, the information returned in that header is controlled by the ServerTokens directive. Then, it's just a matter of inspecting the response headers in Firebug, Chrome DevTools, or Safari Web Inspector timeline.

If you want to be blatantly obvious, you can have your web application embed the server name in the pages it generates as visible text. You could also report the server name in an HTML comment, which would require View Source to see.

200_success
  • 4,701
  • 1
  • 24
  • 42
  • Thanks @200_success. That all sounds pretty straightforward. Updated my question to say that the servers are running Apache so your link is also useful and relevant. – Willl Feb 02 '15 at 10:14
2

You are not stating which protocol you are using, so I am assuming we are talking https.

Each backend probably know some information about itself, which would uniquely identify that backend. That could be a hostname or a unicast IP address. The backend can include that information in appropriate locations. You could include it in a footer on each page. Or if you think that is too visible, only include it on pages that users wouldn't visit under normal circumstances. Any error page (404, 500, etc.) should always include backend identification.

If your load balancer is only load balancing and not doing anything else, then you would be terminating https on the backend, and whenever a TCP connection is closed and the client reconnects, there is a possibility that the client gets directed to a different backend.

The load balancer could remember the most recently used backend for all client IP addresses seen within the last hour in order to reuse the same backend most of the time. Any more detailed information such as cookies and user id would be out of reach for the load balancer, so it couldn't use that to keep a user on the same backend.

This means any identification of which backend a user is using should be taken with a grain of salt, as the user could have moved between backends between the time where they experienced a problem and the time where they found out which backend they were using. But it is still valuable information, as in most cases it will help locate relevant logs quicker.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • Thanks Kasperd, that's helpful. I've updated the question to note that session persistence is configured on the load balancer. – Willl Feb 02 '15 at 10:13