Просветите по raid/lvm

gard	# 10 лет, 8 месяцев назад
Темы: 66 Сообщения: 1167 Участник с: 15 декабря 2009	Привет всем! Сегодня экспериментировал. Поставил арч на массив, если подробно то - было 2 диска, старые максторы 80гб - сделал на них по 2 раздела, 100М и 75000М - собрал массив raid1 из первых разделов каждого диска, обозвал /dev/md0 (100M с –metadata=0.90) - собрал массив raid0 из вторых разделов каждого диска, обозвал /dev/md1 (75000M + 75000M) - создал lvm-группу из физических томов, точнее уже из логического /dev/md1, обозвал mainVg (группа поверх raid0) - создал 2 логических тома lvm, lvswap и lvroot в вышесозданной группе - приступил к установке Арча, под /boot выделил /dev/md0, под swap выделил lvswap, под / выделил lvroot - поправил mkinitcpio.conf, добавив в модули “dm-raid” и в хуки “mdadm lvm2” после udev, поставил grub на каждый диск (sda, sdb) - поставился, протестировал, скорость массива в 2 раза выше, в “начале” массива 160Мб/с на линейном чтении против 80Мб/с отдельного диска из этого же массива. В общем понравилось. Но вот все таки есть кое какие вопросы, которые я немного недопонимаю. После сборки массива, во время установки Арча, когда дело доходит до правки конфигов, в /mnt подмонтируется /mnt/etc будущей системы, я в это время делал: mdadm --examine --scan > /mnt/etc/mdadm.conf чтобы сохранить конфигурацию массива для будущей загрузки системы, ведь в /boot/grub/menu.lst корень указывал на lvroot, который находился в lvm-группе mainVg, расположившейся поверх raid0 /dev/md1. Кроме того в mdadm.conf пришлось прописать HOMEHOST myhost Уж не знаю как оно связано, но если не указать тут имя хоста (которое и в rc.conf и в hosts), то после перезагрузки системы мы получим массивы типа /dev/md125, /dev/md126 или 127. Наверное это какой то баг, встречается мне не первый раз. Прописывание имени хоста спасает, почему я незнаю =). Теперь собственно ближе к вопросам. Как я понимаю, можно при создании разделов указать тип раздела linux raid autodetect. Я этого в общем то не делал. По сути при загрузке и обработке хуков после udev система должна загрузиться с lvroot, который расположился поверх md1. Каким образом здесь может прочитаться /etc/mdadm.conf, если для его чтения нужно собрать массив и инициализировать lvm-группу и тома? Бывает, что в /boot/grub/menu.lst указывается расположение корня на массиве к примеру так root=/dev/md1 md=1,/dev/sda2,/dev/sdb2 Я такого не делал, у меня был указан пусть именно к lvm-тому lvroot, как то так: /dev/mapper/mainVg-lvroot (могу ошибиться, не помню точно формат именования). Вот и получается что курица вперед яйца. Если предположить, что система с помощью отработки хука mdadm сама “автоопределяет” массивы без конфига /etc/mdadm.conf и то же самое делает lvm, то как это происходит? За это отвечают суперблоки массива? Как я понял суперблок массива это место служебной информации о массиве на диске, что-то вроде типа раздела в таблице разделов? Но опять таки, если не происходит чтения файла /etc/mdadm.conf, в котором указан хостнейм, то почему массив собирается правильно, а не md. В общем я просто не могу понять порядок сего магического действа. Что происходит при загрузке, что и откуда читается, как определяется и инициализируется массив, откуда берется информация о том, как это сделать. То же самое с lvm, тоже какой то “autodetect” видимо. Читается ли при сборке массива вообще /etc/mdadm.conf и как он может читаться, если для его чтения надо сначала собрать массив, инициализировав его и lvm поверх него? ps: простите, если много написал, знаю, что вопросы банальны, но не дайте запутаться, внесите ясность. =)

# 10 лет, 8 месяцев назад

Сообщения: 1167

Участник с: 15 декабря 2009

Привет всем!
Сегодня экспериментировал. Поставил арч на массив, если подробно то
- было 2 диска, старые максторы 80гб
- сделал на них по 2 раздела, 100М и 75000М
- собрал массив raid1 из первых разделов каждого диска, обозвал /dev/md0 (100M с –metadata=0.90)
- собрал массив raid0 из вторых разделов каждого диска, обозвал /dev/md1 (75000M + 75000M)
- создал lvm-группу из физических томов, точнее уже из логического /dev/md1, обозвал mainVg (группа поверх raid0)
- создал 2 логических тома lvm, lvswap и lvroot в вышесозданной группе
- приступил к установке Арча, под /boot выделил /dev/md0, под swap выделил lvswap, под / выделил lvroot
- поправил mkinitcpio.conf, добавив в модули “dm-raid” и в хуки “mdadm lvm2” после udev, поставил grub на каждый диск (sda, sdb)
- поставился, протестировал, скорость массива в 2 раза выше, в “начале” массива 160Мб/с на линейном чтении против 80Мб/с отдельного диска из этого же массива. В общем понравилось.

