Когда я командую multipath -ll, результат будет таким.
ocr3 (149455400000000000000000001000000ca0200000d000000) dm-9 IET,VIRTUAL-DISK
[size=980M][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 1:0:0:11 sdo 8:224 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:10 sdn 8:208 [active][ready]
Однако тот же узел разработки ocr3, такой как sdo и sdn, изменяется после перезагрузки.
Я думаю, это проблема последовательности.
Почему после перезагрузки меняется devnode?
Как сделать devnode постоянным после перезагрузки?
Для обеспечения возможности горячего подключения и динамической реконфигурации не следует предполагать, что /dev/sd* узлы устройств останутся неизменными от одной загрузки до другой.
На рабочей станции с одним контроллером AHCI SATA порядок обычно будет статическим, так как он в основном определяется порядком загрузки драйверов контроллера хранилища: обычно драйвер для корневого диска загружается на этапе initramfs при загрузке, прежде чем usb-storage. Затем порядок дисков, управляемых контроллером AHCI, фиксируется, поскольку порты контроллера проверяются драйвером в порядке номеров портов.
Но в системе, подключенной к хранилищу SAN, все не так просто. Может быть несколько контроллеров дисков (один для внутренних системных дисков, затем по одному для каждого HBA SAN), и во время загрузки HBA обычно проверяются в порядке шины PCI, затем LUN в каждом HBA обнаруживаются в порядке, зависящем от драйвера, который может также зависят от конфигурации SAN. Порядок в одном HBA может быть основан на идентификаторах WWID LUN или некоторых других деталях конфигурации хранилища.
И нет заранее выделенных диапазонов /dev/sd* имена для каждого HBA: как только LUN каждого HBA будут присвоены имена, система перейдет к следующему HBA, не оставляя пробелов в /dev/sd* имена.
Один раз /dev/sd* имя было назначено диску или LUN, его нельзя автоматически переназначить для указания на другой LUN во время работы системы, иначе файловые системы или базы данных могут быть повреждены. Такое переназначение во время работы системы всегда должно включать системного администратора. Только во время загрузки их можно переназначить автоматически.
В результате, когда администратор SAN представляет новый LUN для вашей системы, его WWID обязательно должен быть уникальным, но значение WWID может быть до, после или посередине ваших существующих LUN. Когда он добавлен в горячем режиме, каждый путь к нему получит следующий бесплатный /dev/sd* имя устройства, поэтому они будут идти после всех существующих LUN. Даже это само по себе практически гарантирует, что заказ /dev/sd* имена изменятся при следующей загрузке системы.
Конечно, вы можете использовать правила udev, чтобы исправить /dev/sda* имена для конкретных HBA и WWID, если хотите ... но это большая работа для очень небольшой выгоды. Все /dev/sd* Предполагается, что устройства работают точно так же, как и ядро: если вы обнаружите, что это не так, вы обнаружили ошибку и должны сообщить о ней. Следовательно, нет необходимой причины, почему их порядок должен иметь значение.
Разработчики ядра Linux осознали это во время цикла разработки 2.5. *, Поскольку они пытались снять любые ограничения на возможность настройки в режиме онлайн. Теперь есть способы сделать конфигурацию вашей системы полностью независимой от /dev/sd* имена:
Если вы используете традиционные перегородки, вы можете использовать /dev/disk/by-* имена устройств вместо /dev/sd* устройства или используйте UUID= или LABEL= синтаксис в /etc/fstab.
Если вы используете LVM, он даже не хранит имена устройств постоянно, а ищет подписи LVM на любом диске и разделе, который он может видеть, а затем динамически создает конфигурацию оттуда. Это происходит автоматически при загрузке, и каждый раз, когда вы запускаете vgscan. (И да, существуют меры безопасности, которые предотвращают изменение сопоставлений LVM, пока диски используются.)
Если вы используете multipathing, он представляет многопутевые LUN либо по их WWID (если friendly_names отключен), пользователем /dev/mapper/mpath* имена назначаются, когда каждый WWID виден в первый раз, а затем постоянно сохраняются в /etc/multipath/wwids (или /var/lib/multipath/bindings в RHEL / CentOS 6 и ранее, что оказалось ошибкой, если /var это отдельная файловая система ...) или псевдонимами, которые вы можете назначить самостоятельно по WWID.
Однажды мне пришлось администрировать старую систему RHEL 3, к которой были подключены диски SAN. Первоначально у него был только один адаптер главной шины; затем был добавлен еще один HBA-адаптер для резервирования и миграции SAN ... но он был от другого поставщика, поэтому решения для нескольких маршрутов для конкретных поставщиков не были доступны. Мне пришлось использовать (с тех пор заброшенную) функцию многопутевости mdadm. Требовалось отслеживать имена устройств, скорее похожие на то, что вы думаете. Два слова: Это отстой. Я был очень счастлив, когда эта система окончательно устарела.