LINUX.ORG.RU
Форум — Admin  

open-iscsi, multipath и active/passive iSCSI

 ,


0

3

Имеется хранилка HPE EVA 6530 (2 контроллера HSV430 с iscsi мезонинами). Контроллеры умеют FC и через мезонины – iSCSI. Инициаторы по FC и iSCSI – debian. Когда мы подключаемся к обоим контроллерам по FC, мы видим LUN по обоим путям. Когда по iSCSI – только по одному, тому, который связан с «активным» для данного LUN контроллера. Когда мы перезагружаем один контроллер (активный), мы не получаем LUN по пути, связанному с пассивным контроллером, как следствие – multipath имеет по-прежнему один путь в состоянии faulted, через таймаут – ошибки I/O и всё ломается до выхода в онлайн активного контроллера. Вопрос: такая ситуация нормальна? Умеет ли open-iscsi получать LUN с пассивного контроллера? Или нужны какие-то плагины, волшебные команды, или вовсе ничего не поможет?

← Перенаправить трафик через другой сервер
Групповые политики Ubuntu+Samba →
Ответ на: комментарий от etwrq

Да вот я не очень понимаю, похоже, это дело схд – перероутить луны на оставшийся контроллер, или это дело клиента-инициатора – как-то их с этого оставшегося контроллера запросить. Я тут тут наткнулся на доку по Dell Compellent, так там явно расписано, что при отказе одного из контроллеров СХД сама перенаправляет луны на второй. Пытаюсь понять, это у всех так должно быть или кто во что горазд. Так понимаю, если схд ALUA-совместима, то луны должны быть по всем путям, просто частично м.б. в standby, но они хотя бы должны быть видны. Тут же до multipath дело не доходит, ибо нет всех путей. Есть только половина. А вот scsi controller есть по числу сессий.

olegkrutov ★★
() автор топика
Ответ на: комментарий от olegkrutov

а топология какая?
в самом простом случае - головы синкаются, голова/линк пропадают - оставшаяся анонсирует себя мастером по целым линкам, у клиента мелкий фриз, а если тайминги подобранны нормально то и клиент не заметит

etwrq ★★★★★
()
Ответ на: комментарий от etwrq

Топология – каждый мезонин даром что привязан к своему контроллеру, но имеет перекрестный линк к соседскому fc-iscsi мультиплексору. То есть грубо говоря, один контроллер внутри имеет fc wwpn 500…a0, a1, a2, a3, а второй – 500..a8, a9, aa, ab. Мезонин на первом имеет линк к a0, a1, a8, a9. На втором к aa, ab, a2, a3. Это видно по iqn таргетов. Я цепляюсь к таргетам от a0, a8, a2, aa. И устройства есть только в сессиях от первого контроллера (a0, a2). Если его ребутнуть, то эти устройства делаются faulted в multipath с соответствующими сообщениями в сислоге, а новых от второго контроллера не появляется. Точно не скажу, но ребут контроллера занимает несколько минут. Пробовал ресканить в это время сессии с таргетами от второго контроллера, ничего не получилось, то есть сессии есть, устройств нет.

olegkrutov ★★
() автор топика
Последнее исправление: olegkrutov (всего исправлений: 1)
Ответ на: комментарий от olegkrutov

Это дело инициатора. На клиенте может просто HBA сломаться, и что, СХД должна на это реагировать? Ну бред же. Поэтому это дело хоста. Он должен видеть все пути.

Я тут тут наткнулся на доку по Dell Compellent, так там явно расписано, что при отказе одного из контроллеров СХД сама перенаправляет луны на второй.

Тут видимо имеется ввиду то, что другой контроллер становится владельцем LUN’а.

bigbit ★★★★★
()
Ответ на: комментарий от olegkrutov

что-то мисконфигурация по отношению к инициатору.
если сами админите - сделайте нормальную конфигурацию, иначе подрядчику сделайте заявку соответствующую.
имхо, луны не анонсированы через вторую голову - ей нечего сказать на failover.
ну и рандому на админство давать сходу HPE EVA 6530, такое)))

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от etwrq

