Опубликован релиз распределенного реплицируемого блочного устройства DRBD 9.2.0, позволяющего реализовать подобие массива RAID-1, сформированного из объединённых по сети нескольких дисков разных машин (зеркалирование по сети). Система оформлена в виде модуля для ядра Linux и распространяется под лицензией GPLv2. Ветка drbd 9.2.0 может использоваться для прозрачной замены drbd 9.x.x и полностью совместима на уровне протокола, файлов конфигурации и утилит...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57896
Доброе утро. Кто-нибудь пользуется?
Много, много лет назад. Ненужное ненужно это.
Я так понимаю, основное направление использования - устойчивое хранилище для СУБД. Распределенный RAID под базу данных.
Хочу вас сильно расстроить, Вы понимаете не правильно
У субд свои механизмы репликации, более высокоуровневые и надежные
Было когда-то, давным давно в качестве горячей копии бд, еще до появления репликаций на стороне базы. Сейчас скорей под сервера с горячим резервом какого-нибудь медиа и условно ucarp/hartbeat хелфчеком. По опыту использования(лет 10 назад), крайне неудачное решение, но свои юзкейсы имеет.
Реплицированные баззы лучше на raid0 размещать?
Если нужна скорость.
Это для софта который не умеет репликацию сам по себе. Например, если у вас есть сайт на РНР написанный наркоманами и они файлы складывали в папку исторически, вместо какого-нибудь объектного хранилища.
> Это для софта который не умеет репликацию сам по себе. Например, если
> у вас есть сайт на РНР написанный наркоманами и они файлы
> складывали в папку исторически, вместо какого-нибудь объектного хранилища.А если я сам наркоман, как мне это поможет?
> Например, если у вас есть сайт на РНР написанный наркоманами и они файлы складывали в папкутеперь другие наркоманы предлагают блочную репликацию диска вместо файловой
>если у вас есть сайт на РНР написанный наркоманамиrsync не проще? или автодеплой сразу на все серверы
Я пользую, для синхронной репликации дисков с виртуалками на запасной сервер. Уже год как, вроде работает.
Кривой костыль, который еще и подпирать надо, другим костылем.
Ты так говоришь как будто это что-то плохое.
А что это очень хорошл? Вот потому хуманоиды должны вымереть как мамонты.
оно работает только в условиях когда устойчивое соединение по сети и вовремя восстановления и репликации данных нет сбоев, во всех остальных случаях оно прибивает все копии.
А есть альтернатива? Что рекомендуешь?
Надо именно блочное? На уровне фс такого чем угодно жуй. Немного сбоку можно zfs send / zfs receive приделать. Или iscsi задействовать (в пределах локалки). Но времена распределенных/сетевых БЛОЧНЫХ устройств немного прошли, да.
Ceph RBD
Для "похостить php" — вероятно, нормально.
Для чувствительных к задержкам задач — вряд ли.Был опыт эксплуатации в качестве клиента "ceph как услуга" (сэкономить пытались, как водится). ДЦ в одной коноплеводческой евростране.
SAN поверх infiniband не помню уже́ какого точно, только то что карточки были от melanox. Типа, всё круто. На стороне ДЦ было заявлено что "ssd".Результат: периодически выпрыгивающие за 100 мс задержки в IO (всё время эксплуатации), деградации в обслуживании (как я понял, при каких-то ребалансах), отстрелы СХД (при выводе из эксплуатации мастера, видимо).
Допускаю что местные травокуры были феноменально криворукими, но — вот так.
Даже low-end СХД образца нулевых (клоны Netapp E2660 и новее) дают более предсказуемый результат. (Это не совет брать именно такой хлам. Там уже́ электроника от старости сыпется.)
Я пробовал на 5 компов в офисе, версия 9, пару месяцев назад. В течении месяца несколько раз kernel panic.Они пишут на сайте у себя, что в паблик выкладывают апстрим, а LTS стабильная версия у них платная.
Обхаять обхаяли, а альтернативу не предлагаете.
Пару лет CRM с Asterisk на таком пользовал без проблем.
CEPH в сто раз лучше
И в сто раз сложнее, и при деплое, и в обслуживании. Особенно в обслуживании. Особенно под нагрузкой.
Хороший софт в своей нише, но если можно обойтись без неё, то лучше обойтись.
Ну, DRBD8 под proxmox работало неплохо на протяжении долгих лет, но из коробки были kernel panic, пришлось собирать из исходников более свежую версию.