пропало мапирование лунов в иос


Главная Форумы Storage SAN, Disk & Tape пропало мапирование лунов в иос

В этой теме 30 ответов, 6 участников, последнее обновление  Вадим 7 года/лет, 6 мес. назад.

  • Автор
    Сообщения
  • #8501

    Вадим
    Участник

    Добрый день, после обновления VIOSа столкнулся с проблемой в проброске лунов с дискового хранилища в виос (в последствии в систему)
    сервер находится в HACMP кластере по этому пока работает на резервной ноде, на боевой произошло следующее
    показания VIOS боевой ноды

    # fget_config -Adv

    —dar0—

    User array name = ‘DS4700_2’
    dac4 ACTIVE dac6 ACTIVE

    Disk DAC LUN Logical Drive
    hdisk4 dac6 0 TWCMS01_BOOT
    hdisk5 dac6 1 ERP02_boot
    hdisk6 dac6 2 ERP02_PG
    hdisk7 dac6 3 ERP_HB
    hdisk8 dac4 4 T24_HB
    hdisk9 dac6 5 TWCMS_HB
    hdisk10 dac4 6 TWO_HB

    —dar1—

    User array name = ‘DS4700_1’
    dac5 ACTIVE dac7 ACTIVE

    Disk DAC LUN Logical Drive
    hdisk11 dac7 0 T24_DATA
    hdisk12 dac7 1 ERP_BIN
    hdisk13 dac7 2 ERP_DATA
    hdisk14 dac7 3 DI_LOCAL_01
    hdisk15 dac7 4 DI_LOCAL_02
    hdisk16 dac7 5 TWCMS_ORA_BIN
    hdisk17 dac7 6 TWCMS_ORA_DATA
    hdisk18 dac7 7 TWO_ORA_BIN
    hdisk19 dac7 8 TWO_ORA_DATA

    $ lspv
    NAME PVID VG STATUS
    hdisk0 00c0e9a42c7a581b rootvg active
    hdisk1 00c0e9b48be8410b rootvg active
    hdisk2 00c0e9a48be27f75 datavg active
    hdisk3 00c0e9a42e464a2c datavg active
    hdisk4 00c0e9a4334de73f None
    hdisk5 00c0e9a4334f87e2 None
    hdisk6 00c0e9a49dc60633 None
    hdisk7 00c0e9945681a0bc None
    hdisk8 00c0e9943c72680d None
    hdisk9 00c0e9a45a743dc3 None
    hdisk10 00c0e9945fbdadf6 None
    hdisk11 00c0e9943c67cd57 None
    hdisk12 00c0e994568bbb64 None
    hdisk13 none None
    hdisk14 none None
    hdisk15 00c0e9a456855fde None
    hdisk16 00c0e9a45a7b6e71 None
    hdisk17 00c0e9a45a7c1022 None
    hdisk18 00c0e9945fce5f06 None
    hdisk19 00c0e9945fcc88b1 None

    вобщем то вопрос куда делись диски hdisk13 и hdisk14
    пробовал удалять все мапинги дисков в виртуальные разделы и удалять диски после чего cfgmgr но это не помогает, картина аналогичная, тоесть в позиции hdisk13 и hdisk14 стоит None

  • #8507

    Вадим
    Участник

    # lsattr -El hdisk13
    PR_key_value none Persistant Reserve Key Value True
    cache_method default Write Caching method False
    ieee_volname 600A0B8000505F24000007CF4A9666AA IEEE Unique volume name False
    lun_id 0x0002000000000000 Logical Unit Number False
    max_transfer 0x100000 Maximum TRANSFER Size True
    prefetch_mult 0 Multiple of blocks to prefetch on read False
    pvid none Physical volume identifier False
    q_type simple Queuing Type False
    queue_depth 10 Queue Depth True
    raid_level 0 RAID Level False
    reassign_to 120 Reassign Timeout value True
    reserve_policy single_path Reserve Policy True
    rw_timeout 30 Read/Write Timeout value True
    scsi_id 0x20700 SCSI ID False
    size 2899838150 Size in Mbytes False
    write_cache no Write Caching enabled False
    #
    # lsattr -El hdisk10
    PR_key_value none Persistant Reserve Key Value True
    cache_method default Write Caching method False
    ieee_volname 600A0B8000505F0A000005504A8D5AF3 IEEE Unique volume name False
    lun_id 0x0006000000000000 Logical Unit Number False
    max_transfer 0x100000 Maximum TRANSFER Size True
    prefetch_mult 0 Multiple of blocks to prefetch on read False
    pvid 00c0e9945fbdadf60000000000000000 Physical volume identifier False
    q_type simple Queuing Type False
    queue_depth 10 Queue Depth True
    raid_level 5 RAID Level False
    reassign_to 120 Reassign Timeout value True
    reserve_policy single_path Reserve Policy True
    rw_timeout 30 Read/Write Timeout value True
    scsi_id 0x20400 SCSI ID False
    size 9 Size in Mbytes False
    write_cache no Write Caching enabled False

    вот еще что дает команда lsattr тоесть я явно вижу что почему то пропала строчка pvid как ее восстановить? (hdisk13 — потеряшка, hdisk10 нормальный)

  • #8511

    uxTuaHgp
    Участник

    А не в reserve_policy дело?
    Наверное надо в no_reserve ставить.

  • #8512

    Вадим
    Участник

    врядли, но попробую

  • #8513

    Вадим
    Участник

    # lsattr -El hdisk14
    PR_key_value none Persistant Reserve Key Value True
    cache_method default Write Caching method False
    ieee_volname 600A0B8000505F24000007CF4A9666AA IEEE Unique volume name False
    lun_id 0x0002000000000000 Logical Unit Number False
    max_transfer 0x100000 Maximum TRANSFER Size True
    prefetch_mult 0 Multiple of blocks to prefetch on read False
    pvid 00c0e9945b64c14a0000000000000000 Physical volume identifier False
    q_type simple Queuing Type False
    queue_depth 32 Queue Depth True
    raid_level 1 RAID Level False
    reassign_to 120 Reassign Timeout value True
    reserve_policy no_reserve Reserve Policy True
    rw_timeout 30 Read/Write Timeout value True
    scsi_id 0x20700 SCSI ID False
    size 409599 Size in Mbytes False
    write_cache yes Write Caching enabled False

    вот такое стоит на той ноде где этот диск виден
    тоесть политика резервирования на самом диске стоит правильная

  • #8521

    uxTuaHgp
    Участник

    а на другой стоит
    reserve_policy single_path
    ?

  • #8533

    Вадим
    Участник

    нет, стоит именно no_reserve
    14 — это на резервной ноде
    13 — это на боевой

  • #8537

    andrewk
    Участник

    у Вас два VIOS’а на сервере или один?
    LUN’ы Вы отдаете через оба VIOS’а или через один?

  • #8544

    Вадим
    Участник

    vios 1 штука на сервер
    резервная и боевая — это в понятиях HACMP
    вопрос простой, как восстановить связку между
    hdisk13 — и LUN ERP_DATA на хранилище

    в LPARы проброшены не виртуальные FC адаптеры а виртуальные диски (кстати возможно это одна из причин низкой скорости работы на i/o)
    т.е.
    к виосу подключены LUNы, которые мапируются в hdiskи которые в свою очередь через mkvdev мапируются через виртуальные scsi адаптеры пробрасываются в LPARы где тоже появляются соответсвующими volume grouppами, где собственно создаются разделы
    пропала связка между LUN=ERP_DATA и hdiskX (в моем случае 13), что не дает пробросить этот раздел внутрь LPAR

  • #8583

    andrewk
    Участник

    не понимаю, что восстанавливать надо. есть один кластер, состоящий из двух AIX LPAR’ов. есть два VIOS’а (по одному на сервер). есть сторедж.
    на сторедже нарезаны LUN’ы, они отдаются и мы их видим на VIOS’е (как минимум на одном из двух). до сих пор все хорошо.
    если один LUN отдается на два VIOS’а сразу же, то у него по определению должна стоять policy no_reserve, после чего можно его маппировать. так что выставляйте no_reserve для всех hdisk’ов, которые должны быть одновременно видны на двух VIOS’ах, и маппируйте их на здоровье. и никакой проблемы, честно говоря, я пока что не заметил.

  • #8587

    Вадим
    Участник

    проблема в том что VIOS номер 2 не видет эти луны
    на на VIOS номер 1, который видит луны, стоит правильная политика

  • #8588

    andrewk
    Участник

    значит, проблема зонинга или стореджа. проверяйте их.

  • #8589

    Вадим
    Участник

    вот с этого момента по подробнее 🙂
    если не сложно то примерно на пальцах обЪясните 🙂 и дайте ссылку на документацию 🙂
    Спасибо
    и еще один вопрос (хотя может стоит его вынести в отдельную тему)
    сейчас настроенно
    на хранилище лун AAA, хранилище подключено к серверу по файберу.
    на сервере стоит VIOS в нем настроенно мапирование луна из хранилища в вирутальный SCSI адаптер в разделе
    а если пробрасывать в раздел не LUN через виртуальный SCSI а виртуальный FC адаптер, будет ли такая схема быстрее?

  • #8593

    Michael
    Участник

    Вообще-то я бы сначала проверил, нет ли каких ошибок на сториджах и SAN-свитчах, а потом…

    У Вас диски в системе видны, но видны как новые, т. е. неиспользуемые.

    Может попытаться сделать importvg?

  • #8594

    Вадим
    Участник

    как бы сказать, эти диски напрямую как vg внутри виоса не фигурируют они сразу пробрасываются через virtual scsi внутрь партиций
    тоесть последовательность команд по мапированию примерно следующая

    mkvdev -vdev hdisk4 -vadapter vhost0 -dev rootvg_part1
    а внутри уже раздела
    Это является Vg rootvg откуда грузится система

  • #8597

    andrewk
    Участник

    схема с VFC, по идее, должна быть быстрее (сокращается один шаг), но лично у меня нет опыта, чтобы сказать, что быстрее. У меня есть кучка VIOS’ов с VFC и кучка VIOS’ов с VSCSI — ни на те, ни на другие не слышно много жалоб в плане производительности. но для этого Вам будут нужны 8Gbit FC HBA.
    объяснять на пальцах не буду, потому что не специалист в стореджах/зонингах, но — если виос чего-то не видет, в 99% случаев это вина неправильной настройки с другой стороны. в виосе просто нечего настраивать, чтобы он видел/не видел. максимальная проблема, с которой Вы можете столкнуться — свитч не видит WWPNы свежеустановленного VIOS’а и поэтому невозможно настроить зонинг. Решение — под корень удалить все связанные с FC HBA устройства и снова запустить cfgdev/cfgmgr. Зачастую можно даже без удаления обойтись.

  • #8598

    Serg
    Участник

    а lspath что выдает на vios-е?

  • #8610

    Вадим
    Участник

    # lspath
    Enabled hdisk0 sas0
    Enabled hdisk1 sas0
    Enabled hdisk2 sas0
    Enabled hdisk3 sas0

    на ноде где все пучком и работает

    на проблемной ноде
    # lspath
    Enabled hdisk0 sas0
    Enabled hdisk1 sas0
    Enabled hdisk2 sas0
    Enabled hdisk3 sas0
    Missing dac0 fscsi0
    Missing dac1 fscsi0
    Missing dac2 fscsi0
    Missing dac3 fscsi0

  • #8612

    Aleksandr
    Участник

    Я не знаю как у вас, но если на виосе hdisk не делать диски в аAIX команда вот такая в виосе не помню chdev -a pv=yes hdiskX nj pvid не появится. Однако работать с ним возможно.
    $ lspv
    NAME PVID VG STATUS
    hdisk0 00cf3e5c40a9bd9f rootvg active
    hdisk1 none None
    hdisk2 none None
    $ lsmap -all
    SVSA Physloc Client Partition ID
    ————— ——————————————— ——————
    vhost0 U9117.570.65F3E5C-V4-C3 0x00000003

    VTD vtscsi0
    Status Available
    LUN 0x8100000000000000
    Backing device vdisk0
    Physloc

    SVSA Physloc Client Partition ID
    ————— ——————————————— ——————
    vhost1 U9117.570.65F3E5C-V4-C4 0x00000005

    VTD vtopt0
    Status Available
    LUN 0x8200000000000000
    Backing device /var/vio/VMLibrary/dbcfw04cd
    Physloc

    VTD vtscsi1
    Status Available
    LUN 0x8100000000000000
    Backing device hdisk1
    Physloc U7879.001.DQDLNTB-P1-C3-T1-W50001FE15007A91C-L1000000000000

    VTD vtscsi2
    Status Available
    LUN 0x8300000000000000
    Backing device hdisk2
    Physloc U7879.001.DQDLNTB-P1-C3-T1-W50001FE15007A92C-L1000000000000

  • #8625

    Вадим
    Участник

    меня больше вот это напрягает
    Missing dac0 fscsi0
    Missing dac1 fscsi0
    Missing dac2 fscsi0
    Missing dac3 fscsi0

  • #8627

    Michael
    Участник

    А не возникло ли у Вас проблемки с дровами для оптики на этом сервере? Микрокод там не тот или версия драйверов SDD или RDAC чуток выбилась из колеи?

  • #8628

    Вадим
    Участник

    недавно все обновил
    sys0!system:EL350_063 (t) EL350_063 (p) EL350_063 (p)
    sissas0!53495320.02200070
    fcs2!df1000fe-0002.271315
    fcs3!df1000fe-0002.271315
    hdisk0!ST31468.A1700D11.45303130
    hdisk1!ST31468.A1700D11.45303130
    hdisk2!HUS1530.A1700D13.41343234
    hdisk3!ST31468.A1700D11.45303130
    cd0!IBM-DROM0020581.DA33
    fcs0!df1000fe-0002.271315
    fcs1!df1000fe-0002.271315

  • #8630

    Aleksandr
    Участник

    А может просто пути отъели или все таки недоступны и надо просто дать cfgdev?

  • #8633

    Вадим
    Участник

    через несколько дней простоя все вернулось на место 😉 вероятно всетаки чтото хулиганствует хранилище (его тоже нада видимо перешивать)

  • #8650

    Michael
    Участник

    Можете огласить модель DS и версию прошивки?
    То, что у Вас 4700, я догадываюсь, просмотрев начало обсуждения…

  • #8655

    Вадим
    Участник

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

  • #8656

    Michael
    Участник

    Насколько я помню, обсуждалось на форуме, что 7.50.13 приличное глюкалово и лучше либо следовать рекомендациям ИБМ-ов:
    «DS4700 Express
    Guidance for firmware (FW) selection:
    — In general, the recommended level of DS4700 controller FW is 07.36.17.00 and ESM FW 98D0 (1.67) for EXP810 enclosures and 9682 for the EXP710 enclosures.
    — DS4700 controllers using the 600GB disk drive module or requiring the latest interoperability must use firmware 07.60.28.00. New systems which ship with FW 07.50.13.00 or existing systems installed with FW 07.50.13.00 should be upgraded to 7.60.28.00 (see Retain Tip H196757).
    — The minimum controller FW for any DS4700 is 07.36.17.00 or 06.60.22.00 with ESM FW 98D0 (1.67) (EXP810), 9681 (EXP710), 9330 (EXP700) and 9565 (EXP100).
    — If upgrading a DS4700 system from 06.xx FW, you may only upgrade to either 07.36.17.00 or 07.60.28.00 level.
    — Storage Manager 10.60.x5.17 is the latest version and recommended for all FW levels.»

    Либо ставить последнюю на текущий момент 7.60.28. Наша 4700-я с ней не фулюганит 😉

  • #8658

    Вадим
    Участник

    ну к тому что придется шить, я уже пришел
    теперь бы примерный план действий расписать
    1. все забакапить (это действительно долгий процесс)
    2. начать прошивку сначала полок, потом головы
    3. возможно перешить винты (ксати их можно на горячую шить)
    и собственно что делать если вдруг все развалится?
    тоесть примерно и на пальцах, как восстановить настройки проброски лунов в vmware и в vios ?
    документацию и хаутушки я уже почитал 🙂 много воды, но и много очень полезной информации, единственное я так и не понял (ни в одной документации) нет ссылок на траблшутинг или по нашему по русски что делать если все упало

  • #8659

    Michael
    Участник

    1. Когда открываете сторидж в Storage Manager, там есть Storage subsystem -> Configuration -> Save. Надеюсь, пригодится для сохранения конфигурации сториджа 🙂

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

    Если всё успешно перепрошилось, а конфиг сториджа потёрся, то восстанавливаемся с предварительно сохранённого. Если данные на лунах убились, то Вас спасёт только восстановление с лент, если оно было сделано заранее.

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

  • #8661

    Вадим
    Участник

    тоесть можно не стопить даже сервера?
    упц, а вот это уже интересно

  • #8849

    Вадим
    Участник

    перепрошился, проблем не наблюдаю
    правда скорость работы так и не выросла!
    так же напрягает то что нету кеша на адаптерах 🙂 толи их небыло толи они выключенные

Для ответа в этой теме необходимо авторизоваться.