VyOS wan load-balancing проверки интерфейсов, правила балансировки

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

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

Проверка интерфейсов

Что бы занести интерфейсы провайдеров в балансинг, нужно использовать команду

Пример конфигурации интерфейсов с двумя провайдерами

10.10.1.1 - шлюз первого провайдера, 10.10.2.1 - шлюз второго провайдера.

В первой же строчки конфигурации нас ждёт засада. flush-connections означает что если один из интерфейсов упадёт, то все активные соединения будут сброшены, для того, чтобы перестроить маршрут. Это очень ощущается при ssh соединениях. При обрыве одного провайдера, у вас будут падать ssh сессии, а потом ещё при подъеме. Поэтому к настройке мониторинга интерфейса надо подходить с умом. Потому что без этой настройки всё будет работать неочень.

Параметр failure-count - это количество попыток теста, после которых интерфейс деактивируется. А success-count это количество успешных попыток теста для активации деактивированого интерфейса. nexthop - шлюз провайдера.

Дальше описываются правила проверки, у вас оно может быть хоть одно, хоть 10. Проверка может быть двух типов icmp и tcp. Про tcp не могу сказать ничего, ибо не использовал. Собственно параметр type описывает тип проверки, resp-time - время за которое должен быть получен ответ в секундах. target - цель проверки, ip адрес ресурса.

Как вообще работает проверка?

Проверка идёт по возрастанию, в моём примере сначала проверяется 10ое правило. Пингуется 8.8.8.8 и только если оно перестанет отвечать, проверка переходит к следующему правилу. И только если все три правила не проходят проверку, в соответствии с заданными параметрами, - интерфейс деактивируется. Состояние текущих проверок можно глянуть командой

Выглядит вот так:

8.8.8.8 и 8.8.4.4 я поставил для примера, вообще не рекомендую их использовать, потому что это слишком отказоустойчивый сервис. Этот гугловый сервер может стоять у вашего провайдера, а навернется магистраль и для проверки всё будет ОК, а интернетов нормальных не будет. Поэтому лучше всего использовать ваши внутренние корпоративные сервисы и какой-нибудь левый отказоустойчивый сервис. Например 173.245.58.51 - это ntp cloudflare (находится только в США), как минимум, он даёт страховку на случай того, если ваши серваки стоящие в проверке навернутся.

Почему я так ратую за адреса? В моей практике были случаи, когда у балансинга стояла проверка серверов, находящихся в России, а обрывалась магистраль у провайдера до США. Поэтому подумайте хорошо, какие лучше адреса и в каком порядке использовать. Ну и проверьте чтоб РКН их не блочил.

Правила балансировки

Для работы балансера нужно как минимум одно правило

inbound-interface - интерфейс локальной сети, где находятся клиенты

interface - под этим параметром вносим интерфейсы, между которыми должна работать балансировка и его вес

С protocol и description и так всё ясно.

Это общее правило, которое затрагивает всех клиентов, подключенных к шлюзу. Трафик балансируется равномерно между ними. Если у вас, например, один провайдер 50 мбит\с, а другой 100 мбит\с, то поставьте веса к примеру 1 и 2 или 50 и 100, чтобы нагрузка распределялась равномерно.

Так же есть возможность сделать режим failover

Веса тут будут служить для failover'a приоритетом. У кого вес больше - тот и работает. Если интерфейс с большим весом падает, то переходит на второй. Возможно у вас один из провайдеров очень медленный (3g или 4g например) или просто плохо работает и вы не можете с этим ничего поделать, а деваться некуда. Тогда failover в основном правиле очень даже кстати.

Но, если у вас всё-таки балансировка то, как показывает практика, одним правилом не обойдешься.

Начнем с того, что VoIP не умеет работать с балансировкой. Вынесем подсеть с телефонами в отдельное правило

Тут используем параметр source address, все кто из подсети 172.16.1.0/24 будут ходить только через одного провайдера.

Так же есть сервисы, которые не могут работать с двумя разными IP в одной сессии. Например, PPTP серверы, некоторые банковские сервисы, LDAP Account Manager и.т.д

Тут используем параметр destination address, которому задаём ip адрес сервиса.

В общем, настраивать можно по-разному. Помните, что главное правило должно стоять в самом конце, иначе остальные правила работать не будут.

Ещё на заметку, шлюз провайдера настраивается не только по команде set load-balancing, но и в маршрутах

Закладка Постоянная ссылка.

Отправить ответ

avatar
  Subscribe  
Notify of