А нормальная конфигурация это какая? Там в интерфейсе схд указано, что лун принадлежит контроллеру 1. Ну станет он принадлежать контроллеру 2, ситуация же будет зеркальная. Нет варианта принадлежать 1 и 2 контроллерам.

olegkrutov ★★
() автор топика
Ответ на: комментарий от bigbit

Так можно 2, 4, … hba иметь, разнести их по подсетям не проблема. Вот вопрос, как заставить его видеть это пути. Встречал в инете фразы, что с активной/пассивной схд так не получится, вот и пытаюсь понять, так ли это.

olegkrutov ★★
() автор топика
Ответ на: комментарий от olegkrutov

Активныо/пассивных СХД уже давным-давно нет, больше 10 лет точно.

Хотя даже там клиент должен видеть все пути. Разница с ALUA только в том, что ввод/вывод по неактивному пути не возможен до тех пор, пока хост (именно хост!) не скажет СХД активировать его.

Короче, хост должен видеть пути по-любому. Даже если это active/passive. Но у тебя ALUA, так что непонятно, откуда сомнения, должен видеть хост пути или нет.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

А их не перебросить. Контроллер 1 указан информационно. Можно указать в пункте Preferred path/mode конкретного vdisk варианты:

  • No preference
  • Path A Failover only
  • Path A Failover/Failback
  • Path B Failover only
  • Path B Failover/Failback

Если это изменить, меняется конфигурация ALUA LUN (A/N), но только в тех же iscsi сессиях. В сессиях пассивного контроллера присутствует только LUN 0 («storage» в терминах lsscsi). В сессиях активного – и LUN 0, и LUN 1, т.е. и storage, и disk. От безнадёги пробовал sg_start натравить на LUN 0, но без толку.

При этом через FC с той же СХД видны LUN с обоих контроллеров, судя по WWPN. С активного – active, prio=50, с пассивного – enabled, prio=10.

Команды sg_rtpg показывают, что и через iSCSI, и через FC у каждого диска есть 2 TPG по 4 target ports, первая TPG – активный контроллер, 2 – пассивный. Обе эти TPG видны через FC и только одна – через iSCSI. Получается, пассивные пути не проходят через iSCSI мультиплексоры, или я что-то не то делаю.

Пробовал указать разные типы клиентов в админке СХД, там можно задать разные ОС, в надежде, что активируется некий набор фич, недоступный для linux клиентов с т.з. СХД, но это ни к чему не привело.

olegkrutov ★★
() автор топика
Ответ на: комментарий от iliyap

Controller 1 FC ports:

500143801139abe8 -> iscsi
500143801139abe9 -> iscsi
500143801139abea -> FC fabric
500143801139abeb -> FC fabric, disconnected

Controller2 FC ports:

500143801139abec -> iscsi
500143801139abed -> iscsi
500143801139abee -> FC fabric
500143801139abef -> FC fabric, disconnected

iSCSI mezzanines:

controller 1:

192.168.150.50
192.168.150.51
192.168.150.52
192.168.150.53

controller2:

192.168.150.54
192.168.150.55
192.168.150.56
192.168.150.57

iscsiadm -m node:

192.168.149.100:3260,4294967295 iqn.2002-03.com.compellent:5000d31004a4f45b
192.168.150.50:3260,4294967295 iqn.2004-09.com.hp:fcgw.mez50.1.01.500143801139abe8
192.168.150.51:3260,4294967295 iqn.2004-09.com.hp:fcgw.mez50.1.02.500143801139abec
192.168.150.54:3260,4294967295 iqn.2004-09.com.hp:fcgw.mez50.2.01.500143801139abe9
192.168.150.55:3260,4294967295 iqn.2004-09.com.hp:fcgw.mez50.2.02.500143801139abed

iscsiadm -m session:

