Dark_Angel Опубликовано 9 марта, 2011 · Жалоба Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Voicemaster Опубликовано 9 марта, 2011 · Жалоба Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE? Спасибо. По DHCP отдавать разные default gateway. Default gateway в VRRP. . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 9 марта, 2011 · Жалоба Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE? Спасибо. А какая у вас реализация?Может у вас Л3 свитчи напрямую к бордерам подключены, так тут, в сравнении с pppoe и vpn, резервировать просто нечего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 марта, 2011 · Жалоба Нет, Л3 свитчей нет, всё по Л2. Вот хочу понять как люди решают эту задачу перед тем как делать какие-то движения. И вообще, решаема ли она нормально. Раздавать разные гейты - это ответ только на балансинг. А если гейт, который выдан клиенту накрылся? А если его надо перегрузить, снять на профилактику, etc.? Клиенты курят бамбук? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Voicemaster Опубликовано 9 марта, 2011 · Жалоба Про VRRP почитайте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 9 марта, 2011 (изменено) · Жалоба Так кто будет гейтом-то? Тут я вижу два подхода: 1. Гейтом является л3-свитч агрегации. Если этот свитч падает, то никакое резервирование не спасет - связи все равно нет. Чтоб падал л3 интерфейс, а свитч оставался жить - такого не припомню. Зарезервировать это можно только построив двойную звезду, что сильно раздувает бюджет. 2. К л2 агрегации (которая все равно может падать) подключаем внешние гейтвеи, используя протокол резервирования шлюза (в случае падения "мастера" резервный шлюз поднимает у себя его адрес). Такое есть и на на многих л3-свитчах, и в линухах. (тот самый vrrp) Ну а гейты уже с остальной сетью связаны bgp\ospf, они обеспечат резервирование, главное чтоб путей было побольше. Изменено 9 марта, 2011 пользователем Valaskor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 марта, 2011 · Жалоба Мне кажется вариант с vrrp более вероятный, чем со свитчами - размер пока не позволяет разгуляться. Кто-то пользует VRRP, CARP для этих целей? Работает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 марта, 2011 · Жалоба Господа, кто как решает задачу балансировки и фейловера для 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 раздаёте? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 9 марта, 2011 · Жалоба CARP для этих целей? Работает? работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 марта, 2011 (изменено) · Жалоба 2s.lobanov: На сколько я понимаю как работает VRRP и CARP, то клиент получает как раз один адрес шлюзом, а сам адрес уже на уровне этой технологии резервируется. То есть для клиента всё прозрачно. При балансинге выдаются разные шлюзы ( те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP ). С виду всё нормально и я даже уверен, что на стенде оно заработает. Интересует, кто реально так резервирует и кто пользуется этими технологиями в продакшене. Если не пользуются, то чем пользуются и почему. Метод с DHCP - это костыли, как и с DNS+VPN балансировкой. Оно наверное работать будет, но очень много вопросов. Начиная от "а если тот DHCP сервер, где клиент получил лиз ответить не успеет, а ответит второй, что будет?", заканчивая тем, сколько реально будет бегать запросов, пакетов по сети и какая будет чихарда с выдачей MAC-IP, если нужно связать жестко. Я однозначно против такого подхода. Касательно того как сделано у нас - не имеет никакого значения, потому что если надо будет - переделаем как должно быть. Топик именно об этом. 2st_re: Есть ли какие-то подводные камни или всё как в описании? Изменено 9 марта, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 9 марта, 2011 · Жалоба подводные камни есть везде. но в целом все работает довольно давно и стабильно.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 марта, 2011 (изменено) · Жалоба 2s.lobanov: На сколько я понимаю как работает VRRP и CARP, то клиент получает как раз один адрес шлюзом, а сам адрес уже на уровне этой технологии резервируется. То есть для клиента всё прозрачно. При балансинге выдаются разные шлюзы ( те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP ). С виду всё нормально и я даже уверен, что на стенде оно заработает. Интересует, кто реально так резервирует и кто пользуется этими технологиями в продакшене. Если не пользуются, то чем пользуются и почему. Всё правильно понимаете, только если вы будете отдавать "те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP", то тогда смысла от vrrp никакого нет, это будет просто 2 default gw и не понятно как себя будут вести себя различные клиенты(cpe-шки, виндоусы и т.д.). Скорее всего, половина ресурсов будет недоступна, когда один шлюз отвалится, по крайней мере, пока в arp-таблице клиента будет запись на отвалившийся gw. Если хотите failover, то делайте vrrp и отдавайте виртуальный ip адрес в качестве шлюза по умолчанию. Да, при такой схеме не будет балансировки в пределах одного L2-сегмента, но вы можете просто чередовать в разных L2-сегментах кто будет главным маршрутизатором. Тогда в среднем балансировка будет. На практике это всё работает, по крайней мере для серверов. Касательно того как сделано у нас - не имеет никакого значения, потому что если надо будет - переделаем как должно быть. Топик именно об этом. айпишников может не хватить, чтобы сделать всё красиво. Изменено 9 марта, 2011 пользователем s.lobanov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 марта, 2011 (изменено) · Жалоба 2s.lobanov: Так вот не хочется 2 шлюза отдавать именно по причине непонятного поведения. И если на винде, линухе еще это всё вроятно нормально работает, то на SOHO роутерах возникнут недиагностируемые проблемы с вероятностью 100%. Поэтому только один шлюз, а дальше уже VRRP/CARP. Шлюзы емкие, поэтому отбалансить на уровне "столько-то клиентов туда-то" вполне допустимо. Прийдется оставлять запасы, конечно, но что делать - это издержка любых технологий. Динамически раскидывать клиентов в зависимости от загрузки можно через DHCP. У нас NAT+реальные адреса кому надо, поэтому проблемы с адресами точно не будет - хватит всем. 2st_re: я так понимаю у вас фря? Изменено 9 марта, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 9 марта, 2011 · Жалоба Dark_Angel да. carpы плавно едут с 6 до 8 версии. и нат серверов 2 друг друга дублируют через carp и pfnat/pfsync. в данный момент вытыкание питания из любого маршрутизатора (кроме бордеров, там у меня карпов нету) практически не заметно клиентам. Балансировка - первая сеть на первый маршрутизатор, вторяя на второй, третья на первый, четвертая на второй итд. нат соответственно тоже, мальчики направо, девочки налево. если второй пропадает, все едут на первый. задержка не больше секунды. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 9 марта, 2011 · Жалоба Dark_Angel да. carpы плавно едут с 6 до 8 версии. и нат серверов 2 друг друга дублируют через carp и pfnat/pfsync. Если вам не тяжело, можете расписать, какое железо/процы стоят под НАТы, сколько трафа/ппс бегает, pfctl -s info в ЧНН. п.с. как выдаете белые ипы ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...