Я хочу протестировать некоторые изменения конфигурации для односторонней синхронизации между двумя серверами, которые находятся за балансировщиком нагрузки (это вся инфраструктура Rackspace Cloud, к сведению). У меня проблема в том, что я не могу сказать, на каком сервере была выполнена балансировка нагрузки, потому что предоставленный мне IP-адрес всегда является IP-адресом балансировщика нагрузки.
Есть ли простой (или даже не очень простой) способ узнать, на какой сервер я был направлен? В идеале я бы хотел что-то в браузере, потому что это означает, что нетехнические члены команды также могут относительно легко сообщать о проблемах, но любые идеи о лучших подходах к этому будут оценены.
Дополнительная информация: на обоих серверах запущен Apache, и в балансировщике нагрузки настроено сохранение сеанса.
Если вы хотите соблюдать осторожность, просто попросите веб-сервер идентифицировать себя в Server: заголовок ответа (RFC 2616, раздел 14.38). Например, в Apache информация, возвращаемая в этом заголовке, контролируется ServerTokens директива. Затем нужно просто проверить заголовки ответов в Firebug, Chrome DevTools, или Временная шкала Safari Web Inspector.
Если вы хотите быть явно очевидным, вы можете заставить свое веб-приложение встроить имя сервера в страницы, которые оно генерирует, в виде видимого текста. Вы также можете указать имя сервера в HTML-комментарии, для просмотра которого потребуется View Source.
Вы не указываете, какой протокол используете, поэтому я предполагаю, что мы говорим о https.
Каждый бэкэнд, вероятно, знает некоторую информацию о себе, которая однозначно идентифицирует этот бэкэнд. Это может быть имя хоста или одноадресный IP-адрес. Серверная часть может включать эту информацию в соответствующие места. Вы можете включить его в нижний колонтитул на каждой странице. Или, если вы считаете, что это слишком заметно, включите его только на те страницы, которые пользователи не будут посещать при обычных обстоятельствах. Любая страница с ошибкой (404, 500 и т. Д.) Всегда должна включать идентификацию серверной части.
Если ваш балансировщик нагрузки выполняет только балансировку нагрузки и больше ничего не делает, тогда вы завершаете https на бэкэнде, и всякий раз, когда TCP-соединение закрывается и клиент повторно подключается, существует вероятность того, что клиент будет перенаправлен на другой бэкэнд.
Балансировщик нагрузки может запоминать последний использованный бэкэнд для всех клиентских IP-адресов, замеченных в течение последнего часа, чтобы большую часть времени повторно использовать один и тот же бэкэнд. Любая более подробная информация, такая как файлы cookie и идентификатор пользователя, будет недоступна для балансировщика нагрузки, поэтому он не может использовать ее для удержания пользователя на одном сервере.
Это означает, что любая идентификация того, какой бэкэнд использует пользователь, должна восприниматься с недоверием, поскольку пользователь мог перемещаться между бэкэндами между моментом, когда у него возникла проблема, и моментом, когда он узнал, какой бэкэнд он использовал. Но это по-прежнему ценная информация, поскольку в большинстве случаев она помогает быстрее найти нужные журналы.