Глава 12. Режимы развёртывания высокой доступности

Архитектура с восстановлением после отказа разделяет системы на идентичные, независимые стеки. Подобные NGINX балансировщики нагрузки применяются для распределения нагрузки, гарантирую применение того что предоставлено. Самой сердцевиной понятия высокой доступности является балансировка по множеству активных узлов или некая отработка отказа активный- пассивный. Приложения с высокой доступностью не имеют единых точек отказа; все компоненты обязаны применять одну из указанных концепций, включая и сам балансировщик нагрузки. Для нас это означает NGINX. NGINX разработан для работы в одной из настроек: множество активных или отработки отказа активный- пассивный. Данная глава подробно описывает технологию того как запускать множество серверов NGINX для обеспечения высокой доступности на уровне вашей балансировки нагрузки.

Задача

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

Решение

Воспользуйтесь режимом высокой доступности (HA, highly available) NGINX Plus с поддержкой активности устанавливая пакет nginx-ha-keepalived из репозитория NGINX Plus.

Обсуждение

Предлагаемый пакет пакет nginx-ha-keepalived основывается на поддержке активности и управляет неким виртуальным адресом IP, выставляемым его клиенту. На самом сервере NGINX запущен другой процесс, который предоставляет гарантию работы этого NGINX Plus и самого процесса поддержки активности. Процессом поддержки активности является процесс, который применяет протокол VRRP (Virtual Router Redundancy Protocol), часто отправляя небольшие сообщения, именуемые сердцебиениями, в соответствующий сервер основы. Если такой сервер не получает такое сердцебиение на протяжении трёх последовательных периодов, такой сервер основы инициирует свою отработку отказа, перемещая имеющийся виртуальный адрес IP себе и превращаясь в хозяина (master). Имеющиеся возможности отработки отказа пакет nginx-ha-keepalived могут настраиваться для указания индивидуальных ситуаций отказа.

Задача

Вам необходимо распределить нагрузку между двумя или более серверами NGINX.

Решение

Воспользуйтесь карусельным методом (round robin) DNS по серверам NGINX добавляя множество IP адресов в некую запись A DNS.

Обсуждение

При исполнении множества балансировщиков нагрузки вы можете распределять нагрузку через DNS. Запись A позволяет перечислять под одним полностью определённым именем домена (FQDN, fully qualified domain name) множество адресов IP. DNS будет автоматически прокручивать все IP адреса каруселью. DNS также предлагает взвешенный карусели с записями весов, которые работают точно так же как и описанные в Главе 1 карусели NGINX с весами. Эти технологии прекрасно работают. Тем не менее, некой ловушкой может оказаться удаление конкретной записи в том случае, когда некий сервер NGINX испытал отказ. Имеются поставщики DNS - Amazon Route53 для одних, и Dyn DNS для иных - которые предлагают проверки жизнеспособности и отработку отказов вместе со своими предложениями DNS, которые облегчают данные проблемы. Когда вы применяете DNS для балансировки нагрузки по NGINX, в том случае когда некий сервер NGINX помечается как подлежащий удалению, наилучшей практикой является следование тому же самому протоколу, которым NGINX исключается в качестве сервера восходящего потока. Для начала прекратите отправку к нему новых подключений удалив его IP из имеющейся записи DNS, затем включите осушение подключений перед остановкой или отключением его службы.

Задача

Вы применяете NGINX в AWS, причём ваш NGINX Plus HA не поддерживает IP Amazon.

Решение

Поместите NGINX позади некого NLB AWS настроив некую группу с Автоматическим масштабированием из серверов NGINX и связав эту группу Автоматического масштабирования к целевой группе, а затем подключив эту целевую группу к соответствующему NLB. В качестве альтернативы вы можете помещать серверы NGINX в такую целевую группу вручную при помощи консоли AWS, интерфейса командно строки или API.

Обсуждение

