Как я могу узнать, к какому серверу я был сбалансирован?


8

Я хочу протестировать некоторые изменения конфигурации односторонней синхронизации между двумя серверами, которые находятся за балансировщиком нагрузки (это все инфраструктура Rackspace Cloud FYI). У меня проблема в том, что я не могу сказать, к какому серверу у меня была сбалансирована нагрузка, потому что IP-адрес, который мне дают, всегда является IP-адресом балансировщика нагрузки.

Есть ли простой (или даже не очень простой) способ узнать, на какой сервер я на самом деле был направлен. В идеале мне бы хотелось что-то в браузере, потому что это означает, что нетехнические члены команды могут также относительно легко сообщать о проблемах, но любые идеи о лучших подходах к этому будут оценены.

Дополнительная информация: на обоих серверах работает Apache, а для балансировщика нагрузки настроено сохранение сеанса.

Ответы:


8

Если вы хотите быть осторожным, просто попросите веб-сервер идентифицировать себя в Server:заголовке ответа ( RFC 2616 Sec 14.38 ). Например, в Apache информация, возвращаемая в этом заголовке, контролируется ServerTokensдирективой. Затем нужно просто проверить заголовки ответов на временной шкале Firebug , Chrome DevTools или Safari Web Inspector .

Если вы хотите быть очевидным, вы можете сделать так, чтобы ваше веб-приложение встраивало имя сервера в страницы, которые оно генерирует как видимый текст. Вы также можете сообщить имя сервера в HTML-комментарии, для просмотра которого потребуется View Source.


Спасибо @ 200_success. Все это звучит довольно просто. Обновил мой вопрос, сказав, что на серверах работает Apache, поэтому ваша ссылка также полезна и актуальна.
Уиллл

2

Вы не указываете, какой протокол вы используете, поэтому я предполагаю, что мы говорим по https.

Каждый сервер, вероятно, знает некоторую информацию о себе, которая однозначно идентифицирует этот сервер. Это может быть имя хоста или одноадресный IP-адрес. Серверная часть может включать эту информацию в соответствующих местах. Вы можете включить его в нижний колонтитул на каждой странице. Или, если вы считаете, что это слишком заметно, включайте его только на страницы, которые пользователи не будут посещать при нормальных обстоятельствах. Любая страница с ошибкой (404, 500 и т. Д.) Всегда должна содержать идентификацию бэкэнда.

Если ваш балансировщик нагрузки выполняет только балансировку нагрузки и не выполняет никаких других действий, тогда вы будете прерывать https на бэкэнде, и всякий раз, когда TCP-соединение закрывается и клиент повторно подключается, существует вероятность, что клиент будет перенаправлен на другой бэкэнд.

Балансировщик нагрузки может запоминать последний использованный сервер для всех клиентских IP-адресов за последний час, чтобы большую часть времени использовать один и тот же сервер. Любая более подробная информация, такая как файлы cookie и идентификатор пользователя, была бы недоступна для балансировщика нагрузки, поэтому она не могла бы использовать ее, чтобы сохранить пользователя в той же бэкэнде.

Это означает, что любая идентификация того, какой бэкэнд использует пользователь, должна быть сделана с некоторой долей соли, поскольку пользователь мог перемещаться между бэкэндами между временем, когда у него возникла проблема, и временем, когда он узнал, какой бэкэнд он использовал. Но это все еще ценная информация, так как в большинстве случаев она поможет быстрее найти нужные журналы.


Спасибо Касперду, это полезно. Я обновил вопрос, чтобы отметить, что постоянство сеанса настроено на балансировщике нагрузки.
Уиллл
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.