The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз распределенного реплицируемого блочного устройства DRBD 9.1.0

26.02.2021 12:01

Опубликован релиз распределенного реплицируемого блочного устройства DRBD 9.1.0, позволяющего реализовать подобие массива RAID-1, сформированного из объединённых по сети нескольких дисков разных машин (зеркалирование по сети). Система оформлена в виде модуля для ядра Linux и распространяется под лицензией GPLv2.

Ветка drbd 9.1.0 может использоваться для прозрачной замены drbd 9.0.x и полностью совместима на уровне протокола, файлов конфигурации и утилит. Изменения сводятся к переработке механизма установки блокировок и нацелены на уменьшение конкуренции при установке блокировок в коде, отвечающем за ввод-вывод в DRBD. Изменение позволило поднять производительность в конфигурациях с большим числом CPU и c накопителями NVMe, за счёт устранения узкого места, негативно влияющего на производительность при поступлении большого числа параллельных запросов ввода/вывода с разных ядер CPU. В остальном ветка drbd 9.1.0 аналогична выпуску 9.0.28.

Напомним, что DRBD может использоваться для объединения накопителей узлов кластера в единое отказоустойчивое хранилище. Для приложений и системы такое хранилище выглядит как одинаковое для всех систем блочное устройство. При использовании DRBD все операции с локальным диском отправляются на другие узлы и синхронизируются с дисками других машин. В случае выхода из строя одного узла, хранилище автоматически продолжит работу за счёт оставшихся узлов. При возобновлении доступности сбойного узла, его состояние будет автоматически доведено до актуального вида.