Но вот все таки есть кое какие вопросы, которые я немного недопонимаю. После сборки массива, во время установки Арча, когда дело доходит до правки конфигов, в /mnt подмонтируется /mnt/etc будущей системы, я в это время делал:

mdadm --examine --scan > /mnt/etc/mdadm.conf

чтобы сохранить конфигурацию массива для будущей загрузки системы, ведь в /boot/grub/menu.lst корень указывал на lvroot, который находился в lvm-группе mainVg, расположившейся поверх raid0 /dev/md1. Кроме того в mdadm.conf пришлось прописать

HOMEHOST myhost

Уж не знаю как оно связано, но если не указать тут имя хоста (которое и в rc.conf и в hosts), то после перезагрузки системы мы получим массивы типа /dev/md125, /dev/md126 или 127. Наверное это какой то баг, встречается мне не первый раз. Прописывание имени хоста спасает, почему я незнаю =).

Теперь собственно ближе к вопросам. Как я понимаю, можно при создании разделов указать тип раздела linux raid autodetect. Я этого в общем то не делал. По сути при загрузке и обработке хуков после udev система должна загрузиться с lvroot, который расположился поверх md1. Каким образом здесь может прочитаться /etc/mdadm.conf, если для его чтения нужно собрать массив и инициализировать lvm-группу и тома? Бывает, что в /boot/grub/menu.lst указывается расположение корня на массиве к примеру так

root=/dev/md1 md=1,/dev/sda2,/dev/sdb2

Я такого не делал, у меня был указан пусть именно к lvm-тому lvroot, как то так: /dev/mapper/mainVg-lvroot (могу ошибиться, не помню точно формат именования). Вот и получается что курица вперед яйца. Если предположить, что система с помощью отработки хука mdadm сама “автоопределяет” массивы без конфига /etc/mdadm.conf и то же самое делает lvm, то как это происходит? За это отвечают суперблоки массива? Как я понял суперблок массива это место служебной информации о массиве на диске, что-то вроде типа раздела в таблице разделов? Но опять таки, если не происходит чтения файла /etc/mdadm.conf, в котором указан хостнейм, то почему массив собирается правильно, а не md. В общем я просто не могу понять порядок сего магического действа. Что происходит при загрузке, что и откуда читается, как определяется и инициализируется массив, откуда берется информация о том, как это сделать. То же самое с lvm, тоже какой то “autodetect” видимо. Читается ли при сборке массива вообще /etc/mdadm.conf и как он может читаться, если для его чтения надо сначала собрать массив, инициализировав его и lvm поверх него?

ps: простите, если много написал, знаю, что вопросы банальны, но не дайте запутаться, внесите ясность. =)

gard	# 10 лет, 8 месяцев назад
Темы: 66 Сообщения: 1167 Участник с: 15 декабря 2009	Сам же отвечаю на свой вопрос, докопался до истины кажется, цитирую: Массивы всех уровней помимо блоков данных и суперблоков с контрольными суммами могут также содержать специальный суперблок (persistent superblock), который располагается в начале всех дисков массива и содержит информацию о конфигурации MD-устройства. Наличие отдельного суперблока позволяет ядру операционной системы получать информацию о конфигурации устройства RAID прямо с дисков, а не из конфигурационного файла, что может быть полезным, если файл по каким-то причинам перестанет быть доступным. Кроме того, наличие отдельного суперблока — необходимое условие автоопределения RAID-устройств при загрузке системы. Вот как оно автоматически собирает массив при запуске.. надо будет еще поэксперементировать, не пойму почему тогда md присваиваются не те имена (125-127), если конфиг в обоих случаях изначально недоступен..

gard

# 10 лет, 8 месяцев назад

Темы: 66

Сообщения: 1167

Участник с: 15 декабря 2009

Сам же отвечаю на свой вопрос, докопался до истины кажется, цитирую:

Массивы всех уровней помимо блоков данных и суперблоков с контрольными суммами могут также содержать специальный суперблок (persistent superblock), который располагается в начале всех дисков массива и содержит информацию о конфигурации MD-устройства. Наличие отдельного суперблока позволяет ядру операционной системы получать информацию о конфигурации устройства RAID прямо с дисков, а не из конфигурационного файла, что может быть полезным, если файл по каким-то причинам перестанет быть доступным. Кроме того, наличие отдельного суперблока — необходимое условие автоопределения RAID-устройств при загрузке системы.

