Комментарии 25
Во FreeBSD настраивается полегче. Штука удобная, пробовал на древних серверах делать балансировку, для торрент трекера. Все в итоге уперлось в трекер, т.к. пришлось переписывать код для того, чтобы на нескольких серверах они синхронно работали.
CARP в BSD не только настраивается полегче, но ещё и Load balancing позволяет делать:
www.loadbalancing.org/#Free_BSD_stuff_CARP_PF_and_hoststated_
К сожалению, в данном случае мне требовалось компактное решение именно на Линукс.
Про трекер поподробнее рассказать не хотите? С интересом почитаем :)
www.loadbalancing.org/#Free_BSD_stuff_CARP_PF_and_hoststated_
К сожалению, в данном случае мне требовалось компактное решение именно на Линукс.
Про трекер поподробнее рассказать не хотите? С интересом почитаем :)
Кстати в RedHat Cluster suite высокая доступность IP-адреса из коробки работает. Полезно, когда надо не просто адрес перевозить, а ещё и сервис поднимать там, где адрес появился.
Пробовал дружить vrrpd и keepalived с cisco по VRRP. vrrpd работал не со всем корректно, после установки keepalived все проблемы решились.
Такую задачу можно решить ещё вот так:
На узлах (отказоустойчивость которых необходимо обеспечить) поднимаем демон маршрутизации(quagg'у например), который анонсирует сервисный ip (который у всех узлов одинаковый и весит алиасом на loopback'е) на некий маршрутизатор (железный, cisco/dlink/etc...), который и «разбрасывает» пакеты между возможными маршрутами (неразрывность tcp-сессий обеспечивается за счет использования алгоритма основанного на вычислении хеша от src_addr, src_port, dst_addr и dst_port — тем самым пакеты от одного клиента всегда пойдут по одному тоже маршруту). Если один из узлов сдох — то маршрутизатор просто перестает получать от него маршруты и маршрут на него через несколько секунд пропадает из таблицы маршрутизации — клиенты уходят на другие доступные узлы.
Такой вариант намного проще в реализации (особенно на стороне узлов), плюс позволяет не только добиться отказоустойчивости, но ещё и балансировать нагрузку между узлами. Минусом является пожалуй только то, что необходимо иметь железный маршрутизатор с поддержкой данной возможности.
На узлах (отказоустойчивость которых необходимо обеспечить) поднимаем демон маршрутизации(quagg'у например), который анонсирует сервисный ip (который у всех узлов одинаковый и весит алиасом на loopback'е) на некий маршрутизатор (железный, cisco/dlink/etc...), который и «разбрасывает» пакеты между возможными маршрутами (неразрывность tcp-сессий обеспечивается за счет использования алгоритма основанного на вычислении хеша от src_addr, src_port, dst_addr и dst_port — тем самым пакеты от одного клиента всегда пойдут по одному тоже маршруту). Если один из узлов сдох — то маршрутизатор просто перестает получать от него маршруты и маршрут на него через несколько секунд пропадает из таблицы маршрутизации — клиенты уходят на другие доступные узлы.
Такой вариант намного проще в реализации (особенно на стороне узлов), плюс позволяет не только добиться отказоустойчивости, но ещё и балансировать нагрузку между узлами. Минусом является пожалуй только то, что необходимо иметь железный маршрутизатор с поддержкой данной возможности.
Обеспечение отказоустойчивости протоколами маршрутизации — это уже более высокий уровень. Не layer3, а layer7 :) Применим широко, но не везде. Например, шлюз, который обслуживает конечных пользователей, никакими RIP и OSPF не зарезервируешь.
И если верхний провайдер выдал вам сеть /30 и одну BGP-сессию,
то единственный способ зарезервировать свой основной бордер — это отдавать резервному его IP-адрес.
И если верхний провайдер выдал вам сеть /30 и одну BGP-сессию,
то единственный способ зарезервировать свой основной бордер — это отдавать резервному его IP-адрес.
ну а не проще поднять vrrp, умер шлюз, автоматом virt ip поднялся на другом? Уж проще некуда.
Посмотрите в сторону Pacemaker.
Судя по их сайте, это решение на основе Hearthbeat.
Возможно, неплохая весчь, но для относительно несложной задачи «отказоустойчивый роутер» imho несколько тяжеловата.
Возможно, неплохая весчь, но для относительно несложной задачи «отказоустойчивый роутер» imho несколько тяжеловата.
Унификация решениё для построения HA это правильный выбор. И с помощью pacemaker это делать довольно просто. И я не вижу смысла использовать утилиты, у которых последние релизы были год назад.
Это всё конечно но же имхо.
Это всё конечно но же имхо.
Ну он не то, что бы основан, он понимает скрипты.
В вашем варианте можно использовать просто vrrpd, хотелось бы понять почему ucarp?
В общем статья как по мне более чем странно, перечислены методы и не сказанно используем их или нет, если нет то почему нет, почему выбрали вот это. Как это работает в реали, все скатилось к банальному, сделай так, будет вот так.
В вашем варианте можно использовать просто vrrpd, хотелось бы понять почему ucarp?
В общем статья как по мне более чем странно, перечислены методы и не сказанно используем их или нет, если нет то почему нет, почему выбрали вот это. Как это работает в реали, все скатилось к банальному, сделай так, будет вот так.
Во-первых, vrrpd не понимает up/down-сценарии.
Во-вторых, лицензионно-патентные рогатки в протоколе.
В-третьих, у vrrpd в README.Debian прямо написано, что он заброшен и лучше пользоваться ucarp'ом.
Т.к. они оба одинаково компактны, я выбрал ucarp.
Целью заметки было именно описать практическое решение небольшой задачи.
Общая информация приведена только как отправная точка для самостоятельных поисков.
Как показывает опыт, имея то и другое, восполнить пробелы труда не представляет.
Но если у Вас появились конкретные вопросы, то я попробую на них ответить :)
Во-вторых, лицензионно-патентные рогатки в протоколе.
В-третьих, у vrrpd в README.Debian прямо написано, что он заброшен и лучше пользоваться ucarp'ом.
Т.к. они оба одинаково компактны, я выбрал ucarp.
Целью заметки было именно описать практическое решение небольшой задачи.
Общая информация приведена только как отправная точка для самостоятельных поисков.
Как показывает опыт, имея то и другое, восполнить пробелы труда не представляет.
Но если у Вас появились конкретные вопросы, то я попробую на них ответить :)
ну пслд обнавление было в конце 2011 года
sourceforge.net/projects/vrrpd/
ucarp www.ucarp.org/project/ucarp/download
released on Feb 1st, 2010.
так что непонятно где оно там устарело.
С патентами еть проблемы всегда :)
sourceforge.net/projects/vrrpd/
ucarp www.ucarp.org/project/ucarp/download
released on Feb 1st, 2010.
так что непонятно где оно там устарело.
С патентами еть проблемы всегда :)
Для замысловатых ситуаций иногда лучше скрипт с arping-ом внутри
Такое я тоже делал: sources.homelink.ru/fallback-gw/ :)
а чем вариант с conntrackd плох? keepalived обеспечивает ha-адрес, а conntrackd — синхронизацию conntrack между нодами.
Conntrackd ничем не плох, он просто не нужен на шлюзе без NAT, поэтому рассматривать его здесь я не стал.
Если для NAT-клиентов некритичен перерыв на 3-4 секунды в маловероятном случае переключения, то и на NAT-шлюзе без conntrackd imho можно обойтись.
Если для NAT-клиентов некритичен перерыв на 3-4 секунды в маловероятном случае переключения, то и на NAT-шлюзе без conntrackd imho можно обойтись.
conntrack — это не только nat. так что без conntrackd файловер автоматом грохнет все установленные соединения
(т.к. у standby-ноды не будет state table погибшей)
(т.к. у standby-ноды не будет state table погибшей)
Соединения важны для сервера. Маршрутизатору без NAT они в 99,9999% случаев безразличны.
Но для сервера соединение — это не столько флаги пакетов, сколько содержимое.
Если трафик не зеркалируется целиком на резервные серверы, то при аварии основного всё равно запрос придётся отправлять на резервный заново. Поэтому толку от conntrackd в случае с серверами тоже не видно.
Но для сервера соединение — это не столько флаги пакетов, сколько содержимое.
Если трафик не зеркалируется целиком на резервные серверы, то при аварии основного всё равно запрос придётся отправлять на резервный заново. Поэтому толку от conntrackd в случае с серверами тоже не видно.
Т.е. я правильно понимаю: в идеальном случае имеется 2 сервера. На одном из них постоянно поднято 2 интерфейса (один с source ip, другой с virtual ip), на втором поднят 1 интерфейс (source ip) и второй, с virtual ip, постоянно находится в standby?
Спасибо за статью. Очень полезная штука — настраивал под Ubuntu (http://sysadm.pp.ua/linux/carp-ubuntu.html) кластер из трех серверов — до сих пор на проде работает. Не подскажите, если ли возможность(технология) для geodistributed redundent IP, может сталкивались? Заранее спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отказоустойчивый IP-адрес с помощью ucarp