Организация двухузлового сетевого кластера linux-ha для балансировки bgp маршрутизации ISP каналов.

зачем тебе тут кластер, 2 маршрутизатора, по 2 сессии с каждого на провов ну и ibgp между ними, вот только с балансировкой проблемы будут, квага штатно не умеет.

Спасибо, но это не вариант. Интересуют способы именно с использованием конкретных инструментов перечисленных выше в вопросе.

это не возможно без обрыва бгп сессий, так без вариантов.

Интересует вариант, если один провайдер падает мы работаем через другого без потери времени, в обычном режиме трафик распределяется через 2-х провайдеров. В случае падения одного из наших bgp узлов в кластере, второй сможет выполнять балансировку(если это вообще возможно!) самостоятельно и переключить весь трафик на одного из провайдеров в случае падения второго.

И если невозможно, то как лучше тогда сделать?

И какое дополнительное оборудование тогда потребуется, не считая конечно самих серверов с bgp-quagga? Коммутаторы?

в самом первом сообщении уже написал как, едиственное будут проблемы с балансировкой, придется квагу патчить ибо из коробки она пока не умеет втыкать несколько маршрутов для префикса. насчет без потери времени, всеравно частичная потеря связности будет в любом случае, бгп апдейты не молниеносно распространяются и ничего с этим не сделаеш.

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

теоретически, у тебя должна быть связность с обоими провами с обоих маршрутизаторов, тоесть всего 4 бгп сессии, с первого роутера к обоим и со второго та же, какие там тебе комутаторы и че и как втыкать это уж тебе виднее, я твоей инфраструктуры низнаю и чем тебе аплинки отдают тоже.

имхо - обычьно не делают так само наличие 2 аплинков - и двух серверов каждый на отдельного - достигается достаточно приличная надежность сервера дохнут не настолько часто

другое дело как у тебя дальше идет в сеть - если дальше твоя сеть просто раздается с сетевой то - нужно держать по 2 гатевея в настройках клиентов если ты хочеш заюзать HA для имено прозрачной смены гатевея у юзеров - то тогда может быть и еще неизвестно как себя оно поведет при реальной железной проблеме - подмена маков - когда в сети например еще работает другой такой комп

ну и сеха по 2 бгп сессии на каждого из 2 аплинков + 1 препенд на разные каналы у разных роутеров но захотят ли сами провайдеры твои - делать такое

А если все организовать на одном сервере, а производить полную репликацию маршрутной и иной информации на второй узел в виде кластера, но без резервирования сетевых интерфейсов. А когда происходит проблема на рабочем узле-то например скриптами или иным методом поднимаются интерфейсы на втором узле и он входит в строй так сказать?

на одном сервере - точно ненадо - тогда при его падении bgp сесии прервуться и некоторый промежуток до твоей сети не будет путей в инете

ябы сделал так - по 2 вилана на 2 провайдера в каждом вилане гатевей провайдера + 2 твоих сервера два сервера настроены сессии по одному на провайдера + ibgp между ними

в результате - у тебя скорее всего будет роутинги в ядрах - на обеих серверах указывать на сами ip гатевеев провайдера и исходящий траффик сможет идти из твоей сети - через какойто их твоих серверов - напрямую в железку провайдера

ну и потом - настройка разными префами + хопами + другая дребедень - нагрузки на иходящий и входящий траффик этих 2 провов

тем самым - оба сервера одновременно работают - в случае неполадки на одном - траффик идет через второй на твою сеть

но повторюсь - главный вопрос - как раздать и принимать траффик из твоей сети что за серверами - одно дело если там ospf сеть со своими маршрутизаторами - а другое дело если там просто сеть на сетевой сервера

и в погоне за надежностью - не забывай что не только сервера могут не работать - может не работать свить через который идет трафик на провайдеров - иль питание свитча + ....

да обычно вменяемые провы без проблем дают вторую сессию, на межоператорских линках это вообще распространенная практика на которой даже настаивают.

ну уж - меж операторские - это несколько не тот уровень

у меня на одном сервере - провайдер - у него железка крайне древняя и тормазная - она умудряеться фулл виев отдавать минут 5 вот такой могет и не соглавиться на эту железку повесить еще одну сессию

на других - нормальных фулл виев прилетает за секунд 5

ну разные ситуации бывают, но в основном проблем не возникает с этим.

HA...(по 2-на операторов, по одной на HA, по одной на нашу AS

уже смешно. в вашу AS и для HA должно быть min по 2 линка чтоб быть HA. и да, зачем для HA heartbeat отдлеьный от внутреннего интерфейс?8-[ ]

ещё момент непонятный - зачем вы это кластиром обзываете? он вам не нужен для означенных задач.

Вы не могли бы точнее сформулировать и нормальным языком выразить то, что вы пытались сказать? А то получилась каша-малА... С уважением,

1) кластер для означенной задачи - не нужен
2) для надёжной работы общепринято иметь как минимум 2 независимых пути до разных узлов друг к другу, для начала - по 2 независимых сетевых на каждом узле.
3) heartbeat вполне может бегать по общему с public интерфейсу, выделять отдельно его не обязательно, но VLAN - приветствуется.

иначе см. п.2

так понятнее?

А как без кластера обеспечить доступность в случае падения одного из узлов? Как обеспечить баллансировку нагрузки между двумя различными сессиями bgp от двух различных ISP? Это ведь по-сути и есть кластер, не?

да никак. или по твоему другйо узел кластера волшебным образом всё подхватит от другого вообще без перерыва? ;) не туда смотришьб думай лучше в сторону iBGP и т.п.

Спасибо. Совсем без перерыва я понимаю что трудно будет реализовать. Перерыв конечно в данном случае будет. Главное чтобы второй узел перехватывал работу упавшего сервера. А вот балансировку хотелось бы попробовать реализовать. Насчет iBGP - буду копать в эту сторону.