|
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.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 - простота, скорость и надёжность!
| |
|
|
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.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
| |
|
|
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. Почему то работает уже пару лет без вопросов.
| |
|