Определите LUN на сервере Redhat
Я унаследовал среду, в которой не было маскировки LUN или правильного зонирования. С учетом сказанного мне нужно определить правильные номера LUN, представленные на конкретном сервере. Я вижу 6 LUN, если я запускаю "fdisk -l". Один из этих LUN является "новым", который я добавил, но, конечно, я не могу сказать, какой это, так как размеры одинаковы. Я предполагаю, что самое простое, что нужно сделать, это удалить LUN и посмотреть, какой из них исчез, но кто знает, изменится ли порядок раздела (например, с sde на sdf?).
Еще один вопрос, я заметил, что на сервере есть /dev/sdg и /dev/sdf, и они идентичны, я знаю, потому что я смог смонтировать оба и показать идентичные данные. Это почему?
2 ответа
Что касается нескольких идентичных LUN, я предполагаю, что это связано с многолучевым распространением. Если это так, то вполне вероятно, что ваши шесть записей через fdisk - это всего 3 LUN.
Попробуйте немного заглянуть в DM-Multipath и посмотреть, используется ли он: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/DM_Multipath/
DM-Multipath - это путь, если ваше хранилище не представлено поставщиком (таким как EMC), который предоставляет свое собственное решение для многолучевого распространения (Powerpath в случае EMC).
Это не будет проблемой, какие устройства вы устанавливаете, если вы можете быть уверены, что они не изменятся, но вы не можете. В случае сбоя пути или предоставления дополнительного хранилища LUN, находящийся за /dev/sdc, может оказаться в /dev/sdd или что-то еще, если вы перезагрузитесь. Можно смонтировать и поработать немного, но небезопасно оставлять его без присмотра надолго.
Как минимум, вы можете использовать udev, чтобы обеспечить постоянное присвоение имен устройствам при перезагрузках и изменениях в среде, но это не заменяет правильного многопутевого преобразователя, который обеспечит вам восстановление после сбоя и балансировку нагрузки.
Вы действительно должны поработать над зонированием и маскированием в SAN - производительность, вероятно, пострадает, если зонирование будет неправильным, и существует риск случайного уничтожения данных, если маскирование не является правильным.