The OpenNET Project / Index page

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

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

17.06.2015 18:11

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

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

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

Основные новшества DRBD 9:

  • Новая архитектура передачи данных, в которой используется абстрагированный транспортный уровень, позволяющий реализовать каналы связи не только поверх TCP, например, с использованием RDMA/Infiniband и SCTP.
  • Интеграция RDMA (Remote Direct Memory Access) для прямого доступа к оперативной памяти другого компьютера и поддержка сетевых карт Infiniband, позволяют добиться двухкратного увеличения интенсивности репликации с сокращением нагрузки на CPU на 50% по сравнению с транспортом поверх традиционной IP-сети;
  • Расширенные возможности отказоустойчивости - хранилище теперь может быть реплицировано одновременно на 32 узла, размещённых в различных сетевых окружениях.
  • Новый инструментарий для управления, позволяющий развернуть сложное реплицированное хранилище за считанные минуты. Инструментарий предоставляет API для автоматизации выполнения действий с DRBD и интеграции с внешними системами, такими как OpenStack, а также для создания на базе Linux альтернатив традиционным SAN.
  • Поддержка установки нескольких соединений к одному ресурсу, что позволяет создавать более эффективные и сложные схемы соединения узлов между собой.
  • Автоматическая установка статуса узла в зависимости от активности. Например, узел помечается первичным при открытии блочного устройства на запись и вторичным - при прекращении работы с устройством всеми процессами.
  • Распространение обновлений в неблокирующем режиме, что позволило значительно увеличить производительность хранилища (в тестах более 400 тыс операций в секунду).
  • Поддержка двухфазных коммитов, позволяющих охватить косвенно связанные узлы во время установки нового соединения или при смене первичного узла;
  • Переработанная логика принятия решений о ресинхронизации в условиях наличия нескольких соединений или некачественной сетевой связи.


  1. Главная ссылка к новости (http://www.linbit.com/en/n/new...)
  2. OpenNews: Для ядра Linux представлены патчи с реализацией DRBD 8.4
  3. OpenNews: В состав будущей версии Linux ядра решено включить Nouveau и DRBD
  4. OpenNews: Компания Linbit откроет исходные тексты DRBD+
  5. OpenNews: Отказоустойчивая система виртуализации на основе Xen и DRBD
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42447-drbd
Ключевые слова: drbd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 18:23, 17/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    CEPH лучше, чем DRBD
     
     
  • 2.3, yukra (?), 18:33, 17/06/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    у меня сейчас drbd в проде на одном "проекте" и ceph в тестинге в другом проекте. Я когда знакомился с ceph тоже думал "нафиг выкину drbd", но потом подумал и решил что для двух серверов ceph как то оверкил, все таки у них немного разное ЦА. Так что сравнивать "в тупую" неправильно.
     

  • 1.2, A.Stahl (ok), 18:24, 17/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –17 +/
    >подобие массива RAID-1

    Стоп-стоп-стоп! Это тупое зеркало, но по сети? И объединив 100 машин по 1 байту, мы получим сверхнадёжный 1 байт? И ни битом больше?
    Не-не-не! Пусть пилят и другие "подобия рейдов". Тем более, что  базис уже готов...

     
     
  • 2.4, сис.админ_23rus (ok), 19:17, 17/06/2015 [^] [^^] [^^^] [ответить]  
  • +7 +/
    DRBD  заточен в основном на отказоустойчивые системы, поэтому не стоит так реагировать
     
  • 2.5, Аноним (-), 20:22, 17/06/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    С добрым утром.
     
  • 2.7, Dmi (?), 23:13, 17/06/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это не "тупое" зеркало, а довольно таки умное: например, при потере слейва и последующем подсоединении ресинхронизация проходит очень быстро, поскольку гоняются только измененившиеся блоки, отмеченные в битовой карте.
    При этом DRBD дает возможность на халяву делать нормальное дублирование данных, а не делать вид, что дешевая дисковая полка от всего спасает.
     
     
  • 3.8, Andrey Mitrofanov (?), 23:23, 17/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > только измененившиеся блоки, отмеченные в битовой карте.

    А именно битовая карта - не в v8 ли, где только 2 копии? Для v9 с несколькими копиями там что? Несколько бит на блок? Я не смотрел и как обычно всё путаю?  ... ... ...

     
     
  • 4.10, Dmi (?), 00:16, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> только измененившиеся блоки, отмеченные в битовой карте.
    > А именно битовая карта - не в v8 ли, где только 2
    > копии? Для v9 с несколькими копиями там что? Несколько бит на
    > блок? Я не смотрел и как обычно всё путаю?  ...

    В бета-документахе на v9 по прежнему написано, что quick-sync bitmap по-парная. Так что их несколько наверное, если несколько пиров.

     
  • 2.12, Аноним (-), 08:01, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Благодаря этому простому зеркалу по сети, умелые люди добиваются не только резервирования дисков, но и всего сервера с питанием!

    Вполне хватает RAID-1 - простота, скорость и надёжность!

     

  • 1.6, Аноним (-), 23:09, 17/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Это тоже самое что и gluster ?
     
     
  • 2.9, Andrey Mitrofanov (?), 23:24, 17/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это тоже самое что и gluster ?

    Нет. Это то же самое, что LVM. </шютка>

     
  • 2.11, Рудвульф (?), 07:21, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Товарищ вы путаете ФС и блочное устройство. Кстати кто какую ФС поверх DRBD использует?
     
     
  • 3.13, Аноним (-), 08:03, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Товарищ вы путаете ФС и блочное устройство. Кстати кто какую ФС поверх
    > DRBD использует?

    ext4 для тех кто боится и первый раз.

    GFS можно добиться режима работы с одновременной записью на оба диска.

     
     
  • 4.25, pokalo (??), 12:36, 19/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Товарищ вы путаете ФС и блочное устройство. Кстати кто какую ФС поверх
    >> DRBD использует?
    > ext4 для тех кто боится и первый раз.
    > GFS можно добиться режима работы с одновременной записью на оба диска.

    GFS какой то глючный. и много хочет.

     
  • 3.17, Xaionaro (ok), 10:12, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Кстати кто какую ФС поверх DRBD использует?

    Я когда-то использовал OCFS2 поверх DRBD. Работает. Но интерконнект между серверами был слабый (1Gbps ethernet), и в результате многие операции с ФС шли очень медленно. Обычный svn cleanup в одном проекте занимал полчаса.

    [offtop]
    Если действительно интересно обменяться опытом по данной теме, то рекомендую поехать на LVEE на следующей неделе, и я могу подробно пересказать свой опыт [1].

    [1] https://lvee.org/uploads/image_upload/file/337/winter_2014_15_clsync.pdf
    [/offtop]

     

  • 1.14, Аноним (-), 08:10, 18/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки. То есть балансировщик. После повреждения одного с узлов, не только диск, а может отказать мамка, проц, сетевая, другой берёт на себя полную нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется между работающими, исправными узлами.
     
     
  • 2.15, Аноним (-), 08:13, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    PS: от наличия резервного копирования админов не освобождает, особо в случае режима active-active
     
     
  • 3.18, 1 (??), 10:29, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, наладить резервное копирование админов, тоже бы не помешало.
     
     
  • 4.28, count0krsk (ok), 04:07, 22/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И актуализирование ими документации на всё, что они наворотили в реальном времени путем выписывания магического пенделя ;-)
     
     
  • 5.31, Andrey Mitrofanov (?), 09:26, 22/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > И актуализирование ими документации на всё, что они наворотили в реальном времени
    > путем выписывания магического пенделя ;-)

    Наше поколение советских людей будет жить при Полной Документации. Ура, товарищи!!

     
  • 2.16, Аноним (-), 09:39, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Так на картинке active - active :)
     
  • 2.19, Shodan (ok), 10:56, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый
    > откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки.
    > То есть балансировщик. После повреждения одного с узлов, не только диск,
    > а может отказать мамка, проц, сетевая, другой берёт на себя полную
    > нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется
    > между работающими, исправными узлами.

    Это будет глобальный race condition.

     
     
  • 3.20, Xaionaro (ok), 18:58, 18/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый
    >> откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки.
    >> То есть балансировщик. После повреждения одного с узлов, не только диск,
    >> а может отказать мамка, проц, сетевая, другой берёт на себя полную
    >> нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется
    >> между работающими, исправными узлами.
    > Это будет глобальный race condition.

    DLM [1], OCFS2 [2].

    [1] https://en.wikipedia.org/wiki/Distributed_lock_manager
    [2] https://ru.wikipedia.org/wiki/OCFS

     
     
  • 4.21, Shodan (ok), 10:03, 19/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это все красиво только в теории.
     
     
  • 5.23, JR (?), 12:07, 19/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    8 лет проработало -> кластер из 2 нодов на centos+drbd+xen+heartbeat с live миграцией виртуалок между нодами, очень даже положительный опыт.
    Из нюансов  - пара скриптов требовали модификации (wrapper for drbd, ктати интересно, как с этим делом в v.9?), и резервирование ресурсов для возможной миграции на нодах
     
  • 5.24, Xaionaro (ok), 12:15, 19/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Это все красиво только в теории.

    Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.), но оно при правильной настройке может вполне хорошо работать.

     
     
  • 6.26, Shodan (ok), 12:57, 19/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это все красиво только в теории.
    > Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
    > проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
    > но оно при правильной настройке может вполне хорошо работать.

    Работать на каких обьемах данных и на какой нагрузке?

     
     
  • 7.30, Xaionaro (ok), 06:46, 22/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Это все красиво только в теории.
    >> Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
    >> проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
    >> но оно при правильной настройке может вполне хорошо работать.
    > Работать на каких обьемах данных и на какой нагрузке?

    Смотря какое железо у вас имеется.

     
  • 6.27, Shodan (ok), 15:20, 19/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это все красиво только в теории.
    > Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
    > проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
    > но оно при правильной настройке может вполне хорошо работать.

    Сами себе противоречите

    "Я когда-то использовал OCFS2 поверх DRBD. Работает. Но интерконнект между серверами был слабый (1Gbps ethernet), и в результате многие операции с ФС шли очень медленно. Обычный svn cleanup в одном проекте занимал полчаса."

    Так работает или хорошо работает?

     
     
  • 7.29, Xaionaro (ok), 06:45, 22/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Это все красиво только в теории.
    >> Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
    >> проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
    >> но оно при правильной настройке может вполне хорошо работать.
    > Сами себе противоречите
    > "Я когда-то использовал OCFS2 поверх DRBD. Работает. Но интерконнект между серверами был
    > слабый (1Gbps ethernet), и в результате многие операции с ФС шли
    > очень медленно. Обычный svn cleanup в одном проекте занимал полчаса."
    > Так работает или хорошо работает?

    Для такого интерконнекта (1Gbps ethernet) работает хорошо (другими словами latency был высокий, поэтому лучше с данной архитектурой работать и не могло). Был бы Infiniband, было бы всё иначе.

    Вообще хватит вертеться уже. Просто признайте, что были не правы:

    > Это будет глобальный race condition.

     
  • 2.32, Ононим (?), 11:23, 22/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    экспортирую "блочные устройства" по iSCSI, затем собираю их в пул ZFS.

     
  • 2.33, vvi (??), 13:53, 18/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый
    > откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки.
    > То есть балансировщик. После повреждения одного с узлов, не только диск,
    > а может отказать мамка, проц, сетевая, другой берёт на себя полную
    > нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется
    > между работающими, исправными узлами.

    Я использовал primary-primary (1+1) с 8-й версией. Причём в коммерческом проекте - всё ок. drbd + ocfs2 + heartbeat. Можно было записать файл на ФС одного узла и тут же считать этот файл на другом узле. На ocfs2, помимо всего прочего, находится табличное пространство PostgreSQL. Данные доступны одновременно с обоих узлов даже если идёт длительная синхронизация.
    Единственная проблема возникала в таком случае: если вручную выключить оба узла, когда данные ещё не засинхронизировались (обычно такое происходит при пересборке кластера, при нормальном функционировании синхронизация происходит мгновенно), затем включить узел - приёмник данных синхронизации, а затем только секунд через 30 включить источник синхронизации, то происходил brain-splitting, что, в общем-то, логично.
    При разнице в несколько секунд проблема не повторяется. Реальные аварийные ситуации кластер отрабатывал отлично.

     

  • 1.22, pokalo (??), 11:35, 19/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    на каждой ноде по 5 дисков, обединенных последовательно с помощью LVM (типа RAID0) в одно устройство drbd (на всех нодах primary), поверх которого OCFS2. Почему то работает уже пару лет без вопросов.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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