TOC

Как создать HAProxy с высокой доступностью с помощью Corosync, Pacemaker и плавающих IP-адресов в Ubuntu 14.04

Вступление

Из этого туториала Вы узнаете, как создать балансировщик нагрузки HAProxy с высокой доступностью в DigitalOcean с поддержкой плавающего IP и кластерного стека Corosync / Pacemaker. Каждый из балансировщиков нагрузки HAProxy будет настроен для разделения трафика между двумя внутренними серверами приложений. Если основной балансировщик нагрузки выходит из строя, плавающий IP автоматически перемещается на второй балансировщик нагрузки, что позволяет возобновить обслуживание.

изображение: https: //assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [Настройка HAProxy высокой доступности]

Предпосылки

Чтобы выполнить это руководство, вам необходимо заполнить https://www.digitalocean.com/community/tutorials/how-to-create-a-high-availability-setup-with-corosync-pacemaker-and- Руководство по установке плавающего ips-on-ubuntu-14-04 [Как создать установку высокой доступности с помощью Corosync, Pacemaker и плавающих IP-адресов в Ubuntu 14.04] (следует пропустить необязательный раздел * Add Nginx Resource *). Это даст вам две капли, которые мы будем называть * первичными * и * вторичными *, с плавающим IP, который может переходить между ними. В совокупности мы будем называть эти серверы * балансировщиками нагрузки *. Это Droplets, где мы установим балансировщик нагрузки, HAProxy.

Вам также понадобится создать две дополнительные капли Ubuntu 14.04 в одном и том же центре данных с включенной частной сетью, чтобы продемонстрировать, что настройка балансировки нагрузки HA работает. Это серверы, которые будут сбалансированы по нагрузке HAProxy. Мы будем называть эти серверы приложений, на которые мы будем устанавливать Nginx, * app-1 * и * app-2 *. Если у вас уже есть серверы приложений, для которых вы хотите балансировать нагрузку, используйте их.

На каждом из этих серверов вам потребуется пользователь без полномочий root, настроенный с доступом + sudo +. Вы можете воспользоваться нашим Ubuntu 14.04 начальным руководством по установке сервера, чтобы узнать, как настроить этих пользователей.

Создать капли приложения

Первым шагом является создание двух дроплетов Ubuntu с включенной частной сетью в том же центре обработки данных, что и ваши балансировщики нагрузки, которые будут действовать как серверы * app-1 * и * app-2 *, описанные выше. Мы установим Nginx на обе капли и заменим их индексные страницы информацией, которая однозначно их идентифицирует. Это позволит нам показать, как работает балансировщик нагрузки HA. Если у вас уже есть серверы приложений, для которых вы хотите сбалансировать нагрузку, не стесняйтесь адаптировать соответствующие части этого учебника для работы (и пропустите все части, которые не имеют отношения к вашей настройке).

Если вы хотите следовать примеру установки, создайте две капли Ubuntu 14.04, * app-1 * и * app-2 *, и используйте этот скрипт bash в качестве пользовательских данных:

Пример пользовательских данных

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

Эти пользовательские данные установят Nginx и заменит содержимое файла index.html именем хоста и общедоступным IP-адресом дроплета (путем ссылки на службу метаданных). Доступ к любой из Droplet покажет основную веб-страницу с именем хоста Droplet и публичным IP-адресом, которая будет полезна для проверки того, на какой сервер приложений направляют трафик балансировщики нагрузки.

Соберите информацию о сети сервера

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

Для завершения этого руководства вам понадобится следующая информация о ваших серверах:

  • * серверы приложений *: частный IP-адрес

  • * балансировщики нагрузки * частные и якорные IP-адреса

Найти частные IP-адреса

Самый простой способ найти частный IP-адрес вашего Droplet - использовать + curl + для получения частного IP-адреса из службы метаданных DigitalOcean. Эта команда должна быть запущена из ваших капель. На каждой капле введите:

curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

Правильный IP-адрес должен быть напечатан в окне терминала:

Private IP address:10.132.20.236

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

Найти якорные IP-адреса

  • Якорный IP * - это локальный частный IP-адрес, с которым будет связан плавающий IP при подключении к серверу DigitalOcean. Это просто псевдоним для обычного адреса + eth0 +, реализованный на уровне гипервизора.

