Come configurare Nginx come loadbalancer per Apache o Tomcat per HTTP/HTTPS

Puoi usare Nginx come loadbalancer davanti alla tua applicazione web.

Ad esempio, se la tua applicazione aziendale è in esecuzione su Apache (o Tomcat), puoi configurare una seconda istanza della tua applicazione aziendale su Apache (o Tomcat) su un server diverso.

E poi, puoi mettere Nginx nel front-end, che bilancia il carico tra i due server Apache (o Tomcat o JBoss).

Se non conosci Nginx, è importante capire la differenza tra Nginx e Apache e Nginx Architecture.

Nginx supporta i seguenti tre tipi di bilanciamento del carico:

1. round-robin – Questo è il tipo predefinito per Nginx, che utilizza il tipico algoritmo round-robin per decidere dove inviare la richiesta in arrivo
2. meno connesso – Come suggerisce il nome, la richiesta in arrivo verrà inviata al server che ha il minor numero di connessioni.
3. ip-hash – Questo è utile quando vuoi avere la persistenza o la connessione stick della richiesta in arrivo. In questo tipo, l'indirizzo IP del client viene utilizzato per decidere a quale server inviare la richiesta.

1. Definisci upstream e proxy_pass in Nginx Config File

Per il bilanciamento del carico, devi aggiungere due cose al file di configurazione di nginx:1) upstream 2) proxy_pass

In primo luogo, a monte: Specifica un nome univoco (può essere il nome della tua applicazione) ed elenca tutti i server che verranno bilanciati dal carico da questo Nginx.

Nell'esempio seguente, "crmdev" è il nome dell'upstream, che è il nome dell'applicazione in esecuzione su entrambi i singoli server Web Apache (101.1 e 102.2 come mostrato di seguito). Invece di "crmdev", puoi specificare tutto ciò che ti piace qui.

Nota:l'upstream dovrebbe essere definito all'interno del tuo contesto "http" di Nginx.

upstream crmdev {
    server 192.168.101.1;
    server 192.168.101.2;
}

Nota:se i singoli server sono in esecuzione su una porta diversa (diversa dalla porta 80), specificare il numero di porta come mostrato di seguito nell'upstream

upstream crmdev {
    server 192.168.101.1:8080;
    server 192.168.101.2:8080;
}

Secondo, proxy_pass: Specifica il nome univoco a monte che è stato definito nel passaggio precedente come proxy_pass all'interno della sezione "posizione", che sarà nella sezione "server", come mostrato di seguito.

server {
  listen 80;
  
  location / {
    proxy_pass http://crmdev;
  }
}

Nota:in questo esempio, nginx stesso è in ascolto sulla porta 80, come mostrato sopra dal parametro listen.

Tieni presente che puoi anche utilizzare proxy_pass per configurare Nginx come proxy inverso per Apache/PHP.

2. Definisci upstream e proxy_pass nel file di configurazione predefinito di Nginx

Nota:in genere, quanto sopra dovrebbe essere in http o https come mostrato di seguito.

http {
  upstream crmdev {
   server 192.168.101.1:8080;
   server 192.168.101.2:8080;
  }

  server {
      listen 80;

      location / {
          proxy_pass http://crmdev;
      }
  }
}

Ma, se stai usando default.conf fornito con il file nginx.conf predefinito, non è necessario fornire "http", poiché è già definito nel contesto http.

Nota:per HTTPS, sostituisci il contesto "http" (nella prima riga sopra) con https. Inoltre, nella riga proxy_pass, usa https://{your-upstream-name}

In questo caso, se si utilizza "http" come mostrato sopra, è possibile che venga visualizzato il seguente messaggio di errore della direttiva http non consentita:

Starting nginx: nginx: [emerg] "http" directive is not allowed here in /etc/nginx/conf.d/default.conf:1

Questa è la copia del mio file default.conf, dove ho aggiunto upstream in alto (senza http), quindi ho commentato la posizione predefinita e aggiunto la nuova posizione usando proxy_pass.

# vi /etc/nginx/conf.d/default.conf
upstream crmdev {
    server 127.0.0.1:4080;
    server 127.0.0.1:7080;
}
server {
  listen       3080;
  server_name  localhost;
  
  #location / {
  #    root   /usr/share/nginx/html;
  #    index  index.html index.htm;
  #}
  
  location / {
    proxy_pass http://crmdev;
  }
..
..
}