tcp: [1] 192.168.150.54:3260,0 iqn.2004-09.com.hp:fcgw.mez50.2.01.500143801139abe9 (non-flash)
tcp: [2] 192.168.149.100:3260,0 iqn.2002-03.com.compellent:5000d31004a4f45b (non-flash)
tcp: [3] 192.168.150.51:3260,0 iqn.2004-09.com.hp:fcgw.mez50.1.02.500143801139abec (non-flash)
tcp: [4] 192.168.150.55:3260,0 iqn.2004-09.com.hp:fcgw.mez50.2.02.500143801139abed (non-flash)
tcp: [5] 192.168.150.50:3260,0 iqn.2004-09.com.hp:fcgw.mez50.1.01.500143801139abe8 (non-flash)

ls -l /sys/class/scsi_device:

lrwxrwxrwx 1 root root 0 окт 23 01:47 0:0:0:0 -> ../../devices/pci0000:00/0000:00:02.2/0000:03:00.0/host0/scsi_host/host0/port-0:1/end_device-0:1/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:0:0 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-16/target1:0:0/1:0:0:0/scsi_device/1:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:0:1 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-16/target1:0:0/1:0:0:1/scsi_device/1:0:0:1
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:0:2 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-16/target1:0:0/1:0:0:2/scsi_device/1:0:0:2
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:0:3 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-16/target1:0:0/1:0:0:3/scsi_device/1:0:0:3
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:0:4 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-16/target1:0:0/1:0:0:4/scsi_device/1:0:0:4
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:1:0 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-17/target1:0:1/1:0:1:0/scsi_device/1:0:1:0
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:1:1 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-17/target1:0:1/1:0:1:1/scsi_device/1:0:1:1
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:1:2 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-17/target1:0:1/1:0:1:2/scsi_device/1:0:1:2
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:1:3 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-17/target1:0:1/1:0:1:3/scsi_device/1:0:1:3
lrwxrwxrwx 1 root root 0 окт 23 01:47 1:0:1:4 -> ../../devices/pci0000:00/0000:00:02.0/0000:04:00.2/host1/rport-1:0-17/target1:0:1/1:0:1:4/scsi_device/1:0:1:4
lrwxrwxrwx 1 root root 0 окт 23 01:47 3:0:0:0 -> ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.1/2-1.3.1:1.0/host3/target3:0:0/3:0:0:0/scsi_device/3:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:49 4:0:0:0 -> ../../devices/platform/host4/session1/target4:0:0/4:0:0:0/scsi_device/4:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:49 4:0:0:1 -> ../../devices/platform/host4/session1/target4:0:0/4:0:0:1/scsi_device/4:0:0:1
lrwxrwxrwx 1 root root 0 окт 23 01:49 5:0:0:1 -> ../../devices/platform/host5/session2/target5:0:0/5:0:0:1/scsi_device/5:0:0:1
lrwxrwxrwx 1 root root 0 окт 23 01:49 5:0:0:2 -> ../../devices/platform/host5/session2/target5:0:0/5:0:0:2/scsi_device/5:0:0:2
lrwxrwxrwx 1 root root 0 окт 23 01:49 6:0:0:0 -> ../../devices/platform/host6/session3/target6:0:0/6:0:0:0/scsi_device/6:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:49 7:0:0:0 -> ../../devices/platform/host7/session4/target7:0:0/7:0:0:0/scsi_device/7:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:49 8:0:0:0 -> ../../devices/platform/host8/session5/target8:0:0/8:0:0:0/scsi_device/8:0:0:0
lrwxrwxrwx 1 root root 0 окт 23 01:49 8:0:0:1 -> ../../devices/platform/host8/session5/target8:0:0/8:0:0:1/scsi_device/8:0:0:1
olegkrutov ★★
() автор топика
Последнее исправление: olegkrutov (всего исправлений: 1)
Ответ на: комментарий от olegkrutov

Видно, что через сессию 1 доступно два юнита (4:0:0:0 и 4:0:0:1) и через сессию 5 доступно два юнита (8:0:0:0 и 8:0:0:1). Эти сессии идут через разные порталы 192.168.150.54 и 192.168.150.50 соответственно. А эти порталы принадлежат разным головам СХД. Если 4:0:0:1 и 8:0:0:1 это блочные устройства, то multipathd должен был собрать из этих путей mpath устройство.

