Как сопоставить имя устройства sata с физическим интерфейсом sata для RAID-систем

У меня есть система с 10 портами SATA и еще один SATA в качестве загрузочного диска. 10 портов SATA составляют 5 программных RAID1-массивов. Диски RAID могут быть удалены между загрузками и заменены произвольными пустыми дисками в любое время.

Мне нужно убедиться, что / dev / sda всегда является моим первым физическим SATA-портом, а / dev / sdj всегда является десятым для правильной работы массивов RAID1. Если, например, первый диск в первом порту выходит из строя, это должно быть отмечено как недостающий диск, поэтому диск в следующем порту должен быть / dev / sdb. В настоящее время следующий доступный диск монтируется как / dev / sda – полностью уничтожает мои массивы – и мою конфигурацию загрузки.

Представьте себе ужасный сценарий, когда каждый другой диск выходит из строя, поэтому каждый массив RAID1 имеет только один рабочий диск в своей паре. Нумерация должна быть:

/ dev / sda / dev / sdc / dev / sde / dev / sdg / dev / sdi

НЕ:

/ dev / sda / dev / sdb / dev / sdc / dev / sdd / dev / sde

Я видел правила udev для маркировки определенных дисков с помощью UUID, но поскольку пользователи будут беспорядочно загружать диски, это совсем не удобно.

По умолчанию Linux отметит следующий доступный диск следующим алфавитным символом. Существует много ситуаций, когда один сломанный диск разбивает несколько массивов RAID 1.

  • Как я могу сопоставить устройство с конкретным аппаратным интерфейсом? Возможно ли это?
  • Возможно ли иметь «пропавшее» устройство при загрузке, поэтому последующие устройства не помечены неправильно?

Если вы создаете массив с:

 mdadm --create --name=DATA00 --level=6 --auto=part --verbose /dev/md0 --raid-devices=6 /dev/sda1 /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 

а затем выполните:

 mdadm --detail --scan >> /etc/mdadm/mdadm.conf 

вы получаете запись в mdadm.conf как:

 ARRAY /dev/md/DATA00 metadata=1.2 name=owl:DATA00 UUID=5eeada67:ff994361:bae3ab52:d9e8bd49 

Нет необходимости ссылаться на исходные разделы и / или порядок драйверов, поскольку UUID позаботится об этом. Какие фактические разделы представляют собой массив после активации / перезагрузки, можно увидеть из /proc/mdstat . Чтобы посмотреть на отдельный раздел (включая его UUID), используйте mdadm --examine /dev/sdXY

Учитывая, что после перезагрузки нет необходимости иметь определенный порядок в ваших дисках, и поскольку моя BIOS меняет ситуацию в зависимости от того, подключен ли я к внешнему SATA или нет, я очень рад, что это не имеет значения.

