☰

Обратный прокси-сервер Nginx отправляет один и тот же запрос на несколько внутренних серверов

tag-icon • tag-icon nginx
Обратный прокси-сервер Nginx отправляет один и тот же запрос на несколько внутренних серверов

У меня есть NGINX в качестве обратного прокси-сервера и два Apache в качестве вышестоящих серверов.

Всякий раз, когда я посещаю example.com (направленный на NGINX), оба сервера Apache получают запрос GET. Это кажется странным, так как NGINX по умолчанию работает на основе метода Round Robin

Вот моя конфигурация:-

upstream apache {
         server 172.18.0.164;
         server 172.18.8.18;
        }


location / {
       proxy_pass http://apache;
    }

Журналы на машине Apache 1:-

192.168.10.236 - - [05/10/2015:07:59:21 -0400] "GET / HTTP/1.0" 200

Журналы на машине Apache 2:-

172.18.8.97 - - [05/10/2015:11:59:27 +0000] "ПОЛУЧИТЬ /wordpress/ HTTP/1.0"

решение1

Прямо изРуководство администратора Nginx:

Включение сохранения сеанса

NGINX Plus поддерживает три метода сохранения сеанса. Методы задаются с помощьюлипкийдиректива.

Theлипкое печеньеметод. С помощью этого метода NGINX Plus добавляет сеансовый cookie к первому ответу от вышестоящей группы и идентифицирует сервер, который отправил ответ. Когда клиент выдает следующий запрос, он будет содержать значение cookie, и NGINX Plus направит запрос на тот же самый вышестоящий сервер:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;

  sticky cookie srv_id expires=1h domain=.example.com path=/;
}

В примере srv_idпараметр задает имя cookie, который будет установлен или проверен. Необязательный expiresпараметр задает время, в течение которого браузер будет хранить cookie. Необязательный domainпараметр определяет домен, для которого устанавливается cookie. Необязательный pathпараметр определяет путь, для которого устанавливается cookie. Это простейший метод сохранения сеанса.

Theлипкий маршрутметод. С помощью этого метода NGINX Plus назначит клиенту «маршрут» при получении первого запроса. Все последующие запросы будут сравниваться смаршрутпараметрсервердиректива для определения сервера, на котором будут проксироваться запросы. Информация о маршруте берется из cookie или URI.

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

Theузнать кукиметод. С помощью этого метода NGINX Plus сначала находит идентификаторы сеансов, проверяя запросы и ответы. Затем NGINX Plus «узнает», какой вышестоящий сервер соответствует какому идентификатору сеанса. Обычно эти идентификаторы передаются в HTTP-cookie. Если запрос содержит уже «изученный» идентификатор сеанса, NGINX Plus перенаправит запрос на соответствующий сервер:

upstream backend {
   server backend1.example.com;
   server backend2.example.com;

   sticky learn 
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h;
}

В этом примере один из вышестоящих серверов создает сеанс, устанавливая cookie-файл «EXAMPLECOOKIE» в ответе.

Обязательный параметр createуказывает переменную, которая указывает, как создается новый сеанс. В нашем примере новые сеансы создаются из cookie «EXAMPLECOOKIE», отправленного вышестоящим сервером.

Обязательный параметр lookupуказывает, как искать существующие сеансы. В нашем примере существующие сеансы ищутся в cookie «EXAMPLECOOKIE», отправленном клиентом.

Обязательный параметр zoneуказывает зону общей памяти, в которой хранится вся информация о липких сессиях. В нашем примере зона имеет имя client_sessionsи размер 1 мегабайт.

Это более сложный метод сохранения сеанса, поскольку он не требует сохранения каких-либо файлов cookie на стороне клиента: вся информация хранится на стороне сервера в зоне общей памяти.

Связанный контент