Как установить Nginx в качестве loadbalancer для Apache или Tomcat

Вы можете использовать Nginx в качестве loadbalancer как фронт в вашем веб-приложении.

Например, если ваше приложение работает на Apache (или Tomcat), вы можете настроить учетную вторую экземпляр приложения предприятия на Apache (или Tomcat) на другом сервере.

И потом, вы можете положить Nginx на переднем конце, который будет распределять нагрузку между двумя серверами Apache (или Tomcat или JBoss).

Если вы новичок в Nginx, важно понимать разницу между Nginx против Apache и архитектуру Nginx.

Nginx поддерживает следующие три типа балансировки нагрузки:

1. round-robin — это тип по умолчанию для Nginx, который использует типичный алгоритм циклического перебора, чтобы решить, куда направить входящий запрос
2. least-connected — как следует из названия, входящий запрос будет отправлен на сервер, который имеет меньшее количество соединения.
3. ip-hash — это полезно, когда вы хотите иметь настойчивость, или подключать соединение входящего запроса. В этом типе, клиентский IP-адрес используется, чтобы решить, какому серверу запрос должен быть направлен.

1. Определить upstream и proxy_pass в конфигурационном файле Nginx

Для балансировки нагрузки, вам нужно добавить две вещи в файл конфигурации Nginx:

1. upstream
2. proxy_pass

Во- первых, upstream: Укажите уникальное имя (может быть название вашего приложения) и список всех серверов, которые будут балансировкой нагрузки Nginx.

В следующем примере, «crmdev» это название upstream, которое является именем приложения, которое работает как на индивидуальном сервере Apache (101.1 и 102.2, как показано ниже). Вместо того, чтобы «crmdev», вы можете указать все, что вам нравится.

Примечание: upstream должен быть определен внутри контекста «HTTP» Nginx.

upstream crmdev {
    server 192.168.101.1;
    server 192.168.101.2;
}

 

Примечание: Если отдельные серверы работают на другом порту (кроме порта 80), то указать номер порта, как показано ниже в upstream

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

 

Во- вторых, proxy_pass: Укажите уникальное имя upstream которое было определено в предыдущем шаге, как proxy_pass внутри вашей секции «Location», которая будет в соответствии с разделом «server», как показано ниже.

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

 

Примечание: В этом примере, Nginx сам прослушивает порт 80, как показано выше, с помощью параметра listen.

Обратите внимание, что вы также можете использовать proxy_pass для настройки Nginx в качестве обратного прокси для Apache/PHP.

2. Определить upstream и proxy_pass в конфигурационном файле Nginx по умолчанию

Примечание: Как правило, выше, должно быть в соответствии с HTTP или HTTPS, как показано ниже.

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

  server {
      listen 80;

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

 

Но, если вы используете default.conf, который поставляется с файлом по умолчанию nginx.conf, вам не нужно  «HTTP», так как он уже определен в контексте HTTP.

Примечание: Для HTTPS, замените «HTTP» контекст (в 1-й строке выше) на HTTPS. Кроме того, в строке proxy_pass, используйте https: // {-ваше-upstream-имя-}

В этом случае, если вы используете «HTTP», как показано выше, вы можете получить следующую директиву HTTP не допускается сообщение об ошибке:

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

 

Это копия файла default.conf, где я добавил upstream в верхней части (без HTTP), а затем закомментированно местоположение по умолчанию, и добавил новое местоположение с помощью 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. Установка по алгоритму к наименее активному Nginx для балансировки нагрузки

В этом алгоритме, входящий запрос отправляется на сервер, который имеет наименьшее количество существующих активных соединений.

Для этого, добавьте ключевое слово «least_conn» в верхней части upstream, как показано ниже.

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

 

Если у вас есть несколько серверов, перечисленных в least_conn, и если несколько серверов, имеющих аналогичное низкое число существующих активных соединений, то среди этих серверов, один будет выбран на основе взвешенного циклического.

4. Установка Persistence or Sticky алгоритма балансировки нагрузки Nginx

Недостатком циклического и наименее связанный с ним метод заключается в том, что последующее соединение от клиента не будет идти к тому же серверу в пуле. Это может быть хорошо для сеанса, не зависит от конкретного приложения.

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

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

 

Хэш для адресов IPv4, использует первые три октета. Если это IPv6-адрес, используется весь адрес.

5. Параметры весового коэффициента для отдельных серверов

Можно также указать вес для конкретного сервера в вашем пуле. По умолчанию все серверы имеет одинаковый приоритет (вес). т.е. по умолчанию значение веса 1.

Но, вы можете изменить это поведение путем присвоения веса к серверу, как показано ниже.

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;
}

 

В этом примере, мы имеем в общей сложности 5 серверов. Но вес на 3-й сервер со значением 2. Это означает, что для каждого нового запроса 6, 2 запроса пойдет на 3-й сервер, а остальная часть сервера получит по 1 запросу.

Таким образом, это полезно, чтобы распределить больше нагрузки на определенном сервере, который имеет больше мощностей.

Несмотря на то, что в приведенном выше примере, вес используется с алгоритмом круговом по умолчанию, вы можете использовать вес для least_conn и ip_hash также.

6. Параметры времени ожидания для отдельных серверов — max_fails и fail_timeout

Можно также указать max_fails и fail_timeout к конкретному серверу, как показано ниже.

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;
}

 

В приведенном выше:

• По умолчанию fail_timeout составляет 10 секунд. В этом примере выше, это установлено на 30 секунд. Это означает, что в течение 30 секунд, если было х число неудачных попыток (как это определено max_fails), то сервер будет недоступен. Кроме того, сервер будет оставаться недоступным в течение 30 секунд.
• по умолчанию max_fails равен 1 попытки. В приведенном выше примере, это установлено в 3 попытки. Это означает, что после 3 неудачных попыток подключения к этому конкретному серверу, Nginx будет рассматривать этот сервер недоступным в течение всего срока fail_timeout, который составляет 30 секунд.

7. Назначить резервный сервер в Nginx LoadBalancer: Пул

В следующем примере, 5-й сервер помечается как резервное копирование с помощью ключевого слова «backup» в конце параметра сервера.

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;
}

 

Пример выше будет делать 5-сервер (192.168.101.5) в качестве сервера резервного копирования. Входящий запрос не будут передан на этот сервер, если все остальные 4 сервера будут недоступны.