Храним состояния синхронизироваными: добавление pfsync

Последняя часть конфигурирования – настройка синхронизации таблиц состояний между

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

Настройка  интерфейсов   pfsync  является   предметом  некоторого   планирования   и использования команды ifconfig. Можно настроить pfsync на сконфигурированном сетевом интерфейсе, однако, лучшей идееё будет установка отдельной сети для синхронизации. В нашем примере конфигурации (рисунок 7-3), мы выделили для этой цели маленькую сеть. В  нашем  случае,   кроссоверный   кабель  соединяет  два   Ethernet  интерфейса,  но  в конфигурациях   с   большим   числом   узлов   отказоустойчивой   группы,   вы   можете использовать отдельный коммутатор, концентратор или VLAN.

В данном примере мы планируем использовать для синхронизации IP адреса 10.0.12.16 и 10.0.12.17. С основной  конфигурацией TCP/IP, полная установка  pfsync для каждого из двух интерфейсов партнёров синхронизации выглядит следующим образом:

$ sudo ifconfig pfsync0 syncdev ep2

Здесь проиллюстрировано преймущество использования идентичного оборудования, а так же  поддержка  трафика  pfsync  на  отдельной  физической  сети.  Сам  протокол  pfsync практически   не   предоставляет   средств   обеспечения   безопасности.   Он   не   имеет механизмов проверки подлинности и, по умолчанию, общается используя многоадресный IP  трафик.  Однако,  для   случаев,   когда  использование   физически  отдельной  сети невозможно, вы можете поднять безопасность pfsync путём создания специфичного узла синхронизации (syncpeer):

$ sudo ifconfig pfsync0 syncpeer 10.0.12.16 syncdev ep2

Команда  приведёт  к  созданию  интерфейса  параметры  которого  можно  просмотреть используя ifconfig:

pfsync0: flags=41<UP,RUNNING> mtu 1500 priority: 0

pfsync: syncdev: ep2 syncpeer: 10.0.12.16 maxupd: 128 defer: off groups: carp pfsync

Ещё один вариант повышения безопасности – создать туннель IPsec и использовать его для защиты трафика синхронизации. Тогда команда ifconfig будет следующая:

$ sudo ifconfig pfsync0 syncpeer 10.0.12.16 syncdev enc0

Это означает, что используется устройство инкапсуляции syncdev enc0, а не физический интерфейс.

Примечание

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

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

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

Составление набора правил

Завершив различные выкрутасы по установке базовых сетевых настроек, вам, наверняка станет интересно, как изменить правила текущего pf.conf для новой установки. Вы будете рады  узнать,  что  это  не  займёт  много  времени.  Основные  изменения  которые  вы

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

Однако,  мы  ввели  два  новых  протокола: CARP  и  pfsync.  По  всей  вероятности  вам придётся внести некоторые небольшие изменения в набор правил, необходимые для того, чтобы переход на резервный ресур работал как требуется. В принципе, вам необходимо направить трафик CARP и pfsync на соответствующие интерфейсы.

Наиболее приемлемым способом управления трафиком CARP является введение макросов для ваших carpdevs и соответствующих правил pass, например:

pass on $carpdevs proto carp

Вам необходимо передать трафик pfsync на соответствующие интерфейсы. Аналогично, для трафика pfsync, можно ввести макрос для syncdev и соответствующее правило pass:

pass on $syncdev proto pfsync

Если вы хотите вывести устройство pfsync из системы фильтрации используйте следующее правило:

set skip on $syncdev

Исключить  pfsync  интерфейсы  из  фильтрации  обходится  дешевле   фильтровать   и пропускать.

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

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

pass in on $int_if from $ssh_allowed to self

Для   этих   правил   вы   можете   использовать   опцию   no-sync   для   предотвращения синхронизации изменения состояния для соединений,  которые  не имеют отношения к

отказоустойчивости:

pass in on $int_if from $ssh_allowed to self keep state (no-sync)

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

IFSTATE, ДЕМОН СОСТОЯНИЯ ИНТЕРФЕЙСА

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