Самый простой и наименее подверженный ошибкам способ получения этого значения - прямо из сервиса метаданных DigitalOcean. Используя + curl +, вы можете связаться с этой конечной точкой на каждом из ваших серверов, набрав:

curl 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address && echo

Якорный IP будет напечатан в отдельной строке:

Output10.17.1.18

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

Настроить серверы приложений

После сбора данных выше, мы можем перейти к настройке наших сервисов.

Note

Мы начнем с настройки наших внутренних серверов приложений. Оба этих сервера будут просто обслуживать свое имя и публичный IP-адрес; в реальной установке эти серверы будут обслуживать идентичный контент. Они будут принимать веб-соединения только через свои частные IP-адреса. Это поможет гарантировать, что трафик направляется исключительно через один из двух серверов HAProxy, которые мы будем настраивать позже.

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

Настройте Nginx, чтобы разрешать только запросы от балансировщиков нагрузки

Если вы следуете примеру и использовали предоставленные * пользовательские данные * при создании серверов приложений, на ваших серверах уже будет установлен Nginx. Следующим шагом является внесение нескольких изменений в конфигурацию.

Мы хотим настроить Nginx так, чтобы он прослушивал только запросы на частном IP-адресе сервера. Кроме того, мы будем обслуживать только запросы, поступающие с частных IP-адресов наших двух балансировщиков нагрузки. Это заставит пользователей обращаться к вашим серверам приложений через ваши балансировщики нагрузки (которые мы настроим так, чтобы они были доступны только через плавающий IP-адрес).

Чтобы внести эти изменения, откройте файл блока сервера Nginx по умолчанию на каждом из ваших серверов приложений:

sudo vi /etc/nginx/sites-available/default

Для начала мы изменим директивы + listen +. Измените директиву + listen +, чтобы прослушивать частный IP-адрес текущего * сервера приложений * на порте 80. Удалите лишнюю строку + listen +. Это должно выглядеть примерно так:

/ etc / nginx / sites-available / default (1 из 2)

