Расскажите про варианты срастить FC SAN и Proxmox, пожалуйста.

Тут ребята хотят вывести Proxmox и привести VMware

какие молодцы! 😏

А в чем проблема?
Берешь Host Connectivity Guide for Linux от своей хранилки и все делаешь так, как там написано.

Есть более развёрнутый вариант ответа? Я считай совсем не в теме. Я, например, не понимаю, будет ли FC коммутатор прозрачен для proxmox. Далее, что насчёт multipath? Хранилку мы прикручиваем к host-OS, это ясно. Оно в системе будет видно как что? Что это будет? Просто блочное устройство или что? Совсем нет понимания (( На пальцах бы кто пояснил ((

По твоим ключевым словам нашлось https://www.delltechnologies.com/asset/en-us/products/storage/technical-suppo...

Оно?

Вам нужно смотреть в сторону mpath

Коммутатор для хоста будет прозрачен.

На хосте диск будет виден как локальный диск по пути /dev/mapper/mpath или /dev/mapper/[WWNID] (в зависимости от настроек в multipath.conf).

Multipath настраивается одним файлом - /etc/multipath.conf. Судя по вопросам, которые тут люди задавали по Proxmox, multipath там включен из коробки, так что диски у тебя скорее всего увидятся сразу. Проверь, что путей к диску именно столько, сколько должно быть (multipath -l).

В Host connectivity guide для твоей модели хранилки описана настройка multipath. В частности, рекомендованные опции в /etc/multipath.conf.

Лучше залогиниться на сайт EMC, найти там модель этой хранилки, и скачать Host Connectivity Guide оттуда.

В том гайде, который ты нашел, описаны EMC’шные хранилки. А твоя - это OEM от DotHill, судя по ушам. Лучше прямо от нее доку брать.

Спасибо!

Вот правильный гайд: https://downloads.dell.com/manuals/common/powervault-me4-series-linux-3924-bp-l_en-us.pdf

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

Иногда блочное устройство не появляется, но в kernel log падает сообщение о необходимости вручную сканировать шину - echo «- - -» > /sys/class/scsi_host/host3/scan (номер хоста естественно будет другой).

Далее multipath по вкусу, multipath -ll

mpPool3 (3600140568f9dd3a139448558bf0523e6) dm-20 LIO-ORG,Pool3
size=2.0T features='0' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| `- 3:0:1:3 sde 8:64 active ready running
`-+- policy='round-robin 0' prio=50 status=enabled
  `- 4:0:0:3 sdf 8:80 active ready running

Это, например, linux для linux экспортирует диски через FC 8G

Для некоторых хранилок рекомендованные вендором опции отличаются от тех, что вкомпилены в multipath. Причем выясниться это может в самый неподходящий момент, когда случится отказ пути, и окажется, что failover на другой путь не отрабатывает (или отрабатывает не так быстро, как этого ожидает ОС или кластерный софт). Так что гайд нужен.

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

Не совсем понял, что надо пояснить, но попробую :)
Вот, например, смотрим на вывод «multipath -ll» двумя постами выше. Там 2 пути: один из них активный (status=active, по нему идет ввод/вывод), второй ждет своего часа (отказа активного пути). При отказе активного пути multipath может сразу (на самом деле не сразу, секунд на 15 ввод/вывод колом встанет по любому, но для простоты будем считать, что сразу), переключиться на другой путь, а может и накапливать I/O реквесты некоторое время в очереди, в надежде, что путь поднимется. Все это управляется опциями multipath. Для ОС и особенно кластерного софта отказ пути в зависимости от опций multipath может оказаться не прозрачным. Для разных массивов эти дефолтные опции, вкомпиленные в multipath, отличаются, и могут быть не те, что рекомендует вендор.

Другой пример - вендор может давно поддерживать и рекомендовать политику round-robin, а в multipath для данного массива до сих пор вкомпилен alua.