После замены блока питания у нас возникла проблема с кабелем, из-за которой отсутствовали некоторые диски, после отладки и исправления в BIOS при первой загрузке существовавший ранее том raid5 был разделен на две внешние конфигурации — одна содержала 5 дисков, другая содержал 2 оставшихся диска 7 тома raid5 (см. ниже).
Мы не можем импортировать чужие конфигурации с помощью perccli /c0/fall import:
Status = Failure
Description = Incomplete foreign configuration
Итак, все диски есть, но почему-то контроллер считает, что это две разные группы дисков. Есть ли способ выйти из этой ситуации и слить конфиги в один или что-то в этом роде?
----------------------------------------------------------------------------
DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace TR
----------------------------------------------------------------------------
0 - - - - RAID5 Frgn N 54.571 TB dsbl N N dflt N N
0 0 - - - RAID5 Frgn N 54.571 TB dsbl N N dflt N N
0 0 0 67:0 0 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
0 0 1 67:0 1 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
0 0 2 67:0 2 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
0 0 3 67:0 3 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
0 0 4 - - DRIVE Msng - 9.094 TB - - - - - N
0 0 5 - - DRIVE Msng - 9.094 TB - - - - - N
0 0 6 67:0 5 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
1 - - - - RAID5 Frgn N 54.571 TB dsbl N N dflt N N
1 0 - - - RAID5 Frgn N 54.571 TB dsbl N N dflt N N
1 0 0 - - DRIVE Msng - 9.094 TB - - - - - N
1 0 1 - - DRIVE Msng - 9.094 TB - - - - - N
1 0 2 - - DRIVE Msng - 9.094 TB - - - - - N
1 0 3 - - DRIVE Msng - 9.094 TB - - - - - N
1 0 4 67:0 6 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
1 0 5 67:0 4 DRIVE Frgn N 9.094 TB dsbl N N dflt - N
1 0 6 - - DRIVE Msng - 9.094 TB - - - - - N
----------------------------------------------------------------------------
Foreign VD List :
===============
---------------------------------
DG VD Size Type Name
---------------------------------
0 255 54.571 TB RAID5 RV5
1 255 54.571 TB RAID5 RV5
---------------------------------
Обновлять:
Я отключил весь экспандер и загрузился. Это показало все диски в внешней конфигурации (также есть несколько отдельных томов raid1):
-----------------------------------------
DG EID:Slot Type State Size NoVDs
-----------------------------------------
0 - RAID0 Frgn 9.094 TB 1
1 - RAID0 Frgn 10.913 TB 1
2 - RAID0 Frgn 10.913 TB 1
3 - RAID0 Frgn 10.913 TB 1
4 - RAID0 Frgn 9.094 TB 1
5 - RAID0 Frgn 278.875 GB 1
6 - RAID0 Frgn 14.551 TB 1
7 - RAID0 Frgn 16.370 TB 1
8 - RAID0 Frgn 9.094 TB 1
9 - RAID5 Frgn 54.571 TB 1
10 - RAID5 Frgn 54.571 TB 1
-----------------------------------------
Мне удалось успешно импортировать /c0/fall all. К сожалению, это закончилось той же ситуацией, что и раньше, когда другие тома были там, а raid5 был разделен на две внешние конфигурации (т. е. импорт всех внешних конфигураций, созданных для новых внешних конфигураций).
Обновление 2:
Присоединение дисков к системе GNU/Linux показывает это, что для меня в основном говорит о том же, что и контроллер perc: есть два тома рейда с 5 и 7 дисками. Так что это, похоже, результат ошибки прошивки, когда рейд-контроллер фактически разделил группу томов на две неработающие, и поэтому слияние кажется невозможным.
Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10]
md125 : inactive sdi[0]
9765912576 blocks super external:/md127/2
md126 : inactive sdg[1](S) sdf[0](S)
1048576 blocks super external:ddf
md127 : inactive sdm[4](S) sdi[3](S) sdh[2](S) sdk[1](S) sdl[0](S)
2621440 blocks super external:ddf
неиспользуемые устройства:
Я пытаюсь восстановиться отсюда, но теперь возникает вопрос: могу ли я снова воссоздать массив либо в рейд-контроллере, либо в GNU/Linux, чтобы рейд-контроллер распознал массив? Восстановление из резервной копии занимает довольно много времени.
** Обновление 3:**
Поскольку это было запрошено — у меня больше нет информации об исследовании/подробности, но вот дамп того, что напечатал мой собственный инструмент, который дает немного больше структуры и ясно показывает, насколько была повреждена информация. Данные DDF включают в себя больше дисков, чем просто диски в массиве, но мой инструмент выдал только информацию, связанную с конфигурацией массива, которую я хотел восстановить. Обратите внимание, что я решил свою проблему, воссоздав массив после небольшой одиссеи, так что это просто для информации.
/dev/sdf
refno 66fee9c8
guid 'ATA 999901019c64177c25b6'
pd 1 6d67850c 'ATA 9999010198734b845e34'
pd 2 2c442eef 'ATA 99990101a3ff6b169fb3'
pd 3 859c2a72 'ATA 9999010140f57d7b1911'
pd 4 2a25447d 'ATA 9999010181a40ea27a38'
pd 5 6db9e402 'SmrtStor P^A^W1^@tfM-8'
pd 6 0176ebaa 'ATA 99990101bd73575777e4'
pd 7 a63ba301 'ATA 999901017d605c6aadf6'
pd 8 5254f474 'ATA 999901014ecf2257f8f4'
pd 9 80e8a86d 'ATA 999901014c775ca92a87'
pd 10 49416c50 'ATA 99990101d79cd13a1e1e'
pd 11 fa44428b 'ATA 9999010198bd2187a552'
pd 12 66fee9c8 'ATA 999901019c64177c25b6'
pd 13 4a94daa9 'ATA 99990101679d1776307e'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 0 start 0 ref a63ba301
disk 1 start 0 ref 5254f474
disk 2 start 0 ref 80e8a86d
disk 3 start 0 ref 49416c50
disk 4 start 0 ref fa44428b
disk 5 start 0 ref 66fee9c8
disk 6 start 0 ref 4a94daa9
/dev/sdg
refno fa44428b
guid 'ATA 9999010198bd2187a552'
pd 1 6d67850c 'ATA 9999010198734b845e34'
pd 2 2c442eef 'ATA 99990101a3ff6b169fb3'
pd 3 859c2a72 'ATA 9999010140f57d7b1911'
pd 4 2a25447d 'ATA 9999010181a40ea27a38'
pd 5 6db9e402 'SmrtStor P^A^W1^@tfM-8'
pd 6 0176ebaa 'ATA 99990101bd73575777e4'
pd 7 a63ba301 'ATA 999901017d605c6aadf6'
pd 8 5254f474 'ATA 999901014ecf2257f8f4'
pd 9 80e8a86d 'ATA 999901014c775ca92a87'
pd 10 49416c50 'ATA 99990101d79cd13a1e1e'
pd 11 fa44428b 'ATA 9999010198bd2187a552'
pd 12 66fee9c8 'ATA 999901019c64177c25b6'
pd 13 4a94daa9 'ATA 99990101679d1776307e'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 0 start 0 ref a63ba301
disk 1 start 0 ref 5254f474
disk 2 start 0 ref 80e8a86d
disk 3 start 0 ref 49416c50
disk 4 start 0 ref fa44428b
disk 5 start 0 ref 66fee9c8
disk 6 start 0 ref 4a94daa9
/dev/sdh
refno 4a94daa9
guid 'ATA 99990101974a122c9311'
pd 1 6d67850c 'ATA 99990101be1d53ed8c7d'
pd 2 2c442eef 'ATA 99990101ff58714b7f1b'
pd 3 859c2a72 'ATA 99990101fa3ac0b94ef7'
pd 4 2a25447d 'ATA 999901017e74d11eb6e6'
pd 5 0176ebaa 'ATA 99990101f19b3355ec56'
pd 6 a63ba301 'ATA 99990101f391d36e91f9'
pd 7 5254f474 'ATA 99990101fa6d3d5b6c49'
pd 8 80e8a86d 'ATA 99990101b7ad5947d5c0'
pd 9 49416c50 'ATA 99990101d2e6918871bb'
pd 10 4a94daa9 'ATA 99990101974a122c9311'
pd 11 6db9e402 'SmrtStor P^A^W1^@tfM-8'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 0 start 0 ref a63ba301
disk 1 start 0 ref 5254f474
disk 2 start 0 ref 80e8a86d
disk 3 start 0 ref 49416c50
disk 6 start 0 ref 4a94daa9
/dev/sdi
refno 49416c50
guid 'ATA 99990101d2e6918871bb'
pd 1 2a25447d 'ATA 999901017e74d11eb6e6'
pd 2 0176ebaa 'ATA 99990101f19b3355ec56'
pd 3 49416c50 'ATA 99990101d2e6918871bb'
pd 4 6db9e402 'SmrtStor P^A^W1^@tfM-8'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 3 start 0 ref 49416c50
/dev/sdk
refno 80e8a86d
guid 'ATA 99990101b7ad5947d5c0'
pd 1 2a25447d 'ATA 999901017e74d11eb6e6'
pd 2 0176ebaa 'ATA 99990101f19b3355ec56'
pd 3 a63ba301 'ATA 99990101f391d36e91f9'
pd 4 5254f474 'ATA 99990101fa6d3d5b6c49'
pd 5 80e8a86d 'ATA 99990101b7ad5947d5c0'
pd 6 49416c50 'ATA 99990101d2e6918871bb'
pd 7 6db9e402 'SmrtStor P^A^W1^@tfM-8'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 0 start 0 ref a63ba301
disk 1 start 0 ref 5254f474
disk 2 start 0 ref 80e8a86d
disk 3 start 0 ref 49416c50
/dev/sdl
refno 5254f474
guid 'ATA 99990101fa6d3d5b6c49'
pd 1 2a25447d 'ATA 999901017e74d11eb6e6'
pd 2 0176ebaa 'ATA 99990101f19b3355ec56'
pd 3 a63ba301 'ATA 99990101f391d36e91f9'
pd 4 5254f474 'ATA 99990101fa6d3d5b6c49'
pd 5 80e8a86d 'ATA 99990101b7ad5947d5c0'
pd 6 49416c50 'ATA 99990101d2e6918871bb'
pd 7 6db9e402 'SmrtStor P^A^W1^@tfM-8'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 0 start 0 ref a63ba301
disk 1 start 0 ref 5254f474
disk 2 start 0 ref 80e8a86d
disk 3 start 0 ref 49416c50
/dev/sdm
refno a63ba301
guid 'ATA 99990101f391d36e91f9'
pd 1 2a25447d 'ATA 999901017e74d11eb6e6'
pd 2 0176ebaa 'ATA 99990101f19b3355ec56'
pd 3 a63ba301 'ATA 99990101f391d36e91f9'
pd 4 5254f474 'ATA 99990101fa6d3d5b6c49'
pd 5 80e8a86d 'ATA 99990101b7ad5947d5c0'
pd 6 49416c50 'ATA 99990101d2e6918871bb'
pd 7 6db9e402 'SmrtStor P^A^W1^@tfM-8'
part 0
guid 'Dell ^P'
size 117190950912
blocks 19531825152
disk 0 start 0 ref a63ba301
disk 1 start 0 ref 5254f474
disk 2 start 0 ref 80e8a86d
disk 3 start 0 ref 49416c50
seq 0 refno a63ba301 dev /dev/sdm
seq 1 refno 5254f474 dev /dev/sdl
seq 2 refno 80e8a86d dev /dev/sdk
seq 3 refno 49416c50 dev /dev/sdi
seq 4 refno fa44428b dev /dev/sdg
seq 5 refno 66fee9c8 dev /dev/sdf
seq 6 refno 4a94daa9 dev /dev/sdh
аппаратный рейд dell-perc
Помни Монику
2 ответа
Хорошо, вот что я сделал. Пусть это поможет следующему человеку.
Установление фактов
Сначала я подключил все диски к HBA. GNU/Linux попытался собрать рейд, но действительно нашел (по крайней мере) два рейд-тома (и немного больше). Затем я сделал резервную копию первых 32 и последних 32 МБ каждого диска, проиндексировав их WWID/WWN.
Затем я скачал спецификацию SNIA DDF (https://www.snia.org/tech_activities/standards/curr_standards/ddf), потому что я знал, что megaraid/dell (частично) реализовал его (магия блока привязки ddf не de11de11 случайно :), а затем написал очень уродливый скрипт, чтобы расшифровать данные и разобраться в них.
Это показало мне, что массив фактически был разделен на три разные конфигурации: одна включала один диск, другая включала этот диск и еще 4, а третья содержала оставшиеся 2 диска.
Сам сценарий не очень полезен без понимания того, что вы делаете, поэтому я не включил его сюда.
В конце концов, это позволило мне установить правильный первоначальный порядок дисков. Подсказка: после создания массива запишите порядок WWN (perccli /c0/s0 show all | grep WWN) и размер полосы, по крайней мере.
Этот процесс также дал мне начальное смещение (всегда 0) и размер разделов (19531825152 сектора).
Вариант raid5, используемый H740P (и, вероятно, всеми контроллерами megaraid), называется left-symmetric или «RAID-5 с чередованием четности N с продолжением данных (PRL = 05, RLQ = 03)».
Сборка дисков для тестирования
Затем я попытался протестировать рейд, используя mdadm --build. К сожалению, mdadm отказывается собирать массивы raid5 — вы
имеют для записи в массив и уничтожения данных 🙁
В качестве обходного пути, чтобы проверить правильность порядка, я запустил kvm в режиме моментального снимка с некоторым случайным загрузочным образом GNU/Linux, как /dev/sda и диски как виртуальные диски:
exec kvmb -snapshot -m 16384 \
-drive file=linux.img,snapshot=off \
-drive file=/dev/sdm,if=virtio,snapshot=on \
-drive file=/dev/sdl,if=virtio,snapshot=on \
-drive file=/dev/sdk,if=virtio,snapshot=on \
-drive file=/dev/sdi,if=virtio,snapshot=on \
-drive file=/dev/sdg,if=virtio,snapshot=on \
-drive file=/dev/sdf,if=virtio,snapshot=on \
-drive file=/dev/sdh,if=virtio,snapshot=on
Это заставило диски отображаться в указанном порядке как /dev/vda, /dev/vdb и так далее, что позволило мне легко протестировать различные варианты. Первая попытка внутри виртуальной машины удалась:
mdadm --create /dev/md0 -f \
--metadata 1.0 \
--raid-devices 7 \
-z $((19531825152/2))K -c 256K \
-l raid5 -p ddf-N-continue \
--assume-clean -k resync \
/dev/vd?
Для рейда5 размер раздела некритичен — если он больше, то ваша таблица разделов GPT повреждена и у вас есть лишние данные, но остальная часть диска должна оставаться читаемой.
Я проверил правильность данных, смонтировав раздел (что не должно вызывать ошибок, но может быть успешным, даже если порядок неправильный) и используя
btrfs scrubкоторый проверяет контрольные суммы метаданных и блоков данных, что является окончательным тестом и большим плюсом btrfs.
Затем я снова запустил backzp.
Затем я записал WWN всех дисков по порядку, чтобы воссоздать его с помощью perccli. Я также сделал резервную копию первого и последнего 1 ГБ данных самого тома на случай, если рейд-контроллер их перезапишет.
Перемещение тома обратно в рейд-контроллер
Поскольку около 14 ТБ данных не было заархивировано (поскольку данные могут быть извлечены из других источников с некоторыми усилиями, и я был слишком нетерпелив, чтобы дождаться копии), полное восстановление не было вариантом, которого я с нетерпением ждал, поэтому я попытался чтобы переместить массив обратно в контроллер.
Моей первой попыткой было отформатировать массив как DDF-контейнер с томом raid5 внутри, используя те же параметры, что и контроллер, но, к сожалению, мегарайд-контроллер — при использовании самого DDF — не поддерживает «чужой» DDF для импорта и показал диски просто как «ненастроенные хорошие».
Затем я попытался воссоздать массив, просто добавив его снова, например:
perccli /c0 add vd r5 name=XXX дисков=3,6,9,1,2,3,0 pdcache=off wb ra strip=256
Выполнение этого на загруженной системе с perccli гарантирует, что контроллер рейда выполнит фоновую инициализацию, которая не является деструктивной, а с RAID5 даже не уничтожит данные, если порядок дисков или размер полосы неправильный, пока вы используете в яблочко все диски из исходного массива в любом порядке, не пропуская ни одного и не давая слишком много.
Вот тут-то я и потерпел неудачу — каким-то образом я совершенно напортачил с порядком дисков, а также умудрился испортить первые 1,5 МБ тома. Я абсолютно не знаю, что пошло не так, но я перепробовал множество перестановок и не увидел правильных данных, вплоть до того, что подумал, что рейд-контроллер каким-то образом переупорядочит мои диски (но это не так, он точно принимает порядок, как указан).
Короче говоря, я снова подключил диски к HBA и попытался, но безуспешно. Вот где мне пригодилась моя исходная резервная копия: хотя я потерял порядок дисков, я внимательно посмотрел на резервную копию и понизил потенциальный порядок до двух возможных перестановок, просто глядя на шестнадцатеричные дампы. Создание массива с mdadm и проверка данных у меня правильный порядок.
Я потом еще раз записал порядок WWN, подключил диски к контроллеру, загрузился и сделал perccli /c0 add.... Затем я восстановил первые 1,5 МБ тома (которые включали раздел GPT и метки LVM, а также некоторые старые оставшиеся мусорные данные, которые были очень полезны при угадывании порядка). Определенный уровень уверенности в возможности исправить ошибки полезен в этой ситуации.
Результат: массив вернулся, btrfs непротиворечива, а контроллер теперь инициализируется в фоновом режиме, что замедляет работу всей системы на несколько дней, но это небольшая цена.
Вещи узнали
Я многому научился!
Контроллеры perc (и, вероятно, все контроллеры megaraid) плохо справляются с частыми быстрыми и прерывистыми проблемами с дисками — я подозреваю, что быстрое исчезновение и возвращение дисков вызвало состояние гонки, когда контроллер пытался записать новую конфигурацию на диски. и лишь частично удалось с некоторыми дисками, в конечном итоге разделив рейд на два. Это явно глюк прошивки. Но тогда кто мог ожидать, что силовые кабели будут неисправны…
mdadm не очень помогает в понимании или отображении заголовков DDF — я просто не мог понять отображаемые данные, и, как я выяснил при самостоятельном декодировании заголовков, это связано с тем, что в
--detailа также--examineвыход. Это также не очень полезно для экспериментов, так как отказывается выполнять неразрушающую сборку только для чтения.Контроллеры perc/megaraid используют внутренний формат SNIA DDF, и эта общедоступная спецификация была чрезвычайно полезна, хотя в конце концов я понял, что мне нужно, и без этой информации.
Возможность угадать правильный порядок полос рейдов только по данным очень полезна. Остатки мусора и другие данные, которые могут в этом помочь, тоже очень пригодятся. С этого момента я рассмотрю возможность записи «диск 1», «диск 2» и т. Д. В «пустые» области заголовков тома RAID (в первых 2 МБ есть длинные участки по 0 байт).
Облажаться очень легко — имена устройств, номера членов рейда, WWN, номера слотов и т. д., если они разные, могут означать, что нужно управлять большим количеством данных, а WWN длинные, и мои старые глаза уже не так хороши. К тому же, я не организован и излишне самоуверен :/
Создание и удаление массива с использованием дисков с данными не приведет к удалению данных, по крайней мере, при использовании RAID5 и фоновой инициализации. Инициализация переднего плана почти наверняка обнулит диски. Это означает, что вы можете создавать и удалять массив столько раз, сколько пожелаете, не рискуя потерять данные, за одним возможным исключением: иногда для удаления массива требуется принудительная опция, потому что контроллер RAID считает, что он «используется» из-за допустимого раздела. этикетка. И это мощь обнулите метку GPT — YMMV и убедитесь, что у вас есть резервная копия первых нескольких мегабайт на всякий случай.
Perc/megaraid не понимают DDF-контейнеры, отличные от Dell/megaraid. По крайней мере, я не нашел, как заставить мой контроллер принимать DDF-контейнеры, созданные mdadm. Возможность отформатировать диск в GNU/Linux и переместить его обратно в контроллер очень помогла бы и избежала многих часов горя с моей стороны.
Резюме
Я вернул все без восстановления из резервной копии за счет нескольких дней медленной фоновой инициализации. Я записал свое решение выше, на тот случай, если некоторые из них могут быть полезны другим людям в подобных ситуациях.
Вы можете попробовать отключить все диски от выключенного сервера, затем удалить обе группы, а затем снова подключить диски. Это должно сбросить все диски в «чужое» состояние. А затем попробуйте импортировать их все за одну операцию.