3. Imposta l'algoritmo meno connesso per Nginx Load Balancer

In questo algoritmo, la richiesta in entrata viene inviata al server che ha il minor numero di connessioni attive esistenti.

Per questo, aggiungi la parola chiave "least_conn" nella parte superiore dell'upstream come mostrato di seguito.

upstream crmdev {
    least_conn;
    server 192.168.101.1:8080;
    server 192.168.101.2:8080;
}

Se hai più server elencati in less_conn, e se più server hanno lo stesso numero basso di connessioni attive esistenti, tra questi server, uno verrà selezionato in base al round robin ponderato.

4. Imposta la persistenza o l'algoritmo permanente per Nginx Load Balancer

Lo svantaggio del metodo round-robin e meno connesso è che la successiva connessione dal client non passerà allo stesso server nel pool. Questo potrebbe andare bene per un'applicazione non dipendente dalla sessione.

Ma se la tua applicazione dipende dalla sessione, una volta stabilita una connessione iniziale con un particolare server, vuoi che tutte le future connessioni da quel particolare client vadano allo stesso server. Per questo, usa l'algoritmo ip_hash come mostrato di seguito.

upstream crmdev {
    ip_hash;
    server 192.168.101.1:8080;
    server 192.168.101.2:8080;
} 

Per l'hash, per l'indirizzo IPv4, vengono utilizzati i primi tre ottetti. Se si tratta di un indirizzo IPv6, viene utilizzato l'intero indirizzo.

5. Opzioni di peso per i singoli server

Puoi anche specificare un peso per un particolare server nel tuo pool. Per impostazione predefinita, tutti i server hanno la stessa priorità (peso). cioè il valore predefinito del peso è 1.

Tuttavia, puoi modificare questo comportamento assegnando un peso a un server come mostrato di seguito.

upstream crmdev {
    server 192.168.101.1:8080;
    server 192.168.101.2:8080;
    server 192.168.101.3:8080 weight 2;
    server 192.168.101.4:8080;
    server 192.168.101.5:8080;
}

In questo esempio, abbiamo un totale di 5 server. Ma il peso sul 3° server è 2. Ciò significa che per ogni 6 nuove richieste, 2 richieste andranno al 3° server e il resto del server riceverà 1 richiesta.

Quindi, questo è utile per distribuire più carico su un server specifico che ha più potenza.

Anche se nell'esempio precedente viene utilizzato il peso con l'algoritmo round-robin predefinito, puoi utilizzare il peso anche per less_conn e ip_hash.

6. Opzioni di timeout per i singoli server:max_fails e fail_timeout

Puoi anche specificare max_fails e fail_timeout su un server particolare come mostrato di seguito.

upstream crmdev {
    server 192.168.101.1:8080 max_fails=3 fail_timeout=30s;
    server 192.168.101.2:8080;
    server 192.168.101.3:8080 weight 2;
    server 192.168.101.4:8080;
    server 192.168.101.5:8080;
}

In quanto sopra:

• Il fail_timeout predefinito è 10 secondi. In questo esempio sopra, questo è impostato su 30 secondi. Ciò significa che entro 30 secondi se si è verificato un numero x di tentativi non riusciti (come definito da max_fails), il server non sarà disponibile. Inoltre, il server rimarrà non disponibile per 30 secondi.
• Il valore predefinito max_fails è 1 tentativo. Nell'esempio sopra, questo è impostato su 3 tentativi. Ciò significa che dopo 3 tentativi falliti di connessione a questo particolare server, Nginx considererà questo server non disponibile per la durata di fail_timeout che è di 30 secondi.

7. Assegna un server di backup in Nginx LoadBalancer Pool

Nell'esempio seguente, il quinto server è contrassegnato come backup utilizzando la parola chiave "backup" alla fine del parametro server.

upstream crmdev {
    server 192.168.101.1:8080 max_fails=3 fail_timeout=30s;
    server 192.168.101.2:8080;
    server 192.168.101.3:8080 weight 2;
    server 192.168.101.4:8080;
    server 192.168.101.5:8080 backup;
}

Quanto sopra renderà il quinto server (192.168.101.5) come server di backup. La richiesta in arrivo non verrà trasmessa a questo server a meno che tutti gli altri 4 server non siano inattivi.