Миграция с EMC DMX-4 на Storwize v7000

Главная Форумы POWER Systems Миграция с EMC DMX-4 на Storwize v7000

Просмотр 9 веток ответов
  • Автор
    Сообщения
    • #38180
      Александр
      Участник

      Доброго времени суток. Позволю себе порадовать вас своими идиотскими вопросами, ибо в IBM Power, мягко говоря, чайник. Итак. В конторе, где работаю, меняют хранилку EMC Symmetrix DMX 4 на IBM Storwize 7000. Необходимо перетащить тридцать, примерно, LPAR на новую СХД. Всё, в принципе, понятно, примапливаю
      ресурс со Storwize на VIOS’ы, делаю зеркало для rootvg, создаю на новом hdisk dump-device, bosboot, bootlist ну, и т. д. Диск с данными (какой-нибудь Oracle, GlassFish etc) перетаскиваю mklvcopy (migratepv делать стрёмно). Так вот, собственно, вопрос. Есть несколько серверов, где данные хранятся на… короче… к ноде подключены по FC (напрямую, не через VIOS) два (или больше) диска, они находятся в VG, на VG, соответственно, располагается LV 😉 с данными. Насколько адекватно в этом случае будет создать на Storwize диск, прикрутить его к ноде и сделать mklvcopy? Нужно ли при этом копировать loglv00? Или существуют другие решения? Миграцию средствами IBM Storwize не рассматриваю, т. к. требуется остановка всех сервисов, что недопустимо в моём случае.
      И второй вопрос. Как можно идентифицировать диск, прикрученный к ноде, с LUN на хранилке? Например,
      для Symmetrix есть программка, показывающая SYM ID (inq_что-то_там_версия называется, показывает для
      каждого hdisk десятизначный идентификатор, если обрезать первые и последнии три символа, получится
      LUN на Symmetrix).

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

      Александр,

      “не усложняйте без надобности” (c) Оккам 😉

      [предполагаю, что у вас достаточно “свежая” версия AIX 6.1 или 7.1 – в старой AIX 5.3 цепочка команд была подлиннее]
      Перенос rootvg:
      1) вариант, когда и старые, и новые диски подключены через VIOS.
      1.1. Подключаете новые диски к VIOS-ам, пробрасываете их в AIX LPAR.
      1.2. Включаете в rootvg (extendvg)
      1.3. Переносите, либо командой migratepv, либо зеркалированием (mirrorvg)
      1.4. bosbooot, bootlist
      1.5. убираете старые диски из rootvg, удаляете устройства, разбираете в VIOS.
      1.6. Всё.

      2) Диски выданы напрямую по FC.
      2.1 Выполняете пункты: cfgmgr; 1.2; 1.3.; 1.4; rmdev; 1.6 🙂

      3) старые диски напрямую, новые через VIOS или наоборот
      3.1 аналогичная комбинация предыдущих пунктов.

      Возможные “проблемы” (в кавычках):
      1)
      при попытке удалить старый диск из rootvg пишут, что на нём primary dump device
      -sysdumpdev -l # смотрите имена primary и secondary dump device
      -sysdumpdev -P /dev/sysdumpnull # (или как-то так, не помню точного названия устройства – по умоляанию это как-раз secondary dump device
      -перенос/освобождение диска
      -sysdumpdev -P <имя устройства> # устанавливаете primary dump device обратно

      2) bosboot “ругается”
      проверьте bootlist, запустите ещё раз bosboot

      Перенос datavg:
      -Всё то же самое, без bootlist и bosboot.

      ==================
      Всё выполняется “на лету”, многократно проверено в промышленной среде, в разных комбинациях.
      Там, где “стрёмно” (не знаю, почему?) (но у меня тоже иногда так бывает) делаем через mirrorvg/unmirrorvg.

      Я написал команды достаточно схематично, дальше или:
      -Вы и так знаете ключи
      -Смотрите в документации “процедуры замены диска” (есть, кстати, в переведённой на русский язык AIX Redbook)
      -Спрашиваете на нашем Форуме 🙂 [тогда приветствуется более детальное описание конфига, с командами lsdev, lspv, lsvg и т.п.]

      P.S. Своими вопросами Вы нас, действительно, радуете (без кавычек) – мы сообщество всех, кто работает с AIX, на любом уровне. Велкам!

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

      Упс. Второй вопрос. Не заметил.
      Идентификация диска:

      lscfg -vl hdiskX
      LUN ID обычно “прячется” в Z1.

    • #38183
      Александр
      Участник

      Дмитрий, спасибо за развёрнутый ответ! Примерно так всё и делал, два сервера уже перенёс, но, всё-таки, впервые с этим сталкиваюсь – страшно 😉 Хотел узнать, правильно ли делаю. Спасибо!

    • #38219
      Александр
      Участник

      Ещё раз, здравствуйте. Вопрос по той же теме. Все серверы перенесли удачно, кроме одного. Исходные данные такие: rootvg подключен через VIOS, диск с данными (13tb) подключен напрямую по FC. На Storwize создали диск, прикрутили к LPAR напрямую, extendvg, mirrorvg и всё прочее, проблема в том, что все операции с VG, LV выполняются очень долго и с ошибками. Диск с данными, например, mirrorvg/unmirrorvg выполнял часов десять (те же операции на других логических разделах занимали несколько минут). То же касается и rootvg. Вот то, что сейчас:
      [root@backup /]$ lspv
      hdisk0          00ce837351f929d3                    rootvg          active
      hdisk4          00ce8373aa1b670a                    rootvg          active
      hdisk5          00ce8373afd163bc                    backupvg        active

      [root@backup /]$ lsvg
      rootvg
      backupvg

      [root@backup /]$ lsvg -p rootvg
      rootvg:
      PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
      hdisk0            active            799         654         160..82..92..160..160
      hdisk4            active            799         528         147..08..53..160..160

      В rootvg hdisk0 – со старой хранилки, сделали зеркало (делалось очень долго), создали dumpdevice, boot и прочее, зеркало разобрали (операция продолжалась часов восемь или больше). Сейчас запустил reducevg -df rootvg hdisk0 (там остались логические тома), сервер выдал такое:

      [root@backup /]$ reducevg -df rootvg hdisk0
      0516-1008 rmlv: Logical volume hd3 must be closed.  If the logical volume contains a filesystem, the umount command will close the LV device.

      И повис… Примерно то же самое происходило с другим диском, при этом в процессах было такое (это на
      текущий момент, тогда вместо hdisk0 был hdiskX с данными, но ситуация схожая):

      [root@backup /]$ ps -ef | grep lv
      root  2949256 12451850   0 19:08:47  pts/6  0:00 /bin/ksh /usr/sbin/rmlv -f -p hdisk0 00ce837300004c000000013151f938e4.7
      root  6226090  2949256   0 19:08:47  pts/6  0:00 /usr/sbin/lvmt -e -f rmlv.sh -l 22 -p 12451850 rmlv 1
      root  7077992  4980982   0 19:51:46  pts/5  0:00 grep lv
      root  9175094  6226090 120 19:08:47  pts/6 41:23 /usr/bin/alog -t lvmcfg -o

      И ещё висел grep что_то_там_со_странными_параметрами, занимая до 90% процессора.
      В принципе, это уже не столь критично – данные перенесли на новую хранилку, сделал новый сервер, туда можно подключить диск с данными. Но подозреваю, что экспорт группы томов на старом сервере займёт много времени. Сейчас просто интересно понять – что происходит и почему.

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

      Александр,

      Как-то у вас запутанный текст получился. Попробуем распутать… 🙂

      1)

      >диск с данными (13tb) […]. Диск с данными, например, mirrorvg/unmirrorvg выполнял часов десять
      А сколько, по Вашему, должны копироваться 13Тb данных?

      >(те же операции на других логических разделах занимали несколько минут).
      На каких? Объём?
      Команда mirrorvg копирует байт в байт содержимое всех PP, принадлежащих LV. И ей всё-равно, насколько реально это место занято. Поэтому, например, если у меня там файловая система, занятая наполовину, то её сначала лучше уменьшить (chfs -a size…), одновременно автоматически уменьшится размер LV, потом mirrorvg и т.п, и потом обратное увеличение файловой системы.

      А вот unmirrorvg должен делаться очень быстро. Данные физически не удаляются, а только обновляется информация в контрольных зонах (VGDA, LVSA, LVCB).

      2)

      > В rootvg hdisk0 — со старой хранилки, сделали зеркало (делалось очень долго), создали dumpdevice, boot и прочее, зеркало разобрали (операция продолжалась часов восемь или больше).

      Это сразу настораживает. Аппаратные ошибки смотрели?
      # errpt
      vios# errlog
      На уровне СХД всё OK?

      3)

      >Сейчас запустил reducevg -df rootvg hdisk0 (там остались логические тома), сервер выдал такое:
      [root@backup /]$ reducevg -df rootvg hdisk0
      0516-1008 rmlv: Logical volume hd3 must be closed.  If the logical volume contains a filesystem, the umount command will close the LV device.

      Наиболее вероятная причина: hd3 (/tmp) осталась на этом диске.
      Нужно проверить
      lsvg -l rootvg
      lsvg -p rootvg
      lsvg rootvg
      lspv -l hdisk0
      lspv -l hdisk4

    • #38221
      Александр
      Участник

      1. Естественно, имел в виду, что unmirrorvg выполняется очень долго, так же как и reducevg. Как раз это и смущает.
      2. На сервере ошибок не было, логи смотрел. На vios сегодня посмотрю, но, думаю, тоже не будет.
      3. На hdisk0 из rootvg остались три hdX (/opt /tmp и что-то ещё). Поэтому и сделал reducevg с ключами -df. Из зеркала hdisk0, соответственно, был выведен. И выводился он оттуда долго – утром запустили команду, к вечеру она выполнилась. Удалять сначала оттуда hdX не стал, т. к. этот процесс затянулся бы ещё на сутки. errpt -a | less ошибок, как уже сказал, не отображает. Очевидно, что проблема с дисковой подсистемой, но с какой стороны к ней подойти – непонятно. На DMX-4 все физические диски целы (сразу проверил), больше ошибок, вроде, нет (сегодня уточню).

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

      unmirrorvg выпоняется долго – это даже не знаю, с какой стороны подойти…

      а вот здесь

      >3. На hdisk0 из rootvg остались три hdX (/opt /tmp и что-то ещё). Поэтому и сделал reducevg с ключами -df.

      явная ваша ошибка 🙁
      На hdisk0 оставались  файловые системы ОС. А команда reducevg -df стала их удалять. И не важно, что они были отзеркалированы, удаляется логический том (LV) целиком, со всеми копиями и, конечно, с файловой системой. Одна надежда – ОС не должна была это сделать, т.к. эти файловые системы должны были быть смонтированы. Если же вы всё-таки удалили /opt, то… восстанавливаем ОС из бэкапа.

      Что сейчас с ОС? Работает?
      Результаты команд (см. выше) очень помогут для помощи. Ничего секретного они не покажут.

       

      P.S. настоятельно советую прочитать “классический” redbook: LVM from A to Z и переведённый на русский язык redbook “Подготовка к сертификации AIX System Administration & Technical Support”.

    • #38223
      Александр
      Участник

      ОС работает, ничего не удалил. Видимо, правильнее было бы использовать rmlvcopy для удаления? И почему так получилось, что эти разделы остались на диске после зеркалирования и выведения диска из зеркала? На других серверах оставалось только устройство дампа. Зеркалирование прошло некорректно? К сожалению, какие именно ошибки были точно не знаю, т. к. этот LPAR переносил мой коллега. Помню, что после bosboot AIX предложил сделать savebase перед перзагрузкой. Но дело даже не в этом, проблема была в том, что абсолютно любое действие, изменяющее что-либо на VG/LV выполнялось очень долго, тот же bosboot, chdev, unmirrorvg зависали на несколько часов. И это происходило при работе с обеими дисками. В процессах при этом в топе висели alog и grep. Когда этот сервер перезагрузили, загружался он около десяти часов, как выяснилось, это была проверка файловой системы. При этом в логах – никаких ошибок. В общем, пришли к тому, что подключим этот диск к новому серверу, посмотрим что будет. На Storwize сейчас делается flashcopy, либо её попробуем подключить, либо exportvg на старом сервере, importvg на новом.

      LVM from A to Z – да, почитываю 😉

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

      >Видимо, правильнее было бы использовать rmlvcopy для удаления?
      да.
      А ещё правильнее – после mirrorvg убедиться, что всё отзеркалировано (lsvg -l rootvg, lsvg -p rootvg) и разбирать зеркало командой unmirrorvg.

      >Зеркалирование прошло некорректно?
      может быть, см. команды выше…

      >Помню, что после bosboot AIX предложил сделать savebase перед перзагрузкой.
      это бывает после переноса данных (точнее, hd5) с загрузочного диска. Это нормально.

      >Но дело даже не в этом, проблема была в том, что абсолютно любое действие, изменяющее что-либо на VG/LV выполнялось очень долго,
      Это может быть причиной. Мало информации, чтобы разобраться. Но это сразу должно было насторожить и заставить разбираться…

       

      Сейчас – посмотрите, что будет, если что – пишите. Попробуем помочь.

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