Почему через сессии 3 и 4 видно по одному юниту (6:0:0:0 и 7:0:0:0) – непонятно. Может быть надо сделать iscsiadm -m session --rescan для повторного REPORT LUNS?

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Я и пишу, что юниты x:0:0:0 – это не блочные устройства. Вот выхлоп lsscsi:

[0:0:0:0]    storage none                              -        
[1:0:0:0]    storage 500143801139abe0                  -        
[1:0:0:1]    disk    600143801259dcf30000a00000e90000  /dev/sda 
[1:0:0:2]    disk    600143801259dcf30001000000ed0000  /dev/sdb 
[1:0:0:3]    disk    600143801259dcf30000b00000260000  /dev/sdc 
[1:0:0:4]    disk    600143801259dcf30001100000200000  /dev/sdd 
[1:0:1:0]    storage 500143801139abe0                  -        
[1:0:1:1]    disk    600143801259dcf30000a00000e90000  /dev/sde 
[1:0:1:2]    disk    600143801259dcf30001000000ed0000  /dev/sdf 
[1:0:1:3]    disk    600143801259dcf30000b00000260000  /dev/sdg 
[1:0:1:4]    disk    600143801259dcf30001100000200000  /dev/sdh 
[3:0:0:0]    disk    none                              /dev/sdi 
[4:0:0:0]    storage 500143801139abe0                  -        
[4:0:0:1]    disk    600143801259dcf30000a00000fd0000  /dev/sdl 
[5:0:0:1]    disk    6000d31004a4f400000000000000012a  /dev/sdj 
[5:0:0:2]    disk    6000d31004a4f4000000000000000140  /dev/sdk 
[6:0:0:0]    storage 500143801139abe0                  -        
[7:0:0:0]    storage 500143801139abe0                  -        
[8:0:0:0]    storage 500143801139abe0                  -        
[8:0:0:1]    disk    600143801259dcf30000a00000fd0000  /dev/sdm

А multipath и собрал что мог, конечно. К нему вопросов нет. Вопрос изначально именно к тому, почему нет блочных устройств с пассивного контроллера по iscsi.

multipath -ll
3600143801259dcf30000a00000e90000 dm-0 HP,HSV340
size=1000G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 1:0:1:1 sde 8:64  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 1:0:0:1 sda 8:0   active ready running
3600143801259dcf30001000000ed0000 dm-1 HP,HSV340
size=150G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 1:0:0:2 sdb 8:16  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 1:0:1:2 sdf 8:80  active ready running
3600143801259dcf30001100000200000 dm-6 HP,HSV340
size=1000G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 1:0:0:4 sdd 8:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 1:0:1:4 sdh 8:112 active ready running
36000d31004a4f4000000000000000140 dm-11 COMPELNT,Compellent Vol
size=500G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  `- 5:0:0:2 sdk 8:160 active ready running
3600143801259dcf30000a00000fd0000 dm-13 HP,HSV340
size=1000G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 4:0:0:1 sdl 8:176 active ready running
  `- 8:0:0:1 sdm 8:192 active ready running