Вот как оно автоматически собирает массив при запуске.. надо будет еще поэксперементировать, не пойму почему тогда md присваиваются не те имена (125-127), если конфиг в обоих случаях изначально недоступен..

gard	# 10 лет, 8 месяцев назад
Темы: 66 Сообщения: 1167 Участник с: 15 декабря 2009	В общем решил написать сюда еще некоторые свои наблюдения. Суперблок, описывающий конфигурацию массива для автодетектирования находится не в начале диска, а в конце, кто-то говорит, что в “конце, а может быть и в середине”. Но не суть, в общем он там есть и можно пользоваться преимуществами. При создании массива, к примеру /dev/md0 ему присваивается минорный номер 0, посмотреть это можно в выводе mdadm -Q- D /dev/md0, подробнее тут: http://gentoo.theserverside.ru/book/ar68s14.html Интересно несколько другое, что за баг с превращением в md125-127. Итак, я взял диск с убунтой, хотел поставить тестово ее, но не вышло, она не хочет ставиться на рейд или lvm, при выборе мест монтирования и ФС не доступен пункт “изменить”, где можно указать точку монтирования и тип ФС в инсталляторе, он понимает только физ. диски, что собственно говоря странно, арч-инсталлятор понимает все блочные устройства, в т.ч. device-mapper, на котором и основаны устройства с mdadm. Дак вот, создал под убунтой 2 массива: /dev/md0 и /dev/md1. Перед этим как надо, то есть тип диска был указан как raid autodetect. После этого загрузился с archBootCD(dualCore) и продолжил эксперименты. Что примечательно массивы md0 и md1 стали под арчем md126 и md127, посмотрел вывод для каждого из них, к примеру mdadm -Q -D /dev/md126 и их минорные номера были 126 и 127, как могли произойти изменения с суперблоках я незнаю. Исправил суперблоки командой: madam -S /dev/md0 mdadm --assemble --update=super-minor /dev/md0 /dev/sda1 /dev/sdb1 Это исправило суперблок 126 для md0 на 0, как оно и должно быть. Кстати, если вы не можете переформатировать диски, которые были в массиве и наблюдаете странные вещи, то вам нужно очистить суперблоки, чтобы массивы автоматически не собирались. Сначала нужно их состановить: mdadm -S /dev/md0 а потом очистить суперблоки: madadm –zero-superblock /dev/md0, после этого информация о массивах из суперблоков будет удалена полностью и можно делать с дисками что угодно. Дак вот, я сменил минорные номера на 0 и 1 для своих массивов и начал установку, установщик не нашел томов с lvm, ну что же, lvm были удалены и нарезаны заново. После этого установщик их обнаружил, хотя система в общем то видела старые тома lvm, но установщик не хотел их обнаруживать. Далее поставился и перезагрузился.. Каково же было мое удивление, когда система запустилась, но массивы оказались опять таки /dev/md126 и /dev/md127. Тем не менее все работало, почему так - я не знаю. Очень тонкий момент в том, что если вы используете lvm с mdadm, то lvm группа разделов привязана к md-устройствам, это в принципе понятно, но об этом можно забыть. Почему меняется минорный номер.. непонятно, но lvm группа как и была на /dev/md126 и прекрасно заработала. Это видимо какой то баг не иначе. Как говорится “внимательный читатель” уже понял, что /dev/mdadm.conf ни разу не был упомянут. Да все верно, этот конфиг в этот раз я вообще не трогал, в нем просто нет необходимости, если используются суперблоки и тип раздела “raid autodetect”. Ядро с хуком mdadm автоматически находит и объединяет разделы raid, считывая информацию с суперблоков этих разделов. Это по настоящему круто. =) По другому в принципе и не может быть, если хранить конфиг массива отдельно и если он жизненно необходим для сборки массива, то массив не собрать, не прочитав конфиг, и если конфиг не прочитать, не собрав массив, то все плохо. А тут все работает. Оказывается raid не так уж далек он народа, с учетом офигенного прироста скорости х2 на raid0 из двух томов или х3 из 3х томов, такой вот рэйд под систему и файлы будет очень крут, для домашних типовых задач самое то, все что потеряется при выходе из строя диска (все потеряется) не так уж страшно. Можно хранить отдельную важную информацию на отдельном диске. Бывает, советуют часть диска выделять под raid0, часть под raid5 к примеру, или raid1. Берем 3 диска, делаем на них 3 массива по 3 рездела дисков, raid1 под /boot, raid0 под корень, raid5 под важные файлы, по сути должно получиться быстро и красиво. =) Хотя если подумать, то все мы экстремальщики, у всех система работает с 1го диска и не жужжит, если диск умрет, то финиш. ))) Так что между просто диском и raid0 не такая уж большая разница. Ну в общем я кажется изложил свои наблюдения, простите, если в тексте есть ошибки, я просто немного под шафе. ))