В Debian Wiki есть отличная запись, описывающая то, что мне нужно. После этого я сделал свои собственные правила в /etc/udev/rules.d/20-disk-bay.rules. Я включил только первые два сопоставления портов sata в качестве примера:

 # There are different DEVPATHs for major kernel versions! # Example for SATA N: # # Kernel < 3 DEVPATH # *1f.2/hostN/targetN:0:0/N:0:0:0* # # Kernel > 3 DEVPATH # *1f.2/ata(N+1)/host* ########## Map SATA 0 to /dev/sdb ############## # Kernel < 3 KERNEL=="sd?", SUBSYSTEM=="block", DEVPATH=="*1f.2/host0/target0:0:0/0:0:0:0*", NAME="sdb", RUN+="/usr/bin/logger My disk ATTR{partition}=$ATTR{partition}, DEVPATH=$devpath, ID_PATH=$ENV{ID_PATH}, ID_SERIAL=$ENV{ID_SERIAL}", GOTO="END_20_PERSISTENT_DISK" KERNEL=="sd?*", ATTR{partition}=="1", SUBSYSTEM=="block", DEVPATH=="*1f.2/host0/target0:0:0/0:0:0:0*", NAME="sdb%n", RUN+="/usr/bin/logger My partition parent=%p number=%n, ATTR{partition}=$ATTR{partition}" # Kernel > 3 KERNEL=="sd?", SUBSYSTEM=="block", DEVPATH=="*1f.2/ata1/host*", NAME="sdb", RUN+="/usr/bin/logger My disk ATTR{partition}=$ATTR{partition}, DEVPATH=$devpath, ID_PATH=$ENV{ID_PATH}, ID_SERIAL=$ENV{ID_SERIAL}", GOTO="END_20_PERSISTENT_DISK" KERNEL=="sd?*", ATTR{partition}=="1", SUBSYSTEM=="block", DEVPATH=="*1f.2/ata1/host*", NAME="sdb%n", RUN+="/usr/bin/logger My partition parent=%p number=%n, ATTR{partition}=$ATTR{partition}" ########## Map SATA 1 to /dev/sdc ############## # Kernel < 3 KERNEL=="sd?", SUBSYSTEM=="block", DEVPATH=="*1f.2/host1/target1:0:0/1:0:0:0*", NAME="sdc", RUN+="/usr/bin/logger My disk ATTR{partition}=$ATTR{partition}, DEVPATH=$devpath, ID_PATH=$ENV{ID_PATH}, ID_SERIAL=$ENV{ID_SERIAL}", GOTO="END_20_PERSISTENT_DISK" KERNEL=="sd?*", ENV{DEVTYPE}=="partition", SUBSYSTEM=="block", DEVPATH=="*1f.2/host1/target1:0:0/1:0:0:0*", NAME="sdc%n", RUN+="/usr/bin/logger My partition parent=%p number=%n, ATTR{partition}=$ATTR{partition}" # Kernel > 3 KERNEL=="sd?", SUBSYSTEM=="block", DEVPATH=="*1f.2/ata2/host*", NAME="sdc", RUN+="/usr/bin/logger My disk ATTR{partition}=$ATTR{partition}, DEVPATH=$devpath, ID_PATH=$ENV{ID_PATH}, ID_SERIAL=$ENV{ID_SERIAL}", GOTO="END_20_PERSISTENT_DISK" KERNEL=="sd?*", ATTR{partition}=="1", SUBSYSTEM=="block", DEVPATH=="*1f.2/ata2/host*", NAME="sdc%n", RUN+="/usr/bin/logger My partition parent=%p number=%n, ATTR{partition}=$ATTR{partition}" LABEL="END_20_PERSISTENT_DISK" 

Приведенные выше правила всегда будут отображать любой диск, размещенный в порту SATA 0, первом физическом порту SATA на моей материнской плате, в качестве / dev / sdb и любом диске, размещенном в SATA 1, как / dev / sdc. Согласованные сопоставления физических портов имеют решающее значение в моем случае использования , так как у меня есть 5 массивов RAID-1, где диски могут быть произвольно выгружены из своих отсеков для горячих точек. Нетехнический пользователь может в любой момент заменить эти диски без необходимости иметь дело с идентификаторами устройств – система полностью автономна и не будет создавать массивы RAID по неправильным дискам в отсеках горячих точек. Это очень конкретный случай использования, но я надеюсь, что это поможет кому-то в будущем.

Почему пользователи «горячей» замены дисков произвольно?

Многие горячие свопы означают, что диски, скорее всего, будут носить быстрее. Преимущество рейда в скорости будет потеряно. Фактически, производительность массива, вероятно, будет хуже, чем один диск, пока он восстанавливается.

Привычка разрывать диски произвольно рано или поздно приземлится на вас в ситуации, когда кто-то вытаскивает два диска, принадлежащих к одному и тому же массиву, что, вероятно, приведет к сбою системы.

Не говоря уже о проблемах, которые вы описали здесь. И я не уверен, что mdadm заберет новый диск, не добавляя его вручную в массив, но могут быть и такие возможности.

Это схема резервного копирования? Тогда я очень обескураживаю это! Используйте обычную резервную копию – возможно, с моментальными снимками LVM, если у вас LVM.

Если пользователи «злоупотребляют» вашими серверами, поставьте блокировку на дверь в комнате сервера … или лишите их ключей, поставляемых с большинством отсеков для горячей замены … или сообщите руководству, что система – достаточно важная для рейда – рискует из-за такого поведения.

Не используйте диски с горячей заменой, если диски не сломаны или не будут заменены из-за старости!

Горячая замена – это инструмент, обеспечивающий бесперебойную работу системы при замене дисков, которые сломаны, старые или их необходимо заменить по какой-то другой нерегулярной причине – это почти все, что хорошо (что достаточно хорошо, когда речь заходит о очень важных системах ).

Когда диск разбивается, вы можете заранее добавить дополнительный запасной диск в массив рейдов, в результате чего резервный диск будет синхронизироваться автоматически или вам придется вручную добавить замененный диск с заменой.

См. Ответ Anthon или это руководство: https://raid.wiki.kernel.org/index.php/RAID_setup