Основанное на поддержке активности (keepaliving) решение HA от NGINX Plus не будет работать в AWS, поскольку он не поддерживает плавающие виртуальные IP адреса, ибо IP адреса EC2 работают совершенно иначе. Это вовсе не означает что NGINX лишён возможностей HA в облачном решении AWS; на самом деле, верно совершенно обратное. Amazon предлагает продукт AWS NLB, который будет естественным образом выполнять балансировку нагрузки по множеству физически раздельных центров обработки данных, именуемых зонами доступности (AZ, availability zones), снабжёнными активными проверками жизнеспособности, а также некой оконечной точкой DNS CNAME. Неким общепринятым решением для HA NGINX в AWS является размещение уровня NGINX позади имеющегося NLB. Серверы NGINX могут по мере необходимости автоматически добавляться в его целевую группу и удаляться из неё. Такой NLB не выступает заменой NGINX; имеется множество предлагаемых NGINX вещей, которых нет в NLB, например, множество методов балансировки нагрузки, ограничение по частоте, кэширование, а также маршрутизация 7 уровня. AWS ALB выполняет балансировку нагрузки 7 уровня на основе пути URI и заголовка хоста, но он сам по себе не предлагает выполнения таких функций NGINX как кэширование WAF, ограничение полосы пропускания, активную доставку HTTP/2 и многое иное. В случае когда предоставляемый NLB не удовлетворяет вашим потребностям, имеется множество иных вариантов. Одним из вариантов является решение DNS, Route53. Данный продукт DNS от AWS предлагает проверки жизнеспособности и отработку отказов.

Задача

Вы работаете на неком уровне HA NGINX Plus и вам требуется синхронизация конфигураций серверов.

Решение

Воспользуйтесь предоставляемой исключительно NGINX Plus функциональностью синхронизации конфигураций. Для настройки этой функциональности следуйте таким этапам:

Из репозитория пакетов NGINX Plus установите необходимый пакет nginx-sync.

Для RHEL или CentOS:

$ sudo yum install nginx-sync
		

Для Ubuntu или Debian:

$ sudo apt-get install nginx-sync
		

Предоставьте своей машине хозяина SSH доступ от имени root ко всем одноранговым машинам.

Выработайте некую пару ключей аутентификации SSH для root и отыщите полученный общедоступный ключ:

$ sudo ssh-keygen -t rsa -b 2048
$ sudo cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3Nz4rFgt...vgaD root@node1
		

Получите установленный для вашего узла хозяина IP адрес:

$ ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen \
    1000
  link/ether 52:54:00:34:6c:35 brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
    valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe34:6c35/64 scope link
    valid_lft forever preferred_lft forever
		

Выполненная команда ip addr выводит дамп информации относительно интерфейсов вашей машины. Игнорируйте интерфейс петли (loopback), который обычно идёт первым. отыщите тот IP адрес, который следует за inet для самого первого интерфейса. В данном примере таким IP адресам является 192.168.1.2.

Распространите свой общедоступный ключ для файла authorized_keys пользователя root во всех узлах своей одноранговой сети и задайте авторизацию только с IP адреса своего хозяина:

$ sudo echo ‘from=”192.168.1.2" ssh-rsa AAAAB3Nz4rFgt...vgaD \
    root@node1' >> /root/.ssh/authorized_keys
		

Добавьте в /etc/ssh/sshd_confg приводимую ниже строку и выполните перезагрузку sshd на всех узлах:

$ sudo echo 'PermitRootLogin without-password' >> \
/etc/ssh/sshd_config
$ sudo service sshd reload
		

Убедитесь что ваш пользователь root способен выполнять ssh для всех узлов вашей одноранговой сети без пароля:

$ sudo ssh root@node2.example.com
		

в своей мащине хозяина создайте файл настроек /etc/nginx-sync.conf со следующей конфигурацией:

NODES="node2.example.com node3.example.com node4.example.com"
CONFPATHS="/etc/nginx/nginx.conf /etc/nginx/conf.d"
EXCLUDE="default.conf"
		

Данный пример конфигурации демонстрирует три распространённых параметра для данной функциональности: NODES, CONFIGPATHS и EXCLUDE. первый параметр NODES устанавливается некой строкой имён хостов или IP адресов, разделяемых пробелами; это все узлы одноранговой сети (peer), для которых ваш хозяин должен выполнять активную доставку своих изменений настроек. Значение параметра CONFIGPATHS определяет какие файлы или каталоги следует синхронизировать. Наконец, вы можете применять параметр EXCLUDE для исключения из синхронизации файлов конфигурации. В нашем примере хозяин выполняет активную доставку изменений настроек в сам основной файл настроек NGINX, а также включает каталоги /etc/nginx/nginx.conf и /etc/nginx/conf.d для узов одноранговой сети с названиями node2.example.com, node3.example.com и node4.example.com. Если ваш процесс синхронизации обнаруживает некий файл с названием default.conf, для него не будет выполняться активная доставка в этой одноранговой сети, так как он настроен в качестве EXCLUDE.