gard

# 10 лет, 8 месяцев назад

Темы: 66

Сообщения: 1167

Участник с: 15 декабря 2009

В общем решил написать сюда еще некоторые свои наблюдения. Суперблок, описывающий конфигурацию массива для автодетектирования находится не в начале диска, а в конце, кто-то говорит, что в “конце, а может быть и в середине”. Но не суть, в общем он там есть и можно пользоваться преимуществами. При создании массива, к примеру /dev/md0 ему присваивается минорный номер 0, посмотреть это можно в выводе mdadm -Q- D /dev/md0, подробнее тут: http://gentoo.theserverside.ru/book/ar68s14.html

Интересно несколько другое, что за баг с превращением в md125-127. Итак, я взял диск с убунтой, хотел поставить тестово ее, но не вышло, она не хочет ставиться на рейд или lvm, при выборе мест монтирования и ФС не доступен пункт “изменить”, где можно указать точку монтирования и тип ФС в инсталляторе, он понимает только физ. диски, что собственно говоря странно, арч-инсталлятор понимает все блочные устройства, в т.ч. device-mapper, на котором и основаны устройства с mdadm. Дак вот, создал под убунтой 2 массива: /dev/md0 и /dev/md1. Перед этим как надо, то есть тип диска был указан как raid autodetect. После этого загрузился с archBootCD(dualCore) и продолжил эксперименты. Что примечательно массивы md0 и md1 стали под арчем md126 и md127, посмотрел вывод для каждого из них, к примеру mdadm -Q -D /dev/md126 и их минорные номера были 126 и 127, как могли произойти изменения с суперблоках я незнаю. Исправил суперблоки командой:

madam -S /dev/md0
mdadm --assemble --update=super-minor /dev/md0 /dev/sda1 /dev/sdb1

Это исправило суперблок 126 для md0 на 0, как оно и должно быть. Кстати, если вы не можете переформатировать диски, которые были в массиве и наблюдаете странные вещи, то вам нужно очистить суперблоки, чтобы массивы автоматически не собирались. Сначала нужно их состановить: mdadm -S /dev/md0 а потом очистить суперблоки: madadm –zero-superblock /dev/md0, после этого информация о массивах из суперблоков будет удалена полностью и можно делать с дисками что угодно.

Дак вот, я сменил минорные номера на 0 и 1 для своих массивов и начал установку, установщик не нашел томов с lvm, ну что же, lvm были удалены и нарезаны заново. После этого установщик их обнаружил, хотя система в общем то видела старые тома lvm, но установщик не хотел их обнаруживать. Далее поставился и перезагрузился.. Каково же было мое удивление, когда система запустилась, но массивы оказались опять таки /dev/md126 и /dev/md127. Тем не менее все работало, почему так - я не знаю. Очень тонкий момент в том, что если вы используете lvm с mdadm, то lvm группа разделов привязана к md-устройствам, это в принципе понятно, но об этом можно забыть. Почему меняется минорный номер.. непонятно, но lvm группа как и была на /dev/md126 и прекрасно заработала. Это видимо какой то баг не иначе.

Как говорится “внимательный читатель” уже понял, что /dev/mdadm.conf ни разу не был упомянут. Да все верно, этот конфиг в этот раз я вообще не трогал, в нем просто нет необходимости, если используются суперблоки и тип раздела “raid autodetect”. Ядро с хуком mdadm автоматически находит и объединяет разделы raid, считывая информацию с суперблоков этих разделов. Это по настоящему круто. =) По другому в принципе и не может быть, если хранить конфиг массива отдельно и если он жизненно необходим для сборки массива, то массив не собрать, не прочитав конфиг, и если конфиг не прочитать, не собрав массив, то все плохо. А тут все работает.

Оказывается raid не так уж далек он народа, с учетом офигенного прироста скорости х2 на raid0 из двух томов или х3 из 3х томов, такой вот рэйд под систему и файлы будет очень крут, для домашних типовых задач самое то, все что потеряется при выходе из строя диска (все потеряется) не так уж страшно. Можно хранить отдельную важную информацию на отдельном диске. Бывает, советуют часть диска выделять под raid0, часть под raid5 к примеру, или raid1. Берем 3 диска, делаем на них 3 массива по 3 рездела дисков, raid1 под /boot, raid0 под корень, raid5 под важные файлы, по сути должно получиться быстро и красиво. =) Хотя если подумать, то все мы экстремальщики, у всех система работает с 1го диска и не жужжит, если диск умрет, то финиш. ))) Так что между просто диском и raid0 не такая уж большая разница.

Ну в общем я кажется изложил свои наблюдения, простите, если в тексте есть ошибки, я просто немного под шафе. ))