Нет, на уровне приложений схема несколько отличается.
На серверах живут контейнеры OpenVZ с корнями на DRBD-шных разделах.
Это все (контейнеры и DRBD) контролирует heartbeat.
По дефолту контейнеры разбросаны между нодами.
Ежели одна нода вылетает - все переезжает на другую.
Проблема возникает, если вылетает не нода, а сетка между ними.
В результате возникает split brain, т.к. каждая нода считает, что
именно она является ведущей.
2010/10/4 Vladimir Litovka
привет
а сервера работают в режиме hot-standby или hot-hot? Для первого случая простое решение - включить каждый сервер в свой свич (то есть не делать перекрестных линков - это усложняет топологию) и failure detection делать на уровне приложения. Если обнаруживается failure, то уцелевший сервер посылает gratuitous ARP, вызывая немедленное обновление ARP/MAC таблиц на ethernet-сегменте и IP-шлюзе. То есть время восстановления в основном определяется временем failure detection между приложениями.
2010/10/3 Michael Bochkaryov
Мое почтение всем!
Не подскажет ли кто направление копания в такой задаче?
Имеется: 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/
-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua