После четырёх лет разработки увидел свет (http://www.linbit.com/en/n/news/564-drbd9-release) релиз распределенного реплицируемого блочного устройства DRBD 9.0 (http://www.linbit.com/en/p/products/drbd9), позволяющего реализовать подобие массива RAID-1, сформированного из объединённых по сети нескольких дисковых разделов разных машин (зеркалирование по сети). Система оформлена в виде модуля для ядра Linux и распространяется (http://oss.linbit.com/drbd/) под лицензией GPLv2.
DRBD может использоваться для объединения накопителей узлов кластера в единое отказоустойчивое хранилище. При использовании DRBD все операции с локальным диском отправляются на другие узлы и синхронизируются с дисками других машин. В случае выхода из строя одного узла, хранилище автоматически продолжит работу за счёт оставшихся узлов. При возобновлении доступности сбойного узла, все данные его состояние будет автоматически доведено до актуального вида.
В состав формирующего хранилище кластера может входить несколько десятков узлов, размещённых как в локальной сети, так и территориально разнесённых в разные центры обработки данных. Синхронизация в подобных разветвлённых хранилищах выполняется с использованием технологий mesh-сети (данные растекаются по цепочке от узла к узлу). Репликация узлов может производиться как в синхронном режиме, так и в асинхронном. Например, локально размещённые узлы могут применять синхронную репликацию, а для выноса на удалённое размещённые площадки может применяться асинхронная репликация с дополнительным сжатием и шифрованием трафика.
<center><a href="http://drbd.linbit.com/uploads/pics/overview_02.gif">... src="http://www.opennet.ru/opennews/pics_base/0_1434551311.gif" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>Основные новшества (http://git.drbd.org/gitweb.cgi?p=drbd-9.0.git;a=tag;h=refs/t... DRBD 9:
- Новая архитектура передачи данных, в которой используется абстрагированный транспортный уровень, позволяющий реализовать каналы связи не ограничивающиеся TCP, например, с использованием RDMA/Infiniband и SCTP.
- Интеграция RDMA (https://ru.wikipedia.org/wiki/%D0%A3%D0%... (Remote Direct Memory Access) для прямого доступа к оперативной памяти другого компьютера и поддержка сетевых карт Infiniband, позволяют добиться двухкратного увеличения интенсивности репликации с сокращением нагрузки на CPU на 50% по сравнению с транспортом поверх традиционной IP-сети;
- Расширенные возможности отказоустойчивости - хранилище теперь может быть реплицировано одновременно на 32 узла, размещённых в различных сетевых окружениях.
- Новый инструментарий для управления, позволяющий развернуть сложное реплицированное хранилище за считанные минуты. Инструментарий предоставляет API для автоматизации выполнения действий с DRBD и интеграции с внешними системами, такими как OpenStack, а также для создания на базе Linux альтернатив традиционным SAN.- Поддержка установки нескольких соединений к одному ресурсу, что позволяет создавать более эффективные и сложные схемы соединения узлов между собой.
- Автоматическая установка статуса узла в зависимости от активности. Например, узел помечается первичным при открытии блочного устройства на запись и вторичным - при прекращении работы с устройством всеми процессами.- Распространение обновлений в неблокирующем режиме, что позволило значительно увеличить производительность хранилища (в тестах более 400 тыс операций в секунду).- Поддержка двухфазных коммитов, позволяющих охватить косвенно связанные узлы во время установки нового соединения или при смене первичного узла;- Переработанная логика принятия решений о ресинхронизации в условиях наличия нескольких соединений или некачественной сетевой связи;
URL: http://www.linbit.com/en/n/news/564-drbd9-release
Новость: http://www.opennet.ru/opennews/art.shtml?num=42447
CEPH лучше, чем DRBD
у меня сейчас drbd в проде на одном "проекте" и ceph в тестинге в другом проекте. Я когда знакомился с ceph тоже думал "нафиг выкину drbd", но потом подумал и решил что для двух серверов ceph как то оверкил, все таки у них немного разное ЦА. Так что сравнивать "в тупую" неправильно.
>подобие массива RAID-1Стоп-стоп-стоп! Это тупое зеркало, но по сети? И объединив 100 машин по 1 байту, мы получим сверхнадёжный 1 байт? И ни битом больше?
Не-не-не! Пусть пилят и другие "подобия рейдов". Тем более, что базис уже готов...
DRBD заточен в основном на отказоустойчивые системы, поэтому не стоит так реагировать
С добрым утром.
Это не "тупое" зеркало, а довольно таки умное: например, при потере слейва и последующем подсоединении ресинхронизация проходит очень быстро, поскольку гоняются только измененившиеся блоки, отмеченные в битовой карте.
При этом DRBD дает возможность на халяву делать нормальное дублирование данных, а не делать вид, что дешевая дисковая полка от всего спасает.
> только измененившиеся блоки, отмеченные в битовой карте.А именно битовая карта - не в v8 ли, где только 2 копии? Для v9 с несколькими копиями там что? Несколько бит на блок? Я не смотрел и как обычно всё путаю? ... ... ...
>> только измененившиеся блоки, отмеченные в битовой карте.
> А именно битовая карта - не в v8 ли, где только 2
> копии? Для v9 с несколькими копиями там что? Несколько бит на
> блок? Я не смотрел и как обычно всё путаю? ...В бета-документахе на v9 по прежнему написано, что quick-sync bitmap по-парная. Так что их несколько наверное, если несколько пиров.
Благодаря этому простому зеркалу по сети, умелые люди добиваются не только резервирования дисков, но и всего сервера с питанием!Вполне хватает RAID-1 - простота, скорость и надёжность!
Это тоже самое что и gluster ?
> Это тоже самое что и gluster ?Нет. Это то же самое, что LVM. </шютка>
Товарищ вы путаете ФС и блочное устройство. Кстати кто какую ФС поверх DRBD использует?
> Товарищ вы путаете ФС и блочное устройство. Кстати кто какую ФС поверх
> DRBD использует?ext4 для тех кто боится и первый раз.
GFS можно добиться режима работы с одновременной записью на оба диска.
>> Товарищ вы путаете ФС и блочное устройство. Кстати кто какую ФС поверх
>> DRBD использует?
> ext4 для тех кто боится и первый раз.
> GFS можно добиться режима работы с одновременной записью на оба диска.GFS какой то глючный. и много хочет.
> Кстати кто какую ФС поверх DRBD использует?Я когда-то использовал OCFS2 поверх DRBD. Работает. Но интерконнект между серверами был слабый (1Gbps ethernet), и в результате многие операции с ФС шли очень медленно. Обычный svn cleanup в одном проекте занимал полчаса.
[offtop]
Если действительно интересно обменяться опытом по данной теме, то рекомендую поехать на LVEE на следующей неделе, и я могу подробно пересказать свой опыт [1].[1] https://lvee.org/uploads/image_upload/file/337/winter_2014_1...
[/offtop]
Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки. То есть балансировщик. После повреждения одного с узлов, не только диск, а может отказать мамка, проц, сетевая, другой берёт на себя полную нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется между работающими, исправными узлами.
PS: от наличия резервного копирования админов не освобождает, особо в случае режима active-active
Да, наладить резервное копирование админов, тоже бы не помешало.
И актуализирование ими документации на всё, что они наворотили в реальном времени путем выписывания магического пенделя ;-)
> И актуализирование ими документации на всё, что они наворотили в реальном времени
> путем выписывания магического пенделя ;-)Наше поколение советских людей будет жить при Полной Документации. Ура, товарищи!!
Так на картинке active - active :)
> Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый
> откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки.
> То есть балансировщик. После повреждения одного с узлов, не только диск,
> а может отказать мамка, проц, сетевая, другой берёт на себя полную
> нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется
> между работающими, исправными узлами.Это будет глобальный race condition.
>> Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый
>> откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки.
>> То есть балансировщик. После повреждения одного с узлов, не только диск,
>> а может отказать мамка, проц, сетевая, другой берёт на себя полную
>> нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется
>> между работающими, исправными узлами.
> Это будет глобальный race condition.DLM [1], OCFS2 [2].
[1] https://en.wikipedia.org/wiki/Distributed_lock_manager
[2] https://ru.wikipedia.org/wiki/OCFS
Это все красиво только в теории.
8 лет проработало -> кластер из 2 нодов на centos+drbd+xen+heartbeat с live миграцией виртуалок между нодами, очень даже положительный опыт.
Из нюансов - пара скриптов требовали модификации (wrapper for drbd, ктати интересно, как с этим делом в v.9?), и резервирование ресурсов для возможной миграции на нодах
> Это все красиво только в теории.Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.), но оно при правильной настройке может вполне хорошо работать.
>> Это все красиво только в теории.
> Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
> проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
> но оно при правильной настройке может вполне хорошо работать.Работать на каких обьемах данных и на какой нагрузке?
>>> Это все красиво только в теории.
>> Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
>> проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
>> но оно при правильной настройке может вполне хорошо работать.
> Работать на каких обьемах данных и на какой нагрузке?Смотря какое железо у вас имеется.
>> Это все красиво только в теории.
> Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
> проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
> но оно при правильной настройке может вполне хорошо работать.Сами себе противоречите
"Я когда-то использовал OCFS2 поверх DRBD. Работает. Но интерконнект между серверами был слабый (1Gbps ethernet), и в результате многие операции с ФС шли очень медленно. Обычный svn cleanup в одном проекте занимал полчаса."
Так работает или хорошо работает?
>>> Это все красиво только в теории.
>> Вы просто плохо знакомы с вопросом, как мне кажется. Да, есть серьёзные
>> проблемы с различными экзотическими ФС (ceph, lustre, ocfs, gfs и т.п.),
>> но оно при правильной настройке может вполне хорошо работать.
> Сами себе противоречите
> "Я когда-то использовал OCFS2 поверх DRBD. Работает. Но интерконнект между серверами был
> слабый (1Gbps ethernet), и в результате многие операции с ФС шли
> очень медленно. Обычный svn cleanup в одном проекте занимал полчаса."
> Так работает или хорошо работает?Для такого интерконнекта (1Gbps ethernet) работает хорошо (другими словами latency был высокий, поэтому лучше с данной архитектурой работать и не могло). Был бы Infiniband, было бы всё иначе.
Вообще хватит вертеться уже. Просто признайте, что были не правы:
> Это будет глобальный race condition.
экспортирую "блочные устройства" по iSCSI, затем собираю их в пул ZFS.
> Интересны конфигурации кластеров active-activ когда второй узел не тупо ждёт пока первый
> откажет, а работает тоже, В РЕЖИМЕ ЗАПИСИ, и принимает половину нагрузки.
> То есть балансировщик. После повреждения одного с узлов, не только диск,
> а может отказать мамка, проц, сетевая, другой берёт на себя полную
> нагрузку. При присоединении отремонтированной ноды и синхронизации, нагрузка опять распределяется
> между работающими, исправными узлами.Я использовал primary-primary (1+1) с 8-й версией. Причём в коммерческом проекте - всё ок. drbd + ocfs2 + heartbeat. Можно было записать файл на ФС одного узла и тут же считать этот файл на другом узле. На ocfs2, помимо всего прочего, находится табличное пространство PostgreSQL. Данные доступны одновременно с обоих узлов даже если идёт длительная синхронизация.
Единственная проблема возникала в таком случае: если вручную выключить оба узла, когда данные ещё не засинхронизировались (обычно такое происходит при пересборке кластера, при нормальном функционировании синхронизация происходит мгновенно), затем включить узел - приёмник данных синхронизации, а затем только секунд через 30 включить источник синхронизации, то происходил brain-splitting, что, в общем-то, логично.
При разнице в несколько секунд проблема не повторяется. Реальные аварийные ситуации кластер отрабатывал отлично.
на каждой ноде по 5 дисков, обединенных последовательно с помощью LVM (типа RAID0) в одно устройство drbd (на всех нодах primary), поверх которого OCFS2. Почему то работает уже пару лет без вопросов.