3600143801259dcf30000b00000260000 dm-5 HP,HSV340
size=1000G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 1:0:1:3 sdg 8:96  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 1:0:0:3 sdc 8:32  active ready running
36000d31004a4f400000000000000012a dm-12 COMPELNT,Compellent Vol
size=1.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  `- 5:0:0:1 sdj 8:144 active ready running
olegkrutov ★★
() автор топика
Последнее исправление: olegkrutov (всего исправлений: 1)
Ответ на: комментарий от olegkrutov

Вот юнит wwid= 3600143801259dcf30000a00000fd0000 с двумя путями на разные головы. Значит для этого юнита с путями порядок? Или тоже не порядок? Ты говорил, что ни один юнит не виден с двух голов одновременно. Это так или не так?

iliyap ★★★★★
()
Ответ на: комментарий от etwrq

Это да, но тем не менее по этой доке оно умеет обрабатывать i/o по обоим головам и двигать диски на разные головы согласно большей нагрузке, в пункте про implicit lun transition так сказано. Только не сказано, что это только fc касается, т.к. по iscsi с fc портов пассивной головы (не управляющей данным диском) эти диски вовсе не видны, получается. Но более-менее суть проясняется, спасибо. Я натыкался только на какой-то огрызок доки, признаться.

olegkrutov ★★
() автор топика
Ответ на: комментарий от olegkrutov

i/o по обоим головам

дока как раз и говорит, что луна через две головы не будет ни при каком случае, читайте внимательно. емнип там no prefer - активная голова где нагрузка больше, A/B options - просто группировка лунов на голове. там, вроде бы нету ни слова о 2х12гб нагрузке в round-robin(active/active) - ну тупо что бы потребителю из all-flash выдавать 24гб/с, по обоим линкам. эхехехех прогрев от hpe, классика. незнаю есть ли опция купить блоб/расширить лицензию на active/active.
для примера - у сантехников лет 15 тому назад в базе было active|active(емнип, 35хх серия, одм - storagetek, до покупки сантехниками), правда сам блоб был специфичный, и мягко говоря прип*ный

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 3)
Ответ на: комментарий от etwrq

Так вот же цитата. Типа диски видятся через оба контроллера, просто пассивный для данного диска шлёт запрос на активный, который только и может слать запрос на сам диск, ну т.е. такое alua, как я понимаю. А чтоб запрос послать, нужен же сам диск, scsi блочное устройство. Вот и у меня через FC тоже диски видны с обоих контроллеров. В выхлопе выше, например, 1:0:0:1 и 1:0:1:1 – один диск с активного, а другой с пассивного. А вот по iscsi не так, о том и вопрос был.

When creating a virtual disk, one controller is selected to manage the virtual disk. Only this managing controller can issue I/Os to a virtual disk in response to a host read or write request. If a read I/O request arrives on the non-managing controller, the read request must be transferred to the managing controller for servicing. The managing controller issues the I/O request, caches the read data, and mirrors that data to the cache on the non-managing controller, which then transfers the read data to the host. Because this type of transaction, called a proxy read, requires additional overhead, it provides less than optimal performance.

olegkrutov ★★
() автор топика
Ответ на: комментарий от iliyap

То есть подробней: 3600143801259dcf30000a00000fd0000 состоит из двух устройств 4:0:0:1 и 8:0:0:1 (sdl, sdm).

4:0:0:1 -> session 1 -> 192.168.150.54:3260,0 iqn.2004-09.com.hp:fcgw.mez50.2.01.500143801139abe9 (это мезонин, стоящий на втором контроллере, но соединённый с FC первого контроллера)

8:0:0:1 -> session 5 -> 192.168.150.50:3260,0 iqn.2004-09.com.hp:fcgw.mez50.1.01.500143801139abe8 (мезонин на первом контроллере и соединённый с его же FC портом)

olegkrutov ★★
() автор топика
Последнее исправление: olegkrutov (всего исправлений: 1)
Ответ на: комментарий от olegkrutov

Цитата из доки: «iSCSI connected servers can be configured for access to one or both controllers.»

(это мезонин, стоящий на втором контроллере, но соединённый с FC первого контроллера)

Не понял, зачем первый контроллер соединен со вторым?

В моем понимании, есть 2 контроллера. У каждого контроллера есть FC-порты и iSCSI порты. Какие еще мезанины?

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от bigbit

Ну такое там устройство. Базовый функционал там fc, а плюс там есть iscsi или iscsi/fcoe мезонины (это их терминология), которые цепляются к fc портам своего и соседнего контроллера. Для отказоустойчивости, как я понимаю. И контроллеры внутри соединены через, кажется, fc. Это как минимум для того, чтоб можно было обработать запрос с контроллера, не управляющего данным диском. Выше я привёл цитату из доки, как это происходит.

olegkrutov ★★
() автор топика
Ответ на: комментарий от router

А там не выбрать, с какого порта презентовать, с какого нет. Есть инициатор, которому презентуем, есть обслуживающий контроллер (тоже не выбрать). Есть боксик iSCSI Path/LUN id или как-то так, но он не активен. При этом, повторюсь, по FC отдаётся с обоих контроллеров. Ну там и группы хостов свои, понятно.

olegkrutov ★★
() автор топика
Ответ на: комментарий от router

Есть, да. Но там просто можно понять, какой таргет смотрит на какой FC порт, и следовательно, на какой контроллер (но это и из имени таргета понятно): Первый мезонин:

  iSCSI Presented Targets
  -------------------------
  Name     iqn.2004-09.com.hp:fcgw.mez50.1.01.500143801139abe8
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e8 
  VPGroup  1

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.01.500143801139abec
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ec 
  VPGroup  1

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.02.500143801139abe8
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e8 
  VPGroup  2

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.03.500143801139abe8
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e8 
  VPGroup  3

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.04.500143801139abe8
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e8 
  VPGroup  4

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.02.500143801139abec
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ec 
  VPGroup  2

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.03.500143801139abec
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ec 
  VPGroup  3

  Name     iqn.2004-09.com.hp:fcgw.mez50.1.04.500143801139abec
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ec 
  VPGroup  4

MEZ50 (admin) #>

Второй:

 ------------------------------                                                                                                                                                      [0/117]

  iSCSI Presented Targets
  -------------------------
  Name     iqn.2004-09.com.hp:fcgw.mez50.2.01.500143801139abed
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ed 
  VPGroup  1

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.02.500143801139abed
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ed 
  VPGroup  2

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.03.500143801139abed
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ed 
  VPGroup  3

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.04.500143801139abed
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:ed 
  VPGroup  4

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.01.500143801139abe9
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e9 
  VPGroup  1

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.03.500143801139abe9
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e9 
  VPGroup  3

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.04.500143801139abe9
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e9 
  VPGroup  4

  Name     iqn.2004-09.com.hp:fcgw.mez50.2.02.500143801139abe9
  Alias    
  <MAPS TO>
  WWNN     50:01:43:80:11:39:ab:e0 
  WWPN     50:01:43:80:11:39:ab:e9 
  VPGroup  2

И кнопка More есть, только опять же там ничего не изменить.

olegkrutov ★★
() автор топика
Последнее исправление: olegkrutov (всего исправлений: 1)
Ответ на: комментарий от router

Да знаю я, что такое мезонин. Просто не думал, что ТС внутрь СХД полез. Внутрь обычно только сервисные инженеры лазают. Думал, мало ли, может чего снаружи присобачено. СХД с мезонином =)

bigbit ★★★★★
()
Ответ на: комментарий от olegkrutov

И контроллеры внутри соединены через, кажется, fc

Обычно через PCI-E соединяются. Поэтому кросс-линк между портами и показался мне странным. Это же не ты мезонины подсоединял, а специально обученный человек из HPE?

bigbit ★★★★★
()
Ответ на: комментарий от olegkrutov

И кнопка More есть, только опять же там ничего не изменить.

Не изменить ладно. Там хотя бы можно увидеть список таргетов, с которых доступен этот lun данному хосту

Если там все 4 (8?) по разным контроллерам, тогда копай дальше в сторону хоста

А вот если то, что ты там видишь, совпадает с тем, что видит хост (только один target для проблемных lun’ов или только один контроллер), тогда косяк на стороне презентации с массива

Но там просто можно понять, какой таргет смотрит на какой FC порт, и следовательно, на какой контроллер (но это и из имени таргета понятно)

Там ещё какая-то vpgroup. Насколько я понимаю, это набор портов, который будет виден в презентации lun’а

В общем, сначала нужно убедиться, что со стороны массива диск выдан хосту по нужным путям (через разные контроллеры), а уже потом искать эти пути на хосте

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Не оч понятно, как это сделать. Есть окно презентации, можно выбрать хост, тип хоста, а контрол «iSCSI path» не выбирается. Даже если б выбиралось, так через FC же диски видны с обоих контроллеров. А в More… относительно хоста ISCSI MPX, который автоматом добавляется, видно, что он гейтует FC порты обоих контроллеров (..e8, e9 –первый, ec, ed – второй.) В свойствах самого ISCSI MPX сказано про 2 ISCSI контроллера, но не сказано про основные контроллеры. Фигня какая-то, в общем.

olegkrutov ★★
() автор топика
← Перенаправить трафик через другой сервер
Admin
Групповые политики Ubuntu+Samba →