Перейти к содержимому
Калькуляторы

IPoE балансировка и failover

Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE?

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE?

 

Спасибо.

 

По DHCP отдавать разные default gateway. Default gateway в VRRP.

 

 

.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE?

 

Спасибо.

А какая у вас реализация?

Может у вас Л3 свитчи напрямую к бордерам подключены, так тут, в сравнении с pppoe и vpn, резервировать просто нечего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, Л3 свитчей нет, всё по Л2. Вот хочу понять как люди решают эту задачу перед тем как делать какие-то движения. И вообще, решаема ли она нормально.

 

Раздавать разные гейты - это ответ только на балансинг. А если гейт, который выдан клиенту накрылся? А если его надо перегрузить, снять на профилактику, etc.? Клиенты курят бамбук?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Про VRRP почитайте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так кто будет гейтом-то?

 

Тут я вижу два подхода:

1. Гейтом является л3-свитч агрегации. Если этот свитч падает, то никакое резервирование не спасет - связи все равно нет. Чтоб падал л3 интерфейс, а свитч оставался жить - такого не припомню. Зарезервировать это можно только построив двойную звезду, что сильно раздувает бюджет.

2. К л2 агрегации (которая все равно может падать) подключаем внешние гейтвеи, используя протокол резервирования шлюза (в случае падения "мастера" резервный шлюз поднимает у себя его адрес). Такое есть и на на многих л3-свитчах, и в линухах. (тот самый vrrp)

 

Ну а гейты уже с остальной сетью связаны bgp\ospf, они обеспечат резервирование, главное чтоб путей было побольше.

Изменено пользователем Valaskor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мне кажется вариант с vrrp более вероятный, чем со свитчами - размер пока не позволяет разгуляться. Кто-то пользует VRRP, CARP для этих целей? Работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE?

 

Спасибо.

 

По DHCP отдавать разные default gateway. Default gateway в VRRP.

 

 

.

И смысл такого двойного резервирования? Отказоусточивости 2 default gw + каждый по vrrp столько же, сколько и 1 default gw по vrrp. А вот как будут работать различные cpe-шки с 2умя дефолтами это большой вопрос.

 

Ещё как вариант можно в один vlan засунуть 2 маршрутизатора, на соответсвующие L3-интерфейсы повесить разные сетки, туда же засунуть два независимых dhcp-сервера, которые будут предлагать каждый свой адрес(1ый dhcp-сервер из адресов 1го маршрутизатора, 2ой из второго), поставить маленький lease-time, тогда если один маршрутизатор навернётся, то по окончанию времени аренды, абонент получит другой адрес и будет работать. Этот вариант хуже тем, что в момент переключения сбросятся все сессии(закачки по http, аська и т.д.). В случае vrrp сброса сессий не будет, если раздавать реальники, в случае использования NAT всё сложнее.

 

Как у вас абоненты выходят во внешний мир? Через NAT или сразу реальники по dhcp раздаёте?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2s.lobanov: На сколько я понимаю как работает VRRP и CARP, то клиент получает как раз один адрес шлюзом, а сам адрес уже на уровне этой технологии резервируется. То есть для клиента всё прозрачно. При балансинге выдаются разные шлюзы ( те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP ). С виду всё нормально и я даже уверен, что на стенде оно заработает. Интересует, кто реально так резервирует и кто пользуется этими технологиями в продакшене. Если не пользуются, то чем пользуются и почему.

 

Метод с DHCP - это костыли, как и с DNS+VPN балансировкой. Оно наверное работать будет, но очень много вопросов. Начиная от "а если тот DHCP сервер, где клиент получил лиз ответить не успеет, а ответит второй, что будет?", заканчивая тем, сколько реально будет бегать запросов, пакетов по сети и какая будет чихарда с выдачей MAC-IP, если нужно связать жестко. Я однозначно против такого подхода.

 

Касательно того как сделано у нас - не имеет никакого значения, потому что если надо будет - переделаем как должно быть. Топик именно об этом.

 

2st_re: Есть ли какие-то подводные камни или всё как в описании?

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

подводные камни есть везде. но в целом все работает довольно давно и стабильно..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2s.lobanov: На сколько я понимаю как работает VRRP и CARP, то клиент получает как раз один адрес шлюзом, а сам адрес уже на уровне этой технологии резервируется. То есть для клиента всё прозрачно. При балансинге выдаются разные шлюзы ( те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP ). С виду всё нормально и я даже уверен, что на стенде оно заработает. Интересует, кто реально так резервирует и кто пользуется этими технологиями в продакшене. Если не пользуются, то чем пользуются и почему.

Всё правильно понимаете, только если вы будете отдавать "те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP", то тогда смысла от vrrp никакого нет, это будет просто 2 default gw и не понятно как себя будут вести себя различные клиенты(cpe-шки, виндоусы и т.д.). Скорее всего, половина ресурсов будет недоступна, когда один шлюз отвалится, по крайней мере, пока в arp-таблице клиента будет запись на отвалившийся gw.

 

Если хотите failover, то делайте vrrp и отдавайте виртуальный ip адрес в качестве шлюза по умолчанию. Да, при такой схеме не будет балансировки в пределах одного L2-сегмента, но вы можете просто чередовать в разных L2-сегментах кто будет главным маршрутизатором. Тогда в среднем балансировка будет.

 

На практике это всё работает, по крайней мере для серверов.

 

 

Касательно того как сделано у нас - не имеет никакого значения, потому что если надо будет - переделаем как должно быть. Топик именно об этом.

айпишников может не хватить, чтобы сделать всё красиво.

Изменено пользователем s.lobanov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2s.lobanov: Так вот не хочется 2 шлюза отдавать именно по причине непонятного поведения. И если на винде, линухе еще это всё вроятно нормально работает, то на SOHO роутерах возникнут недиагностируемые проблемы с вероятностью 100%. Поэтому только один шлюз, а дальше уже VRRP/CARP. Шлюзы емкие, поэтому отбалансить на уровне "столько-то клиентов туда-то" вполне допустимо. Прийдется оставлять запасы, конечно, но что делать - это издержка любых технологий. Динамически раскидывать клиентов в зависимости от загрузки можно через DHCP.

 

У нас NAT+реальные адреса кому надо, поэтому проблемы с адресами точно не будет - хватит всем.

 

2st_re: я так понимаю у вас фря?

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel да. carpы плавно едут с 6 до 8 версии. и нат серверов 2 друг друга дублируют через carp и pfnat/pfsync. в данный момент вытыкание питания из любого маршрутизатора (кроме бордеров, там у меня карпов нету) практически не заметно клиентам. Балансировка - первая сеть на первый маршрутизатор, вторяя на второй, третья на первый, четвертая на второй итд. нат соответственно тоже, мальчики направо, девочки налево. если второй пропадает, все едут на первый. задержка не больше секунды.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel да. carpы плавно едут с 6 до 8 версии. и нат серверов 2 друг друга дублируют через carp и pfnat/pfsync.

Если вам не тяжело, можете расписать, какое железо/процы стоят под НАТы, сколько трафа/ппс бегает, pfctl -s info в ЧНН.

п.с. как выдаете белые ипы ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.