antiCisco blogs

Опубликовано dmbaturin 27 Март , 2011

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

На выбор предлагается два механизма:

1. VRRP (Virtual Router Redundancy Protocol). Традиционный протокол резервирования, поддерживаемый многими поставщиками.
2. Кластеризация. С другими системами несовместима, зато умеет проверять доступность на сетевом уровне.

Сегодня мы рассмотрим только VRRP. Также с любым из них может быть использован механизм синхронизации таблицы соединений, который позволяет резервной железке подхватить сессии вышедшей из строя.

VRRP

О протоколе

Основным понятием VRRP является «виртуальный маршрутизатор», представляющий собой группу интерфейсов с разными IP-адресами и общим виртуальным адресом, который может одновременно принадлежать только одному из них. Соответственно, маршрутизатор из группы может быть основным (master), если он сейчас использует виртуальный адрес; либо резервным (backup).

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

Разные интерфейсы маршрутизатора могут принадлежать к разным виртуальным маршрутизаторам.

Основным интерфейсом становится интерфейс с наибольшим приоритетом (который задается в настройках), при совпадении приоритетов — с наибольшим IP-адресом.

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

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

Настройка

Настраивается в свойствах интерфейса. Может быть настроен как для физических интерфейсов, так и для VLAN.

set interfaces ethernet eth0 vrrp vrrp-group <1-255> ...

Основные параметры следующие:

• virtual-address <IPv4> — виртуальный адрес группы интерфейсов;
• priority <1-255> — приоритет интерфейса для выборов основного маршрутизатора;
• preempt <true|false> — отдавать ли виртуальный адрес интерфейсу с большим приоритетом при его появлении в группе;
• hello-source-address <IPv4> — адрес, с которого отправлять сообщения о состоянии интерфейса;
• disable — отключить участие в группе;
• description — описание.

Также можно настроить синхронизацию групп, если разные интерфейсы маршрутизатора принадлежат к разным группам. В этом случае при падении одного интерфейса все остальные автоматически перейдут в состояние резервных, что может быть полезно, если топология такова, что для выполнения маршрутизатором своей задачи все интерфейсы должны быть активны одновременно. Для всех таких интерфейсов нужно указать «sync-group <NAME>» (с одинаковым для всех интерфейсов маршрутизатора именем).

И в завершение этой части, приведу пример настроек:

# show interfaces ethernet eth0
 address 10.91.17.102/24
 vrrp {
     vrrp-group 1 {
         priority 200
         sync-group SOME_GROUP
         virtual-address 10.91.17.160
     }
 }

Также существует опция «run-transition-scripts [master|backup|fault] </path/to/script>», которая позволяет выполнять скрипт при изменении состояния. Таким образом можно обеспечить отказоустойчивость для IPv6 (версия VRRP для него еще находится в разработке) или отключить сервисы.

Синхронизация соединений

В резервировании обидно только одно — при переходе виртуального адреса резервному маршрутизатору сбрасываются все соединения. С версии 6.1 появился механизм, позволяющий этого избежать (или хотя бы минимизировать потери).

Если он используется с VRRP, на интерфейсах обязательно должна быть настроена sync-group.

Этот механизм синхронизирует таблицу состояний соединений, используемую МСЭ и NAT.

set service conntrack-sync ...

Основные параметры:

• interface <Interface name> — используемый интерфейс;
• failover-mechanism [vrrp sync-group <NAME>|cluster group <NAME>] — механизм резервирования;
• mcast-group <IPv4> — групповой адрес для обеспечения синхронизации, по умолчанию 224.0.0.50;
• event-listen-queue-size <SIZE IN MEGABYTES> — размер локальной очереди, используемой для синхронизации;
• sync-queue-size <SIZE IN MEGABYTES> — размер очереди, хранящей информацию о синхронизации;
• accept-protocol <PROTOCOL LIST> — протоколы, соединения по которым будут синхронизированы.

Простой пример настройки:

# show service conntrack-sync 
 failover-mechanism {
     vrrp {
         sync-group SOME_GROUP
     }
 }
 interface eth0

При построении правил NAT, если используется этот механизм, следует использовать виртуальный адрес.

Заключение

Мы кратко рассмотрели как можно обеспечить горячее резервирование. Более подробную информацию об этом можно найти в документе Vyatta_HARef*.pdf из комплекта документации.

 

Опубликовано: Vyatta