Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
До недавнего времени в drbd была замечательная багофича — если запись на одной из нод не завершается (к этому времени в linux-raid был другой баг, приводящий к дедлоку при записи во время ресинка), то вторая нода так же не завершает запись.
Багофичу (после скандала с массовыми отказами из-за глюки в рейде) поправили, а осадочек остался.
DRBD крайне неустойчивое решение — partitioning оно не переживает адекватно. (Устойчивое решение должно использовать кворум, а сделать устойчивый кворум из 2 нод невозможно).
Второй момент — drbd создаёт не очень адеватную нагрузку на метаданные.
Третий момент, показывать результаты dd без опций iflag/oflag=direct,dsync — мерять производительность кеша, а не IO.
Четвёртый момент — если бондинг делается на оптике, то можно поймать ситуацию, когда голова считает, что у неё всё хорошо, а коммутатор её уже не видит.
Багофичу (после скандала с массовыми отказами из-за глюки в рейде) поправили, а осадочек остался.
DRBD крайне неустойчивое решение — partitioning оно не переживает адекватно. (Устойчивое решение должно использовать кворум, а сделать устойчивый кворум из 2 нод невозможно).
Второй момент — drbd создаёт не очень адеватную нагрузку на метаданные.
Третий момент, показывать результаты dd без опций iflag/oflag=direct,dsync — мерять производительность кеша, а не IO.
Четвёртый момент — если бондинг делается на оптике, то можно поймать ситуацию, когда голова считает, что у неё всё хорошо, а коммутатор её уже не видит.
1. Я mdraid в продакшене не использую особо, только дома, так что видать чаша сия меня обошла. Баги то они везде бывают, тут вопросов нет, другое дело, что тобы они вылезли зачастую нужно чтобы звезды сошлись правильным образом. У меня система, подобная описаной в статье, работает уже пару лет под 24х7 нагрузкой (пусть и не стрессовой) — всё ровно.
2. Зачем ему partitioning в режиме single-primary? DRBD вообще до последнего времени не подразумевало более двух нод, так что кворум в принципе не был возможен. Да и теперь, когда появилась возможность строить трехнодовую репликацию, по сути ничего не изменилось. Сам по себе DRBD не будет же переводить ресурсы в primary режим при потере связи и прочих бедах, это забота менеджера кластера, а там вопрос split-brain решается избыточностью heartbeat-каналов, этого в 99.9% достаточно.
3. Тут ничего не скажу, не мерял этот вопрос. В любом случае, если проблема встает, то метаданные можно вынести на отдельный массив из SSD.
4. Насчет dd — тут в общем и целом да, только вот в случае с dm-crypt ситуация получается странная — скорость с oflag=direct получается ниже, а с iflag=direct (при, соответственно, чтении) — выше. Тут, я думаю, дело в том, что dm-crypt берёт блоки из кеша пачкой и разбрасывает их по worker-ам на разных ядрах. А при обходе кеша он этого делать не может, поэтому получается в разы медленнее.
5. Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
2. Зачем ему partitioning в режиме single-primary? DRBD вообще до последнего времени не подразумевало более двух нод, так что кворум в принципе не был возможен. Да и теперь, когда появилась возможность строить трехнодовую репликацию, по сути ничего не изменилось. Сам по себе DRBD не будет же переводить ресурсы в primary режим при потере связи и прочих бедах, это забота менеджера кластера, а там вопрос split-brain решается избыточностью heartbeat-каналов, этого в 99.9% достаточно.
3. Тут ничего не скажу, не мерял этот вопрос. В любом случае, если проблема встает, то метаданные можно вынести на отдельный массив из SSD.
4. Насчет dd — тут в общем и целом да, только вот в случае с dm-crypt ситуация получается странная — скорость с oflag=direct получается ниже, а с iflag=direct (при, соответственно, чтении) — выше. Тут, я думаю, дело в том, что dm-crypt берёт блоки из кеша пачкой и разбрасывает их по worker-ам на разных ядрах. А при обходе кеша он этого делать не может, поэтому получается в разы медленнее.
5. Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
Можно поподробнее, это какая-то настройка бондинга или самописный скрипт (с софтовыми бондингами опыта почти нет)?
Использовали аналогичную конструкцию, но в итоге отказались от нее. Перешли на Ceph + Proxmox, хоть и говорят что Ceph сырой, но вполне нормально ворочается, и показывает вполне адекватную скорость. Единственный нюанс — это то что кол-во серверов под CEPH должно быть больше как минимум на один, чем серверов Proxmox, иначе при хорошей нагрузке всё может развалиться.
При использовании DRBD в режиме master-master, ставить режим работы B чревато негативными последствиями, не раз ловили ситуацию когда из за одновременной записи, на разные LUN, на разные сервера — DRBD уходил в split-brain.
Использование в режиме master-slave считаю расточительным!
При использовании DRBD в режиме master-master, ставить режим работы B чревато негативными последствиями, не раз ловили ситуацию когда из за одновременной записи, на разные LUN, на разные сервера — DRBD уходил в split-brain.
Использование в режиме master-slave считаю расточительным!
Я режим master-master не использую принципиально — производительности single-master мне более чем достаточно, а сохранность данных у меня на первом месте.
По поводу протокола B и dual-primary в доках DRBD чётко написано:
По поводу протокола B и dual-primary в доках DRBD чётко написано:
Dual-primary mode requires that the resource is configured to replicate synchronously (protocol C).
Были ли пробы аналогичные на FreeBSD?
Нет.
И хотя я начинал знакомство с UNIX-like системами именно с FreeBSD, сейчас я не вижу смысла его использовать в большинстве проектов.
Причин много, например — существенно меньший выбор проектов, разрабатываемых параллельно ядру или включенных в него.
Так, есть аналог(скорее даже клон) DRBD под названием HAST, но он, судя по всему, работает вообще в пространстве пользователя и вряд-ли сможет тягаться по скорости (если что — бенчмарков не видел и не делал). Да и вообще возможностей у него относительно DRBD мало крайне: нет каких-либо контрольных сумм, только один протокол синхронизации (синхронный), ну и так далее.
C iSCSI и FC таргетами там, судя по всему, тоже выбор не велик, только то, что в ядре. В Linux же есть LIO (который уже в ядре, поддерживает уже даже 16Гбит FC, FCoE и вообще много чего), SCST (тоже много протоколов), STGT и еще много всякого — есть из чего выбрать.
Ну и поддержка производителей железа идет в первую очередь линуксу, а BSD уже во вторую очередь.
Так что нет, для себя смысла не вижу.
И хотя я начинал знакомство с UNIX-like системами именно с FreeBSD, сейчас я не вижу смысла его использовать в большинстве проектов.
Причин много, например — существенно меньший выбор проектов, разрабатываемых параллельно ядру или включенных в него.
Так, есть аналог(скорее даже клон) DRBD под названием HAST, но он, судя по всему, работает вообще в пространстве пользователя и вряд-ли сможет тягаться по скорости (если что — бенчмарков не видел и не делал). Да и вообще возможностей у него относительно DRBD мало крайне: нет каких-либо контрольных сумм, только один протокол синхронизации (синхронный), ну и так далее.
C iSCSI и FC таргетами там, судя по всему, тоже выбор не велик, только то, что в ядре. В Linux же есть LIO (который уже в ядре, поддерживает уже даже 16Гбит FC, FCoE и вообще много чего), SCST (тоже много протоколов), STGT и еще много всякого — есть из чего выбрать.
Ну и поддержка производителей железа идет в первую очередь линуксу, а BSD уже во вторую очередь.
Так что нет, для себя смысла не вижу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание надёжного iSCSI-хранилища на Linux, часть 1