heartbeat + drbd

не понятна архетиктура кластера вашего, вы диски синкать по usb собрались?

на второй вопрос - не будет.

вы диски синкать по usb собрались?

думаю речь идет о heartbeat, он прямо об этом и написал

Можно для heartbeat вместо COM использовать USB?

Некоторое время назад задавался этим вопросом. Общая рекомендация com порты использовать. Про USB мне не известно.

1. Хартбит уже протух, юзай Pacemaker + Corosync. Ресурсы от хартбита оно умеет использовать.

2. В Corosync (это бэкенд Pacemaker для общения друг с другом) есть механизм Redundant Ring. Я у себя сделал связь через внешнюю сеть и через прямой кроссовер между серверами, по которому гуляет DRBD. Обе сети плюс к этому, конечно же, через bonding. Так что заморачиваться через ком-порты не вижу смысла.

На крайняк вставь две 100Мбит карты, повесь на них какие-нибудь адреса и пусти хартбиты по ним.

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

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

Будут вопросы - пиши.

ЗЫ: Кабели USB AM AM это, обычно, просто сетевые адаптеры cdc ethernet и в системе выглядят соответственно.

Две ноды amd_64 с 3х1Gb в каждой, коммутатор Eltex:

1-2 порты в LAG 802.3ad - 1 нода 2x1Gb

2-4 порты в LAG 802.3ad - 2 нода 2x1Gb

Между нодами прямой кабель Ethernet 1Gb

Могу заюзать ещё свободные порты USB-3 кабелем AM-AM

Пока на первой работают все сервисы, без кластера, вторая чистая.

Планирую на второй поднять кластер перелить туда сервисы, потом подключить первую.

Спасибо! Попробую Pacemaker + Corosync.

Ядром Linux bonding 802.3ad laer2+3 пока только поддерживается. По этому между двумя IP больше 1Gb не будет. Исходя из этого и сделал конфигурацию кластера описаную выше.

Но могу заменить на:

1-3 порты в LAG 802.3ad - 1 нода 3x1Gb

4-6 порты в LAG 802.3ad - 2 нода 3x1Gb

По верх bond0 сделать выделеный VLAN между нодами для кластерной фигни. Дать ему высший приоритет и по 3 IP на этот интерфейс в каждой ноде. Тек по идее должно быть 3Gb приёмо-передачи между нодами но разделяемой, с учётом приоритетов, с другими внешними Vlan-ами.

Ядро линукс легко умеет layer3+4, почитай bonding.txt в доках ядра. Так что можно активировать его.

Есть правда нюанс, что layer3+4 не совсем совместим со стандартном 802.3ad, но это не мешает. А вот свичи layer3+4 обычно не умеют. Так что балансировка будет несколько однобокой.

Если есть возможность добавить еще один интерфейс в сервера, лучше это сделать. И соеденить 2 интерфейсами со свичем и 2 с соседом. И лучше использовать два свитча, а то в случае его смерти весь твой кластер будет бесполезен :)

Я у себя сделал связь через внешнюю сеть и через прямой кроссовер между серверами, по которому гуляет DRBD. Обе сети плюс к этому, конечно же, через bonding. Так что заморачиваться через ком-порты не вижу смысла.

Для чего используется подобная схема? Под сторадж или виртуализацию?

iscsi хранилище отказоустойчивое. Для виртуализации :)

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

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

Именно bonding.txt меня и отпугнул от layer3+4.

Коммутатор MES2124 (он вообще, то поддерживает src-dest-mac-ip-port) к нему воткнуты сетевухи 82574L, а между нодами стоят 82579V, на bond с 82574L моного Vlan-ов. Есть у меня надежда, интел и bonding.txt пишут, что связка и сами Vlan-ы работают на аппаратном уровне. Проц не грузят.

Eltex включает тип балансировки 802.3ad глобально для всего коммутатора, а там ещё центось старая, которую не я админю, еле связку layer2+3 смогла сделать.

Да если бы было два коммутатора в стеке надёжность повысилась, но конторка такая что пока 3 порта есть свободны они другой коммутатор не купят. Это корень сети и если он сдохнет то и сеть будет бесполезна.

Винты там очень дохлые WD Black 500Gb и WD Blue 500Gb на второй ноде. Так что профита от ещё одной сетевухи учитывая DRBD почти нет. (скорость 140 и 120 Mb/s)

Вот USB-3.0 Очень хочется заюзать, всё таки скорость 5 Гбит/с.. Сеть поверх USB нормально работать будет, без задержек? Там не тормозной драйвер? Покупать 2 кабеля USB-3.0 AM-AM и сделать между нодами бондинг с 2xUSB-3.0 на 10Gb/s? :)

И где там в кластере, кроме единого коммутатора, узкое место?

Отдельно бекаплю postgresql, mongo, все настройки и свои скрипты. Отдельно юзерам желаю на своих компах держать бекапы своих трудов на сетевых шарах.

Я не видел проводов ам-ам усб3, может конечно такие уже и делают, не знаю. Даже просто гигабитных сетевух на усб3 вроде в продаже особо нет.

И где там в кластере, кроме единого коммутатора, узкое место?

накроется твоя файловая система и что будешь делать? или серверная погорит )

Отдельно бекаплю postgresql, mongo, все настройки и свои скрипты.

и не стоит прекращать, спокойней спится.

