1 votos

¿Nginx carga balanceo mala configuración o mal comportamiento?

Actualmente estoy usando Nginx como equilibrador de carga con el fin de equilibrar el tráfico de red entre los 3 nodos, en donde un NodeJS API está ejecutando.

El Nginx instancia se ejecuta en el nodo 1 y cada pedido se realiza con el nodo1. Tengo una mirada de solicitudes acerca de 700k en 2 horas y nginx en configurados para cambiar, en un round robin, entre ellos el nodo1, nodo2 y nodo3. Aquí la conf.d/deva.conf:

upstream deva_api {
    server 10.8.0.30:5555 fail_timeout=5s max_fails=3;
    server 10.8.0.40:5555 fail_timeout=5s max_fails=3;
    server localhost:5555;
    keepalive 300;
}

server {

        listen 8000;

        location /log_pages {

                proxy_redirect off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_http_version 1.1;
                proxy_set_header Connection "";

                add_header 'Access-Control-Allow-Origin' '*';
                add_header 'Access-Control-Allow-Methods' 'GET, POST, PATCH, PUT, DELETE, OPTIONS';
                add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Origin,X-Auth-Token';
                add_header 'Access-Control-Allow-Credentials' 'true';

                if ($request_method = OPTIONS ) {
                        return 200;
                }

                proxy_pass http://deva_api;
                proxy_set_header Connection "Keep-Alive";
                proxy_set_header Proxy-Connection "Keep-Alive";

                auth_basic "Restricted";                                #For Basic Auth
                auth_basic_user_file /etc/nginx/.htpasswd;  #For Basic Auth
        }
}

y aquí la nginx.conf configuración:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

