Итак, поговорим о таком мощном инструмента как nginx. Он очень функционален, и говорить о нем можно бесконечно долго. Но меня он интересует, прежде всего, как балансировщик нагрузки между «стоящими» за ним серверами приложений (СП) (например: geronimo или websphere liberty). Данная запись будет содержать некоторые рабочие конфиги с комментариями.
1) Установка nginx, настройка фаервола
Тут мы просто обновим систему, накатим nginx и откроем необходимые нам порты.
Обновляем систему:
sudo apt-get update -y && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y
Устанавливаем nginx:
sudo apt-get install nginx
Firewall (все кроме 22 надо для СП):
sudo ufw enable sudo ufw allow 22 sudo ufw allow 80 sudo ufw allow 443 sudo ufw allow 8080 sudo ufw allow 8443 sudo ufw status verbose
2) Настройка nginx
Здесь записаны основные команды для управления nginx. Запуск, остановка, загрузка конфига, правка конфига… считайте, что это ваш вечный «порочный круг» :)
Запускаем сервис (при запуске системы он будет запускаться автоматически):
sudo service nginx start
Соответственно, для остановки (на всякий случай):
sudo service nginx stop
Далее идем править конфиг nginx:
sudo nano /etc/nginx/nginx.conf
Обновляем настройки nginx:
sudo nginx -s reload
3) Конфиги
Вся сила nginx — в конфигах. Скажу сразу, приведенные мною примеры конфигов — не являются идеальными, но, как говорится… «it works for me». Вообще, на «полировке» конфигов nginx зарабатывают вполне себе такую нормальную денежку. Так что, чем богаты — тем и рады. Поехали!
3.1) Конфиг №1 (сквозной для одного СП)
В данном примере, у нас есть некий CП и он находится по адресу: 1.1.4.201, а его веб-интерфейс находится тут: http://1.1.4.201:8080/ Мы сделаем так, что он будет доступен на нашем сервере nginx по адресу: http://1.1.4.202/
3.2) Конфиг №2 (кэширование и несколько СП)
В данном примере, мы имеем 2 СП. Балансировщик с этим конфигом работает по адресу: http://1.1.4.205:8080/
Особенности:
1) nginx запоминает, кто откуда пришел через хеш входящего IP адреса. Каждого клиента он направляет на свой сервер (наименее загруженный в данный момент), при этом, что самое важное, не разрывает сессию. Это не значит, что клиент будет навсегда привязан к определенному серверу приложений. Тестирование показало равномерную нагрузку на оба сервера приложений.
2) Чтобы лишний раз не нагружать сервер, все логи (а они у nginx тяжеленные) отправляются в /dev/null.
3) У сервера работает кэш. Он живет только 10 минут (!) и кроме кэширования обычной статики, он еще кэширует одинаковые динамические запросы, тем самым уменьшая нагрузку на ЦП сервера приложений (!!!) и ускоряя вывод одинаковых запросов. Длительное тестирование проблем не показало, все работает очень красиво и аккуратно.
4) Максимальное время отклика на сервер приложений составляет 3 минуты. Если он в это время будет недоступен, запрос автоматически будет переброшен на другой сервер приложений.
5) Количество серверов в пуле может быть насколько угодно большим. Кроме того, можно подготовить также специальные резервные сервера, которые вступят в бой только в случае недоступности какого-либо из основных.
6) Веб-адрес можно сократить, убрав «8080».. и все остальное, что не прописано в модулях СП с помощью «хардкодинга».
7) В моем случае, крайне не рекомендуется менять/добавлять что-либо в данный конфиг. Добавление простейшей опции, например enhanced life check, приводит к непредвиденным ошибкам в моем СП.
3.3) Конфиг №3 (кэширование, сжатие, несколько СП)
На данной этапе, мы добавим сжатие статического содержания веб-интерфейса, т.е. между nginx и непосредственно клиентом. Мы будем использовать модуль ngx_http_gzip_module — сжимающий ответ методом gzip, что позволяет уменьшить размер передаваемых данных в 2 и более раз. Он сжимает передаваемые данные на стороне сервере и пересылает их клиенту. Браузер разархивирует их налету автоматически, если что-то не получится — то данные будут переданы без сжатия в обычном виде.
Данный балансировщик доступен по адресу: http://1.1.4.202:8080/
3.4) Конфиг №4 (кэширование, сжатие + SSL)
И последний штрих, мы подключим сертификат SSL к nginx и направим трафик через него. Доверенным центром (в моем случае) является COMODO, сертификат типа wildcard SSL. Вот официальная документация на их сайте: comodo За дополнительной информацией, обращайтесь за доками к своему центру сертификации. Итак, у нас есть 5 файлов: 4-ре *.cer и 1-н *.key. Сертификаты необходимо «склеить» в одной целое, с помощью команды cat. Последовательность важна!
Итак, у нас имеется (подробнее):
1) Сертификат домена: STAR_domain_ru.crt
2) Промежуточный 1: COMODORSAAddTrustCA.cr
3) Промежуточный 2: COMODORSADomainValidationSecureServerCA.cr
4) Корневой: AddTrustExternalCARoot.crt
Скидываем их в каталог /etc/ssl и переходим в него:
cd /etc/ssl
Собираем единый сертификат bundle.crt:
cat STAR_domain_ru.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt AddTrustExternalCARoot.crt > bundle.crt
В новом конфиге мы задействуем новый сертификат bundle.crt и ключ private.key, также потребуется ввести пароль от ключа при каждом запуске/остановке nginx. Этот конфиг исключает все небезопасные шифры и протоколы.
3.5) Конфиг №5 (Oracle Database через nginx)
nginx тут это 1.1.5.249 (у него три сетевых интерфейса, еще есть 5.250 и 5.251) он смотрит на сервер БД 1.1.1.40, причем подключается к нему с другого своего сетевого интерфейса 1.1.5.250 (параметр nginx — proxy_bind)
Подключившись к базе, проверить с какого IP мы подключились можно так:
select SYS_CONTEXT('USERENV', 'CURRENT_SCHEMAID' ) current_schemaid
,SYS_CONTEXT('USERENV', 'HOST') host
,SYS_CONTEXT('USERENV', 'OS_USER') os_user
,SYS_CONTEXT('USERENV', 'EXTERNAL_NAME') external_name
,SYS_CONTEXT('USERENV', 'IP_ADDRESS') ip_address
,SYS_CONTEXT('USERENV', 'NETWORK_PROTOCOL') network_protocol
from dual
или так:
select SYS_CONTEXT('USERENV', 'IP_ADDRESS') ip_address
from dual
Итак, иногда может потребоваться, чтобы Oracle Database заработали через nginx. Таким образом можно реализовать балансировку нагрузку между БД. Однако одного конфига для данного пункта недостаточно. Прежде чем его применять, необходимо выполнить ряд требований:
— откройте порт 1521 в фаерволле
— nginx должен быть не ниже версии 1.9.8 (nginx -v)
— должен быть отключен SELinux, т.к. он блокирует привязку к оракловому дефолтному порту 1521 (возможно его можно как-нибудь настроить, но я не заморачивался)
Отключение SELinux. Проверка статус, включен ли он (этот пункт тестировался только в RHEL 6 и CentOS 6):
/usr/sbin/getenforce
Он выдает Enforcing (включен и агрессивен), Permissive или Disabled.
Отключается он так:
nano /etc/selinux/config
Там найти параметр SELINUX и сделать его disabled, тобишь будет: SELINUX=disabled. После чего нужно сделать reboot.
Итог
На данный момент вот такие у нас конфиги в количестве 4-х штук. Все они прекрасно выполняют свою работу. Наш любимый nginx — очень мощное ПО, способное выдерживать самые тяжелые нагрузки. Возможно, материал будет дополнен со временем новыми примерами конфигов.
отлично, нужно здесь это оставить о настройке в новой версии