Решение лучшее из худших. Отказаться внедрять IP-телевидение нельзя. Ждать, пока закончится модернизация транспортной сети, тоже нельзя. Расчитывать при её нынешнем состоянии только на мультикаст тоже нельзя. Если хотя бы сто клиентов смотрят телевидение там, куда мультикаст не прокинуть — в этих случаях нужно использовать udpxy и обходить его ограничения.
Без up/down-сценариев обойтись почти нереально.
Например, если провайдер выдал сеть /30 и после получения IP надо добавить статический маршрут по умолчанию.
Или если он выдал одну bgp-сессию, то надо скомандовать Квагге "(no) neighbor 1.2.3.1 shutdown".
Во-первых, vrrpd не понимает up/down-сценарии.
Во-вторых, лицензионно-патентные рогатки в протоколе.
В-третьих, у vrrpd в README.Debian прямо написано, что он заброшен и лучше пользоваться ucarp'ом.
Т.к. они оба одинаково компактны, я выбрал ucarp.
Целью заметки было именно описать практическое решение небольшой задачи.
Общая информация приведена только как отправная точка для самостоятельных поисков.
Как показывает опыт, имея то и другое, восполнить пробелы труда не представляет.
Но если у Вас появились конкретные вопросы, то я попробую на них ответить :)
Redhat как платформа imho слишком тяжеловесен. Приходится одновременно иметь дело с Centos и Debian — по субъективным ощущениям Дебиан более проворен, менее запутан и тщательнее допилен.
Возможно, это объясняется тем, что Дебиан смотрит на завтрашний день, а Редхат нацелен на послезавтрашний :)
Соединения важны для сервера. Маршрутизатору без NAT они в 99,9999% случаев безразличны.
Но для сервера соединение — это не столько флаги пакетов, сколько содержимое.
Если трафик не зеркалируется целиком на резервные серверы, то при аварии основного всё равно запрос придётся отправлять на резервный заново. Поэтому толку от conntrackd в случае с серверами тоже не видно.
Обеспечение отказоустойчивости протоколами маршрутизации — это уже более высокий уровень. Не layer3, а layer7 :) Применим широко, но не везде. Например, шлюз, который обслуживает конечных пользователей, никакими RIP и OSPF не зарезервируешь.
И если верхний провайдер выдал вам сеть /30 и одну BGP-сессию,
то единственный способ зарезервировать свой основной бордер — это отдавать резервному его IP-адрес.
Судя по их сайте, это решение на основе Hearthbeat.
Возможно, неплохая весчь, но для относительно несложной задачи «отказоустойчивый роутер» imho несколько тяжеловата.
> пользователем Wilmer с форума Cacti и мной
В чём заключались поправки?
Шаблон Эрика импортируется с ошибками:
forums.cacti.net/viewtopic.php?f=12&t=19250&p=226881#p226881
Например, если провайдер выдал сеть /30 и после получения IP надо добавить статический маршрут по умолчанию.
Или если он выдал одну bgp-сессию, то надо скомандовать Квагге "(no) neighbor 1.2.3.1 shutdown".
Во-вторых, лицензионно-патентные рогатки в протоколе.
В-третьих, у vrrpd в README.Debian прямо написано, что он заброшен и лучше пользоваться ucarp'ом.
Т.к. они оба одинаково компактны, я выбрал ucarp.
Целью заметки было именно описать практическое решение небольшой задачи.
Общая информация приведена только как отправная точка для самостоятельных поисков.
Как показывает опыт, имея то и другое, восполнить пробелы труда не представляет.
Но если у Вас появились конкретные вопросы, то я попробую на них ответить :)
Возможно, это объясняется тем, что Дебиан смотрит на завтрашний день, а Редхат нацелен на послезавтрашний :)
Но для сервера соединение — это не столько флаги пакетов, сколько содержимое.
Если трафик не зеркалируется целиком на резервные серверы, то при аварии основного всё равно запрос придётся отправлять на резервный заново. Поэтому толку от conntrackd в случае с серверами тоже не видно.
Если для NAT-клиентов некритичен перерыв на 3-4 секунды в маловероятном случае переключения, то и на NAT-шлюзе без conntrackd imho можно обойтись.
www.loadbalancing.org/#Free_BSD_stuff_CARP_PF_and_hoststated_
К сожалению, в данном случае мне требовалось компактное решение именно на Линукс.
Про трекер поподробнее рассказать не хотите? С интересом почитаем :)
статьюхабратопик! :)И если верхний провайдер выдал вам сеть /30 и одну BGP-сессию,
то единственный способ зарезервировать свой основной бордер — это отдавать резервному его IP-адрес.
Возможно, неплохая весчь, но для относительно несложной задачи «отказоустойчивый роутер» imho несколько тяжеловата.
Т.е. данные на центральном сервере помогают увидеть проблему, а если нужно глубокое расследование — идём на конкретный сервер.