Имею сервера с аппаратной поддержкой RAID. Диски поставлены в зеркало. Вроде всё работает. Точнее - работало без каких либо моих в том сомнений. А сейчас они появились:
Вот кусок из лога загрузки:
text
Jan 4 19:52:19 tom fedora-storage-init[461]: failed to stat() /dev/mapper/ddf1_4c5349202020202080862925000000004711471100000a28
Jan 4 19:52:19 tom fedora-storage-init[461]: Устанавливаются параметры Logical Volume Manager Found duplicate PV iyxfFkeP7IQNwSbJnt5ykY4m7l3lwkAp: using /dev/sdb2 not /dev/sda2
Jan 4 19:52:19 tom fedora-storage-init[461]: 6 logical volume(s) in volume group "vg_tom" now active
Меня очень сильно смущают первые две строчки. На более древних федорах это дело (инициализировал LVM)делал dracut. И никаких у него сомнений в дисках не возникало. А тут боюсь, как бы не оказаться с одним работающим диском... Думая при этом, что ты в полном зеркале... Не нравятся мне эти записи...
Более того - если я выполняю команды vgdisplay, lvdisplay и так далее, то они радостно сообщают ту же самую ошибку:
text
Found duplicate PV iyxfFkeP7IQNwSbJnt5ykY4m7l3lwkAp: using /dev/sdb2 not /dev/sda2
Ощущение такое, что система грубо игнорирует наличие аппаратного RAID'а и работает только с одним диском. Хотя ставилась именно в RAID bios. Не хотелось бы оказаться в нехорошей ситуации, когда он из строя выйдет. Или я на воду дую?
Он, сволочь находит все правильно, действительно есть два диска, sda2 и sdb2, на которых лежит аппаратный RAID с LVM-разделом. Эти разделы имеют одинаковую метку. Так вместо того, чтобы сделать правильный вывод о том, что это RAID-1 и начать работать с ним через /dev/mapper/ddf-XXXXXX он берет в рассмотрение только диск sdb2, и так далее. Хорошо, если это только по чтению берет. А если и по записи? Тогда - полная задница...
Вот вывод dmesg на ту же тему на аналогичном сервере, под Fedora-12:
text
dracut: dracut-005-5.fc13
dracut: rd_NO_LUKS: removing cryptoluks activation
dracut: Starting plymouth daemon
dracut: rd_NO_MDIMSM: no MD RAID for imsm/isw raids
dracut: rd_NO_MD: removing MD RAID activation
dracut: rd_NO_MDIMSM: no MD RAID for imsm/isw raids
dracut: Scanning for dmraid devices ddf1_4c5349202020202080862925000000004711471100001450
dracut: Found dmraid sets:
dracut: ddf1_4c5349202020202080862925000000004711471100001450
dracut: Activating ddf1_4c5349202020202080862925000000004711471100001450
dracut: RAID set "ddf1_4c5349202020202080862925000000004711471100001450" was activated
dracut: RAID set "ddf1_4c5349202020202080862925000000004711471100001450" was not activated
dracut: Scanning devices dm-2 sdc1 for LVM logical volumes vg_dbserver/lv_root
dracut: inactive '/dev/vg_sdc/LV_DRBD' [32.00 GiB] inherit
dracut: inactive '/dev/vg_sdc/LV_WORK' [433.76 GiB] inherit
dracut: inactive '/dev/vg_dbserver/lv_root' [100.00 GiB] inherit
dracut: inactive '/dev/vg_dbserver/lv_data' [328.09 GiB] inherit
dracut: Mounted root filesystem /dev/mapper/vg_dbserver-lv_root
dracut: Loading SELinux policy
dracut: /sbin/load_policy: Невозможно загрузить политику: Нет такого файла или каталога
dracut: Switching root
Здесь он четко разобрался и сделал _правильный_ вывод. Зацепил dmraid и вперед через него... Если это бага, то она - на мой взгляд - весма критическая. Так как чревата внезапной потерей данных.
и вот еще немного непонятности:
На исправном сервере:
[console]#ls /dev/mapper/
control ddf1_4c5349202020202080862925000000004711471100001450p5
ddf1_4c5349202020202080862925000000004711471100001450 vg_dbserver-lv_data
ddf1_4c5349202020202080862925000000004711471100001450p1 vg_dbserver-lv_root
ddf1_4c5349202020202080862925000000004711471100001450p2 vg_sdc-LV_DRBD
ddf1_4c5349202020202080862925000000004711471100001450p3 vg_sdc-LV_WORK
ddf1_4c5349202020202080862925000000004711471100001450p4
[/console]
И это правильно. А вот на проблемых совсем иное:
[console]#ls /dev/mapper/
control vg_tom-LV_DATA vg_tom-LV_DRBD vg_tom-LV_FIRMDOCS vg_tom-LV_ISCSI vg_tom-LV_ROOT vg_tom-LV_SWAP
[/console]
То есть нету RAID-овского набора с длинным именем.
Беда еще в том, что на тех серверах, где я это обнаружил RAID-1 строится аппаратно (на полутерабайтных дисках) очень неспешно. Часов 10-12 сервер в "отключке" стоит... Можно, конечно, развалить аппаратный RAID, перейти на программный. Но это - лишняя нагрузка на не слишком мощные процессоры будет. Не нравится мне это...
если это в зеркале, то наверно можно по одному диски вытащить/отключить и посмотреть или это действительно зеркало,
а программный я бы не делал, просто ИМХО
Вытащу завтра. Хотя мне иных дел хватает... Программный делать сам не хочу.
Вполне возможно, что загрузчик не может нужный UUID ядру передать. В строке груба параметр есть, а ядро его не получает... Точнее - получает, но обработать не может:
[console][root@tom grub2]# dmesg | grep ddf1_4c
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.6.10-2.fc17.x86_64 root=/dev/mapper/vg_tom-LV_ROOT ro LANG=ru_RU.UTF-8 rd.md=0 rd.lvm.lv=vg_tom/LV_ROOT KEYTABLE=ru rd.dm.uuid=ddf1_4c5349202020202080862925000000004711471100000a28 SYSFONT=False rd.luks=0 rd.lvm.lv=vg_tom/LV_SWAP rhgb quiet
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.6.10-2.fc17.x86_64 root=/dev/mapper/vg_tom-LV_ROOT ro LANG=ru_RU.UTF-8 rd.md=0 rd.lvm.lv=vg_tom/LV_ROOT KEYTABLE=ru rd.dm.uuid=ddf1_4c5349202020202080862925000000004711471100000a28 SYSFONT=False rd.luks=0 rd.lvm.lv=vg_tom/LV_SWAP rhgb quiet
[/console]
В 12-й федоре - там на этот UUID дракут реагировал и dmraid на него натравливал. А в 17-й - ой. На этом месте всякие упоминания об этом диске и заканчиваются.
======================
нашел патч на эту тему: http://permalink.gmane.org/gmane.linux.kernel.initramfs/2966. Завтра поробую применить. Вдруг поможет. А пока систему затарю...
если бы это на одном сервере было, я бы на диск грешил, но я понимаю, это на нескольких:
...Беда еще в том, что на тех серверах, где я это обнаружил...
?
На двух серверах. Работали они себе спокойно по управлением стареньких федор, 12-13. И там всё было четко, диски лежали на /dev/mapper/ddf.... Но, решил на них поднять кластер на pacemaker'е. Кувыркания на стенде (в виртуалках) показало, что CentOS 6.3 весьма сильно сопротивляется этому делу. Всё чего-то не хватало. В тоже время на Федоре - завелось как доктор прописал. Сборка-разборка почти без проблем. Поэтому обновляю ось на этих серверах, при обновлении явно вижу, что ставимся в аппаратный RAID. А вот дальше... В процессе работы идут в логи малоприятные собщения. И я не знаю, как относится аппаратный RAID при записи на один диск, на sda, дублирует ли эту запись на sdb или нет.
аппаратный - значит хардверный?
если так, стоят ли на этих машинах идентичные контроллеры? если да, идентичны ли ониконтроллерам на нормально работающих серверах?
аппаратный - значит хардверный?
если так, стоят ли на этих машинах идентичные контроллеры? если да, идентичны ли ониконтроллерам на нормально работающих серверах?
Да, сервера (проблемные) идентичны. Интеловские. Рабочий похож, только отличается процессором, матерью, под тот процессор (пара ксеонов) и объемом памяти. Дисковая подсистема, контроллеры скорее всего идентичны. Имена их, серверов, на память не скажу. Завтра загружусь с флешки с RFR-14 и посмотрю, что она увидит. А заодно посмотрю - на какой именно диск идет запись. Если на оба - то и фиг с ним. А если на один... То очередной мне гимор... Ведь рутовый раздел я поместил в LVM.
У вас точно аппаратный raid есть? Мне кажется, что то, что вы называете аппаратным raid-ом может быть обычной, как это говорят, маркетинговой уловкой. Т.е. часть логики реализована аппаратно, а часть - должна быть в драйверах, которые поставляются вместе с железом.
На сколько я понимаю, если у вас полностью аппаратный raid, то для системы он должен выглядеть одним диском. Но вы же говорите о sda и sdb. Мб я чего-то не так понял и это и есть 2 raid-а, которые вы хотите собрать в soft raid?
Если же raid таки аппаратный, то статус его можно посмотреть в утилите управления контроллера (я так понял, что не проблема сейчас добраться до нее, т.к. сервер не в "боевом" режиме). Оттуда уже и делать выводы на счет правильности работы массива.
У вас точно аппаратный raid есть? Мне кажется, что то, что вы называете аппаратным raid-ом может быть обычной, как это говорят, маркетинговой уловкой.
Извините за грубое слово, но мне гораздо лучше чем Вам известен состав моег железа. Которое уже не первый год в эксплуатации. И если я говорю, что у меня - сервер, то это именно сервер (в данном случае в RACK-исполнении) а не писюк голимый, используемый в качестве сервака. Если я говорю, что там именно аппаратный RAID, то именно так оно и есть. Мои сервера несут на борту интеловские RAID-контроллеры.
Это первое.
Второе. Меня всегда удивляла особенность федоры (12,13,14) показывать не только dmraid-овские диски, которые она получает от этого контроллера, но и сами первоисточники, sda и sdb. Но показ не страшен. Пусть показывает, благо ничего с ними она делать не давала. Вся работа шла через опознанный при загрузке как RAID дисковый массив, через /dev/mappwe/ddf=XXXXX. А вот на федоре 17 - полная задница. Анаконда при установке поняла, что массив RAID-овский. Поставила ось именно на райдовский массив. А вот после перезагрузки (первой) вместо райдовского массива подхватился диск /dev/sdb2, в котром лежит большой LVM-массив. Со всеми данными, с корнем и так далее.
Третье - аппаратный котроллер совершенно не ожидал такой подлости и если заись шла не через dmraid, а напрямую, в /dev/sda2 - пропускал её спокойно. То есть аппаратное зеркало - разрушено. Это было проверено путем заггрузки CentOS 6.3. CentOS увидела dmraid-диск. Причем именно в виде перед первой перезагрузкой. В девстенно чистом состоянии sda2. Кстати, CentOS (в отличие от федоры) не показал ни sda, ни sdb. Этих дисков для него не существут. Есть только то, что получено от dmraid'а
И, к моему великому сожелению, после того, как я поработал с Центоосью - система с диски отказалась загружаться вообще. Кернел-паник приходит по причине ненахождения диска. Мгновенно...
Есть какие идеи? Мне нужна именно Федора на сервере, так как эксперименты с pacemaker'ом на CentOC 6.3 кончились неудачно. А на федоре оно беспроблемно заводится и работает по написанному руководству.
Между тем, man dmraid в первой строке говорит следующее:
NAME
dmraid - discover, configure and activate software (ATA)RAID
По этой причине и задал вопрос.
И тем не менее - на федорах от 12 до 14й версий именно через него шла работа с интеловским RAID массивом. Логи я показывал выше. А вот на 17-й федоре этот массив увидела только анаконда, когда ось на него накатывала. А вот дальше - процесс правильной загрузки накрывается медным тазом. И вместо работы с RAID-1 через /dev/mapper/ddf-XXXX система цепляется к одному из физических дисков и работает в обход этого интеловского RAID-массива. Причем настолько в обход, что попытки поиграть с ключами загрузки типа rd.md и rd.dm разрушают систему полностью. Вроде выяснил, что стоит поставить параметры rd.md=1 rd.dm=auto (массив поднялся зеркально), но попытка записать эти параметры в конфиг груба грубо разрушает RAID. Полностью. Настолько, что его можно только в биосе проинициализировать. На первой машине я удивился этому, вторая - подтвердила разрушение. То есть эффект повторяем. Отсюда - Fedora 17 абсолютно непригодна для работы на интеловских серверах с интеловскими RAID-контроллерами.
Меня задолбал этот трах (лучи поноса от меня в мозг разработчиков дракута, до седьмого их колена), поставил CentOS 6.3. Там RAID-1 массив прекрасно опозналя и завелся как положено. Вот лог загрузки:
[console]# dmesg | grep dracut
dracut: dracut-004-284.el6_3.1
dracut: rd_NO_LUKS: removing cryptoluks activation
dracut: Starting plymouth daemon
dracut: rd_NO_MD: removing MD RAID activation
dracut: Scanning for dmraid devices ddf1_4c5349202020202080862925000000004711471100000a28
dracut: Found dmraid sets:
dracut: ddf1_4c5349202020202080862925000000004711471100000a28
dracut: Activating ddf1_4c5349202020202080862925000000004711471100000a28
dracut: RAID set "ddf1_4c5349202020202080862925000000004711471100000a28" was activated
dracut: RAID set "ddf1_4c5349202020202080862925000000004711471100000a28" was not activated
dracut: Scanning devices dm-2 for LVM logical volumes vg_jerry/LV_SWAP vg_jerry/LV_ROOT
dracut: inactive '/dev/vg_jerry/LV_ROOT' [15.62 GiB] inherit
dracut: inactive '/dev/vg_jerry/LV_SWAP' [2.00 GiB] inherit
dracut: inactive '/dev/vg_jerry/LB_DRBD' [32.00 GiB] inherit
dracut: inactive '/dev/vg_jerry/LV_ISCSI' [100.00 GiB] inherit
dracut: inactive '/dev/vg_jerry/LV_FIRMDOCS' [200.00 GiB] inherit
dracut: inactive '/dev/vg_jerry/LV_DATA' [114.61 GiB] inherit
dracut: Mounted root filesystem /dev/mapper/vg_jerry-LV_ROOT
dracut:
dracut: Switching root
[/console]
Разница видна невооруженным взлядом. Соответственно программы pvdisplay, lvdisplay и прочая требуха по управлению LVM-томами никаких дуплицирующихся PV-меток на томах не видят. Потому как работают не с физическими sd[ab], а с /dev/mapper/ddf1_xxxxx.
Да не работает... У меня цель не просто запустить в работу сервера, а постоить на них HA-кластер. Причем не на heartbeat, он только на двух нодах умеет, а на pacemaker-e. У меня в кластере должно стоять три сервера. А вот pacemaker на CentOS 6.3 я за две недели предновогоднего траха на виртуалках завести так и не смог. :( А на федоре он поднимается на раз-два, делай по книжке и всё получится.
Обидно, что целую неделю потерял на этом долбаном дракуте с RAIDом. Мог бы дано уже отдыхать и пиво пьянствовать. А тут уще целый сервер витруализации переделывать надо. И закончить всё надо 8-го числа. 9-го всё должно работать как часы...
А если свежеустановленной федоре скормить этим параметры (rd.md=1 rd.dm=auto) во время первой загрузки? Или так тоже пробовали?
А потом уже (если всё будет ок) - в конфиг груба записать
А если свежеустановленной федоре скормить этим параметры (rd.md=1 rd.dm=auto) во время первой загрузки? Или так тоже пробовали?
А потом уже (если всё будет ок) - в конфиг груба записать
Для пробы нужно прежде всего время. А его у меня уже не осталось. Сегодня к вечеру должно запустить в предварительную эксплуацию третий сервер. Добиться, чтобы основные службы на нём задышали. Над этим и работаю с утра.
А ставить эксперименты с тем экскрементом у меня нет больше желания. И нужды. Если разработчики поломали логику работы дракута, поломали настолько, что он перестал реагировать на явно задаваемый (установленный той же анакондой при инсталляции системы) параметр запуска rd.dm.uuid=.... На что всегда раньше срабатывал правильно...
Желающие могут потренироваться на досуге.
ну, на виртуалках иногда всякое бывает, я бы нa любой физической машине (если есть возможность) попробовал бы
Программа не того уровня, чтобы зависеть от виртуальности. Там тривиальное расхождение версий pacemaker'а и corosinc'а. Причем некоторые нужные для работы программы исчезли в тумане, нету там основной программы crm. Вот всё начинающееся с этих букв есть, а самого менеджера - нету, выпилили. Как выпилили поддержку heartbeat'а и так далее... Вобщем, не сладно в pacemaker'е для Центоси 6.3.
