Уберкостыль(не проверял, да и идея идиотская - первое что в голову пришло) - отправлять пакеты с другого source-адреса, который вещать по протоколу динамической маршрутизации(OSPF,RIP,BGP,whatever). То есть использовать связку между серверами только как failover, когда всё навернется.

Ты знаешь, я уже тут всяких костылей напридумывал похуже твоего :))

Но самым адекватным оказалось вот что:

1. В линухах относительно недавно появилась штука под названием HSR (http://en.wikipedia.org/wiki/High-availability_Seamless_Redundancy), которая позволяет организовывать через Ethernet топологию кольцо без использования Spanning Tree, оно отправляет пакет в оба интерфейса сразу и когда пакет возвращается к нему по кольцу, то оно его отбрасывает (там что-то вроде TTL в IP + порядковые номера пакетов) + ретранслирует чужие пакеты дальше по кольцу.

2. Объединю все три сервера в кольцо с помощью этого HSR (тут можно было сделать и bridge со Spanning Tree, но там время схождения большое при разрыве кольца)

3. Профит! ))

Тестово погонял HSR, вроде работает. Настраивается достаточно тупо:

ip link add name hsr0 type hsr slave1 eth0 slave2 eth1

Это конечно не вписывается в изначальную задачу вправления мозгов Corosync, но тоже решение...

Как оказалось, HSR сыроват. При удалении девайса вываливает Kernel NULL Pointer dereference (в GIT ядра уже поправили, но всё же). Так что придётся юзать обычный бридж...

Как вариант - попробуй посмотреть в сторону mstpd. ЕМНИП у него время сходимость поменьше чем у встроенного в bridge-модуль ядра обычного stp

Да, на встроенном меньше 5 секунд не сходится. Спасибо, как раз искал какой-нибудь аналог RSTP. Но оно, смотрю, с 13 года не развивается.

Но оно, смотрю, с 13 года не развивается.

Если протокол реализован в полной мере - чему там развиваться? :-)

Да в том-то и дело что

At the moment the latest version 0.03 is reported to be compliant with IXIA ANVL RSTP test suite, with the notable exception of looped-back BPDUs (see discussion on the matter on the Implementation Features wiki page).

Important note! MSTP part of the code (as opposed to STP/RSTP part) is mainly untested, so I believe it will behave unexpectedly in many situations. Don't use it in production!

Т.е. MSTP там как раз практически не рабочий. Можно, конечно, RSTP заюзать благо мне «Rapid» как раз и нужно, но боюс я такую поделку версии 0.03 в продакшен пускать :) Буду искать обходные пути. Наверное просто бриджевое кольцо + связь через свичи будет достаточно мне.

Кому интересно:

В итоге, перепробовав целую кучу L2 способов реализовать кольцо, забил на него (и действительно, чего я к нему привязался?) и перешёл на L3.

Повесил на lo на каждый сервак адреса дополнительные и вещаю их через Кваггу по OSPF на соседей с настройкой

ip ospf dead-interval minimal hello-multiplier 10

Короче, при такой настройке роутинг сходится за 0.3-0.4 секунды, и есть ещё место для тюнинга. В общем, всем рекомендую.

UPDATE: если выставить «timers throttle spf 10 10 100» то сходится даже за 0.1с

Добрый вечер.

Прочитал Твою статью на Хабре, но поскольку там правила суровые а кама моя равно ровно 0, то задам вопрос здесь с вашего позволения. Речь идет о статье Бюджетное SAN-хранилище на LSI Syncro. Прочитал обе части и у меня возникли вопросы. Каким образом vSpere управляет хранилищем? Возможно ли построить подобную систему без участия Esxi и vSpere? Так же у меня нет такой полки как у Вас, есть три штуки IBM DS4800 подключенных по тому-же FC.

Каким образом vSpere управляет хранилищем?

Никаким образом он им не управляет. Он просто является клиентом (инициатором) этого хранилища.

Возможно ли построить подобную систему без участия Esxi и vSpere?

Конечно, с точки зрения хранилища там никакой завязки на vSphere нету. Используются стандартные протоколы и компоненты (FC, ALUA) - если вместо ESXi использовать линукс, то всё будет примерно так же, DM-Multipath поддерживает ALUA.

Так же у меня нет такой полки как у Вас, есть три штуки IBM DS4800 подключенных по тому-же FC.

Ну, тут уже нужно другие топологии думать.

Может какие-то сервера, которые будут по FC подключаться к этим полкам и зеркалировать данные на две из них (через тот же MD-RAID в ядре, например). И потом этот массив отдавать обратно в FC (с правильным зонированием, конечно). При отказе одного из серверов второй может подхватывать этот массив и обслуживать запросы.

Это так, первое что в голову пришло.

Подскажите пожалуйста, какую функцию в вашей системе выполняют fc соединения серверов со fc-коммутаторами и нужно-ли соединять контроллеры Syncro между собой или достаточно scst для синхронизации кэша? Я так же до конца не понял где у вас живет ESXi, в первой статье упоминается debian в качестве о.с. кластера.

и собственно у меня сейчас нет задачи сделать супер отказоустойчивость, главное сделать active/active запись данных на lun в одной полке, для начала. Т.е. я хочу из двух лунов сделать зеркало с вирт.диском подключенным к Syncro, но полки у меня есть только fc, денег на sas мне сейчас никто не выделит. Поэтому мне не совсем понятен вопрос получится-ли связать два Syncro и заставить их читать\записывать через qlogic. А поскольку стоят они все-же не мало, меня терзают сомнения стоит ли с ними связываться или попробовать настроить подобную систему на Ceph.

У тебя в голове какая-то каша, не обессудь.

Сервера выполняют роль контроллеров хранилища, не более того, почитай внимательно статью.

1. Syncro работают только через SAS сеть и только с SAS дисками. С полками по FC они никак работать не будут в принципе.

главное сделать active/active запись данных на lun в одной полке

Что-то не совсем понял. Что тебе мешает писать на один и тот же лун в полке с разных мест? Нужна только кластерная ФС или что-то подобное.

Да действительно некоторая каша есть. Просто непонятна роль FC соединения серверов с коммутаторами крест накрест в вашей схеме?

Сервера-контроллеры хранилища подключаются к коммутаторам по отказоустойчивой схеме, там же это описано. При отказе любого HBA и любого FC-коммутатора вместе в любой комбинации связь сохранится.

К этим же коммутаторам потом подключаются сервера ESXi примерно таким же макаром (только FC портов у них по 2, а не по 4) и начинают видеть LUNы экспортированные с серверов-хранилищ.

Спасибо за комментарии, схема проясняется. Думаю пойти по простой схеме, два сервера с Syncro и схд sas с таким же бэкплейном, будет не супер устойчивая система, но хотя бы active/active, т.к. мне более важно добиться чтобы чтение данных с хранилища не превышало 100мс при отказе одного из серверов с Syncro. Думаю, исходя из вашей схемы сделать два луна под зеркало и с него читать данные. Как думаете получится у меня добиться такой задержки по чтению? или лучше сделать три луна?

мне более важно добиться чтобы чтение данных с хранилища не превышало 100мс при отказе

Всмысле чтобы задержка на переключение на резервный сервер проходило за 100мс? Не знаю, Syncro переключается в активный режим достаточно быстро, я не мерял за сколько. Основную задержку вносит инициатор (ESXi) который соображает какое-то время что путь до основного сервера сдох и как же жить дальше.

Большое спасибо за комментарии, успехов во всех делах. Ушел настраивать, посмотрим что получится.