ifstated был введён в OpenBSD 3.5 в качестве инструмента для запуска действий основанных на  изменении состояния сетевого интерфейса. вы можете думать о ifstated как о "маленьком помощнике CARP". ifstated включён в базовую систему OpenBSD   и   доступен   посредством   портов   net/ifstated   на    FreeBSD.    В   OpenBSD,   файл   /etc/ifstated.conf   (или

/usr/local/etc/ifstated.conf если вы установили порт на FreeBSD) содержит практически готовую к работе  конфигурацию, которая даёт вам множество ответов по настройке ifstated в окружающей среде.

основные контролируемые объекты  – интерфейсы и их состояния, где carp0.link.up – состояние, в котором интерфейс carp0 имеет связь и вы выполняете действия в ответ на изменение состояния. Они определяются  простым языком сценариев с основными особенностями подобными переменным, макросам и простым  логическим условиям. Обратитесь к man-странице ifstated и ifstated.conf если хотите разобраться подробнее.


CARP для балансировки нагрузки

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

Дополняя балансировку ARP, которая работает путём вычисления хешей, основываясь на MAC адресе источника входящего соединения, CARP в OpenBSD 4.3 и выше поддерживает несколько  разновидностей  балансировки  IP  нагрузки,  где  трафик  распределяется  на основе  вычисления  хешей IP адресов  источника  и назначения соединения. Поскольку балансировка  ARP основана  на  MAC адресе источника, она будет работать только для хостов в непосредственно подключенном сетевом сегменте. Метод основанные на IP более подходящи для балансировки нагрузки соединений в сетью Интернет.

Какой выбрать режим зависит от вашего приложения и точных спецификаций сетевого оборудования  используемого  в   работе.  Основной  режим  IP  балансировки  использует групповой   MAC   адрес   для   создания   непосредственно   подключенногокоммутатора направляющего   трафик   всем   хостам   кластера   балансировки   нагрузки.   Сочетание индивидуального   IP   адреса  и  группового   MAC  адреса  может  не  поддерживаться некоторыми системами. В таком случае, вам может потребоваться настройка балансировки нагрузки   в      режиме   одноадресного   IP   (ip-unicast   mode)   (который    использует индивидуальный  MAC  адрес)  и  сконфигурировать  ваш  коммутатор  для  направления трафика соответствующим хостам, или в режиме невидимого IP (ip-stealth mode), который не использует групповой  MAC. Как обычно,  проблемы  скрываются  в  деталях, а ответы можно  найти  в   руководстве  и  прочей  документации,  при  условии  проведения  ряда экспериментов.

Замечание

Традиционно, relayd использовался для интеллектуальной балансировки нагрузки в качестве  фронтенда для серверов которые предлагали свои  сервисы.  В OpenBSD 4.7, relayd приобрёл возможность  отслеживать  доступные  каналы и изменять таблицы маршрутизации основываясь на состоянии линков, используя обертку с ключевым словом router. Для установки с несколькими возможными каналами или вариантами таблиц маршрутизации, вы можете настроить relayd для выбора вашего канала, или  с некоторой помощью переменных sysctl  net.inet.ip.multipath и net.inet6.ip6.multipath, выполнять  балансировку  нагрузки между доступными маршрутами и  каналами. Конкретная специфика будет изменяться в  зависимости  от сетевого  окружения. man- страница relayd.conf включает полный пример для начала работы.

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

Какая группа и каким физическим хостом заканчивается обработка данного соединения – определяется CARP, посредством значения хеша, вычисляемого на основании MAC адреса источника соединения в  случае выбора  ARP  балансировки,  или IP адресе источника и назначения при выборе  IP  балансировки.  Обратной стороной этого, является  то, что каждая  из  этих  групп  потребляет  один  виртуальный  идентификатор  хоста,  так  что нехватка  идентификаторов  при  использовании  конфигурации  балансировки  нагрузки, будет ощущаться быстрее чем при конфигурации отказоустойчивости.  На  самом деле, существует жесткий верхний предел числа кластеров балансировки нагрузки основаных на CARP, установленный в 32 виртуальных идентификаторов хостов.