Для настройки имеющегося местоположения исполняемых файлов NGINX, RSYNC, SSH, diff, а также расположения lockfile и каталога backup имеются дополнительные параметры. Существует также некий параметр, который применяет sed для выработки шаблона заданных файлов. Для получения дополнительных сведений относительно расширенных параметров, ознакомьтесь с Configuration Sharing.

Проверьте свою конфигурацию:

$ nginx-sync.sh -h # display usage info
$ nginx-sync.sh -c node2.example.com # compare config to node2
$ nginx-sync.sh -C # compare master config to all peers
$ nginx-sync.sh # sync the config & reload NGINX on peers
		

Обсуждение

Эта имеющаяся только в NGINX Plus функциональность позволяет вам управлять множеством серверов NGINX Plus в конфигурации с высокой доступностью через обновление только узла хозяина и выполнения синхронизации со всеми прочими узлами одноранговой сети узлов. Выполняя синхронизацию в автоматическом режиме вы ограничиваете риск ошибок при передаче настроек. Приложение nginx-sync.sh предоставляет некие меры предосторожности для предотвращения отправки по одноранговой сети плохих конфигураций. Они содержат проверку выполненных настроек в самом хозяине, создание резервных копий имеющейся для одноранговой сети конфигурации и удостоверение полученной в одноранговой сети конфигурации перед перезагрузкой. Хотя более предпочтительной является синхронизация вашей конфигурации при помощи инструментов управления конфигурацией или Docker, функциональность синхронизации конфигурации NGINX Plus имеет ценность когда вам ещё только предстоит выполнить такой большой скачок к управлению средами таким образом.

Задача

Вам требуется чтобы NGINX Plus выполнил синхронизацию своих зон разделяемой памяти по флотилии серверов высокой доступности.

Решение

Воспользуйтесь параметром sync при настройке совместно используемой зоны памяти NGINX Plus:

stream {
    resolver 10.0.0.2 valid=20s;

    server {
        listen 9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
        # ... Security measures
    }
}
http {
    upstream my_backend {
        zone my_backend 64k;
        server backends.example.com resolve;
        sticky learn zone=sessions:1m
                     create=$upstream_cookie_session
                     lookup=$cookie_session
                     sync;
    }

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

Обсуждение

Рассматриваемый модуль zone sync является исключительным свойством NGINX Plus, которое в реальности превращает NGINX Plus в кластер. Как показано в приведённой конфигурации, вам следует установить некий сервер stream, настроенный в качестве zone_sync. В дпнном примере это сервер, выполняющий ожидание по порту 9000. NGINX Plus взаимодействует со всеми оставшимися своими среврами, которые определены в директиве zone_sync_server. Для динамических кластеров вы можете настраивать эту директиву на некое доменное имя, которое разрешается множеством IP адресов, либо же статически определять некую последовательность директив zone_sync_server. Вам следует ограничить доступ к своей зоне синхронизации сервера; имеются особые SSL/ TLS директивы для данного модуля в целях выполнения аутентификации машин. Основным преимуществом настройки NGINX Plus в какой- то кластер состоит в том, что вы имеете возможность синхронизации зон разделяемой памяти для ограничения частот, сеансов sticky learn, а также хранилища ключ- значение. Данный пример предоставляет демонстрацию применения параметра sync, прикрепляемого в самый конец директивы sticky learn. В этом примере некий пользователь ограничивается каким- то сервером восходящего потока на основе куки с названием session. При отсутствии рассматриваемого модуля синхронизации зоны, когда некий пользователь выполняет какой- то запрос к другому серверу NGINX Plus, он может утратить свой сеанс. В случае наличия модуля синхронизации зоны все имеющиеся серверы NGINX Plus осведомлены о таком сеансе и том, с каким именно сервером восходящего потока он связан.