Jump to content
Калькуляторы

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

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

 

Спасибо.

Share this post


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

 

Спасибо.

 

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

 

 

.

Share this post


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

 

Спасибо.

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

 

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

Edited by Valaskor

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Господа, кто как решает задачу балансировки и фейловера для 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 раздаёте?

Share this post


Link to post
Share on other sites
CARP для этих целей? Работает?

работает.

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

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

Share this post


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

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

 

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

 

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

 

 

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

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

Edited by s.lobanov

Share this post


Link to post
Share on other sites

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

 

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

 

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

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

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

 

 

Share this post


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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this