Нет, на уровне приложений схема несколько отличается.

На серверах живут контейнеры OpenVZ с корнями на DRBD-шных разделах.
Это все (контейнеры и DRBD) контролирует heartbeat.

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

Проблема возникает, если вылетает не нода, а сетка между ними.
В результате возникает split brain, т.к. каждая нода считает, что
именно она является ведущей.



2010/10/4 Vladimir Litovka <doka.ua@gmail.com>
привет

а сервера работают в режиме 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/



--
Regards,
Michael Bochkaryov
Net.Style - VoIP and VAS development
www.netstyle.com.ua