The OpenNET Project / Index page

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

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

10.10.2022 22:55

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

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

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

В новом выпуске:

  • Снижены задержки для зеркалируемых запросов на запись. Более плотная интеграция с сетевым стеком позволила снизить число переключений контекста планировщика.
  • Снижена конкуренция между вводом/выводом приложений и вводом/выводом ресинхронизации за счёт оптимизации блокировок при ресинхронизации экстентов.
  • Значительно повышена производительность ресинхронизации на бэкендах, в которых применяется динамическое выделение места в хранилище ("thin provisioning"). Производительность удалось поднять благодаря объединению операций trim/discard, которые выполняются значительно дольше обычных операций записи.
  • Добавлена поддержка сетевых пространств имён (network namespaces), которая позволила реализовать возможность интеграции с Kubernetes для передачи сетевого трафика репликаций через привязанную к контейнерам отдельную сеть, вместо сети хост-окружения.
  • Добавлен модуль transport_rdma для использования в качестве транспорта Infiniband/RoCE вместо TCP/IP поверх Ethernet. Использование нового транспорта позволяет снизить задержки, уменьшить нагрузку на CPU и обеспечить получение данных без лишних операций копирования (zero-copy).


  1. Главная ссылка к новости (https://lists.linbit.com/piper...)
  2. OpenNews: Релиз распределенного реплицируемого блочного устройства DRBD 9.1.0
  3. OpenNews: Компания Versity открыла исходные тексты файловой системы ScoutFS
  4. OpenNews: Обновление кластерной файловой системы LizardFS 3.13.0-rc2
  5. OpenNews: Первый публичный выпуск распределённой файловой системы JuiceFS
  6. OpenNews: Компания Linbit откроет исходные тексты DRBD+
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/57896-drbd
Ключевые слова: drbd, raid
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 05:26, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Доброе утро. Кто-нибудь пользуется?
     
     
  • 2.4, Аноним (-), 06:03, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Много, много лет назад. Ненужное ненужно это.
     
     
  • 3.5, Аноним (3), 06:14, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я так понимаю, основное направление использования - устойчивое хранилище для СУБД. Распределенный RAID под базу данных.
     
     
  • 4.17, tty0 (?), 10:14, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хочу вас сильно расстроить, Вы понимаете не правильно
     
  • 4.18, Аноним (18), 10:16, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У субд свои механизмы репликации, более высокоуровневые и надежные
     
  • 4.20, Андрей (??), 10:49, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Было когда-то, давным давно в качестве горячей копии бд, еще до появления репликаций на стороне базы. Сейчас скорей под сервера с горячим резервом какого-нибудь медиа и условно ucarp/hartbeat хелфчеком. По опыту использования(лет 10 назад), крайне неудачное решение, но свои юзкейсы имеет.
     
     
  • 5.25, George (??), 12:46, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Реплицированные баззы лучше на raid0 размещать?
     
     
  • 6.32, V1 (ok), 08:25, 12/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если нужна скорость.
     
  • 4.22, Товарисч (?), 11:33, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это для софта который не умеет репликацию сам по себе. Например, если у вас есть сайт на РНР написанный наркоманами и они файлы складывали в папку исторически, вместо какого-нибудь объектного хранилища.
     
     
  • 5.23, Аноним (3), 11:44, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это для софта который не умеет репликацию сам по себе. Например, если
    > у вас есть сайт на РНР написанный наркоманами и они файлы
    > складывали в папку исторически, вместо какого-нибудь объектного хранилища.

    А если я сам наркоман, как мне это поможет?

     
  • 5.24, Аноним (24), 12:11, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Например, если у вас есть сайт на РНР написанный наркоманами и они файлы складывали в папку

    теперь другие наркоманы предлагают блочную репликацию диска вместо файловой

     
  • 5.29, лютый жабби.... (?), 18:32, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >если у вас есть сайт на РНР написанный наркоманами

    rsync не проще? или автодеплой сразу на все серверы

     
  • 2.12, Аноним (12), 09:28, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я пользую, для синхронной репликации дисков с виртуалками на запасной сервер. Уже год как, вроде работает.
     

  • 1.6, bOOster (ok), 06:47, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кривой костыль, который еще и подпирать надо, другим костылем.
     
     
  • 2.11, Аноним (11), 08:59, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты так говоришь как будто это что-то плохое.
     
     
  • 3.21, намэ (?), 11:23, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что это очень хорошл? Вот потому хуманоиды должны вымереть как мамонты.
     

  • 1.13, Аноним (13), 09:35, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    оно работает только в условиях когда устойчивое соединение по сети и вовремя восстановления и репликации данных нет сбоев, во всех остальных случаях оно прибивает все копии.
     
     
  • 2.14, 111 (??), 09:41, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А есть альтернатива? Что рекомендуешь?
     
     
  • 3.15, Аноним (18), 09:51, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Надо именно блочное? На уровне фс такого чем угодно жуй. Немного сбоку можно zfs send / zfs receive приделать. Или iscsi задействовать (в пределах локалки). Но времена распределенных/сетевых БЛОЧНЫХ устройств немного прошли, да.
     
  • 3.27, Аноним (27), 14:46, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ceph RBD
     
     
  • 4.33, PnD (??), 13:05, 13/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для "похостить php" — вероятно, нормально.
    Для чувствительных к задержкам задач — вряд ли.

    Был опыт эксплуатации в качестве клиента "ceph как услуга" (сэкономить пытались, как водится). ДЦ в одной коноплеводческой евростране.
    SAN поверх infiniband не помню уже́ какого точно, только то что карточки были от melanox. Типа, всё круто. На стороне ДЦ было заявлено что "ssd".

    Результат: периодически выпрыгивающие за 100 мс задержки в IO (всё время эксплуатации), деградации в обслуживании (как я понял, при каких-то ребалансах), отстрелы СХД (при выводе из эксплуатации мастера, видимо).
    Допускаю что местные травокуры были феноменально криворукими, но — вот так.
    Даже low-end СХД образца нулевых (клоны Netapp E2660 и новее) дают более предсказуемый результат. (Это не совет брать именно такой хлам. Там уже́ электроника от старости сыпется.)

     

  • 1.16, Аноним (16), 09:57, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я пробовал на 5 компов в офисе, версия 9, пару месяцев назад. В течении месяца несколько раз kernel panic.

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

     
  • 1.19, benu (ok), 10:46, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Обхаять обхаяли, а альтернативу не предлагаете.
    Пару лет CRM с Asterisk на таком пользовал без проблем.
     
  • 1.26, George (??), 12:46, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    CEPH в сто раз лучше
     
     
  • 2.30, Аноним (30), 19:27, 11/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И в сто раз сложнее, и при деплое, и в обслуживании. Особенно в обслуживании. Особенно под нагрузкой.
     

  • 1.31, Аноним (30), 19:30, 11/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хороший софт в своей нише, но если можно обойтись без неё, то лучше обойтись.
     
  • 1.34, Аноним (34), 14:42, 17/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну, DRBD8 под proxmox работало неплохо на протяжении долгих лет, но из коробки были kernel panic, пришлось собирать из исходников более свежую версию.
     

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



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

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