Вы можете использовать Nginx в качестве loadbalancer как фронт в вашем веб-приложении.
Например, если ваше приложение работает на Apache (или Tomcat), вы можете настроить учетную вторую экземпляр приложения предприятия на Apache (или Tomcat) на другом сервере.
И потом, вы можете положить Nginx на переднем конце, который будет распределять нагрузку между двумя серверами Apache (или Tomcat или JBoss).
Если вы новичок в Nginx, важно понимать разницу между Nginx против Apache и архитектуру Nginx.
Nginx поддерживает следующие три типа балансировки нагрузки:
Для балансировки нагрузки, вам нужно добавить две вещи в файл конфигурации Nginx:
Во- первых, 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.
Примечание: Как правило, выше, должно быть в соответствии с 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; } .. .. }
В этом алгоритме, входящий запрос отправляется на сервер, который имеет наименьшее количество существующих активных соединений.
Для этого, добавьте ключевое слово “least_conn” в верхней части upstream, как показано ниже.
upstream crmdev { least_conn; server 192.168.101.1:8080; server 192.168.101.2:8080; }
Если у вас есть несколько серверов, перечисленных в least_conn, и если несколько серверов, имеющих аналогичное низкое число существующих активных соединений, то среди этих серверов, один будет выбран на основе взвешенного циклического.
Недостатком циклического и наименее связанный с ним метод заключается в том, что последующее соединение от клиента не будет идти к тому же серверу в пуле. Это может быть хорошо для сеанса, не зависит от конкретного приложения.
Но если ваше приложение зависит от сессии, то, как только начальное соединение устанавливается с определенным сервером, то вы хотите, чтобы все будущие соединения от этого конкретного клиента шли к тому же серверу. Для этого, используйте алгоритм ip_hash, как показано ниже.
upstream crmdev { ip_hash; server 192.168.101.1:8080; server 192.168.101.2:8080; }
Хэш для адресов IPv4, использует первые три октета. Если это IPv6-адрес, используется весь адрес.
Можно также указать вес для конкретного сервера в вашем пуле. По умолчанию все серверы имеет одинаковый приоритет (вес). т.е. по умолчанию значение веса 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 также.
Можно также указать 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; }
В приведенном выше:
В следующем примере, 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 сервера будут недоступны.