Параметр  advskew  играет  аналогичную  роль  при  балансировке   нагрузки,   однако синтаксис ifconfig (и соответственно  hostname.carp№) несколько  отличается от режима отказоустойчивости.   Изменение  группы   отказоустойчивости   CARP  созданной  нами  в предыдущих разделах к кластеру балансировки нагрузки заключается в  редактировании конфигурационных  файлов  и  перезагрузке. В  этом  примере  мы  пойдём  по  схеме  IP балансировки.  Если  вы  выбираете  отличную схему,  конфигурации  будут  различаться только ключевым словом выбора режима.

На первом хосте мы изменим файл /etc/hostname.carp0 следующим образом:

pass mekmitasdigoat 192.0.2.19 balancing ip carpnodes 5:100,6:0

Это значит, что на данном хосте, интерфейс carp0 является членом группы с vhid 5, где advskew = 100, а так же vhid 6, где он является  главным  кандидатом на получение master’а, с avdskew = 0.

Теперь изменим /etc/hostname.carp1:

pass mekmitasdigoat 192.168.12.1 balancing ip carpnodes 3:100,4:0

Для carp1, участника vhid 3 и 4, значения advskew 100 и 0 соответственно.

Для другого хоста значения advskew соответственно меняются местами, а конфигурации похожи. Здесь /etc/hostname.carp0 выглядит так:

pass mekmitasdigoat 192.0.2.19 balancing ip carpnodes 5:0,6:100

Соответственно,  он является  участником vhid 5 с advskew = 0 и участником  vhid 6   с advskew = 100. Файл /etc/hostname.carp1 выглядит следующим образом:

pass mekmitasdigoat 192.168.12.1 balancing ip carpnodes 3:0,4:100

И снова, carp1 является участником vhid3 и 4, с advskew 0 и 100 соответственно.

Вывод ifconfig для группы интерфейсов CARP на первом хосте выглядит так:

$ ifconfig carp

carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 01:00:5e:00:01:05

priority: 0

carp: carpdev vr0 advbase 1 balancing ip state MASTER vhid 5 advskew 0

state BACKUP vhid 6 advskew 100 groups: carp

inet 192.0.2.19 netmask 0xffffff00 broadcast 192.0.2.255

inet6 fe80::200:24ff:fecb:1c10%carp0 prefixlen 64 scopeid 0x7

carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 01:00:5e:00:01:03

priority: 0

carp: carpdev vr1 advbase 1 balancing ip state MASTER vhid 3 advskew 0

state BACKUP vhid 4 advskew 100 groups: carp

inet 192.168.12.1 netmask 0xffffff00 broadcast 192.168.12.255 inet6 fe80::200:24ff:fecb:1c10%carp1 prefixlen 64 scopeid 0x8 pfsync0: flags=41<UP,RUNNING> mtu 1500

priority: 0

pfsync: syncdev: vr2 syncpeer: 10.0.12.17 maxupd: 128 defer: off groups: carp pfsync

А на втором хосте так:

$ ifconfig carp

carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 01:00:5e:00:01:05

priority: 0

carp: carpdev vr0 advbase 1 balancing ip state BACKUP vhid 5 advskew 100

state MASTER vhid 6 advskew 0 groups: carp

inet 192.0.2.19 netmask 0xffffff00 broadcast 192.0.2.255

inet6 fe80::200:24ff:fecb:1c18%carp0 prefixlen 64 scopeid 0x7

carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 01:00:5e:00:01:03

priority: 0

carp: carpdev vr1 advbase 1 balancing ip state BACKUP vhid 3 advskew 100

state MASTER vhid 4 advskew 0 groups: carp

inet 192.168.12.1 netmask 0xffffff00 broadcast 192.168.12.255 inet6 fe80::200:24ff:fecb:1c18%carp1 prefixlen 64 scopeid 0x8 pfsync0: flags=41<UP,RUNNING> mtu 1500

priority: 0

pfsync: syncdev: vr2 syncpeer: 10.0.12.16 maxupd: 128 defer: off groups: carp pfsync

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

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

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

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

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

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