null

Probe-based IPMP

 

 Недавно мы с Сергеем Кляусом понаписали 2 статьи про IPMP. Но, как мне кажется, вопросу probe-based уделили недостаточно внимания. Посему было решено взять буквы и составить из них данный текст.

Технология IP multipathing подразумевает мониторинг состояния сетевых интерфейсов и, при недоступности некоторых из них, действия по перемещению логических сетевых интерфейсов. За эти махинации отвечает демон in.mpathd. Используется два основных метода выявления неисправностей: link-based и probe-based. Кроме этого, в OpenSolaris отслеживаются ситуации, когда существует файл /etc/hostname.inerface, а соответствующий ему физический интерфейс отсутствует при загрузке системы. В таком случае, при установке сетевой карточки (используя DR), интерфейс будет сконфигурирован автоматически.


Link-based failure detection

При использовании Link-based failure detection, in.mpathd реагирует на отсутствие линка (а точнее на сброс флага RUNNING) немедленной установкой fail'а на интерфейс. Данный метод используется всегда, за исключением тех редких случаев, когда сетевое устройство/драйвер не поддерживают уведомление об изменении состояния сетевого соединения.

Результат Link-based failure detection можно лицезреть в колонке LINK вывода команды ipmpstat -i:

 

Probe-based failure detection

Понятно, что наличие линка вовсе не означает доступность интерфейса, и в большинстве случаев лишь говорит о наличии соединения с ближайшим свитчём. Probe-based тесты подразумевают обмен icmp echo пакетами с определенными хостами, именуемыми target'ами. Интерфейс забраковывается, если ответ не получен подряд на пять echo запросов. Интенсивность запросов определяется временем детектирования неисправности (Fail Detection Time, FDT), лицезреть которое можно при помощи команды ipmpstat -g:

# ipmpstat -g
GROUP       GROUPNAME   STATE     FDT       INTERFACES
ipmpi0      ipmpi0      ok        10.00s    sub1 (sub0)

 

По умолчанию FDT равно 10 секундам и может быть изменено в файле /etc/deafult/mpathd. Хорошим и годным интерфейс признается при получении ответов в течение времени RDT (repair detection time), равном 2*FDT.

 

Почти всем людям очевидно, что для probe-based проверки физическому интерфейсу необходим ip адрес. Такой адрес называется test address и он не должен использоваться приложениями для обмена данных. Все, что надо, чтобы задействовать probe-based тест, это добавить test address:

# ifconfig sub0 -failover 192.168.2.85/24
# ipmpstat -i
INTERFACE   ACTIVE  GROUP       FLAGS     LINK      PROBE     STATE
sub1        yes     ipmpi0      --mb---   up        disabled  ok
sub0        no      ipmpi0      is-----   up        ok        ok


Ключ -t показывает текущие target'ы для probe тестов, а -p покажет статистику тестовых пакетов:

# ipmpstat -t
INTERFACE   MODE      TESTADDR            TARGETS
sub1        disabled  --                  --
sub0        multicast 192.168.2.85        192.168.2.12 192.168.2.24 192.168.2.22 192.168.2.7 192.168.2.9

# ipmpstat -p
TIME      INTERFACE   PROBE  NETRTT    RTT       RTTAVG    TARGET
0.97s     sub0        2684   1.61ms    2.82ms    2.49ms    192.168.2.12
2.79s     sub0        2685   1.54ms    2.45ms    2.31ms    192.168.2.24
3.79s     sub0        2686   1.73ms    2.56ms    2.37ms    192.168.2.22
5.10s     sub0        2687   1.68ms    2.97ms    2.34ms    192.168.2.7
7.06s     sub0        2688   1.54ms    2.49ms    2.74ms    192.168.2.9
8.45s     sub0        2689   1.70ms    2.97ms    2.55ms    192.168.2.12
9.90s     sub0        2690   1.57ms    2.80ms    2.37ms    192.168.2.24
^C

Осталось разобраться с тем, как формируется список target хостов. Сначала демон in.mpathd шерстит таблицу маршрутизации на предмет наличия в ней маршрутов до хостов, находящихся в той же подсети, что и тестовый интерфейс. Если такие записи найдены, именно эти хосты и будут выступать в роли target'ов. В противном случае in.mpathd засылает icmp echo пакет на multicast адрес (224.0.0.1 для IPv4, и ff02::1 для IPv6), и в качестве target-хостов берутся первые пять ответивших.

Зададим список target-хостов вручную. Как уже должно было стать понятно, для этого достаточно добавить адреса в таблицу маршрутизации:

# route -p add -host 192.168.2.17 192.168.2.17 -static
add host 192.168.2.17: gateway 192.168.2.17
add persistent host 192.168.2.17: gateway 192.168.2.17
# route -p add -host 192.168.2.12 192.168.2.12 -static
add host 192.168.2.12: gateway 192.168.2.12
add persistent host 192.168.2.12: gateway 192.168.2.12
# ipmpstat -t
INTERFACE   MODE      TESTADDR            TARGETS
sub1        disabled  --                  --
sub0        routes    192.168.2.85        192.168.2.12 192.168.2.17

# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
192.168.2.0          192.168.2.83         U         1         22 ipmpi0
192.168.2.0          192.168.2.85         U         1          0 sub0
192.168.2.12         192.168.2.12         UGH       1          0
192.168.2.17         192.168.2.17         UGH       1          0
127.0.0.1            127.0.0.1            UH        5        483 lo0

 

 

Являюсь инженером компании Tune-IT. Проявляю интерес к:

  • вопросам производительности ВС
  • VoIP и Asterisk
  • железу SUN
  • Solaris