Нет, на уровне приложений схема несколько отличается.
На серверах живут контейнеры OpenVZ с корнями на DRBD-шных разделах.
Это все (контейнеры и DRBD) контролирует heartbeat.
По дефолту контейнеры разбросаны между нодами.
Ежели одна нода вылетает - все переезжает на другую.
Проблема возникает, если вылетает не нода, а сетка между ними.
В результате возникает split brain, т.к. каждая нода считает, что
именно она является ведущей.
привет
а сервера работают в режиме hot-standby или hot-hot? Для первого случая простое решение - включить каждый сервер в свой свич (то есть не делать перекрестных линков - это усложняет топологию) и failure detection делать на уровне приложения. Если обнаруживается failure, то уцелевший сервер посылает gratuitous ARP, вызывая немедленное обновление ARP/MAC таблиц на ethernet-сегменте и IP-шлюзе. То есть время восстановления в основном определяется временем failure detection между приложениями.
2010/10/3 Michael Bochkaryov <misha@rattler.kiev.ua>Мое почтение всем!
Не подскажет ли кто направление копания в такой задаче?
Имеется:
1) 2 сервера на linux c 2 x ethernet
2) 2 управляемых свича с поддержкой link aggregation 802.3ad
Нужно организовать "шибко надежный" ethernet для парочки серверов.
Чтобы как при вылете порта, так и при вылете одного из свичей сетка
продолжала работать, пускай и с меньшей скоростью.
Можно ли link aggregation организовать на портах в разных свичах?
Или нужно на уровне IP это разруливать (чего не хочется)?
Заранее спасибо :)
--
Regards,
Michael Bochkaryov
Net.Style - VoIP and VAS development
www.netstyle.com.ua
--
/doka
~~~~~~~~
http://doka-ua.blogspot.com/
http://omar-ha-em.blogspot.com/