Работа со стороны AIX(HACMP) при расширении LV на DS8300

Главная Форумы POWER Systems AIX/Hardware Работа со стороны AIX(HACMP) при расширении LV на DS8300

В этой теме 29 ответов, 5 участников, последнее обновление  Albert Maksimov 7 года/лет, 1 месяц назад.

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

    nickalias
    Участник

    Доброго всем здоровья!
    При расширении LV на DS8300 в составе кластера(HACMP):
    1. Можно ли отработать dscli>chfbvol –cap … не опуская сам HACMP?
    2. Если можно, то как расширить саму файловую систему которая сидит на этом LV со стороны AIX?
    В случае AIX без HACMP это ясно:
    # cfgmgr
    # chvg –g …
    # chfs –a size=….
    А как в случае с HACMP, логично делать это через SPOC, но какими опциями?

  • #16375

    uxTuaHgp
    Участник

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

  • #16376

    uxTuaHgp
    Участник

    Так что если без остановок, то только добавлять тома в VG

  • #16377

    nickalias
    Участник

    Это понятно.
    Непонятно, зачем тогда SPOC нужен. По идее, можно было бы на каждом узле кластер, не опуская HACMP, запустить chvg –g …. Потом отработать в SPOC по расширению шареной файловой системы. И все, никакой синхронизации и down time не нужны.
    Или я в корне не прав?

  • #16378

    Albert Maksimov
    Участник

    На 6100-07-01-141 и PowerHA 6.1.0.3 работает :whistle:
    Увеличиваем лун на ds, потом c-spoc (+10Gb к примеру) и вуаля.

    Какие у Вас версии?

    Файловую систему можно увеличить с помощью зеркалирования и, конечно, без перезагрузки! Так раньше делали.

  • #16379

    Albert Maksimov
    Участник

    nickalias, игры с кластером к добру не приведут – он очень нежный (так мне кажется, возможно, из-за недостатка опыта). Не играйте с ним на продуктивной системе.

    У нас однажды он ни с того, ни с сего halt’нул продуктивные сервера, а еще один раз расщепился 😆 Версия была 5.3

  • #16383

    nickalias
    Участник

    Нам тут не до игр! Особенно с кластером!
    AIX 5.3, HACMP 5.3
    Планируем down time.

  • #16384

    Albert Maksimov
    Участник

    Почему не обновляетесь?

  • #16386

    Michael
    Участник

    Наверняка у них техподдержки нетути, потому и не обновляются…

    AIX 6.1 и выше, положим, на торрентах найти можно, а вот HACMP или PowerHA…

  • #16387

    nickalias
    Участник

    Вот именно, IBM support нет и, похоже, скоро не будет!
    А жить как-то надо.

  • #16388

    uxTuaHgp
    Участник

    поподробнее пожалуйста

  • #16435

    nickalias
    Участник

    Возвращаясь к нашим баранам:
    AIX 5.3 TL10
    HACMP 5.3
    Необходимо расширить Shared FS, LV которой расположен на DS8300.
    1.Опустить HACMP
    2.Расширить LV на DS8300
    3.Со стороны первичного Nodе(а)
    – cfgmgr
    – chvg -g
    4.Со стороны вторичного Nodе(а)
    – cfgmgr
    – chvg -g
    5. Провести синхронизацию и верификация кластера
    6. Запустить HACMP
    7. При момощи SPOC расширирить shared FS

    ПУСТЬ БОЛЕЕ ОПЫТНЫЕ ТОВАРИЩИ МЕНЯ ПОПРАВЯТ!

  • #16436

    Albert Maksimov
    Участник

    chvg -g

    Насчет этого у меня сомнения. В AIX 5.3 такая операция не поддерживалась для EnhancedConcurrent VG.

  • #16437

    Albert Maksimov
    Участник

    root@asdsd:/$ oslevel -s
    5300-12-02-1036

    root@asdsd:/$ man chvg
    -g
    Will examine all the disks in the volume group to see if they have grown in size. If any disks have grown in size attempt to add additional PPs to PV. If necessary
    will determine proper 1016 multiplier and conversion to big vg. Notes:
    1 The user might be required to execute varyoffvg and then varyonvg on the volume group for LVM to see the size change on the disks.
    2 There is no support for re-sizing while the volume group is activated in classic or enhanced concurrent mode.
    3 There is no support for re-sizing for the rootvg.

    Видимо перед chvg -g придется активировать vg в обычном режиме, не concurrent.

    После расширения LV на DS AIX видит новый размер диска сразу (bootinfo -s), без cfgmgr.

  • #16438

    andrewk
    Участник

    а зачем расширять LUN? нарежьте еще один и не останавливайте hacmp.

  • #16439

    nickalias
    Участник

    Как concurrent(ную) группу varyonvg, как обычную?

  • #16440

    Albert Maksimov
    Участник

    После остановки кластерных сервисов и ресурсных групп на обоих узлах vg деактивируется автоматом.
    Для активации достаточно varyonvg .
    В выводе lspv в последнем столбце будет статус “active”

    Так делал на версиях 6.1.

    ps Для активации в active concurrent mode “varyonvg -n -c -A ” при запущенном кластере. Это есть в cookbook.

  • #16441

    uxTuaHgp
    Участник

    В общем я был прав – без остановки никак?
    Конечно, если рсширять вдвое, то есть смысл делать, как andrewk написал – добавить на ходу новые тома в VG.

  • #16442

    Albert Maksimov
    Участник

    И без перезагрузки делали. Подробности не помню, но вкратце:

    Дано:
    1. aix 5.3, hacmp ХЗ (наверное тоже 5.3);
    2. enhanced concurrent vg, зеркало из двух лунов;

    Делали так:
    1. Увеличили LUN;
    2. Разбили зеркало (unmirrorvg);
    3. Из VG вытащили диск(reducevg), с которого убрали зеркало;
    4. Засунули его обратно в VG (extendvg); – на этом этапе в VG диск уже с новым размером.
    5. Зазеркалировали (mirrorvg)
    Проделали то же самое со вторым LUN’ом.

    ps Возможно пункт 1 был выполнен после 3го. Это, думаю, неважно.

  • #16443

    nickalias
    Участник

    Как я понял, после останова кластера, если concurrent(ную) группу поднять простым
    varyonvg , то она подмимется как обычная. Потом chvg -g. Потом опять varyoffvg, чтобы в следующий раз она уже поднялась, как concurrent(ная).Эти операции нужно делать на обоих узлах поочередно, чтобы ODM база их обновилась или на одном, т.к. верификация и синхронизация обновит ODM на вторичном узле?

  • #16444

    andrewk
    Участник

    Albert, между 3 и 4 тогда по идее еще rmdev -Rdl того hdisk’а, который выкинули из группы, и cfgmgr.

  • #16445

    uxTuaHgp
    Участник

    действительно, разбить зеркало, переопределить том и обратно.
    Однако синхронизация зеркала размером в 20-30ТБ то еще удовольствие.
    Вероятно при таком раскладе нужно либо с остановкой кластера делать либо добавлять новые тома вместо расширения имеющихся.

  • #16446

    Albert Maksimov
    Участник

    Как я понял, после останова кластера, если concurrent(ную) группу поднять простым
    varyonvg , то она подмимется как обычная. Потом chvg -g. Потом опять varyoffvg, чтобы в следующий раз она уже поднялась, как concurrent(ная).

    Да, именно так, однако, если у Вас есть возможность протестировать – протестируйте.

    Эти операции нужно делать на обоих узлах поочередно, чтобы ODM база их обновилась или на одном, т.к. верификация и синхронизация обновит ODM на вторичном узле?

    Нет. На обоих узлах так делать не надо, только на первом. На втором узле делаете exportvg-importvg.
    Протестируйте!

    Albert, между 3 и 4 тогда по идее еще rmdev -Rdl того hdisk’а, который выкинули из группы, и cfgmgr.

    За AIX 5.3 не ручаюсь (лень проверять), но под AIX 6.1 размер hdisk’а меняется сразу после расширения LUN’а. Поэтому, как мне кажется, нет смысла в rmdev-cfgmgr.

  • #16447

    Albert Maksimov
    Участник

    действительно, разбить зеркало, переопределить том и обратно.
    Однако синхронизация зеркала размером в 20-30ТБ то еще удовольствие.
    Вероятно при таком раскладе нужно либо с остановкой кластера делать либо добавлять новые тома вместо расширения имеющихся.

    С такими объёмами дел не имел.
    Для надёжности я бы в зеркало добавил третью копию перед тем, как начать процедуру увеличения:)

  • #16449

    uxTuaHgp
    Участник

    Не имел дел,но представить время, за которое создастся третья копия а потом пересоздастся заново можешь?
    Темп, чтобы сильно не напрягать пользователей будет примерно 200МБ/сек на хорошем СХД.
    Одно зеркало создаваться будет ~40 часов, создавая немалую дополнительную нагрузку на СХД.

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

  • #16451

    nickalias
    Участник

    Опять напрягаю Albert(а).
    Тестировать нам негде, будем резать по живому, поэтому хочется уточнить еще раз:

    Работа со стороны AIX c HACMP после расширения LV на DS8300

    На Узле1
    a. cfgmgr
    b. varyonvg
    c. chvg –g
    d. varyoffvg
    e. exportvg

    На Узле2
    a. importvg -y -n -V vpathN
    b. varyonvg sapvg
    c. varyoffvg sapvg

    На Узле1
    a. Синхронизация и верификация кластера
    b. Запуск кластера
    c. Увеличение через SPOC файловой системы, что на LV в VG

    Я правильно понял?

  • #16452

    Albert Maksimov
    Участник

    Не имел дел,но представить время, за которое создастся третья копия а потом пересоздастся заново можешь?
    Темп, чтобы сильно не напрягать пользователей будет примерно 200МБ/сек на хорошем СХД.
    Одно зеркало создаваться будет ~40 часов, создавая немалую дополнительную нагрузку на СХД.

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

    Согласен с вами. Если объёмы сущщественные и система сильно нагруженна, то добавление нового тома выглядит предпочтительнее.

    nickalias, какие у вас объёмы данных? Почему бы, действительно, не добавить новый том?

    На Узле1
    a. cfgmgr
    b. varyonvg
    c. chvg –g
    d. varyoffvg
    e. exportvg Этого делать не надо. exportvg удаляет определенеи VG из ODM.

    На Узле2
    Вот здесь я бы сделал exportvg , чтобы вдальнейшем импортировать обновленную VG.
    a. importvg -y -n -V vpathN
    b. varyonvg sapvg Не стал бы этого делать. Для чего активировать и сразу деактивировать vg?
    c. varyoffvg sapvg

    На Узле1
    a. Синхронизация и верификация кластера
    b. Запуск кластера
    c. Увеличение через SPOC файловой системы, что на LV в VG

    Пункты “a” и “b” не надо ли поменять местами? Как вы будете делать синхронизацию-верификацию если кластерные сервисы неактивны?
    Я бы сначала стартовал кластерные сервисы, потом синхронизация-верификация и в случае успеха старт ресурсной группы.

    Я бы сделал так:
    1. остановка ресурсной группы и кластерных сервисов на обоих узлах
    2. увеличение LUN’ов

    3. на Узле1
    a. bootinfo -s – проверить, изменились ли размеры дисков
    b. varyonvg
    c. chvg –g
    d. varyoffvg

    4. На Узле2
    a. exportvg
    b. importvg -y -n -V hdisk <<< здесь имя диска, не путь. Так?

    5. на Узле1 или на Узле2
    a. запуск кластерных сервисов
    б. синхронизация-верификация
    с. старт ресурсной группы

    Хорошо бы услышать мнение других участников дискуссии. Не хотелось бы наткнуться на рифы!

  • #16461

    nickalias
    Участник

    Albert! Что-то я опять не догоняю:

    на Узле1
    a. bootinfo -s – проверить, изменились ли размеры дисков

    Почему , а не ? При SDD драйвере, если смотреть datapath query device ,
    то hdiskN – это часть метаустройства vpath и предствляет собой один из путей до реального LV на DS8300.

    4. На Узле2
    a. exportvg
    b. importvg -y -n -V hdisk <<< здесь имя диска, не путь. Так?

    То же самое не , а наверное

    5. на Узле1 или на Узле2
    a. запуск кластерных сервисов
    б. синхронизация-верификация

    Всегда до запуска кластера производится его синхронизация и верификация кластера, т.е. a и б перепутаны местами.

    МОЖЕТ КТО-НИБУДЬ ИЗ ПРИСУТСТВУЮЩИХ ТОВАРИЩЕЙ ВНЕСЕТ ЯСНОСТЬ?

  • #16462

    Albert Maksimov
    Участник

    Всегда до запуска кластера производится его синхронизация и верификация кластера, т.е. a и б перепутаны местами.

    Да, Вы правы. Синхронизацию-верификацию можно делать до запуска сервисов.

  • #16463

    Albert Maksimov
    Участник

    [quote]
    на Узле1
    a. bootinfo -s – проверить, изменились ли размеры дисков

    Почему , а не ? При SDD драйвере, если смотреть datapath query device ,
    то hdiskN – это часть метаустройства vpath и предствляет собой один из путей до реального LV на DS8300.[/quote]Вы попробуйте. Вместо неподдерживаемой bootinfo можно исползовать getconf DISK_SIZE /dev/hdiskX

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