В состав кластера, формирующего хранилище, может входить несколько десятков узлов, размещённых как в локальной сети, так и территориально разнесённых в разные центры обработки данных. Синхронизация в подобных разветвлённых хранилищах выполняется с использованием технологий mesh-сети (данные растекаются по цепочке от узла к узлу). Репликация узлов может производиться как в синхронном режиме, так и в асинхронном. Например, локально размещённые узлы могут применять синхронную репликацию, а для выноса на удалённое размещённые площадки может применяться асинхронная репликация с дополнительным сжатием и шифрованием трафика.



  1. Главная ссылка к новости (https://lists.linbit.com/piper...)
  2. OpenNews: Новый выпуск распределенного реплицируемого блочного устройства DRBD 9.0.1
  3. OpenNews: Релиз распределенного реплицируемого блочного устройства DRBD 9.0
  4. OpenNews: Компания Linbit откроет исходные тексты DRBD+
  5. OpenNews: В Reiser5 анонсирована поддержка выборочной миграции файлов
  6. OpenNews: Bcachefs доведена до состояния, пригодного для включения в состав ядра Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54661-drbd
Ключевые слова: drbd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:11, 26/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    найс
     
     
  • 2.28, AlexN (??), 20:21, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В стабильном дебиане версия Пакет: drbd-utils (9.5.0-1), в sid - Пакет: drbd-utils (9.15.0-1). Не понял о чем новость...
     
     
  • 3.38, ya (??), 08:41, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нумерация drbd и drbd-utils не совпадает. Пакетов с самим drbd нет, он в ядре. По крайней мере, это касается бубунты.
     
     
  • 4.39, AlexN (??), 09:23, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Все верно. Мое заблуждение вызвано тем, что я вводил в эксплуатацию эту систему, когда номера почти совпадали.
     

  • 1.2, Qwerty (??), 12:42, 26/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –32 +/
    Зумерки изобрели GlusterFS.
     
     
  • 2.3, Зумерок (?), 12:50, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Ага, изобрели. и это случилось ещё до твоего рождения, если ты про drdb впервые слышишь. Лично я про drdb узнал году так в 2005ом.
     
     
  • 3.8, Qwerty (??), 13:46, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –14 +/
    > Ага, изобрели. и это случилось ещё до твоего рождения, если ты про
    > drdb впервые слышишь. Лично я про drdb узнал году так в
    > 2005ом.

    Впервые. Зачем какой-то недоделанный DRDB, если есть GFS, которая уже работает?

     
     
  • 4.11, ford1813 (ok), 14:32, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Кому нужно GFS - возьмут его, кому нужен DRDB возьмут его.
    Если вы о DRDB слышите впервые - это не значит что он недоделанный.
    Сейчас много расхайпаного говна, каждому своё.
     
  • 4.18, Аноним (18), 16:35, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +7 +/
    То есть, ты не видишь разницы между файловой системой и блочным устройством?
     
  • 4.20, бублички (?), 16:46, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > есть GFS, которая уже работает

    которая тормозит себе целиком в user-space да ещё через FUSE. ты хоть бы почитал какие книжки или газеты для развития, а-то совсме мозги засохли

     
  • 4.26, zzz (??), 19:31, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >есть GFS, которая уже работает

    Ну это ты погорячился. Намедни у одного провайдера люстра упала. Два раза. Клиенты были рады до одури.

     
     
  • 5.41, бублички (?), 12:43, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    ты путаешь Lustre и Gluster (GlusterFS). а твой предшественник скорее всего вообще не знал о чём писал (GFS). GFS в 90-х финансировал SGI для своей IRIX. все 3 давно закопаны. а то что сейчас в RedHat, это GFS2 - развитие OpenGFS (порт GFS для Linux). впрочем не удивлюсь если тот человек вообще думал про GPFS (детище IBM)
     
  • 2.4, YetAnotherOnanym (ok), 13:00, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По линкам не ходил, не знаю, насколько сабж по функционалу аналогичен глустеру, но если он будет лучше, то почему бы нет? Глустер я когда-то пощупал, оказался он тормозным и глючным. Так что альтернативу я могу только приветствовать.
     
  • 2.5, RomanCh (ok), 13:20, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Про "зумерки" вам ответили. Но вообще, вы точно понимаете смысл того что пишете? Похоже что нет, т.к. DBRD это про репликацию блочного устройства работающую на уровне ядра, а глюЧстерФС - про POSIX совместимую FUSE.
     
     
  • 3.19, Аноним (18), 16:37, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Более того, распределенная файловая система, 100% совместимая с POSIX, даже теоретически невозможна, поскольку семантика блокировок в POSIX противоречит CAP-теореме.
     
     
  • 4.32, Минона (ok), 23:22, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подробнее в чем противоречие.
     
     
  • 5.43, Аноним (43), 16:43, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Видимо либо всё колом будет вставать на любой записи либо сплитбрейн.
     
     
  • 6.48, Минона (ok), 21:36, 28/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Видимо либо всё колом будет вставать на любой записи либо сплитбрейн.

    Так называемая "САР-теорема" это не теорема, так как не существует никакого математического обоснования её.
    Сплитбрейн это аварийная ситуация. В чем противоречие "теореме" при штатной работе - не понятно.

     
  • 4.49, PnD (??), 09:47, 01/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Попробую улучшить формулировку.
    1. Если под "распределённой" ФС понимать "shared", то да. Блокировками придётся жертвовать. Потому что "shared" реализуется за счёт отказа от атомарности операций.
    2. В случае "clustered" ФС, атомарность операций достигается ценой понижения надёжности как отдельных узлов, так (зачастую) и системы в целом. Про это — GFS и OCFS. B куча батхёртов "а чего оно такое ненадёжное". А вот того.
    3. "CAP-теорема" пока AFAIK не доказана и не опровергнута. Я даже не уверен, что данные положения потрудились формально выразить. Но при проектировании ей пользуются не хуже чем каким-нибудь "правилом буравчика". Кто не пользуется — получает что-то вроде rabbitMQ. (Всё здорово до первой попытки собрать "кластер").
     
  • 2.6, это не я (?), 13:21, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Алё! DRBD в зрелом состоянии прибывает уже с середины нулевых. Каждый второй нище-хостер тогда держал её как хранилище для xen. Замеры метнулись во времени, или же комментатор не в себе?

    Ожидаем появление комментариев в духе "NBD? AoE? Зумеры изобрели iSCSI?" и "NFS? Школьники делают свой нескучный cifs?"

     
  • 2.7, Аноним (7), 13:39, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Палишься. Совсем разные вещи, а существует уже черт знает сколько как тут и до меня уже написали
     
  • 2.9, Аноним (9), 14:15, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты не прав. Как уже написали выше, DBRD существовал уже как минимум в 2005 году.
     
  • 2.21, Аноним (21), 16:49, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Редхатовский глистФС работает в пространстве пользователя FUSE... короче говоря тормозит
     
     
  • 3.40, Анончик (?), 09:45, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Анон системный программист у которого FUSE в GlusterFS является узким местом.
    Ты хотя бы погугли про переключение контекстов и на что оно влияет, а потом трассировку сделай на проде GlusterFS что бы посмотреть где же fuse тормозит так сильно.
    Ощущение что кассиры из Макдака только и деляют что в свободное время линь себе ставят и охают как у них тормозит.
     
  • 2.24, Аноним (24), 18:42, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >Зумерки изобрели GlusterFS.

    Я так понимаю, на этом блочном устройстве можно создать любую желаемую ФС.

     
     
  • 3.46, Аноним (46), 20:34, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понимаю, на этом блочном устройстве можно создать любую желаемую ФС.

    Да. И даже использовать без ФС совсем при необходимости. Просто как блочное устройство.

     

  • 1.10, kissmyass (?), 14:23, 26/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А репликация двухсторонняя? Только в синхронном режиме?

    Для синхронизации видео-архива лучше блочное устройство с DRBD или какой-нибудь Syncting?

     
     
  • 2.12, ford1813 (ok), 14:53, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    DRBD supports both synchronous and asynchronous write operations, which will be further discussed below in relation to the three protocol setups.
     
     
  • 3.13, kissmyass (?), 15:10, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > DRBD supports both synchronous and asynchronous write operations, which will be further
    > discussed below in relation to the three protocol setups.

    И? Как это отвечает хоть на один мой вопрос?

     
     
  • 4.27, Аноним (27), 19:37, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На этот, например?
    > Только в синхронном режиме?
     
     
  • 5.30, kissmyass (?), 22:44, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > На этот, например?
    >> Только в синхронном режиме?

    Так без ответа на первый не имеет большого смысла ответ на второй (это как бы уточняющий вопрос).

    Я уже нашел документацию, пишут про 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 получается намного проще, ведь мне блочная синхронизация необязательна.

     
     
  • 6.31, Аноним (18), 23:13, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В 9.1 как раз планировали допилить работающий в бете с девятки dual-primary. Не знаю, допилили или нет :-)
     
     
  • 7.42, kissmyass (?), 14:37, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В 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, но не думаю что так всё просто.

     
  • 6.33, vvi (??), 23:24, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Да, полноценного использования мультимастера нужна кластерная ФС.
    В 2010-м успешно делал отказоустойчивые кластеры на связке DRBD+OCFS2 (Oracle Cluster FileSystem v2 - GPL, драйвер входит в ванильное ядро).
    Например, поверх этого дела отлично работал (в том числе и) PostgreSQL.
     
     
  • 7.34, kissmyass (?), 23:43, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Да, полноценного использования мультимастера нужна кластерная ФС.
    > В 2010-м успешно делал отказоустойчивые кластеры на связке DRBD+OCFS2 (Oracle Cluster FileSystem
    > v2 - GPL, драйвер входит в ванильное ядро).
    > Например, поверх этого дела отлично работал (в том числе и) PostgreSQL.

    а что поверх чего прикручивается?

    допустим есть две машины, в локальной сети (ну или близко к локальной)

    на обеих есть mdraid и LUKS, как сделать синхронизацию с помощью DRBD+OCFS2?

     
     
  • 8.45, AlexN (??), 17:48, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Для синхронизации файловая система не нужна Утилите dd же ведь наплевать какая ... текст свёрнут, показать
     
     
  • 9.47, kissmyass (?), 04:51, 28/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    читайте мануал или хотя бы эту ветку ... текст свёрнут, показать
     
  • 7.44, AlexN (??), 17:26, 27/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >Да, полноценного использования мультимастера нужна кластерная ФС.
    >В 2010-м успешно делал отказоустойчивые кластеры на связке DRBD+OCFS2 (Oracle Cluster >FileSystem v2 - GPL, драйвер входит в ванильное ядро).
    >Например, поверх этого дела отлично работал (в том числе и) PostgreSQL.

    Я то же самое - ту же связку - мастерил, но для облачной инфраструктуры предприятия. ) До сих пор работает.

     
  • 2.16, Ананоним (?), 16:29, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Всё лучше Syncting

    Go   HTML   Kotlin   Shell  Python

    Ты серьёзно считаешь что это может потягаться с такой великолепной и отлаженной штукой как DRBD?

     

  • 1.15, Ананоним (?), 16:26, 26/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Замечательная штука. Молодцы ребята. Долгих вам лет и успехов.
     
     
  • 2.22, валяйте (?), 17:38, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ещеб документация у этой байды была...
     
     
  • 3.23, Умею пользоваться поисковиком (?), 17:43, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не благодари: https://www.linbit.com/drbd-user-guide/
     
     
  • 4.29, валяйте (?), 21:07, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну и заодно расскажи как к этому цеплять ocfs или gfs
     
     
  • 5.36, Онаним (?), 23:47, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В принципе так же, как и к любой хранилке.
    Можно напрямую. Можно iSCSI поверх навернуть и цеплять к нему.

    Основная задница с DRBD наступает, когда кластер разваливается полностью. Даже при синхронной репликации и в режиме suspend-io, когда в теории ничего нового процессы уже не запишут, и можно по меткам времени записи восстановиться, оно так нормально восстанавливаться не умеет

     
     
  • 6.37, Онаним (?), 23:49, 26/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Любимый способ восстановления - убиение ноды через внешний stonith или хотя бы через sysrq.
    Чтобы в добавок к разрыву синхронизации ещё локально не дописанные данные потерять.
    Это (он), уважаемая рыдагция.
     

  • 1.25, Аноним (-), 19:05, 26/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Глючная штука, убивает обе копии при сбоях при синхронизации
     
  • 1.35, Онаним (?), 23:45, 26/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всё бы было ничего, если бы арбитраж и механизмы поддержания кворума и целостности так и не остались на уровне 2005 года.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру