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


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

В этой теме 9 ответов, 2 участника, последнее обновление  Дмитрий 1 год, 10 мес. назад.

  • Автор
    Сообщения
  • #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 выполнялось очень долго,
    Это может быть причиной. Мало информации, чтобы разобраться. Но это сразу должно было насторожить и заставить разбираться…

     

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

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