Получение права балансировки нагрузки посредством relayd

После  того,  как  вы  запустили  распределение  нагрузки  посредством   round-robin

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

если   хост   в   списке   целей   перенаправления   «упал»,   трафик   все    еще    будет

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

Очевидно, что требуется решение мониторинга. К счастью, базовая система  OpenBSD предоставляет  это.  Relay  демон  relayd2    взаимодествует  с  вашей  PF  конфигурацией,

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

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

Realyd  демон  работает  в  двух  основных  классах  сервисов,  которые   называются

редиректы(redirects) и релеи(relays). Он ожидает, до тех пор пока у него не  появится возможность включить или исключить хосты с IP адресами в/из таблицу(ы) PF которыми

он управляет. Демон взаимодействует с набором правил через специального назначения

2.   Первоначально введен в OpenBSD 4.1 под названием hoststated, демон развивался(в основном Рейк  Флетери и Пьер-Ив Ришардом) активно в течение нескольких лет, в том числе несколько важных изменений  в синтаксисе конфигурации и был переименован в relayd в релизе OpenBSD 4.3.

якорями  называемыми  relayd  (и  в  версиях  предшествующих  OpenBSD   4.7,   также перенаправление якорем, RDR-якорь, назывался также).

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

вершины вашего pf.conf файла, добавим якорь для relayd написав:

