Обсуждение статьи тематического каталога: Отказоустойчивые файловые хранилища на основе DRBD (drbd disk storage linux raid mdadm iscsi samba heartbeat)Ссылка на текст статьи: http://www.opennet.ru/base/sys/ha_drbl_storage.txt.html
Спасибо, Петр!
Я как раз рисовал схему такой системы, а тут - готовая статья с примерами.
Репликация происходит в пределах одной машины ?
Нет. Реплицируется на 2
Статья хорошая. Но есть моменты которые неприемлемы, а именно в пакетных дистрах ставить из исходников программы нельзя. Если и нужно что-либо поставить из исходников, то имеет смысл скомпилировать пакет, а затем его и устанавливать штатными средствами системы. Таким образом не нарушится целостность системы.
>Статья хорошая. Но есть моменты которые неприемлемы, а именно в пакетных дистрах
>ставить из исходников программы нельзя. Если и нужно что-либо поставить из
>исходников, то имеет смысл скомпилировать пакет, а затем его и
>устанавливать штатными средствами системы. Таким образом не нарушится целостность системы.Не нуди, а напиши статью для тех кому это нужно.
>Статья хорошая. Но есть моменты которые неприемлемы, а именно в пакетных дистрах
>ставить из исходников программы нельзя. Если и нужно что-либо поставить из
>исходников, то имеет смысл скомпилировать пакет, а затем его и
>устанавливать штатными средствами системы. Таким образом не нарушится целостность системы.Не нуди, а напиши статью для тех кому это нужно.
хорошо написано
по мелочи - есть сомнение, что диски с разной геометрией корректно обработаются sfdisk ом
а т.к. при вылете винта вполне вероятно, что приобретаться будет винт другой геометрией, возможны накладки. В этом случае придется разбивать новый диск руками, причем разделы поблочно должны быть не меньше существующего (для raid1, например)
кстати, возможность гибкого использования винтов с разной геометрией - большой плюс софтверного массива
>кстати, возможность гибкого использования винтов с разной геометрией - большой плюс софтверного
>массиваА кто-нибудь может ответить в чем плюс создания RAID из уже размеченных разделов, вместо того чтобы создать RAID на диск целиком или уже в нем разбивать разделы ? То что можно разные типы RAID на одном диске и RAID из дисков разного размера это понятно. Но встречал много утверждений что RAID из разделов в mdadm надежнее. Осмысленно никто не мог объяснить почему.
>А кто-нибудь может ответить в чем плюс создания RAID из уже размеченных
>разделов, вместо того чтобы создать RAID на диск целиком или уже
>в нем разбивать разделы ? То что можно разные типы RAID
>на одном диске и RAID из дисков разного размера это понятно.
>Но встречал много утверждений что RAID из разделов в mdadm надежнее.
>Осмысленно никто не мог объяснить почему.Смысл в том, что кто-то где-то когда-то может, не найдя на таком диске таблицу разделов, её создать. Именно по этому даже новый формат таблицы разбиения GPT включает в себя староодную таблицу, в которой записано, что весь диск выделен.
- я бы не стал говорить, что софтверный RAID надежнее
- он удобнее и нагляднее в администрировании - это да, и за счет этого "сквозная" надежность администратор-железо-технология выше
- однако для серьёзных решений правильнее выбирать аппаратные массивы, но это серьёзные уже промышленные системы. Если говорить об опыте - на определенных боевых задачах мы используем софтверные решения на linux или Solaris, для других задач техника потяжелее - массивы infortrend и Hitachi
- опять же цена вопроса тоже важна ...
пардон - не о том написал
по вопросу - навскидку только удобство поддержки и наглядность. Например при выходе из строя одного из подзеркал удобнее работать только с этим зеркалом, не путаясь с зависимостями жестких дисков и прочих массивов
Protocol C в конфиге drbd гарантирует очень большое падение производительности, используя Protocol B - практически не теряещь в стабильности и падение производительности не столь катастрофично
Падения производительности я не заметил. Зато с протоколом C, когда сначала данные пишутся на ведомый узел, а потом клиент получает отмашку "запись окончена" я уверен, что данные одинаковые.
Вспоминаем, что нам говорили "The new table will be used at the next reboot."
ps02:~ # rebootВместо этого можно сделать partprobe, тогда перезагрузка не понадобится
Спасибо, это ценное дополнение.
Мм. Эт всё конечно здорово но много минусов. Во первых это не Active/Active а Active/Passive, тоесть одна машина будет простаивать, ну да ладно, для этого придумали распределённые ФС.Такой вариант в принципе вполне сгодился бы для общего хранилища. Дейстительно - сервисы с помощью HeardBeart запустятся на резервном хосте,
НО! в статье не описано как сделать чтобы клиентские хосты которые собственно и использует диски через iscsi и samba будут переключаться.
К примеру все хосты настроены на использование iscsi и samba с ps02. Который неожиданно упал. Всё запустилось на ps01. Но хосты по прежнему будут искать ps02. И тогда не понятен смысл всего шаманства. Получаеться какой то удалённый бэкап в реальном времени, а нафиг он нужен тоже не понятно, т.к. от человеческого фактора не зашишает как это делает обычных бэкап, а руками всё переключать придёться.
А воопще класно. Но самые интересные вещи как всегда за кадром...
Автоматическая смена IP, действительно упущена, но возможна: нужно добавить общий IP в haresources. С "простаиванием" - тоже проблема решаемая: для DRBD есть режим "Dual primary", естественно работает только с GFS, OCFS ...
Вы невнимательно читаете/etc/ha.d/haresources
ps02 drbddisk::r0 192.168.1.40/23 ...
>Вы невнимательно читаете
>
>/etc/ha.d/haresources
>
>
> ps02 drbddisk::r0 192.168.1.40/23 ...Извиняюсь...
Не правильно. Среди общих ресурсов кластера есть так-же IP адрес 192.168.1.40, клиенты будут подключатся по нему. В случае падения ведущего узла этот IP поднимет резервный узел.