CARP(4) Руководство по интерфейсам ядра FreeBSD CARP(4)

НАЗВАНИЕ

carp -- (Common Address Redundancy Protocol) Протокол резервирования разделяемых адресов

СИНОПСИС

Псевдо-устройство carp

ОПИСАНИЕ

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

Интерфейс carp может быть создан "на лету" с помощью команды ifconfig carpN create, либо с использованием опции cloned_interfaces в файле /etc/rc.conf.

Чтобы использовать carp, администратору нужно сконфигурировать по крайней мере идентификаторы виртуальных хостов VHID (Virtual Host Identifier), а также IP-адреса виртуальных хостов на каждой из машин, входящих в виртуальную группу. Дополнительные параметры могут быть установлены индивидуально для каждого интерфейса: advbase и advskew определяют частоту, с которой хост отправляет уведомления о том, что он является ведущим в группе; pass используется для аутентификации сообщений CARP. Название параметра advbase является сокращением от "advertisement base" (базовый интервал уведомлений). Значение этого параметра измеряется в секундах и определяет продолжительность базового интервала между отправкой уведомлений. Сокращение advskew происходит от "advertisement skew" (отклонение интервала уведомлений). Значение параметра измеряется временными интервалами, кратными 1/256 секунды. Этот параметр используется для добавления небольшой задержки к базовому интервалу, чтобы один из хостов отправлял уведомления чуть реже остальных. Оба параметра advbase и advskew приводятся в сообщениях CARP-протокола. Настройка этих параметров может быть выполнена с использованием ifconfig, либо посредством опций ioctl.

net.inet.carp.allow	Принимать входящие carp-пакеты. Разрешено по-умолчанию.
net.inet.carp.preempt	Этот параметр позволяет виртуальным хостам реализовывать приоритет по отношению к остальным. Также он используется для отработки отказа ряда интерфейсов как единой группы. Когда данная опция включена, в случае отказа одного из физических интерфейсов, на котором активирован протокол CARP, значение параметра advskew изменяется на 240 для всех CARP-интерфейсов. См. пример номер один. По-умолчанию отключено.
net.inet.carp.log	Значение 0 отключает ведение каких-либо логов. Значение 1 разрешает запись в лог CARP-пакетов, которые не могут быть корректно обработаны. Значения, превышающие 1, разрешают запись в лог изменения состояний CARP-интерфейсов. Значение по-умолчанию равно 1.
net.inet.carp.arpbalance	Включает балансирование трафика с использованием протокола ARP (см. ниже). По-умолчанию отключено.
net.inet.carp.suppress_preempt	Параметр только для чтения, отображающий состояние блокировки повышения приоритета. Повышение приоритета может быть заблокировано если линк, подключенный к данному интерфейсу, поврежден, либо когда интерфейс pfsync не синхронизирован. Нулевое значение параметра означает, что блокировка повышения приоритета не применялась, следовательно, проблем зафиксировано не было. С появлением каждой проблемы значение параметра увеличивается на единицу.

Балансирование нагрузки на уровне ARP

Протокол CARP обладает ограниченным набором возможностей для балансирования входящего трафика между хостами в ethernet-сети. Для использования балансирования нагрузки, нужно сконфигурировать несколько CARP-интерфейсов с одинаковым IP-адресом, но различными VHID. Таким образом, при получении ARP-запроса, протокол CARP применив функцию хеширования к IP-адресу источника ARP-запроса определит VHID хоста, которому этот запрос принадлежит. Если соответствующий CARP-интерфейс находится в состоянии "ведущий", будет отправлен ответ на ARP-запрос, в противном случае запрос будет проигнорирован. См. примеры использования балансирования нагрузки в разделе ПРИМЕРЫ.

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

ПРИМЕРЫ

Для межсетевых экранов и маршрутизаторов с несколькими интерфейсами желательно использовать защиту от сбоев всех CARP-интерфейсов сразу. Для этого применяется опция реализации приоритета. Включим ее на хостах А и Б:

sysctl net.inet.carp.preempt=1

Полагая, что хост А должен быть ведущим и на одном из его физических интерфейсах сконфигурирован адрес 192.168.1.х/24, а на другом - 192.168.2.х/24. Настройки хоста А будут иметь вид:

ifconfig carp0 create
ifconfig carp0 vhid 1 pass mekmitasdigoat 192.168.1.1/24
ifconfig carp1 create
ifconfig carp1 vhid 2 pass mekmitasdigoat 192.168.2.1/24

Настройки хоста Б идентичны, но для него установлены большие значения advskew:

ifconfig carp0 create
ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.1/24
ifconfig carp1 create
ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.2.1/24

При включенной опции реализации приоритета, в случае отказа одного из интерфейсов хоста А, значение параметра advskew будет установлено равным 240 на всех CARP-интерфейсах. Это позволит хосту Б получить повышенный приоритет по отношению к обоим интерфейсам хоста А, а не только к тому, что отказал.

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

Сначала конфигурируются CARP-интерфейсы на хосте А. Значение параметра advskew равное 100 для второго виртуального хоста, означает, что его сообщения будут отсылаться чуть реже остальных.

ifconfig carp0 create
ifconfig carp0 vhid 1 pass mekmitasdigoat 192.168.1.10/24
ifconfig carp1 create
ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.1.10/24

Конфигурация хоста Б идентична, за исключением того, что значение параметра advskew изменено для виртуального хоста 1, а не для виртуального хоста 2.

ifconfig carp0 create
ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.10/24
ifconfig carp1 create
ifconfig carp1 vhid 2 pass mekmitasdigoat 192.168.1.10/24

И наконец, функция балансирования при помощи ARP должна быть включена на обоих хостах:

sysctl net.inet.carp.arpbalance=1

Когда хосты получают ARP-запрос адресованный 192.168.1.10, IP-адрес источника запроса используется для определения виртуального хоста, который должен ответить на запрос. Виртуальный хост, находящийся в состоянии "ведущий", ответит на запрос, в то время как другой виртуальный хост проигнорирует его.

Таким образом, локально подключенные хосты будут получать различные ARP-ответы и, как следствие, IP-трафик будет сбалансирован между хостами А и Б. При отказе одного из хостов, другой примет его виртуальный MAC-адрес и станет отвечать на ARP-запросы от его имени.

СМОТРИ ТАКЖЕ

inet(4), pfsync(4), rc.conf(5), ifconfig(8), sysctl(8)

ХРОНОЛОГИЯ

Впервые протокол CARP был реализован в OpenBSD 3.5. Устройство CARP было импортировано во FreeBSD 5.4.

FreeBSD 7.2 6 июня 2006 FreeBSD 7.2