Опубликован релиз распределенного реплицируемого блочного устройства DRBD 9.1.0, позволяющего реализовать подобие массива RAID-1, сформированного из объединённых по сети нескольких дисков разных машин (зеркалирование по сети). Система оформлена в виде модуля для ядра Linux и распространяется под лицензией GPLv2...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54661
найс
В стабильном дебиане версия Пакет: drbd-utils (9.5.0-1), в sid - Пакет: drbd-utils (9.15.0-1). Не понял о чем новость...
Нумерация drbd и drbd-utils не совпадает. Пакетов с самим drbd нет, он в ядре. По крайней мере, это касается бубунты.
Все верно. Мое заблуждение вызвано тем, что я вводил в эксплуатацию эту систему, когда номера почти совпадали.
Зумерки изобрели GlusterFS.
Ага, изобрели. и это случилось ещё до твоего рождения, если ты про drdb впервые слышишь. Лично я про drdb узнал году так в 2005ом.
> Ага, изобрели. и это случилось ещё до твоего рождения, если ты про
> drdb впервые слышишь. Лично я про drdb узнал году так в
> 2005ом.Впервые. Зачем какой-то недоделанный DRDB, если есть GFS, которая уже работает?
Кому нужно GFS - возьмут его, кому нужен DRDB возьмут его.
Если вы о DRDB слышите впервые - это не значит что он недоделанный.
Сейчас много расхайпаного говна, каждому своё.
То есть, ты не видишь разницы между файловой системой и блочным устройством?
> есть GFS, которая уже работаеткоторая тормозит себе целиком в user-space да ещё через FUSE. ты хоть бы почитал какие книжки или газеты для развития, а-то совсме мозги засохли
>есть GFS, которая уже работаетНу это ты погорячился. Намедни у одного провайдера люстра упала. Два раза. Клиенты были рады до одури.
ты путаешь Lustre и Gluster (GlusterFS). а твой предшественник скорее всего вообще не знал о чём писал (GFS). GFS в 90-х финансировал SGI для своей IRIX. все 3 давно закопаны. а то что сейчас в RedHat, это GFS2 - развитие OpenGFS (порт GFS для Linux). впрочем не удивлюсь если тот человек вообще думал про GPFS (детище IBM)
По линкам не ходил, не знаю, насколько сабж по функционалу аналогичен глустеру, но если он будет лучше, то почему бы нет? Глустер я когда-то пощупал, оказался он тормозным и глючным. Так что альтернативу я могу только приветствовать.
Про "зумерки" вам ответили. Но вообще, вы точно понимаете смысл того что пишете? Похоже что нет, т.к. DBRD это про репликацию блочного устройства работающую на уровне ядра, а глюЧстерФС - про POSIX совместимую FUSE.
Более того, распределенная файловая система, 100% совместимая с POSIX, даже теоретически невозможна, поскольку семантика блокировок в POSIX противоречит CAP-теореме.
Можно подробнее в чем противоречие.
Видимо либо всё колом будет вставать на любой записи либо сплитбрейн.
> Видимо либо всё колом будет вставать на любой записи либо сплитбрейн.Так называемая "САР-теорема" это не теорема, так как не существует никакого математического обоснования её.
Сплитбрейн это аварийная ситуация. В чем противоречие "теореме" при штатной работе - не понятно.
Попробую улучшить формулировку.
1. Если под "распределённой" ФС понимать "shared", то да. Блокировками придётся жертвовать. Потому что "shared" реализуется за счёт отказа от атомарности операций.
2. В случае "clustered" ФС, атомарность операций достигается ценой понижения надёжности как отдельных узлов, так (зачастую) и системы в целом. Про это — GFS и OCFS. B куча батхёртов "а чего оно такое ненадёжное". А вот того.
3. "CAP-теорема" пока AFAIK не доказана и не опровергнута. Я даже не уверен, что данные положения потрудились формально выразить. Но при проектировании ей пользуются не хуже чем каким-нибудь "правилом буравчика". Кто не пользуется — получает что-то вроде rabbitMQ. (Всё здорово до первой попытки собрать "кластер").
Алё! DRBD в зрелом состоянии прибывает уже с середины нулевых. Каждый второй нище-хостер тогда держал её как хранилище для xen. Замеры метнулись во времени, или же комментатор не в себе?Ожидаем появление комментариев в духе "NBD? AoE? Зумеры изобрели iSCSI?" и "NFS? Школьники делают свой нескучный cifs?"
Палишься. Совсем разные вещи, а существует уже черт знает сколько как тут и до меня уже написали
Ты не прав. Как уже написали выше, DBRD существовал уже как минимум в 2005 году.
Редхатовский глистФС работает в пространстве пользователя FUSE... короче говоря тормозит
Анон системный программист у которого FUSE в GlusterFS является узким местом.
Ты хотя бы погугли про переключение контекстов и на что оно влияет, а потом трассировку сделай на проде GlusterFS что бы посмотреть где же fuse тормозит так сильно.
Ощущение что кассиры из Макдака только и деляют что в свободное время линь себе ставят и охают как у них тормозит.
>Зумерки изобрели GlusterFS.Я так понимаю, на этом блочном устройстве можно создать любую желаемую ФС.
> Я так понимаю, на этом блочном устройстве можно создать любую желаемую ФС.Да. И даже использовать без ФС совсем при необходимости. Просто как блочное устройство.
А репликация двухсторонняя? Только в синхронном режиме?Для синхронизации видео-архива лучше блочное устройство с DRBD или какой-нибудь Syncting?
DRBD supports both synchronous and asynchronous write operations, which will be further discussed below in relation to the three protocol setups.
> DRBD supports both synchronous and asynchronous write operations, which will be further
> discussed below in relation to the three protocol setups.И? Как это отвечает хоть на один мой вопрос?
На этот, например?
> Только в синхронном режиме?
> На этот, например?
>> Только в синхронном режиме?Так без ответа на первый не имеет большого смысла ответ на второй (это как бы уточняющий вопрос).
Я уже нашел документацию, пишут про primary и secondary. Синхронный "мульти-мастер" возможен только с GFS или другой подобной фс.
А что касается режимов работы то их вообще не 2 а 3
- Asynchronous replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has finished, and the replication packet has been placed in the local TCP send buffer. In the event of forced fail-over, data loss may occur.
- Memory synchronous (semi-synchronous) replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred, and the replication packet has reached the peer node. Normally, no writes are lost in case of forced fail-over.
- Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss.
Как прикрутить GFS слабо себе представляю, что за зверинец будет в итоге тоже непонятно.
Надо курить дальше, может кто и подскажет по теме.. Но поднять Syncthing получается намного проще, ведь мне блочная синхронизация необязательна.
В 9.1 как раз планировали допилить работающий в бете с девятки dual-primary. Не знаю, допилили или нет :-)
> В 9.1 как раз планировали допилить работающий в бете с девятки dual-primary.
> Не знаю, допилили или нет :-)Dual-primary mode requires that the resource is configured to replicate synchronously (protocol C). Because of this it is latency sensitive, and ill suited for WAN environments.
Additionally, as both resources are always primary, any interruption in the network between nodes will result in a split-brain.
In DRBD 9.0.x Dual-Primary mode is limited to exactly 2 Primaries for the use in live migration.In dual-primary mode, a resource is, at any given time, in the primary role on two cluster nodes[1]. Since concurrent access to the data is thus possible, this mode requires the use of a shared cluster file system that utilizes a distributed lock manager. Examples include GFS and OCFS2.
А OCFS2 я так понимаю часть ядра Unbreakable Kernel от оракла.
Не знаю что там будет в 9.1, но не думаю что так всё просто.
Да, полноценного использования мультимастера нужна кластерная ФС.
В 2010-м успешно делал отказоустойчивые кластеры на связке DRBD+OCFS2 (Oracle Cluster FileSystem v2 - GPL, драйвер входит в ванильное ядро).
Например, поверх этого дела отлично работал (в том числе и) PostgreSQL.
> Да, полноценного использования мультимастера нужна кластерная ФС.
> В 2010-м успешно делал отказоустойчивые кластеры на связке DRBD+OCFS2 (Oracle Cluster FileSystem
> v2 - GPL, драйвер входит в ванильное ядро).
> Например, поверх этого дела отлично работал (в том числе и) PostgreSQL.а что поверх чего прикручивается?
допустим есть две машины, в локальной сети (ну или близко к локальной)
на обеих есть mdraid и LUKS, как сделать синхронизацию с помощью DRBD+OCFS2?
>на обеих есть mdraid и LUKS, как сделать синхронизацию с помощью DRBD+OCFS2?Для синхронизации файловая система не нужна. Утилите dd же ведь наплевать какая файловая поручена ей для копирования. )) ФС нужна для структурирования информации на носителе и описании правил доступа к ней. А вот CEPH и DRBD позволяют "размазать" блочное устройство по сети. Либо в raid 1, либо в raid 5. С некоторыми вариациями.
>>на обеих есть mdraid и LUKS, как сделать синхронизацию с помощью DRBD+OCFS2?
> Для синхронизации файловая система не нужна. Утилите dd же ведь наплевать какая
> файловая поручена ей для копирования. )) ФС нужна для структурирования информации
> на носителе и описании правил доступа к ней. А вот CEPH
> и DRBD позволяют "размазать" блочное устройство по сети. Либо в raid
> 1, либо в raid 5. С некоторыми вариациями.читайте мануал или хотя бы эту ветку
>Да, полноценного использования мультимастера нужна кластерная ФС.
>В 2010-м успешно делал отказоустойчивые кластеры на связке DRBD+OCFS2 (Oracle Cluster >FileSystem v2 - GPL, драйвер входит в ванильное ядро).
>Например, поверх этого дела отлично работал (в том числе и) PostgreSQL.Я то же самое - ту же связку - мастерил, но для облачной инфраструктуры предприятия. ) До сих пор работает.
Всё лучше SynctingGo HTML Kotlin Shell Python
Ты серьёзно считаешь что это может потягаться с такой великолепной и отлаженной штукой как DRBD?
Замечательная штука. Молодцы ребята. Долгих вам лет и успехов.
Ещеб документация у этой байды была...
Не благодари: https://www.linbit.com/drbd-user-guide/
Ну и заодно расскажи как к этому цеплять ocfs или gfs
В принципе так же, как и к любой хранилке.
Можно напрямую. Можно iSCSI поверх навернуть и цеплять к нему.Основная задница с DRBD наступает, когда кластер разваливается полностью. Даже при синхронной репликации и в режиме suspend-io, когда в теории ничего нового процессы уже не запишут, и можно по меткам времени записи восстановиться, оно так нормально восстанавливаться не умеет
Любимый способ восстановления - убиение ноды через внешний stonith или хотя бы через sysrq.
Чтобы в добавок к разрыву синхронизации ещё локально не дописанные данные потерять.
Это (он), уважаемая рыдагция.
Глючная штука, убивает обе копии при сбоях при синхронизации
Всё бы было ничего, если бы арбитраж и механизмы поддержания кворума и целостности так и не остались на уровне 2005 года.