worker_rlimit_nofile 65535;
events {
        worker_connections 65535;
        use epoll;
        multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 120;
        send_timeout 120;
        types_hash_max_size 2048;
        server_tokens off;

        client_max_body_size 100m;
        client_body_buffer_size  5m;
        client_header_buffer_size 5m;
        large_client_header_buffers 4 1m;

        open_file_cache max=200000 inactive=20s;
        open_file_cache_valid 30s;
        open_file_cache_min_uses 2;
        open_file_cache_errors on;

        reset_timedout_connection on;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

El problema es que, con esta configuración, tengo cientos de errores en el error.de registro como la siguiente:

upstream prematurely closed connection while reading response header from upstream

pero sólo en el nodo2 y nodo3. Ya he probado las siguientes pruebas:

  1. aumentar el número de concurrentes Api en cada nodo (en realidad estoy usando PM2 como intra-nodo equilibrador)
  2. eliminar un nodo con el fin de hacer más fácil nginx del trabajo
  3. aplica pesos a nginx

Nada hace que el resultado mejor. En esas pruebas me di cuenta de que no eran sólo los errores en la de 2 nodos remotos (nodo2 y nodo3), así que traté de quitar de la ecuación. El resultado fue que no recibo más errores como que uno, pero empecé a tiene 2 errores:

recv() failed (104: Connection reset by peer) while reading response header from upstream

y

writev() failed (32: Broken pipe) while sending request to upstream

Parece que el problema era debido a la falta de API en el nodo1, la Api probablemente no puede responder todo el tráfico entrante antes de que el cliente espera (este fue, es, supongo). Dijo que, he aumentado el número de concurrentes a la API en el nodo 1 y el resultado fue mejor que los anteriores pero me sigue apareciendo el último 2 errores y no puedo aumento simultáneo de la API en el nodo1 más.

Entonces, la pregunta es, ¿por qué no puedo utilizar nginx como equilibrador de carga con todos mis nodos? Estoy haciendo errores en la configuración de nginx? Hay otros problemas que no me aviso?

EDITAR: Puedo ejecutar algunas pruebas de red entre los 3 nodos. Los nodos se comunican entre sí a través de Openvpn:

PING:

node1->node2
PING 10.8.0.40 (10.8.0.40) 56(84) bytes of data.
64 bytes from 10.8.0.40: icmp_seq=1 ttl=64 time=2.85 ms
64 bytes from 10.8.0.40: icmp_seq=2 ttl=64 time=1.85 ms
64 bytes from 10.8.0.40: icmp_seq=3 ttl=64 time=3.17 ms
64 bytes from 10.8.0.40: icmp_seq=4 ttl=64 time=3.21 ms
64 bytes from 10.8.0.40: icmp_seq=5 ttl=64 time=2.68 ms

node1->node2
PING 10.8.0.30 (10.8.0.30) 56(84) bytes of data.
64 bytes from 10.8.0.30: icmp_seq=1 ttl=64 time=2.16 ms
64 bytes from 10.8.0.30: icmp_seq=2 ttl=64 time=3.08 ms
64 bytes from 10.8.0.30: icmp_seq=3 ttl=64 time=10.9 ms
64 bytes from 10.8.0.30: icmp_seq=4 ttl=64 time=3.11 ms
64 bytes from 10.8.0.30: icmp_seq=5 ttl=64 time=3.25 ms

node2->node1
PING 10.8.0.12 (10.8.0.12) 56(84) bytes of data.
64 bytes from 10.8.0.12: icmp_seq=1 ttl=64 time=2.30 ms
64 bytes from 10.8.0.12: icmp_seq=2 ttl=64 time=8.30 ms
64 bytes from 10.8.0.12: icmp_seq=3 ttl=64 time=2.37 ms
64 bytes from 10.8.0.12: icmp_seq=4 ttl=64 time=2.42 ms
64 bytes from 10.8.0.12: icmp_seq=5 ttl=64 time=3.37 ms

node2->node3
PING 10.8.0.40 (10.8.0.40) 56(84) bytes of data.
64 bytes from 10.8.0.40: icmp_seq=1 ttl=64 time=2.86 ms
64 bytes from 10.8.0.40: icmp_seq=2 ttl=64 time=4.01 ms
64 bytes from 10.8.0.40: icmp_seq=3 ttl=64 time=5.37 ms
64 bytes from 10.8.0.40: icmp_seq=4 ttl=64 time=2.78 ms
64 bytes from 10.8.0.40: icmp_seq=5 ttl=64 time=2.87 ms

node3->node1
PING 10.8.0.12 (10.8.0.12) 56(84) bytes of data.
64 bytes from 10.8.0.12: icmp_seq=1 ttl=64 time=8.24 ms
64 bytes from 10.8.0.12: icmp_seq=2 ttl=64 time=2.72 ms
64 bytes from 10.8.0.12: icmp_seq=3 ttl=64 time=2.63 ms
64 bytes from 10.8.0.12: icmp_seq=4 ttl=64 time=2.91 ms
64 bytes from 10.8.0.12: icmp_seq=5 ttl=64 time=3.14 ms

node3->node2
PING 10.8.0.30 (10.8.0.30) 56(84) bytes of data.
64 bytes from 10.8.0.30: icmp_seq=1 ttl=64 time=2.73 ms
64 bytes from 10.8.0.30: icmp_seq=2 ttl=64 time=2.38 ms
64 bytes from 10.8.0.30: icmp_seq=3 ttl=64 time=3.22 ms
64 bytes from 10.8.0.30: icmp_seq=4 ttl=64 time=2.76 ms
64 bytes from 10.8.0.30: icmp_seq=5 ttl=64 time=2.97 ms

El ancho de banda de verificación, a través de IPerf:

node1 -> node2
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   229 MBytes   192 Mbits/sec

node2->node1
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   182 MBytes   152 Mbits/sec

node3->node1
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   160 MBytes   134 Mbits/sec

node3->node2
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   260 MBytes   218 Mbits/sec

node2->node3
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   241 MBytes   202 Mbits/sec

node1->node3
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   187 MBytes   156 Mbits/sec

Parece que hay un cuello de botella en el túnel OpenVPN porque la misma prueba a través de la eth es acerca de 1Gbits. Dijo que, he seguido esta guía community.openvpn.net pero tengo sólo dos veces el ancho de banda medido antes.

Me gustaría mantener OpenVPN, así que hay otros trucos para hacer en el fin de aumentar el ancho de banda de red o cualquier otro ajuste a la configuración de nginx para que funcione correctamente?

1voto

Andy Puntos 587

Los problemas fueron causados por la lentitud de la red OpenVPN. Al enrutar las solicitudes en Internet después de agregar autenticaciones en cada servidor diferente, obtuvimos los errores hasta 1-2 / día y probablemente se deban a algunos otros problemas ahora.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: