CARP (Common Address Redundancy Protocol) — различия между версиями

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:05, 24 декабря 2016.
(Новая страница: «{{Карточка протокола |Аббр = CARP |Название = Common Address Redundancy Protocol |Уровень = Протоколы сет…»)
 
 
(не показаны 3 промежуточные версии этого же участника)
Строка 1: Строка 1:
{{Карточка протокола
+
'''CARP''' (от {{lang-en|Common Address Redundancy Protocol}} — протокол дупликации общего адреса) — сетевой протокол, основной задачей которого является использование одного IP-адреса несколькими хостами в пределах сегмента сети.
  |Аббр = CARP
+
  |Название = Common Address Redundancy Protocol
+
  |Уровень = [[Протоколы сетевого уровня|3 (сетевой)]]
+
  |Семейство = [[стек протоколов TCP/IP|TCP/IP]]
+
  |Создан = [[2003]]
+
  |Порт =
+
  |Назначение = распределение [[IP-адрес]]а по нескольким [[хост]]ам
+
  |Спецификация =
+
  |Клиенты =
+
  |Серверы =
+
}}
+
'''CARP''' (от {{lang-en|Common Address Redundancy Protocol}} — протокол дупликации общего адреса) — [[сетевой протокол]], основной задачей которого является использование одного [[IP-адрес]]а несколькими [[хост]]ами в пределах сегмента сети.
+
  
CARP является свободной, безопасной (в той степени, в какой вообще можно говорить о безопасности протокола ARP) альтернативой протоколам [[VRRP]] и [[HSRP]]. CARP позволяет выделить группу хостов в сегменте сети и назначить ей один IP-адрес. Такая группа называется «redundancy group» (группа избыточности). В пределах этой группы один из хостов становится «главным», а остальные обозначаются как «резервные». В каждый момент времени мастер-хост отвечает на [[ARP]]-запросы к назначенному IP-адресу и обрабатывает трафик, идущий к этому адресу. Каждый хост одновременно может принадлежать к нескольким группам.
+
CARP является свободной, безопасной (в той степени, в какой вообще можно говорить о безопасности протокола ARP) альтернативой протоколам VRRP и HSRP. CARP позволяет выделить группу хостов в сегменте сети и назначить ей один IP-адрес. Такая группа называется «redundancy group» (группа избыточности). В пределах этой группы один из хостов становится «главным», а остальные обозначаются как «резервные». В каждый момент времени мастер-хост отвечает на ARP-запросы к назначенному IP-адресу и обрабатывает трафик, идущий к этому адресу. Каждый хост одновременно может принадлежать к нескольким группам.
  
Одним распространённым случаем использования CARP является создание избыточности на [[Межсетевой экран|брандмауэрах]]. Виртуальный IP-адрес, который назначен на группу избыточности, указан на клиентских машинах в качестве шлюза по умолчанию. В случае отказа брандмауэра, выполняющего роль мастера, резервный брандмауэр возьмёт этот IP-адрес и продолжит обслуживание клиентов. Дизайн CARP требует, чтобы члены одной группы физически находились в одной подсети с одним статическим IP-адресом, хотя с введением директивы carpdev нет необходимости назначать адрес на физический интерфейс. Сервисы, требующие постоянного соединения с сервером (такие, как [[SSH]] и [[IRC]]) не могут быть прозрачно переброшены в случае отказа и потребуют переподключения. CARP не может синхронизировать данные между приложениями. Для решения этой проблемы могут использоваться дополнительные механизмы, осуществляющие синхронизацию состояния брандмауэров, например, [[pfsync]].
+
Одним распространённым случаем использования CARP является создание избыточности на [[Межсетевой экран|брандмауэрах]]. Виртуальный IP-адрес, который назначен на группу избыточности, указан на клиентских машинах в качестве шлюза по умолчанию. В случае отказа брандмауэра, выполняющего роль мастера, резервный брандмауэр возьмёт этот IP-адрес и продолжит обслуживание клиентов. Дизайн CARP требует, чтобы члены одной группы физически находились в одной подсети с одним статическим IP-адресом, хотя с введением директивы carpdev нет необходимости назначать адрес на физический интерфейс. Сервисы, требующие постоянного соединения с сервером (такие, как SSH и IRC) не могут быть прозрачно переброшены в случае отказа и потребуют переподключения. CARP не может синхронизировать данные между приложениями. Для решения этой проблемы могут использоваться дополнительные механизмы, осуществляющие синхронизацию состояния брандмауэров, например, pfsync.
  
CARP также поддерживает распределение нагрузки посредством балансировки [[ARP]]. Когда хосты, объединённые в CARP-группу, принимают ARP-запрос, то исходящий IP-адрес используется для определения, какой из хостов будет отвечать. В этом случае хост, выбранный главным для виртуальной группы, ответит, а остальные проигнорируют запрос. Связанные серверы<!-- what the hell is that?! ~~~ ---> примут различные ARP-ответы и последующий трафик будет балансироваться между серверами. В случае отказа одного из хостов в CARP-группе один из оставшихся перехватит виртуальный [[MAC-адрес]] и будет отвечать на ARP-запросы. Балансировка ARP работает только в локальном сегменте. Она невозможна при использовании промежуточного маршрутизатора, так как маршрутизатор будет направлять данные на один и тот же хост.
+
CARP также поддерживает распределение нагрузки посредством балансировки ARP. Когда хосты, объединённые в CARP-группу, принимают ARP-запрос, то исходящий IP-адрес используется для определения, какой из хостов будет отвечать. В этом случае хост, выбранный главным для виртуальной группы, ответит, а остальные проигнорируют запрос. Связанные серверы примут различные ARP-ответы и последующий трафик будет балансироваться между серверами. В случае отказа одного из хостов в CARP-группе один из оставшихся перехватит виртуальный MAC-адрес и будет отвечать на ARP-запросы. Балансировка ARP работает только в локальном сегменте. Она невозможна при использовании промежуточного маршрутизатора, так как маршрутизатор будет направлять данные на один и тот же хост.
  
 
== История создания ==
 
== История создания ==
В конце [[1990-е|90-х]] [[IETF]] начал работать над созданием протокола для резервирования [[маршрутизатор]]ов. В [[1997 год]]у компания [[Cisco]] сообщила, что подобный протокол (HSRP) уже запатентован ими. Тем не менее, IETF продолжал работу над протоколом VRRP. Поскольку VRRP решил проблемы протокола HSRP, Cisco стала использовать VRRP, утверждая, что он является их собственностью.
+
В конце 90-х IETF начал работать над созданием протокола для резервирования маршрутизаторов. В 1997 году компания Cisco сообщила, что подобный протокол (HSRP) уже запатентован ими. Тем не менее, IETF продолжал работу над протоколом VRRP. Поскольку VRRP решил проблемы протокола HSRP, Cisco стала использовать VRRP, утверждая, что он является их собственностью.
  
Из-за патента на HSRP было невозможно разработать свободную реализацию VRRP, поэтому программисты команды [[OpenBSD]] начали разрабатывать CARP как альтернативу патентованному VRRP. Чтобы избежать судебного иска из-за патента HSRP, разработчики гарантировали, что CARP существенно отличается от HSRP. Разработка протокола была завершена командой проекта OpenBSD в октябре [[2003 год]]а, и первой [[Операционная система|операционной системой]] с поддержкой CARP стала OpenBSD 3.5<ref>[http://www.openbsd.org/35.html#new What's new in OpenBSD 3.5]{{ref-en}}</ref>. Позже поддержка протокола появилась во [[FreeBSD]] (под именем "ucarp") и [[NetBSD]], а затем и в [[DragonFlyBSD]].
+
Из-за патента на HSRP было невозможно разработать свободную реализацию VRRP, поэтому программисты команды [[OpenBSD]] начали разрабатывать CARP как альтернативу патентованному VRRP. Чтобы избежать судебного иска из-за патента HSRP, разработчики гарантировали, что CARP существенно отличается от HSRP. Разработка протокола была завершена командой проекта OpenBSD в октябре 2003 года, и первой [[Операционная система|операционной системой]] с поддержкой CARP стала OpenBSD 3.5<ref>[http://www.openbsd.org/35.html#new What's new in OpenBSD 3.5]{{ref-en}}</ref>. Позже поддержка протокола появилась во [[FreeBSD]] (под именем "ucarp") и [[NetBSD]], а затем и в DragonFlyBSD.
 +
 
 +
==Принцип работы CARP==
 +
 
 +
Мастер-хост группы регулярно рассылает объявления по сети, с целью оповестить остальные машины группы, что он все еще работоспособен. В случае, если резервной машиной объявление не будет получено в течение заданного интервала, то она перехватывает функции мастер-хоста (та из них, которая имеет меньшие значения advbase и advskew). Это сделано для работы нескольких CARP-групп в пределах одного сегмента. Объявления CARP содержат Virtual Host ID, который позволяет членам группы идентифицировать, предназначено ли объявление для данной группы.
 +
 
 +
Для предотвращения спуфинга объявлений CARP, каждая группа может быть сконфигурирована на использование пароля. В этом случае, каждый CARP пакет в группе шифруется по алгоритму SHA1 HMAC.
 +
 
 +
===Конфигурирование CARP===
 +
 
 +
Каждая отказоустойчивая группа представлена виртуальным сетевым интерфейсом carp(4). Как следствие, CARP конфигурируется с помощью ifconfig(8). Доступны следущие опции:
 +
 
 +
<code>ifconfig carpN vhid vhid [pass password] [carpdev carpdev] [advbase advbase] [advskew advskew] [state state] [group|-group group] ipaddress netmask mask</code>
 +
 
 +
* carpN: имя виртуального интерфейса carp(4), где N - целое число, обозначающее номер интерфейса (например carp0).
 +
* vhid: Virtual Host ID. Уникальное число, которое используется для обозначения группы избыточности. Возможные значения лежат в диапазоне от 1 до 255. Это позволяет иметь несколько групп в пределах одной сети.
 +
* password: пароль, используемый для обмена сообщениями CARP. Должен быть одинаковым в пределах группы.
 +
* carpdev: опциональный параметр, указывающий на физический сетевой интерфейс, принадлежащий группе избыточности. По умолчанию, CARP будет пытаться использовать тот интерфейс, к которому присвоен адрес из той же подсети, что и на интерфейсе carp(4).
 +
* advbase: этот опциональный параметр определяет, как часто происходят объявления о членстве в группе избыточности. Значение по умолчанию - 1 секунда. Возможные значения лежат в диапазоне от 1 до 255.
 +
* advskew: этот опциональный параметр указывает, на сколько будет задержано обьявление advbase. Управляя параметром advbase, можно контролировать, какой хост станет мастером. Чем выше это число, тем меньше статус этого хоста. Значение по умолчанию - 0. Возможные значения лежат в диапазоне от 1 до 254.
 +
* state: перевести интерфейс carp(4) в определенное состояние. Может принимать значения init, backup и master.
 +
* ipaddress: адрес, назначенный группе избыточности. Данный адрес должен быть в одной сети с адресом на физическом интерфейсе (если он назначен).
 +
* mask: маска подсети группы.
 +
 
 +
Поведением CARP можно управлять с помощью sysctl(8).
 +
* net.inet.carp.allow: принимать входящие пакеты carp. Установлено по умолчанию.
 +
* net.inet.carp.preempt: позволяет виртуальным хостам резервировать друг друга. Эта функция используется для обеспечения отказоустойчивости в группе. Когда эта опция установлена и один из физических интерфейсов на котором выполняется carp теряет связь, advskew устанавливает значение 240 на всех carp интерфейсах. Хост, у которого advskew меньше назначается главным в группе и на него направляются пакеты до отказа интерфейса. По умолчанию выключено.
 +
* net.inet.carp.log: значение 0 отключает ведение журнального файла. Значение 1 фиксирует некорректные пакеты carp и состояние интерфейса. По умолчанию 0.
 +
* net.inet.carp.arpbalance: балансировка локального трафика используя ARP. по умолчанию выключено.
  
 
== Примечания ==
 
== Примечания ==
 
<references/>
 
<references/>
  
== Ссылки ==
+
==Источники==
* [http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4 man-страница carp(4) проекта OpenBSD]{{ref-en}}
+
* man-страница carp(4) проекта OpenBSD [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4
* [http://www.openbsd.org/lyrics.html#35 Комментарий к выходу OpenBSD 3.5 касаемо ситуации с CARP]{{ref-en}}
+
* Комментарий к выходу OpenBSD 3.5 касаемо ситуации с CARP [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: http://www.openbsd.org/lyrics.html#35
 +
* CARP, материал из Википедии [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: https://ru.wikipedia.org/wiki/CARP
 +
* CARP(4) Руководство по интерфейсам ядра FreeBSD (carp apr balance openbsd freebsd cluster) [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: https://www.opennet.ru/base/net/carp_freebsd.txt.html

Текущая версия на 16:05, 24 декабря 2016

CARP (от англ. Common Address Redundancy Protocol — протокол дупликации общего адреса) — сетевой протокол, основной задачей которого является использование одного IP-адреса несколькими хостами в пределах сегмента сети.

CARP является свободной, безопасной (в той степени, в какой вообще можно говорить о безопасности протокола ARP) альтернативой протоколам VRRP и HSRP. CARP позволяет выделить группу хостов в сегменте сети и назначить ей один IP-адрес. Такая группа называется «redundancy group» (группа избыточности). В пределах этой группы один из хостов становится «главным», а остальные обозначаются как «резервные». В каждый момент времени мастер-хост отвечает на ARP-запросы к назначенному IP-адресу и обрабатывает трафик, идущий к этому адресу. Каждый хост одновременно может принадлежать к нескольким группам.

Одним распространённым случаем использования CARP является создание избыточности на брандмауэрах. Виртуальный IP-адрес, который назначен на группу избыточности, указан на клиентских машинах в качестве шлюза по умолчанию. В случае отказа брандмауэра, выполняющего роль мастера, резервный брандмауэр возьмёт этот IP-адрес и продолжит обслуживание клиентов. Дизайн CARP требует, чтобы члены одной группы физически находились в одной подсети с одним статическим IP-адресом, хотя с введением директивы carpdev нет необходимости назначать адрес на физический интерфейс. Сервисы, требующие постоянного соединения с сервером (такие, как SSH и IRC) не могут быть прозрачно переброшены в случае отказа и потребуют переподключения. CARP не может синхронизировать данные между приложениями. Для решения этой проблемы могут использоваться дополнительные механизмы, осуществляющие синхронизацию состояния брандмауэров, например, pfsync.

CARP также поддерживает распределение нагрузки посредством балансировки ARP. Когда хосты, объединённые в CARP-группу, принимают ARP-запрос, то исходящий IP-адрес используется для определения, какой из хостов будет отвечать. В этом случае хост, выбранный главным для виртуальной группы, ответит, а остальные проигнорируют запрос. Связанные серверы примут различные ARP-ответы и последующий трафик будет балансироваться между серверами. В случае отказа одного из хостов в CARP-группе один из оставшихся перехватит виртуальный MAC-адрес и будет отвечать на ARP-запросы. Балансировка ARP работает только в локальном сегменте. Она невозможна при использовании промежуточного маршрутизатора, так как маршрутизатор будет направлять данные на один и тот же хост.

История создания

В конце 90-х IETF начал работать над созданием протокола для резервирования маршрутизаторов. В 1997 году компания Cisco сообщила, что подобный протокол (HSRP) уже запатентован ими. Тем не менее, IETF продолжал работу над протоколом VRRP. Поскольку VRRP решил проблемы протокола HSRP, Cisco стала использовать VRRP, утверждая, что он является их собственностью.

Из-за патента на HSRP было невозможно разработать свободную реализацию VRRP, поэтому программисты команды OpenBSD начали разрабатывать CARP как альтернативу патентованному VRRP. Чтобы избежать судебного иска из-за патента HSRP, разработчики гарантировали, что CARP существенно отличается от HSRP. Разработка протокола была завершена командой проекта OpenBSD в октябре 2003 года, и первой операционной системой с поддержкой CARP стала OpenBSD 3.5[1]. Позже поддержка протокола появилась во FreeBSD (под именем "ucarp") и NetBSD, а затем и в DragonFlyBSD.

Принцип работы CARP

Мастер-хост группы регулярно рассылает объявления по сети, с целью оповестить остальные машины группы, что он все еще работоспособен. В случае, если резервной машиной объявление не будет получено в течение заданного интервала, то она перехватывает функции мастер-хоста (та из них, которая имеет меньшие значения advbase и advskew). Это сделано для работы нескольких CARP-групп в пределах одного сегмента. Объявления CARP содержат Virtual Host ID, который позволяет членам группы идентифицировать, предназначено ли объявление для данной группы.

Для предотвращения спуфинга объявлений CARP, каждая группа может быть сконфигурирована на использование пароля. В этом случае, каждый CARP пакет в группе шифруется по алгоритму SHA1 HMAC.

Конфигурирование CARP

Каждая отказоустойчивая группа представлена виртуальным сетевым интерфейсом carp(4). Как следствие, CARP конфигурируется с помощью ifconfig(8). Доступны следущие опции:

ifconfig carpN vhid vhid [pass password] [carpdev carpdev] [advbase advbase] [advskew advskew] [state state] [group|-group group] ipaddress netmask mask

  • carpN: имя виртуального интерфейса carp(4), где N - целое число, обозначающее номер интерфейса (например carp0).
  • vhid: Virtual Host ID. Уникальное число, которое используется для обозначения группы избыточности. Возможные значения лежат в диапазоне от 1 до 255. Это позволяет иметь несколько групп в пределах одной сети.
  • password: пароль, используемый для обмена сообщениями CARP. Должен быть одинаковым в пределах группы.
  • carpdev: опциональный параметр, указывающий на физический сетевой интерфейс, принадлежащий группе избыточности. По умолчанию, CARP будет пытаться использовать тот интерфейс, к которому присвоен адрес из той же подсети, что и на интерфейсе carp(4).
  • advbase: этот опциональный параметр определяет, как часто происходят объявления о членстве в группе избыточности. Значение по умолчанию - 1 секунда. Возможные значения лежат в диапазоне от 1 до 255.
  • advskew: этот опциональный параметр указывает, на сколько будет задержано обьявление advbase. Управляя параметром advbase, можно контролировать, какой хост станет мастером. Чем выше это число, тем меньше статус этого хоста. Значение по умолчанию - 0. Возможные значения лежат в диапазоне от 1 до 254.
  • state: перевести интерфейс carp(4) в определенное состояние. Может принимать значения init, backup и master.
  • ipaddress: адрес, назначенный группе избыточности. Данный адрес должен быть в одной сети с адресом на физическом интерфейсе (если он назначен).
  • mask: маска подсети группы.

Поведением CARP можно управлять с помощью sysctl(8).

  • net.inet.carp.allow: принимать входящие пакеты carp. Установлено по умолчанию.
  • net.inet.carp.preempt: позволяет виртуальным хостам резервировать друг друга. Эта функция используется для обеспечения отказоустойчивости в группе. Когда эта опция установлена и один из физических интерфейсов на котором выполняется carp теряет связь, advskew устанавливает значение 240 на всех carp интерфейсах. Хост, у которого advskew меньше назначается главным в группе и на него направляются пакеты до отказа интерфейса. По умолчанию выключено.
  • net.inet.carp.log: значение 0 отключает ведение журнального файла. Значение 1 фиксирует некорректные пакеты carp и состояние интерфейса. По умолчанию 0.
  • net.inet.carp.arpbalance: балансировка локального трафика используя ARP. по умолчанию выключено.

Примечания

  1. What's new in OpenBSD 3.5 (англ.)

Источники

  • man-страница carp(4) проекта OpenBSD [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4
  • Комментарий к выходу OpenBSD 3.5 касаемо ситуации с CARP [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: http://www.openbsd.org/lyrics.html#35
  • CARP, материал из Википедии [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: https://ru.wikipedia.org/wiki/CARP
  • CARP(4) Руководство по интерфейсам ядра FreeBSD (carp apr balance openbsd freebsd cluster) [Электронный ресурс]: Дата обращения: 24.12.2016. — Режим доступа: https://www.opennet.ru/base/net/carp_freebsd.txt.html