server {
   listen :80;

   . . .

Непосредственно под директивой + listen + мы установим две директивы + allow +, чтобы разрешить трафик, исходящий из частных IP-адресов наших двух балансировщиков нагрузки. Мы будем следовать правилу + deny all +, чтобы запретить весь другой трафик:

/ etc / nginx / sites-available / default (2 из 2)

   allow ;
   allow ;
   deny all;

Сохраните и закройте файлы, когда вы закончите.

Проверьте, что внесенные вами изменения представляют правильный синтаксис Nginx, набрав:

sudo nginx -t

Если о проблемах не сообщалось, перезапустите демон Nginx, набрав:

sudo service nginx restart

Не забудьте выполнить все эти шаги (с соответствующими частными IP-адресами сервера приложений) на обоих серверах приложений.

Тестирование изменений

Чтобы проверить, что ваши серверы приложений ограничены правильно, вы можете делать запросы, используя + curl из разных мест.

На самих серверах приложений вы можете попробовать простой запрос локального контента, набрав:

curl 127.0.0.1

Из-за ограничений, которые мы установили в наших файлах блоков сервера Nginx, этот запрос будет фактически отклонен:

Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

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

Теперь с любого из * балансировщиков нагрузки * мы можем запросить любой из открытых IP-адресов нашего сервера приложений:

curl

Еще раз, это должно потерпеть неудачу. Серверы приложений не прослушивают общедоступный интерфейс, и, кроме того, при использовании общедоступного IP-адреса наши серверы приложений не будут видеть разрешенные частные IP-адреса в запросе от наших балансировщиков нагрузки:

Outputcurl: (7) Failed to connect to  port 80: Connection refused

Однако если мы изменим вызов, чтобы сделать запрос, используя _private IP-адрес сервера приложений, он должен работать правильно:

curl

Страница Nginx + index.html должна быть возвращена. Если вы использовали пользовательские данные примера, страница должна содержать имя и общедоступный IP-адрес сервера приложений, к которому осуществляется доступ:

app server index.htmlDroplet: app-1, IP Address: 159.203.130.34

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

Как только вышеприведенное поведение продемонстрировано, мы можем двигаться дальше. Наша серверная конфигурация сервера приложений завершена.

Удалить Nginx из балансировщиков нагрузки

Следуя обязательному руководству * HA Setup с учебными пособиями Corosync, Pacemaker и Floating IPs *, на ваших серверах балансировки нагрузки будет установлен Nginx. Поскольку мы собираемся использовать HAProxy в качестве балансировщика нагрузки обратного прокси-сервера, мы должны удалить Nginx и все связанные ресурсы кластера.

Удалить ресурсы кластера Nginx

Если вы добавили ресурс кластера Nginx, следуя обязательному руководству, остановите и удалите ресурс + Nginx + с помощью этих команд на * одном из ваших балансировщиков нагрузки *:

sudo crm resource stop Nginx
sudo crm configure delete Nginx

Это также должно удалить любые настройки кластера, которые зависят от ресурса + Nginx +. Например, если вы создали + clone + или + colocation +, который ссылается на ресурс + Nginx +, они также будут удалены.

Удалить пакет Nginx

Теперь мы готовы удалить Nginx * на обоих серверах балансировки нагрузки *.

Сначала остановите службу Nginx:

sudo service nginx stop

Затем очистите пакет с помощью этой команды:

sudo apt-get purge nginx

Вы также можете удалить файлы конфигурации Nginx:

sudo rm -r /etc/nginx

Теперь мы готовы установить и настроить HAProxy.

Установите и настройте HAProxy

Далее мы настроим балансировщики нагрузки HAProxy. Каждый из них будет находиться перед нашими веб-серверами и распределять запросы между двумя внутренними серверами приложений. Эти балансировщики нагрузки будут полностью избыточными в активно-пассивной конфигурации; только один будет получать трафик в любой момент времени.

Конфигурация HAProxy будет передавать запросы на оба веб-сервера. Балансировщики нагрузки будут прослушивать запросы на их якорные IP-адреса. Как упоминалось ранее, это IP-адрес, с которым будет связан плавающий IP-адрес при подключении к дроплету. Это гарантирует, что будет пересылаться только трафик, исходящий с плавающего IP-адреса.

Установить HAProxy

Этот раздел необходимо выполнить на * обоих серверах балансировки нагрузки *.

Мы установим HAProxy 1.6, которого нет в репозиториях Ubuntu по умолчанию. Тем не менее, мы все еще можем использовать менеджер пакетов для установки HAProxy 1.6, если мы используем PPA, с помощью этой команды:

sudo add-apt-repository ppa:vbernat/haproxy-1.6

Обновите локальный индекс пакетов на ваших балансировщиках нагрузки и установите HAProxy, введя:

sudo apt-get update
sudo apt-get install haproxy

HAProxy теперь установлен, но нам нужно настроить его сейчас.

Настроить HAProxy

Откройте основной файл конфигурации HAProxy:

sudo vi /etc/haproxy/haproxy.cfg

Найдите раздел + defaults + и добавьте в него две следующие строки:

/etc/haproxy/haproxy.cfg (1 из 3)

   option forwardfor
   option http-server-close

Параметр forwardfor устанавливает для HAProxy добавление заголовков + X-Forwarded-For + к каждому запросу, что полезно, если вы хотите, чтобы серверы приложений знали, с какого IP-адреса изначально был отправлен запрос, а параметр http-server-close уменьшает задержку между HAProxy и ваши пользователи закрывают соединения, но поддерживают keep-alive.

Далее, в конце файла, нам нужно определить конфигурацию нашего интерфейса. Это будет диктовать, как HAProxy прослушивает входящие соединения. Мы свяжем HAProxy с IP-адресом привязки балансировщика нагрузки. Это позволит ему прослушивать трафик, исходящий с плавающего IP-адреса. Мы будем называть наш интерфейс «http» для простоты. Мы также определим бэкэнд по умолчанию, + app_pool +, для передачи трафика (который мы будем настраивать через минуту):

/etc/haproxy/haproxy.cfg (2 из 3)

frontend http
   bind    :80
   default_backend app_pool

Далее мы можем определить конфигурацию бэкэнда. Это будет указывать нижестоящие местоположения, где HAProxy будет передавать полученный трафик. В нашем случае это будут частные IP-адреса обоих серверов приложений Nginx, которые мы настроили:

/etc/haproxy/haproxy.cfg (3 из 3)

backend app_pool
   server app-1 :80 check
   server app-2 :80 check

Когда вы закончите вносить вышеуказанные изменения, сохраните и выйдите из файла.

Проверьте, что внесенные нами изменения конфигурации представляют правильный синтаксис HAProxy, набрав:

sudo haproxy -f /etc/haproxy/haproxy.cfg -c

Если об ошибках не сообщалось, перезапустите службу, введя:

sudo service haproxy restart

Опять же, обязательно выполните все шаги в этом разделе на обоих серверах балансировки нагрузки.

Тестирование изменений

Мы можем убедиться, что ваша конфигурация верна, снова протестировав + curl.

С серверов балансировки нагрузки попробуйте запросить локальный хост, собственный публичный IP-адрес балансировщика нагрузки или собственный IP-адрес сервера:

curl 127.0.0.1
curl
curl

Они все должны потерпеть неудачу с сообщениями, которые похожи на это:

Outputcurl: (7) Failed to connect to  port 80: Connection refused

Однако, если вы делаете запрос к _anchor IP-адресу балансировщика нагрузки, он должен успешно завершиться:

curl

Вы должны увидеть страницу Nginx + index.html одного из серверов приложений:

app server index.htmlDroplet: app-1, IP Address: app1_IP_address

Выполните тот же запрос curl снова:

curl

Вы должны увидеть страницу + index.html + другого сервера приложений, поскольку HAProxy по умолчанию использует циклическое распределение нагрузки:

app server index.htmlDroplet: app-2, IP Address: app2_IP_address

Если это поведение соответствует поведению вашей системы, балансировщики нагрузки настроены правильно; Вы успешно проверили, что ваши серверы балансировки нагрузки балансируют трафик между обоими серверами внутренних приложений. Кроме того, ваш плавающий IP-адрес уже должен быть назначен одному из серверов балансировки нагрузки, как это было установлено в обязательном порядке * Настройка HA с учебником Corosync, Pacemaker и Floating IPs *.

Скачать HAProxy OCF Resource Agent

На этом этапе у вас есть базовое переключение на уровне хоста, но мы можем улучшить настройку, добавив HAProxy в качестве ресурса кластера. Это позволит вашему кластеру убедиться, что HAProxy работает на сервере, которому назначен ваш плавающий IP. Если Pacemaker обнаруживает, что HAProxy не работает, он может перезапустить службу или назначить плавающий IP-адрес другому узлу (на котором должен быть запущен HAProxy).

Pacemaker позволяет добавлять агенты ресурсов OCF, размещая их в определенном каталоге.

На * обоих серверах балансировки нагрузки * загрузите агент ресурса HAProxy OCF с помощью следующих команд:

cd /usr/lib/ocf/resource.d/heartbeat
sudo curl -O https://raw.githubusercontent.com/thisismitch/cluster-agents/master/haproxy

На обоих серверах балансировки нагрузки сделайте его исполняемым:

sudo chmod +x haproxy

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

Теперь мы можем использовать агент ресурса HAProxy OCF для определения нашего кластерного ресурса + haproxy +.

Добавить ресурс haproxy

С нашим установленным агентом ресурса HAProxy OCF мы можем теперь настроить ресурс `+ haproxy + ', который позволит кластеру управлять HAProxy.

На * сервере балансировки нагрузки * создайте примитивный ресурс + haproxy + с помощью этой команды:

sudo crm configure primitive haproxy ocf:heartbeat:haproxy op monitor interval=15s

Указанный ресурс сообщает кластеру контролировать HAProxy каждые 15 секунд и перезапускать его, если он становится недоступным.

Проверьте состояние ресурсов вашего кластера, используя + sudo crm_mon или` + sudo crm status`:

crm_mon:...
Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started
Nginx  (ocf::heartbeat:nginx): Started

К сожалению, Pacemaker может решить запустить ресурсы + haproxy + и + FloatIP + на отдельных узлах, потому что мы не определили никаких ограничений ресурсов. Это является проблемой, поскольку плавающий IP-адрес может указывать на одну каплю, в то время как служба HAProxy работает на другой капле. Доступ к плавающему IP-адресу покажет вам сервер, на котором не запущена служба, которая должна быть высокой доступности.

Чтобы решить эту проблему, мы создадим ресурс * clone *, который указывает, что существующий примитивный ресурс должен быть запущен на нескольких узлах.

Создайте клон ресурса + haproxy + с именем «haproxy-clone» с помощью этой команды:

sudo crm configure clone haproxy-clone haproxy

Состояние кластера теперь должно выглядеть примерно так:

crm_mon:Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
Clone Set: haproxy-clone [Nginx]
    Started: [ primary secondary ]

Как видите, ресурс clone + haproxy-clone + теперь запущен на обоих наших узлах.

Последний шаг - настройка ограничения размещения, чтобы указать, что ресурс + FloatIP + должен запускаться на узле с активным ресурсом + haproxy-clone +. Чтобы создать ограничение колокейшна под названием «FloatIP-haproxy», используйте эту команду:

sudo crm configure colocation FloatIP-haproxy inf: FloatIP haproxy-clone

Вы не увидите никакой разницы в выводе статуса crm, но вы можете видеть, что ресурс colocation был создан с помощью этой команды:

sudo crm configure show

Теперь на обоих ваших серверах должен быть запущен HAProxy, в то время как только на одном из них запущен ресурс FloatIP.

Попробуйте остановить службу HAProxy на любом из серверов балансировки нагрузки:

sudo service haproxy stop

Вы заметите, что он снова запустится в течение следующих 15 секунд.

Затем мы проверим вашу настройку HA, перезагрузив ваш активный сервер балансировки нагрузки (тот, на котором в данный момент «запущен» ресурс + FloatIP +).

Проверить высокую доступность балансировщиков нагрузки

С вашей новой настройкой High Availability HAProxy вы захотите проверить, что все работает как положено.

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

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

Контролировать состояние кластера

Выполняя предстоящие тесты, вы можете посмотреть в режиме реального времени состояние узлов и ресурсов кластера. Вы можете сделать это с помощью этой команды на любом сервере балансировки нагрузки (если он работает):

sudo crm_mon

Вывод должен выглядеть примерно так:

crm_mon output:Last updated: Thu Nov  5 13:51:41 2015
Last change: Thu Nov  5 13:51:27 2015 via cibadmin on primary
Stack: corosync
Current DC: secondary (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
3 Resources configured

Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
Clone Set: haproxy-clone [haproxy]
    Started: [ primary secondary ]

Это покажет вам, какие узлы балансировки нагрузки находятся в сети, а какие узлы запущены для ресурсов + FloatIP + и + haproxy +.

Обратите внимание, что узел, для которого ресурс + FloatIP + является + Started + on, * primary * в приведенном выше примере, является сервером балансировки нагрузки, которому в настоящее время назначен плавающий IP. Мы будем называть этот сервер * активным сервером балансировки нагрузки *.

Автоматизировать запросы к плавающему IP

На вашем локальном компьютере мы будем запрашивать веб-контент с плавающим IP-адресом каждые 2 секунды. Это позволит нам легко увидеть, как активный балансировщик нагрузки обрабатывает входящий трафик. То есть мы увидим, на какие серверы приложений он отправляет трафик. В локальном терминале введите эту команду:

while true; do curl ; sleep 2; done

Каждые две секунды вы должны видеть ответ от одного из внутренних серверов приложений. Вероятно, он будет чередоваться между * app-1 * и * app-2 *, потому что алгоритм баланса по умолчанию HAProxy, который мы не указали, установлен на * round-robin *. Итак, ваш терминал должен показать что-то вроде этого:

[secondary_label curl loop output:
Droplet: app-1, IP Address:
Droplet: app-2, IP Address:
...

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

Хвост журналы на веб-серверах

На каждом из наших внутренних серверов приложений мы можем + tail + расположение + / var / log / nginx / access.log +. Это покажет каждый запрос, сделанный на сервер. Поскольку наши балансировщики нагрузки равномерно распределяют трафик с помощью циклического чередования, каждый внутренний сервер приложений должен видеть около половины выполненных запросов.

Адрес клиента - самое первое поле в журнале доступа, поэтому его будет легко найти. Запустите на обоих серверах приложений Nginx следующее (в отдельных окнах терминала):

sudo tail -f /var/log/nginx/access.log

В первом поле должен отображаться частный IP-адрес вашего активного сервера балансировки нагрузки каждые четыре секунды (мы будем считать, что это * основной * балансировщик нагрузки, но в вашем случае это может быть * вторичный *):

Output. . .
- - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Сохраняйте команду + tail + на обоих серверах приложений.

Прервать службу HAProxy на основном балансировщике нагрузки

Теперь давайте перезагрузим * основной * балансировщик нагрузки, чтобы убедиться, что аварийное переключение с плавающим IP работает:

sudo reboot

Теперь обратите внимание на журналы доступа Nginx на обоих серверах приложений. Следует заметить, что после отработки отказа с плавающим IP-адресами журналы доступа показывают, что доступ к серверам приложений осуществляется с другого IP-адреса, чем раньше. В журналах должно быть указано, что сервер подсистемы балансировки нагрузки * вторичный * отправляет запросы:

Output. . .
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Это показывает, что был обнаружен сбой первичного балансировщика нагрузки, и плавающий IP был успешно переназначен вторичному балансировщику нагрузки.

Вы также можете проверить выходные данные своего локального терминала (который обращается к плавающему IP каждые две секунды), чтобы убедиться, что вторичный балансировщик нагрузки отправляет запросы на оба серверных сервера приложений:

[secondary_label curl loop output:
Droplet: app-1, IP Address:
Droplet: app-2, IP Address:
...

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

Настройте Nginx для регистрации фактического IP-адреса клиента

Как вы видели, журналы доступа Nginx показывают, что все клиентские запросы поступают с частного IP-адреса текущего балансировщика нагрузки, а не с фактического IP-адреса клиента, который первоначально сделал запрос (т.е. ваша локальная машина). Часто полезно регистрировать IP-адрес исходного запросчика, а не сервера балансировки нагрузки. Этого легко достичь, внеся несколько изменений в конфигурацию Nginx на всех ваших серверных серверах приложений.

На обоих * серверах приложений * откройте файл + nginx.conf + в редакторе:

sudo vi /etc/nginx/nginx.conf

Найдите раздел «Настройки ведения журнала» (в блоке + http +) и добавьте следующую строку:

добавить в /etc/nginx/nginx.conf

log_format haproxy_log 'ProxyIP: $remote_addr - ClientIP: $http_x_forwarded_for - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';

Сохранить и выйти. Это задает новый формат журнала с именем + haproxy_log +, который добавляет значение + $ http_x_forwarded_for + - IP-адрес клиента, который сделал исходный запрос, - к записям журнала доступа по умолчанию. Мы также включаем + $ remote_addr +, который является IP-адресом балансировщика нагрузки обратного прокси-сервера (т.е. активный сервер балансировки нагрузки).

Затем, чтобы использовать этот новый формат журнала, нам нужно добавить строку в наш блок сервера по умолчанию.

На * обоих серверах приложений * откройте конфигурацию сервера + default +:

sudo vi /etc/nginx/sites-available/default

В блоке + server (прямо под директивой` + listen` это хорошее место) добавьте следующую строку:

добавить в / etc / nginx / sites-available / default

       access_log /var/log/nginx/access.log haproxy_log;

Сохранить и выйти. Это говорит Nginx писать свои журналы доступа, используя формат журнала + haproxy_log +, который мы недавно создали.

На * обоих серверах приложений * перезапустите Nginx, чтобы изменения вступили в силу:

sudo service nginx restart

Теперь ваши журналы доступа Nginx должны содержать фактические IP-адреса клиентов, делающих запросы. Проверьте это, следя за логи ваших серверов приложений, как мы делали в предыдущем разделе. Записи в журнале должны выглядеть примерно так:

New Nginx access logs:. . .
ProxyIP:  - ClientIP:  - - [05/Nov/2015:15:05:53 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Если ваши журналы выглядят хорошо, все готово!

Заключение

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

Конфигурация с плавающим IP-адресом и Corosync / Pacemaker устраняет единственную точку отказа на уровне балансировки нагрузки, позволяя вашей службе продолжать функционировать, даже если основной балансировщик нагрузки полностью выходит из строя. Эта конфигурация довольно гибкая и может быть адаптирована к вашей собственной среде приложений путем настройки предпочтительного стека приложений за серверами HAProxy.

Related