anchor “relayd/*”

В версиях предшествующих OpenBSD 4.7, вам также нужен якорь перенаправления как этот:

rdr-anchor "relayd/*" anchor "relayd/*"

В наборе правил распределения нагрузки мы имеем следующее определение для нашего пул веб-сервера:

table webpool persist { 192.0.2.214, 192.0.2.215, 192.0.2.216, 192.0.2.217 }

В этом наборе правил создается перенаправление:

match in on $ext_if proto tcp to $webserver port $webports rdr-to <webpool> round-robin

Или в версиях предшествующих OpenBSD 4.7 вы должны использовать следующее:

rdr on $ext_if proto tcp to $webserver port $webports -> <webpool> round-robin

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

После  части  pf.conf,  которыми  мы  занимались,  мы  обращаемся  к   собственной конфигурации файла relayd.conf. синтаксис этого  конфигурационного файла достаточно похож на pf.conf, что делает его  довольно легко читаемым и понятным. Во-первых, мы добавим определение макроса, который будем использовать позже:

web1="192.0.2.214"

web2="192.0.2.215"

web3="192.0.2.216"

web4="192.0.2.217" webserver="192.0.2.227" sorry_server="192.0.2.200"

Все они соответсвуют опредлениям, которые мы могли бы поместить в pf.conf файл. По умолчанию проверочный интервал relayd 10 секунд, что означает,  что  хост может быть недоступен  в  течение  10  секунд,  пока  не  будет  определено,  что  он  находится  в оффлайне. Будьте осторожны, мы установим интервал в 5 секунда, чтобы минимизировать время простоя, следующей строкой:

interval 5 # проверка хоста каждые 5 секунд

Теперь  мы  сделаем  вызов  таблицы  webpool,  которая  использует  многие  из  наших макросов:

table <webpool> { $web1, $web2, $web3, $web4 }

По причинам, к которым мы вернемся в ближайшее время, мы определим  еще одну таблицу:

table <sorry> { $sorry_server }

В этой части, мы готовы установить перенаправление:

redirect www {

listen on $webserver port 80 sticky-address tag relayd

forward to <webpool> check http "/status.html" code 200 timeout 300 forward to <sorry> timeout 300 check icmp

}

Это говорит, что соединения на 80 порт должны быть перенаправлены на других членов таблицы webpool. Опция «липкий» адрес имеет тот же эффект  здесь, что и с rdr в PF правилах:  новое  соединение  с  того  же  самого  источника  IP  адреса  (с  временным интервлом определенным в значении  timeout) перенаправиться на тот же хост в пуле бэкэнде как и в предыдущем случае.

Relayd  демон  должен  проверять  видимость,  если  хост  доступен,  опрашивать  его  в соответствии с файлом /status.html, используя протокол  HTTP, и ожидая возвращения кода равным 200. Это ожидаемый результат для клиента которого опрашивают на предмет работы веб сервера, его файл доступен.

Без  больших  сюрпризов  до  сих  пор,  не  так  ли?!  Relayd  демон  позаботиться  об исключении хостов из таблица, если они «упадут». Но что  если все хосты в  webpool таблице упадут? К счастью разработчики предусмотрели и это также, и ввели концепцию резервирования таблицы для сервисов. Это последняя часть определения веб сервиса, с таблицей sorry как  таблицей резервного копирования: хосты в sorry таблице берут на себя все обслуживание, если таблица webpool становится пустой. Это означает, что вам нужно сконфигурировать сервис, чтобы была доступно предложение  “Извините, у нас проблемы”  сообщение  в  случае,  если  хосты  в  вашем  веб  пуле  «упадут».  Со  всеми элементами   дествующей   relayd   конфигурации   вы   можете   включить   вашу   новую конфигурацию. Перезапустите ваш набор  правил PF, а затем запустите relayd. Если вы хотите  проверить  вашу   конфигурацию  до  того  как  запустить  relayd  вы  можете использовать опцию –n в командной строке с relayd:

$ sudo relayd -n

Если ваша конфигурация корректна, relayd отобразит сообщение  конфигурация ОК и выйдет.

Чтобы действительно запустить демона, мы нам не нужен какой-либо флаг в командной строке, поэтому следующий последовательность перезагрузит вашу  отредактированную

конфигурацию PF и включит relayd.

$ sudo pfctl -f /etc/pf.conf

$ sudo relayd

Если конфигурация верна, обе команды спокойно запустятся, без  отображения  каких- либо сообщений. Вы можете проверить, что relayd  запущен командами top или ps. Во обоих случаях, вы найдете три relayd процесса, приблизительно как это:

$ ps waux | grep relayd

_relayd 9153 0.0 0.1 776 1424 ?? S 7:28PM 0:00.01 relayd: pf update engine (relayd)

_relayd 6144 0.0 0.1 776 1440 ?? S 7:28PM 0:00.02 relayd: host check engine (relayd)

root 3217 0.0 0.1 776 1416 ?? Is 7:28PM 0:00.01 relayd: parent (relayd)

Практически во всех случаях, вы захотите, чтобы relayd стартовал при загрузке системы.

Вы должны добавить вот эту строку в свой rc.conf.local файл:

relayd_flags="" # for normal use: ""

Однако, как только конфигурация включена, то большая часть взаимодействия с relayd произойдет через программу администрирования relayctl . Кроме контроля статуса, relayctl позволит  вам  загружать  relayd  конфигурацию  и  выборочно  отключать  или  включать хосты, таблицы и сервисы. Вы всегда можете посмотреть статус сервиса в интерактивном режиме, примерно как здесь:

$ sudo relayctl show summary Id Type Name Avlblty Status

1 redirect www active

1  table webpool:80 active (2 hosts) 1 host 192.0.2.214 100.00% up

2  host 192.0.2.215 0.00% down 3 host 192.0.2.216 100.00% up 4 host 192.0.2.217 0.00% down 2 table sorry:80 active (1 hosts) 5 host 127.0.0.1 100.00% up

В качестве примера, веб пул серьезно упадет, только с двумя из четырех работающих хостов. К счастью, таблица бэкапа все еще функционирует. Все  таблицы активны с по крайней мере одним работающим хостом. Для таблиц,  которые уже не имеют членов, столбец статуса изменится на пустой.  Запрашиваемая relayctl для хостов информация отображает информацию о статусе в центральной части отображения:

$ sudo relayctl show hosts

Id Type Name Avlblty Status

1  table webpool:80 active (3 hosts) 1 host 192.0.2.214 100.00% up total: 11340/11340 checks

2  host 192.0.2.215 0.00% down

total: 0/11340 checks, error: tcp connect failed 3 host 192.0.2.216 100.00% up

total: 11340/11340 checks

4  host 192.0.2.217 0.00% down

total: 0/11340 checks, error: tcp connect failed 2 table sorry:80 active (1 hosts)

5  host 127.0.0.1 100.00% up total: 11340/11340 checks

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

$ sudo relayctl host disable 192.0.2.217

В большинстве случаев, операция отобразит команду succeeded, что  показывает, что операция завершена успешно. После завершения  обслуживания и после того, как вы поставите машину в онлайн, вы можете  снова включить его в качестве части вашего relayd пула этой командой:

$ sudo relayctl host enable 192.0.2.217

Снова вы должны были увидеть сообщение команды succeeded почти сразу  отобразит, что операция была завершена успешно.

В дополнение к базовому распределению нагрузки, продемонстрированного здесь, relayd

имеет расширенную версию в недавней OpenBSD, и предлагает несколько характеристик, которые сделают его привлекательным в более сложных  настройках. Для примера, он

может  теперь  обрабатыватьс  седьмой  уровень  проксирования  или   ретранслировать

функции  HTTP  и  HTTPS,  включая  обработку  протокола  с  добавлением  заголовка  и перезаписи, добавлением  URL  пути  и  перезаписи, и  даже  обработку сессий  и  куки. Обработка протокола должна быть адаптирована  для вашего приложения. Например, ниже приведен просто HTTPS relay для  распределения нагрузки зашифрованного веб трафика от клиентов на веб-серверах:

http protocol "httpssl" {

header append "$REMOTE_ADDR" to "X-Forwarded-For"

header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By" header change "Keep-Alive" to "$TIMEOUT"

query hash "sessid" cookie hash "sessid"

path filter "*command=*" from "/cgi-bin/index.cgi" ssl { sslv2, ciphers "MEDIUM:HIGH" }

tcp { nodelay, sack, socket buffer 65536, backlog 128 }

}

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

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

URL и хэш куки используется для балансировки нагрузки, чтобы выбрать  те  хосты, которые в пуле целевого запроса перенаправляется. Специфика фильтрации пути такова,

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

ограничение второго отброшенного. Опция SSL указывает, что только для SSL версии 2 шфиры будут приняты, с длиной ключа в средне-высоком диапазоне; другими словами,

128 битный или более3. И наконец, в-третьих, tcp опции nodelay задают  минимизацию задержек,   указывающих   на   использование   селективных   методов   (RFC   2018),   и

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

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

Определение relay c помощью обработчика протокола означает, что  шаблон  должен определяться в раннем определении веб-службы:

relay wwwssl {

# Run as a SSL accelerator

listen on $webserver port 443 ssl protocol "httpssl"

table <webhosts> loadbalance check ssl

}

Тем не менее вашим веб приложениям с поддержкой SSL, скорее всего, будет выгодно иметь немного другой набор параметров:

Замечание:

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

Наконец, для отказоустойчивости хостов основанной на CARP relayd в сети  (смотрите

«Избыточность и отказоустойчивость: CARP и pfsync» на странице 119)  должен быть сконфигурирован  для  поддержки  CARP   взаимодействуя  с   установками  понижения счетчика CARP для указанной группы интерфейсов при выключении или запуске. Похоже все части системы OpenBSD идут с информативными страницами мануалов. Для угловатых вариантов  не  освещенных  здесь  (есть  несколько),  изучайте  страницы  мануалов  для relayd,   relayd.conf   и   relayctl,   и   начинайте   экспериментировать   для   поиска   той конфигурации, что вам нужна.

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий