Назад | Перейти на главную страницу

Nginx ip_hash не балансирует нагрузку на соединения с серверной частью Meteor

Я не могу заставить nginx балансировать внутренние соединения с включенным ip_hash. Мне нужны липкие сеансы, поскольку я использую Meteor в бэкэнде с сокетами, но все запросы всегда попадают в один и тот же бэкэнд.

В файле журнала доступа nginx отображаются следующие IP-адреса:

192.168.0.20 - - [xx/xxx/2017:xx:xx:xx +xxxx] "GET /favicon.ico HTTP/1.1"  404 5 "http://xxxx.lokal/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
192.168.0.11 - - [xx/xxx/2017:xx:xx:xx +xxxx] "GET /sockjs/602/dpkl6lfe/websocket HTTP/1.1" 101 55045 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
192.168.0.208 - - [xx/xxx/2017:xx:xx:xx +xxxx] "GET /sockjs/031/cx1kml79/websocket HTTP/1.1" 101 1146677 "-" "Mozilla/5.0 (iPad; CPU OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Version/10.0 Mobile/14D27 Safari/602.1"

Это потому, что все они происходят из одной подсети 192.168.0. *? Если да, то как я могу изменить это поведение?

Вот мой файл конфигурации:

user  www;
worker_processes  4;
error_log  /var/log/nginx/error.log;

events {
 worker_connections  1024;
}

http {
    map $http_upgrade $connection_upgrade {
      default upgrade;
      ''      close;
    }

    upstream demo {
      ip_hash;
      server 127.0.0.1:5000;
      server 127.0.0.1:5001;
    }

    include       mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    gzip on;
    gzip_disable "msie6";

    server_tokens off; # for security-by-obscurity: stop displaying nginx version

     server {
          listen       80;
              server_name xxxx.lokal;

          location / {
            proxy_pass http://demo;
            proxy_redirect      off;
            proxy_set_header    Host              $host;
            proxy_set_header    X-Real-IP         $remote_addr;
            proxy_set_header    X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header    X-Forwarded-Proto $scheme;
            proxy_http_version 1.1;
            proxy_set_header    Upgrade           $http_upgrade; # allow websockets
            proxy_set_header    Connection        "upgrade"; 
            proxy_buffering     off;
            proxy_connect_timeout 43200000;
            proxy_read_timeout    43200000;
            proxy_send_timeout    43200000;

            if ($uri != '/') {
                expires 30d;
            }
    }
}

Да, это происходит потому, что ip_hash использует только первые три октета IP-адреса для выбора внутреннего узла.

Ты можешь использовать hash $remote_addr; директива, чтобы nginx использовал полный удаленный IP-адрес для хеширования. Обратной стороной этого является то, что если узел выходит из строя, все сопоставления хэшей изменяются, и сеансы будут потеряны.

Более подробную информацию о методах отбора апстрима можно найти на сайте документация по восходящему модулю nginx.