Сам пока в руках не держал, в магазинах не видил, но в инете есть: http://ru.made-in-china.com/co_diseeno/product_USB-Cable-3-0-AM-AM_hrhnsyusg.... синие такие :)

Наверно между нодами бондинг с двух усб3 сделаю на 10Гб!

накроется твоя файловая система и что будешь делать?

Это не страшно, есть anyfs-tools, testdisk, если фс не шифрована была, то данные достать всегда можно.

или серверная погорит )

или ядерная бомба в серверную попадёт! Тогда ноды кластера в разных городах в бомбоубежищах держать надо )

вы диски синкать по usb собрались?

Пока прямым соединением гигабитными сетевухами, но как достану 2 кабеля буду синкать по усб, есть возражения?

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

А то что тебе нужно - должно быть с блоком посередине, типа такого: http://www.hongtongcable.com/UploadFiles/image/t201011202834.jpg

Там у тебя нету чтоли пустых слотов чтобы сетевухи вставить?

Есть еще дофига слотов, сетевуха ~1000р, могут не дать денег.

Потом, как всё заработает, попрошу нормальные SSD диски и за одно сетевухи дополнительно. Или буду искать нормальный кабель USB-3.0, так дешевле и скорость больше.

1000 рублей не дадут? Издеваешься? УСБ кабели не найдёшь, в лучшем случае - USB2.0, а там всего 480 сферических в вакууме мегабит. Да и стоит такой кабель не дешевле тысячи.

Так что не страдай фигней, а вставь пару сетевух.

Решил вместо бекапа сделать нормальную гарячую замену

ВМЕСТО бекапа кластеры не делают. Бекап нужен всегда.

Да, кбелей USB-3 пока увы нет, http://forums.debian.net/viewtopic.php?f=20&t=103273 не один я ищу..

Ну вставлю ещё одну сетевуху в бондинг.

После празников покопаюсь с Pacemaker + Corosync.

Это не страшно, есть anyfs-tools, testdisk, если фс не >шифрована была, то данные достать всегда можно.

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

или ядерная бомба в серверную попадёт! Тогда ноды кластера в >разных городах в бомбоубежищах держать надо )

Вы не поверите, но в серьезных проектах учитываются и такие риски. И в этом не ничего странного и удивительного.

PS: Вам совершенно правильно сказали о том, что кластеризация и резервирование данных при помощи бекапов-это совершенно разные, необходимые и взаимодополняющие элементы организации и резервирования инфраструктуры и обеспечения ее информационной безопасности. Учите матчасть.

ВМЕСТО бекапа кластеры не делают. Бекап нужен всегда.

+1 Совершенно верно!

Там минимум бекапится, базы данных, все конфики, скрипты..

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

Приведите пример, когда при целом железе (оно у нас резервируется) с «бывшей», не шифрованой, не сжатой ФС нельза достать данные. Да, соглашусь, это долго, может и больше сутки занять, если раздел большой, но возможно.

Приведите пример, когда при целом железе (оно у нас >резервируется) с «бывшей», не шифрованой, не сжатой ФС нельза >достать данные

Примеров полно. Начиная с физического разрушения поверхности диска от брака, старости и сбоев в электросети/оборудовании, заканчивая магнитными и иными воздействиями, в том числе и сгоранием контроллеров. Да и без больших структурных воздействий в целом ряде случаев восстановить полную целостность данных не удается. Поинтересуйтесь у спецов по восстановлению данных. Они вам скажут тоже самое и даже больше) НИКОГДА вменяемый администратор не станет полагаться на кластеризацию данных, приравнивая ее к резервированию посредством бекапа. Это наиглупейшее сравнение. У кластеризации цель горячего резервирования узлов системы и актуальных снимков данных, но при этом его надежность по целостности данных, не намного выше чем у одного узла, по ряду причин. Бекапы-на порядок надежнее в плане именно сохранения целостности и скорости и надежности восстановления. А также хранения например более старых версии данных и скорости их восстановления. НИКОГДА не надейтесь просто на кластеризацию данных-она имеет несколько иное назначение, нежели бекап. Да и вообще-почитайте литературу на сей счет специальную. По информационной безопасности например. Эти правила в данном контексте непреложны.

Да, соглашусь, это долго, может и больше сутки занять, если >раздел большой, но возможно.

Нет! Есть такое понятие как вероятность восстановления данных. Так вот даже и не сравнивайте вороятности возможность восстановить данные с убитого диска/массива с вороятностью восстановить данные с бекапа.

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

Зная это-необходимо хотя-бы дополнительно чуть больше подстраховываться, например не пить за рулем и пристегиваться ремнем безопасности и так далее. Хотя и это не гарантирует полной безопасности от всех проблем, но вероятность ситуаций и рисков значительно понизит. И самое главное-это общеизвестные привила безопасности, написанные кровью. Так и с бекапом...

Если бы пользователи не хранили в сетевых шарах фильмы, музыку, инсталки прог, а только рабочие документы

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

P.S.: Я «отброшенные» бэкапером файлы перемещаю в другую папку не видимую пользователям и там они по сроку давности удаляются.

Какую версию используете?

Corosync 1.3.0 и pacemaker-1.0.10 - стабильны.

или

Corosync 1.4.5 или 2.3.0 с pacemaker-1.1.10 - нестабилен

Последние из squeeze-backports в дебиане, что-то вроде коросинк 1.4.х и пейсмейкер 1.1.х, точно не помню.