Умер диск в lpar из под Vios. Что делать?

Главная Форумы POWER Systems Умер диск в lpar из под Vios. Что делать?

Помечено: ,

Просмотр 37 веток ответов
  • Автор
    Сообщения
    • #39679
      Templar
      Участник

      Господа, если я правильно понимаю у меня умер hdisk0?

      lpar боевой!

      Файловая система в зеркале, работает из под dual vios.
      Какой порядок действий по замене диска? подскажите пожалуйста.

      Все команды в lpar. В errpt на vios ошибок нет.

      bash-3.00# lspv
      hdisk0 000520ffffda3ac2 rootvg active
      hdisk2 000520fffef457fc rootvg active

      bash-3.00# lsdev -Cc disk
      hdisk0 Available Virtual SCSI Disk Drive
      hdisk1 Defined Virtual SCSI Disk Drive
      hdisk2 Available Virtual SCSI Disk Drive

      bash-3.00# lsvg -l rootvg
      rootvg:
      LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
      hd5 boot 1 2 2 closed/stale N/A
      hd6 paging 4 8 2 open/syncd N/A
      hd8 jfs2log 1 2 2 open/stale N/A
      hd4 jfs2 2 4 2 open/stale /
      hd2 jfs2 103 206 2 open/stale /usr
      hd9var jfs2 4 8 2 open/stale /var
      hd3 jfs2 80 160 2 open/stale /tmp
      hd1 jfs2 1 2 2 open/stale /home
      hd10opt jfs2 16 32 2 open/stale /opt

      bash-3.00# lscfg -v | grep disk
      hdisk2 U9133.55A.655DC9H-V3-C4-T1-L820000000000 Virtual SCSI Disk Drive
      hdisk0 U9133.55A.655DC9H-V3-C3-T1-L810000000000 Virtual SCSI Disk Drive

      bash-3.00# bootlist -m normal -o
      hdisk0
      hdisk2 blv=hd5

      bash-3.00# bosboot -ad /dev/hdisk2

      0301-108 /usr/lib/boot/bin/mkboot_chrp: Unable to read file blocks. Return code: -1

      0301-158 bosboot: mkboot failed to create bootimage.

      0301-165 bosboot: WARNING! bosboot failed – do not attempt to boot device.

      bash-3.00# errpt
      IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
      EAA3D429 0127113017 U S LVDD PHYSICAL PARTITION MARKED STALE

    • #39680
      Templar
      Участник

      Прошу прощения на одном из виосов тоже все плохо:
      #errpt
      ksh:Invalid file system control data detected

      # lspv
      ksh: Invalid file system control data detected
      hdisk2 000520fffae529a7 rootvg active
      hdisk3 000520ffd402eff6 rootvg active

      # lsvg -l rootvg
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.

      Как правильно заменить сломавшийся диск?

    • #39681
      Michael
      Участник

      1. Проверить наличие гарантии/техподдержки на сервер.

      2.1. Если техподдержка есть, то открыть заявку в IBM и следовать инструкциям.

      2.2. Если же техподдержки нет, то…

    • #39682
      sdudnik
      Участник

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

       

      на лпаре нужно определить, был ли hdisk1 в rootvg

      lsvg -p rootvg

      и определить какие диски живы

      lquerypv -h /dev/hdiskX, где  X это номер диска

       

       

      • #39683
        Templar
        Участник

        Сервер 2006 года, гарантии никакой нет(

        Что-то мне страшно перезагружать lpar. Все началось с того что мне нужно было немного расширить раздел opt и вот что он выдал:
        bash-3.00# chfs -a size=5G /opt/
        lquerypv: Warning, physical volume hdisk0 is excluded since it may be
        either missing or removed.
        0516-404 allocp: This system cannot fulfill the allocation request.
        There are not enough free partitions or not enough physical volumes
        to keep strictness and satisfy allocation requests. The command
        should be retried with different allocation characteristics.
        0516-1734 extendlv: Warning, savebase failed. Please manually run ‘savebase’ before rebooting.

        Диск hdisk1 не в rootvg

        bash-3.00# lsvg -p rootvg
        rootvg:
        PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
        hdisk2 active 279 67 11..00..00..00..56
        hdisk0 missing 279 67 11..00..00..00..56

        bash-3.00# lquerypv -h /dev/hdisk0
        bash-3.00# lquerypv -h /dev/hdisk1
        bash-3.00# lquerypv -h /dev/hdisk2
        00000000 C9C2D4C1 00000000 00000000 00000000 |…………….|
        00000010 00000000 00000000 00000000 00000000 |…………….|
        00000020 00000000 00000000 00000000 00000000 |…………….|
        00000030 00000000 00000000 00000000 00000000 |…………….|
        00000040 00000000 00000000 00000000 00000000 |…………….|
        00000050 00000000 00000000 00000000 00000000 |…………….|
        00000060 00000000 00000000 00000000 00000000 |…………….|
        00000070 00000000 00000000 00000000 00000000 |…………….|
        00000080 000520FF FEF457FC 00000000 00000000 |.. …W………|
        00000090 00000000 00000000 00000000 00000000 |…………….|
        000000A0 00000000 00000000 00000000 00000000 |…………….|
        000000B0 00000000 00000000 00000000 00000000 |…………….|
        000000C0 00000000 00000000 00000000 00000000 |…………….|
        000000D0 00000000 00000000 00000000 00000000 |…………….|
        000000E0 00000000 00000000 00000000 00000000 |…………….|
        000000F0 00000000 00000000 00000000 00000000 |…………….|

        Такой диск на замену у меня в наличии есть…

    • #39684
      sdudnik
      Участник

      Имел ввиду перегружать не лпару, а виос. Опасения понятные, ибо если некорректо настроена отказоустойчивость, то лпара отвалиться.

      Судя по выводу отвалился hdisk0  на лпаре. Нужно убедиться с какого виоса он примаплен.

      можете прислать lspv с рабочего виоса? и вывод lsmap -all

      Еще нужен номер сбойно лпары, можно посмотреть из HMC.

       

    • #39685
      Templar
      Участник

      Lpar ID 3

      $ lsmap -all
      SVSA Physloc Client Partition ID
      ————— ——————————————– ——————
      vhost0 U9133.55A.655DC9H-V2-C5 0x00000003

      VTD vtopt0
      Status Available
      LUN 0x8100000000000000
      Backing device cd0
      Physloc U787B.001.DNWG06Z-P4-D2

      VTD vtscsi0
      Status Available
      LUN 0x8200000000000000
      Backing device dnsrootvg
      Physloc

      SVSA Physloc Client Partition ID
      ————— ——————————————– ——————
      vhost1 U9133.55A.655DC9H-V2-C6 0x00000004

      VTD vtscsi1
      Status Available
      LUN 0x8100000000000000
      Backing device nimrootvg
      Physloc

      SVSA Physloc Client Partition ID
      ————— ——————————————– ——————
      vhost2 U9133.55A.655DC9H-V2-C7 0x00000000

      VTD vtscsi2
      Status Available
      LUN 0x8100000000000000
      Backing device monrootvg
      Physloc

      $ lspv
      NAME PVID VG STATUS
      hdisk0 000520ffdacd05b9 rootvg active
      hdisk1 000520fffb00f594 rootvg active

    • #39686
      sdudnik
      Участник

      Еще вывод lsvg -lv rootvg с рабочего виоса

       

    • #39687
      Templar
      Участник

      $ lsvg -lv rootvg
      rootvg:
      LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
      hd5 boot 1 1 1 closed/syncd N/A
      hd6 paging 4 4 1 open/syncd N/A
      paging00 paging 8 8 1 open/syncd N/A
      hd8 jfs2log 1 1 1 open/syncd N/A
      hd4 jfs2 4 4 1 open/syncd /
      hd2 jfs2 30 30 1 open/syncd /usr
      hd9var jfs2 5 5 1 open/syncd /var
      hd3 jfs2 18 18 1 open/syncd /tmp
      hd1 jfs2 80 80 1 open/syncd /home
      hd10opt jfs2 14 14 1 open/syncd /opt
      lg_dumplv sysdump 8 8 1 open/syncd N/A
      hd11admin jfs2 1 1 1 open/syncd /admin
      livedump jfs2 2 2 1 open/syncd /var/adm/ras/livedump
      dnsrootvg jfs 280 280 1 open/syncd N/A
      nimrootvg jfs 280 280 1 open/syncd N/A
      monrootvg jfs 280 280 2 open/syncd N/A

    • #39688
      sdudnik
      Участник

      Получается следующая ситуация –  у каждого виоса по два диска, они НЕ в зеркале  ( это можно также проверить командой lslv -m hd4) и на них расположен rootvg виосов. Также в rootvg расположены логические тома

      <span style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;”>dnsrootvg jfs 280 280 1 open/syncd N/A</span><br style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;” /><span style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;”>nimrootvg jfs 280 280 1 open/syncd N/A</span><br style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;” /><span style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;”>monrootvg jfs 280 280 2 open/syncd N/A</span>

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

      Из плохих новостей – похоже что диск вылетел на виосе, а так как на нем не было зеркало (похоже, что отказоустойчивость сделали с помощью двух виосов, но пожалели диски, чтобы сделать зеркало на каждом и защитить их от сбоя), данные на одном виосе потеряны.  Скорее всего потребуется замена диска и переустановка сбойного виоса. В данный момент желательно проверить как устроена сеть, если используется shared ethernet adapter, то убедиться что активный адаптер сейчас у живого виоса ( для этого найти имя адаптера в lsdev -virtual на живом виосе, затем entstat -d имя-адаптера). Так же нужно посмотреть евенты в HMC,   там должны быть ошибки, если проблема хардварная.

       

    • #39689
      Дмитрий
      Участник

      Небольшой оффтоп про физическую замену диска: диски, к счастью, самые обыкновенные. Можно купить для x86, максимум, придётся салазки поменять.

      Вот только в прошлый раз я такое делал, когда IBM ещё выпускал диски под x86. Понятно, что внутри это Wd или ещё что-то, но прошивка была IBM овская.

      • #39690
        sdudnik
        Участник

        В прошивке как раз и дело. Скорее всего с другой прошивкой не заведется.

    • #39691
      Templar
      Участник

      Диск родной PN 03N6347 на замену у меня есть.

      SEA используется. Адаптер активный (вывод писать не буду, он очень большой) кол-во Packets меняется…

      Eventы в HMC, к сожалению, удалил – видимо проблема давняя, просто обнаружил только сейчас…

      Какая последовательность действий по восстановлению?
      Если я правильно понимаю, то мне нужно сначала разломать зеркало на Lpar (а точнее на трех lpar):
      unmirrorvg rootvg hdisk0
      reducevg rootvg hdisk0
      bosboot -a -d /dev/hdisk02
      bootlist -m normal hdisk2

      Не понятно, что дальше?
      Можно ли как-то без переустановки vios решить проблему? даже сбойный vios долго, но грузится!
      Может как-то вставить новый диск загрузиться с диска vios и восстановить битые lv?

    • #39693
      Дмитрий
      Участник

      2) ремонт VIOS

      Судя по lsvg -lv rootvg, смотрим на строки
      dnsrootvg jfs 280 280 1 open/syncd N/A
      nimrootvg jfs 280 280 1 open/syncd N/A
      monrootvg jfs 280 280 2 open/syncd N/A
      предполагая здравый смысл при установке VIOS,
      а также зная, что он всё-таки работает и даже грузится,
      можем предположить, что Вам повезло:
      VIOS установлен на работающем диске, а LV для клиентов как-то разбросаны (monrootvg точно поплохело).
      Чтобы узнать точно, нужно посмотреть
      lspv -lv hdisk0
      lspv -lv hdisk1
      чтобы точно в этом убедиться.
      Если ВСЕ остальные LV, кроме этих трёх, ЦЕЛИКОМ на хорошем диске, то переустанавливать VIOS не надо. Ну, разве что, /tmp и /home, если на битом диске, то, наверное, можно их переделать.

      Если это предположение верно, то надо будет
      разобрать виртуальные устройства (rmvdev -dev dnsrootvg и т.д.),
      убрать диск из VG (reducevg rootvg битый_диск);
      удалить устройство (rmdev -dev битый_диск);
      заменить на новый
      найти (cfgdev)
      а вот дальше я бы сделал на нём отдельную VG для клиентов, а не включал в rootvg. Это правильнее. Гораздо правильнее.  Ещё правильнее включить его в riootvg и сделать зеркало, а клиентам диски пробрасывать с СХД (или найти ещё внутренние диски). Но, если со свободным местом совсем плохо, то придётся включать его в rootvg…
      С этим разберёмся потом, надо понять, сколько места есть, сколько нужно, и тогда уже решить, как им распорядиться.
      ну и, конечно, потом придётся заново создать LV для клиентов, создать виртуальные устройства, а в AIX-ах – пересоздать зеркало rootvg.

       

    • #39694
      Дмитрий
      Участник

      1) ремонт AIX
      Если я правильно понимаю, то мне нужно сначала разломать зеркало на Lpar (а точнее на трех lpar):
      unmirrorvg rootvg hdisk0
      reducevg rootvg hdisk0
      bosboot -a -d /dev/hdisk02
      bootlist -m normal hdisk2

      да, всё правильно, только не “разломать” (уже разломано), а удалить 😉
      небольшие дополнения: reducevg rootvg hdisk0 может не пройти, а ругаться на dump device
      надо его временно отключить:
      sysdumpdev -l (запоминаете имя primary dump device)
      sysdumpdev -p /dev/sysdumpnull (временно отключаете)
      после ремонта: sysdumpdev -p старое_имя
      bootlist -m service hdisk2 тоже надо сделать

      команда bosboot может не пройти, обычно лечится командой savebase (без параметров) и опять bosboot.

      После того, как сбойный диск убрали из rootvg, можете смело его удалять из ОС
      rmdev -dl сбойный_диск.

      Повторяем это на всех затронутых AIX-ах (предварительно проверив и убедившись, что они требуют ремонта),
      и переходим к ремонту VIOS.

    • #39701
      Templar
      Участник

      На рабочем VIOS:
      bash-4.3# lspv -l hdisk0
      hdisk0:
      LV NAME LPs PPs DISTRIBUTION MOUNT POINT
      dnsrootvg 280 280 109..15..30..109..17 N/A
      hd11admin 1 1 00..00..01..00..00 /admin
      livedump 2 2 00..02..00..00..00 /var/adm/ras/livedum
      p
      monrootvg 14 14 00..00..00..00..14 N/A
      hd9var 5 5 00..00..05..00..00 /var
      hd3 18 18 00..00..18..00..00 /tmp
      hd1 80 80 00..80..00..00..00 /home
      hd10opt 14 14 00..00..14..00..00 /opt
      paging00 8 8 00..00..08..00..00 N/A
      hd8 1 1 00..00..01..00..00 N/A
      lg_dumplv 8 8 00..08..00..00..00 N/A
      hd4 4 4 00..00..02..00..02 /
      hd2 30 30 00..00..30..00..00 /usr
      hd5 1 1 01..00..00..00..00 N/A
      hd6 4 4 00..04..00..00..00 N/A

      bash-4.3# lspv -l hdisk1
      hdisk1:
      LV NAME LPs PPs DISTRIBUTION MOUNT POINT
      nimrootvg 280 280 00..109..109..62..00 N/A
      monrootvg 266 266 110..00..00..47..109 N/A

      На сбойном VIOS:
      # lspv
      ksh: Invalid file system control data detected
      hdisk2 000520fffae529a7 rootvg active
      hdisk3 000520ffd402eff6 rootvg active

      # lspv -l hdisk2
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.

      # lspv -l hdisk3
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.

    • #39702
      Templar
      Участник

      Еще глупый вопрос, не могу разобраться… в данном сервере у меня всего 4 диска, нет СХД. Как мне узнать location code сбойного диска?

      Рабочий VIOS
      # lsdev -Cc disk -F ‘name location physloc’
      hdisk0 02-08-00-3,0 U787B.001.DNWG06Z-P1-C3-T1-L3-L0
      hdisk1 02-08-00-4,0 U787B.001.DNWG06Z-P1-C3-T1-L4-L0

      Сбойный VIOS#
      #lsdev -Cc disk -F ‘name location physloc’
      ksh: Invalid file system control data detected
      hdisk0 00-08-00-3,0 U787B.001.DNWG06Z-P1-C3-A3
      hdisk1 00-08-00-4,0 U787B.001.DNWG06Z-P1-C3-A4
      hdisk2 03-08-00-5,0 U787B.001.DNWG06Z-P1-T14-L5-L0
      hdisk3 03-08-00-8,0 U787B.001.DNWG06Z-P1-T14-L8-L0

      HMC:
      hscroot@hmc1:~> lshwres -m 9133-55A-SRV -r virtualio –rsubtype scsi –level lpar –filter “lpar_ids=3” -F slot_num,remote_lpar_id,remote_slot_num
      4,2,5
      3,1,5

      Я бы предположил, что сбойный диск находится в слоте 5…? Но такого нет http://puu.sh/tGAYP/bf617b29ba.png

    • #39704
      Григорий
      Участник

      согласно этому https://www.ibm.com/support/knowledgecenter/en/POWER5/iphau_p5/loc550.htm

      Рабочий VIOS
      # lsdev -Cc disk -F ‘name location physloc’
      hdisk0 02-08-00-3,0 U787B.001.DNWG06Z-P1-C3-T1-L3-L0 – U<em class=”ph i”>n-P2-D4
      hdisk1 02-08-00-4,0 U787B.001.DNWG06Z-P1-C3-T1-L4-L0 – U<em class=”ph i”>n-P2-D3

      Сбойный VIOS#
      #lsdev -Cc disk -F ‘name location physloc’
      ksh: Invalid file system control data detected
      hdisk0 00-08-00-3,0 U787B.001.DNWG06Z-P1-C3-A3
      hdisk1 00-08-00-4,0 U787B.001.DNWG06Z-P1-C3-A4
      hdisk2 03-08-00-5,0 U787B.001.DNWG06Z-P1-T14-L5-L0 – U<em class=”ph i”>n-P2-D2
      hdisk3 03-08-00-8,0 U787B.001.DNWG06Z-P1-T14-L8-L0 –  U<em class=”ph i”>n-P2-D1

      Т.е. lsdev выдает логические коды, а с помощью документации определяем физические коды и ищем на вашей диаграмме. Что такое Un-C3-A3 и Un-C3-A4 – не знаю.

      Если предположение о пятом слоте взялось из вывода lshwres, то это не правильно, так как это виртуальные адаптеры раздела с id=3.

    • #39706
      Templar
      Участник

      Спасибо!
      Из вывода lspv -lv hdiskX (выше) видно на каких дисках лежат логические тома для клиентов на vios1. А как можно узнать какой из двух дисков вылетел (P2-D1 или P2-D2) на vios2? Уже кучу всего перепробовал в т.ч. lquerypv, lqueryvg, readvgda.
      LVMу совсем плохо.

      Сбойный vios:
      # lslv -m dnsrootvg
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.

      # lspv hdisk2
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.
      PHYSICAL VOLUME: hdisk2 VOLUME GROUP: rootvg
      PV IDENTIFIER: 000520fffae529a7 VG IDENTIFIER 000520ff0000d6000000011f4b434d8c
      PV STATE: ???????
      STALE PARTITIONS: ??????? ALLOCATABLE: ???????
      PP SIZE: ??????? LOGICAL VOLUMES: ???????
      TOTAL PPs: ??????? VG DESCRIPTORS: ???????
      FREE PPs: ??????? HOT SPARE: ???????
      USED PPs: ??????? MAX REQUEST: 256 kilobytes
      FREE DISTRIBUTION: ???????
      USED DISTRIBUTION: ???????
      MIRROR POOL: ???????
      # lspv hdisk3
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.
      PHYSICAL VOLUME: hdisk3 VOLUME GROUP: rootvg
      PV IDENTIFIER: 000520ffd402eff6 VG IDENTIFIER 000520ff0000d6000000011f4b434d8c
      PV STATE: ???????
      STALE PARTITIONS: ??????? ALLOCATABLE: ???????
      PP SIZE: ??????? LOGICAL VOLUMES: ???????
      TOTAL PPs: ??????? VG DESCRIPTORS: ???????
      FREE PPs: ??????? HOT SPARE: ???????
      USED PPs: ??????? MAX REQUEST: 256 kilobytes
      FREE DISTRIBUTION: ???????
      USED DISTRIBUTION: ???????
      MIRROR POOL: ???????

    • #39707
      Григорий
      Участник

      а в rootvg есть свободное место? на сбойном vios-е? и errpt бы глянуть…

    • #39708
      Templar
      Участник

      Ничего не показывает

      # lsvg rootvg
      ksh: Invalid file system control data detected
      0516-070 : LVM system call found an unaccountable
      internal error.
      # errpt
      ksh: Invalid file system control data detected
      #

    • #39709
      Григорий
      Участник

      Конец рабочего дня, виноват, я не rootvg имел ввиду, а / – корневую файловую систему. Если и errpt не работает, то мне кажется не в LVM дело. Может просто нет места в /, /var или в /tmp, и команды просто с ODM работать не могут нормально.

    • #39710
      Templar
      Участник

      Вы правы. Места нет в /
      # df -g
      ksh: Invalid file system control data detected
      Filesystem GB blocks Free %Used Iused %Iused Mounted on
      /dev/hd4 0.25 0.00 100% 2789 88% /
      /dev/hd2 3.75 0.81 79% 82230 28% /usr
      /dev/hd9var 0.62 0.41 34% 4457 5% /var
      /dev/hd3 2.25 2.24 1% 105 1% /tmp
      /dev/hd1 10.00 9.97 1% 75 1% /home
      /proc – – – – – /proc
      /dev/hd10opt 1.75 0.84 52% 10399 5% /opt
      /dev/hd11admin 0.12 0.12 1% 5 1% /admin
      /dev/livedump 0.25 0.25 1% 4 1% /var/adm/ras/livedump

      Но получается какой-то “замкнутый круг”…
      # chfs -a size=+10M /
      ksh: Invalid file system control data detected
      0516-070 /usr/sbin/lquerylv: LVM system call found an unaccountable
      internal error.
      chfs: Cannot get volume group partition size.

      Удалить я даже не знаю что от туда можно… никаких логов нет.
      du -sg /* при поиске выдает ряд I/O error

    • #39711
      Дмитрий
      Участник

      Да, засада полная.
      Ещё и в / место закончилось.
      В “нормальной” ситуации я бы предложил отрезать место у /home и добавить его /
      но здесь, со сбойным диском, это, наверное, не пройдёт.

      Под рукой у меня VIOSа нет сейчас, посмотрите сами в корневом каталоге, вероятно, там есть core и/или какие-нибудь текстовые логи.
      core можно смело удалять, логи, если боитесь, то перенести в /home.
      Пока корневую ф.с. не почистить, толку не будет.

      Интересный случай 🙂
      Здесь проще всего посоветовать проверить, что с одним VIOS-ом всё работает, да и переставить сбойный. Но это не интересно 🙂

    • #39713
      Григорий
      Участник

      Если расчистка корня не поможет, то возможно дело не только в переполнении, есть вероятность что и файловая система побилась. Тогда без перезагрузки не обойтись, мне кажется. На этапе загрузки должна отработать fsck по файловым системам у которых check=true в /etc/filesystems. Если /etc/filesystems тоже попортился, то вот сюда https://www-01.ibm.com/support/docview.wss?uid=isg3T1000131 .

      fsck – без ключа -y будет спрашивать разрешение на внесение исправлений, так что следите за консолью во время загрузки.

      Как минимизировать простой для клиентов? Если они еще держатся на плаву, то может им третий vios как-то подсунуть удастся? или на первый переключить?

    • #39714
      Templar
      Участник

      Здесь проще всего посоветовать проверить, что с одним VIOS-ом всё работает, да и переставить сбойный. Но это не интересно

      Можно и такой вариант, но нужно как-то определить какой именно диск сдох (P2-D1 или P2-D2).
      Может это можно сделать по индикации?

      Если /etc/filesystems тоже попортился, то вот сюда https://www-01.ibm.com/support/docview.wss?uid=isg3T1000131 .

      Что-то мне подсказывает, что так и будет….

      В общем, ситуация такая.
      Вот содержимое /
      # ls -la .
      ksh: Invalid file system control data detected
      total 208
      drwxr-xr-x 17 root system 4096 Dec 8 18:10 .
      drwxr-xr-x 17 root system 4096 Dec 8 18:10 ..
      -rw——- 1 root system 94 Feb 6 2009 .sh_history
      drwxr-xr-x 4 root system 256 Feb 6 2009 admin
      drwxr-x— 2 root audit 256 Oct 8 2008 audit
      lrwxrwxrwx 1 bin bin 8 Feb 6 2009 bin -> /usr/bin
      -rw-r–r– 1 root system 5133 Jun 6 2007 bosinst.data
      drwxrwxr-x 5 root system 8192 Jan 30 20:13 dev
      drwxr-xr-x 34 root system 20480 Jul 30 2013 etc
      drwxr-xr-x 6 bin bin 256 Jan 31 12:00 home
      -rw-r–r– 1 root system 13794 Oct 5 2009 image.data
      lrwxrwxrwx 1 bin bin 8 Feb 6 2009 lib -> /usr/lib
      drwx—— 2 root system 256 Oct 8 2008 lost+found
      drwxr-xr-x 163 bin bin 12288 Mar 12 2009 lpp
      -rw-r–r– 1 root staff 0 Dec 8 17:51 lvmt.log
      drwxr-xr-x 2 bin bin 256 Oct 8 2008 mnt
      drwxr-xr-x 15 root system 4096 Feb 6 2009 opt
      -rwxr-xr-x 1 root system 602 Jun 6 2007 post_install
      dr-xr-xr-x 1 root system 0 Jan 31 12:09 proc
      -rw-r–r– 1 root system 0 Jun 6 2007 save_bosinst.data_file
      drwxr-xr-x 3 bin bin 256 Feb 6 2009 sbin
      -rw-r–r– 1 root system 751 Feb 6 2009 smit.script
      -rw-r–r– 1 root system 1186 Feb 6 2009 smit.transaction
      drwxrwxr-x 2 root system 256 Feb 6 2009 tftpboot
      drwxrwxrwt 10 bin bin 4096 Jun 13 2015 tmp
      lrwxrwxrwx 1 bin bin 5 Feb 6 2009 u -> /home
      lrwxrwxrwx 1 root system 21 Feb 6 2009 unix -> /usr/lib/boot/unix_64
      drwxr-xr-x 43 bin bin 4096 Feb 6 2009 usr
      drwxr-xr-x 30 bin bin 4096 Feb 6 2009 var

      Не знаю, что отсюда можно удалить, да и не удалит он видимо ничего
      # rm /lvmt.log
      ksh: Invalid file system control data detected
      rm: /lvmt.log not removed.
      Invalid file system control data detected

      Тогда пробую перезагрузить сбойный vios?) С одним вроде должен работать

    • #39721
      Templar
      Участник

      Перезагрузил, Lpar работает нормально.

      Сбойный vios повис с кодом 0552: IPL vary-on failed
      До fsck не дошел.

      Что посоветуете? грузиться с диска и по этой процедуре https://www-01.ibm.com/support/docview.wss?uid=isg3T1000131
      ??

    • #39722
      Григорий
      Участник

      если 552, то лучше по этой http://www-01.ibm.com/support/docview.wss?uid=isg3T1000132 , хотя разница не большая. Да и на форуме у нас тут был случай https://aixportal.ru/forums/topic/ipl-vary-on-failed/ …  так это ж ваш пост!

       

    • #39723
      Дмитрий
      Участник

      1) у вас сохранилась инфа, через какие ethernet-порты настроены SEA-bridge?
      Это когда VIOS всё-таки переставите, их придётся пересоздавать.
      с дисками проще.

      2) если по п.1 OK, то, может, не ходить дальше по краю, а переставить VIOS?

      3) какой диск сбойный?
      Для начала: его всё-равно менять и новый диск есть. Значит, вынимаем все старые, вставляем только новый, ставим на него VIOS и потом подсовываем ему диски на изучение.
      Чтобы не перепутать, что вынимать: у вас, судя по листингу, всего 6 дисков.
      2 в “хорошем” VIOS, 4 в “плохом”. Правильно?
      Непонятно только, почему не одинаково…
      В “хорошем” VIOS из-под root запускаем diag, идём в 3-й пункт меню (diagnostic procedures?), там где-то есть пункт Identification. Или disk routines -> identify disk.
      Он зажигает моргающий светодиод на диске, иногда плохо видимый.
      Можно запускать на работающем диске.
      “Поморгав” хорошими дисками, вычисляем остальные.
      Если по дискам предположение верное, то в одной половине корзины 2 диска, в другой – 4.

      Если по дискам всё не так, как я описал:
      Где-то я смутно помню, что в p5 была возможность поставить “совсем внутренние”, не hot-swap диски.
      У вас сервер <span class=”keyword”>9133-55A? В каких слотах установлены диски, что установлено в PCI-адаптеры?
      </span>

       

    • #39730
      Templar
      Участник

      1) у вас сохранилась инфа, через какие ethernet-порты настроены SEA-bridge?
      Это когда VIOS всё-таки переставите, их придётся пересоздавать.
      с дисками проще.

      Не сохранилась. Я лишь могу предположить, что конфигурация такая же как на рабочем vios

      $ lsmap -all -net
      SVEA Physloc
      —— ——————————————–
      ent2 U9133.55A.655DC9H-V2-C2-T1

      SEA NO SHARED ETHERNET ADAPTER FOUND

      SVEA Physloc
      —— ——————————————–
      ent3 U9133.55A.655DC9H-V2-C3-T1

      SEA ent6
      Backing device ent5
      Status Available
      Physloc

      SVEA Physloc
      —— ——————————————–
      ent4 U9133.55A.655DC9H-V2-C4-T1

      SEA NO SHARED ETHERNET ADAPTER FOUND

      2) если по п.1 OK, то, может, не ходить дальше по краю, а переставить VIOS?

      Да, я уже готов переставить

      У вас сервер <span class=»keyword»>9133-55A?

      Да

      В каких слотах установлены диски, что установлено в PCI-адаптеры?

      Диски установлены с слотах P2-D1, P2-D2 Сбойный vios и P2-D3, P2-D4 рабочий vios. Должно быть не 6 а 4 диска
      Вот вывод по PCI

      $ lsdev | grep PCI
      ent0 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
      ent1 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
      pci0 Available PCI Bus
      pci1 Available PCI Bus
      pci2 Available PCI Bus
      pci3 Available PCI Bus
      pci4 Available PCI Bus
      pci5 Available PCI Bus
      sa0 Available 2-Port Asynchronous EIA-232 PCI Adapter
      scsi0 Available PCI-X Dual Channel Ultra320 SCSI Adapter bus
      scsi1 Available PCI-X Dual Channel Ultra320 SCSI Adapter bus
      sisscsia0 Available PCI-XDDR Dual Channel Ultra320 SCSI Adapter

      Я сегодня туда поеду и все глазами посмотрю

    • #39735
      Templar
      Участник

      Спасибо за подробные инструкции и помощь!

      Что сделано:
      – приехал на место, удалил из lparов диск со сбойного vios (прошло нормально, без sysdumpdev, chpv -c hdiskX только надо было сделать еще)
      – вытащил из сервера все диски, вставил 1 новый и установил на него vios (правда не нашел той же версии и теперь viosы разных версий (2.2.4 и 2.1.0), но думаю это ничего страшного)

      Что интересно: дисков (которые hot-swap) оказалось все-таки 4 и находились они в слотах P2-D1, P2-D2 (сбойный vios) и P3-D3, P3-D4 (рабочий vios) (а локейшн коды показывали, что находятся в слотах P2-D3, P2-D4) и остается загадкой, что такое P1-C3-A3 и P1-C3-A4….

      – возникла проблема с определением сбойного диска:
      1. вставил два старых диска зашел в diag=>Task Selection=>c идентификацией там только пункт Identify and Attention Indicators, но я так понял он просто подсвечивает слоты и не проверяет диски. (оба диска поморгали оранжевым)
      2. сделал cfgmgr, оба диска определились. Зашел в diag=>Diagnostic Routines=> Problem Determination и выбрал их проверить – он написал все ок и предложил что-то типа Certification (который должен был занять много времени и я его не стал делать)

      Все делал со свежеустановленного vios.

      Вопрос с определением битого диска пока остается открытым….

    • #39736
      Дмитрий
      Участник

      С разными версиями должно работать, но второй виос лучше обновить.

      Старые available devices: AIX (VIOS) видит то, что есть, и не видит того, чего нет (простите за философию).

      Но если физически отключить или вытащить устройство, то его статус в ОС не поменяется, оно останется available. До перезагрузки. После перезагрузки оно станет defined. Вы писали, что перезагрузки VIOS и после этого диски были available. Значит, они были. Ну или виосу совсем уже плохо было и он бредил… Вообще мне эти локейшн коды очень напоминают внутренние диски или scsi-полку.

      Как найти битый диск: certification хорошая процедура. В качестве альтернативы создайте на диске vg, lv, FS. Смонтируйте и посмотрите, что получится. Может получиться, тогда надо заполнить диск данными. Сертификация правильнее 😀

      А identify только светит лампочками, верно. Это очень удобно при замене устройств. Я так понимаю, что у вас нет туда удаленного доступа?

    • #39737
      Templar
      Участник

      Вы писали, что перезагрузки VIOS и после этого диски были available.

      Не совсем так. Я установил новый vios, вставил диски и они нашлись в lspv после cfgmgr. Статус наверное defined у них был

      Я так понимаю, что у вас нет туда удаленного доступа?

      Доступ есть.

      Я диски (старые) вытащил. Тогда завтра поеду, вставлю их сделаю cfgmgr и поочередно certification, если пройдет то посоздаю на них больших файлов. Надеюсь это поможет определить битый. Отпишусь

    • #39738
      Templar
      Участник

      Поочередно вставил диски и после cfgmgr сделал certify. Не на одном из дисков он не нашел ни битых секторов ни каких-либо других ошибок (в отчете все по 0). Сделал на каждом из дисков по VG, LV, файловой системе, смонтировал, попробовал расширить FS, сделал большой файл вот таким образом “dd if=/dev/zero of=/test1/test.dat bs=8192 count=20000”, еще раз расширил FS.
      В общем оба диска работают. Что еще посоветуете?

      В HMC загорелся Attention LED на этом виосе, но в eventах ничего нет.
      Еще когда вставил диск в слот P2-D1 в diage показал ошибку: SCSI bus problem: cables, terminators or other SCSI devices (DISK_ERR3), но после того как диск переткнул она ушла.

    • #39739
      Дмитрий
      Участник

      Вот оно как… Это мы что, не то чинили? Смеяться и плакать, плакать и смеяться…
      Сертификации дисков я доверяю, errpt тоже. а реальному чтению-записи файлов ещё больше.

      Что это: сбой контроллера, контактов с слоте?

      Зато у вас теперь свежий, хороший VIOS, и диск лишний появился. можно всё аккуратно настроить.
      И проблему, так или иначе, но устранили.

    • #39740
      Templar
      Участник

      В серверной несколько лет назад сверлили кирпичную стену, не выключая сервера. Думаю скорее всего на контакты пыль попала. Спасибо всем ОГРОМНОЕ за помощь!

      Буду настраивать на следующей неделе

    • #39748
      Григорий
      Участник

      Так вам не удалось после перезагрузки  и “0552: IPL vary-on failed” починить файловые системы?

    • #39749
      Templar
      Участник

      Так вам не удалось после перезагрузки  и «0552: IPL vary-on failed» починить фай

      Я решил не чинить, предполагая, что какой-то диск мертвый просто переустановил vios на новый диск

    • #41149

      походу ничего уже не сделаешь..интересно как все разрешилось..

    • #41152
      Дмитрий
      Участник

      Здравствуйте, Владимир!

      Templar написал: “Я решил не чинить, предполагая, что какой-то диск мертвый просто переустановил vios на новый диск”.

      С точки зрения исследователя – жаль. С точки зрения практики часто выбирают самый быстрый (сейчас), хотя, может быть, и не самый оптимальный путь. И это часто справедливо.

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