Компания IBM
Опубликован: 01.02.2008 | Доступ: свободный | Студентов: 540 / 20 | Оценка: 4.60 / 4.40 | Длительность: 43:55:00
Специальности: Разработчик аппаратуры

Лекция 5: Миграция кластера на HACMP V5.3

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >

Основные этапы миграции

Циклическая миграция

Метод циклической миграции используется в тех случаях, когда требуется обеспечить доступность приложения в процессе миграции. Этот тип миграции состоит из следующих этапов (рис. 5.1):

Основные этапы циклической миграции с HA 4.5 до HA 5.3

увеличить изображение
Рис. 5.1. Основные этапы циклической миграции с HA 4.5 до HA 5.3
  1. Остановка служб кластера на первом узле с передачей ресурсов на резервный узел.
  2. Обновление программного обеспечения AIX и RSCT (если необходимо).
  3. Обновление программного обеспечения HACMP (включая последние PTF).
  4. Перезагрузка.
  5. Реинтеграция узла в кластер и повторное выполнение операций на следующем узле.

На рис. 5.1 представлен пример обновления с кластера HACMP 4.5 под управлением AIX 5.1 до кластера HACMP 5.3 под управлением AIX 5.2.

Миграция с использованием снимков

Также существует возможность миграции кластера с использованием метода снимков. Использование этого метода предполагает применение снимка, созданного до выполнения обновления, для восстановления конфигурации. После удаления и повторной установки всех узлов выполняется преобразование и применение снимка. Однако в процессе миграции целый кластер будет недоступен, и все узлы должны быть обновлены до повторной активизации кластера.

Этот тип миграции состоит из следующих этапов:

  1. Остановка служб кластера на всех узлах.
  2. Обновление программного обеспечения AIX и RSCT на всех узлах (если необходимо).
  3. Деинсталляция текущей версии HACMP и установка HACMP 5.3 на всех узлах (включая последние PTF, если они доступны).
  4. Перезагрузка.
  5. Преобразование снимка.
Замечание. Если вы планируете использовать метод снимков, помните о том, что при попытке повторного применения снимка на узлах в первую очередь HACMP попытается использовать путь для связи, заданный в объектном классе HACMPnode.
#odmget HACMPnode HACMPnode:
name = Ccobra"
object = "COMMUNICATION_PATH"
value = "10.10.32.33"
node_id = 2
node_handle = 2
version = 8
Это значение изначально устанавливается при первом определении узлов в кластере с указанием COMMUNICATION PATH. Рекомендуется всегда устанавливать этот путь в качестве постоянного IP-адреса. Если по какой-либо причине этот IP-адрес недоступен на момент применения снимка, следует вручную установить этот синоним на одном из интерфейсов. Последним файлом, в котором выполняется поиск пути для связи, является файл /usr/es/sbin/cluster/etc/rhosts, в котором при необходимости можно вручную задать все IP-адреса кластера. IP-адреса будут включать: базовые, сервисные и постоянные IP-адреса.
  1. Применение снимка (при этом конфигурация будет передана на все узлы).
  2. Запуск служб кластера поочередно на каждом узле.
  3. Верификация и синхронизация кластера.

Протестированные сценарии

В процессе написание этой книги мы протестировали выполнение миграции на HACMP V5.3 с трех разных версий:

  • HAES 4.5;
  • HAES 5.1;
  • HAES 5.2.

Для каждой из этих версий мы выполняли циклическую миграцию и миграцию с использованием снимков, выполняя документирование действий и результатов. Обратите внимание на то, что при переходе с HAS на HAES мы решили не рассматривать способ поузловой миграции. При подготовке к обновлению с HAS 4.5 мы рекомендуем по возможности использовать метод преобразования снимка.

Мы выполнили все инсталляции и обновления с применением NIM-сервера с наиболее актуальными PTF для HACMP, AIX, RSCT и SDD.

Сценарий 1: AIX 5.1 и HAES 4.5

В качестве первого теста миграции мы решили выполнить обновление трехузлового кластера AIX 5.1 / HAES 4.5 до AIX 5.2 / HA 5.3. Мы использовали серверы p630 (70286C4) в своей конфигурации кластера. На рис. 5.2 представлена диаграмма конфигурации, используемой в нашей тестовой среде.

Сценарий 1: среда миграции с HA 4.5 на HA 5.3

увеличить изображение
Рис. 5.2. Сценарий 1: среда миграции с HA 4.5 на HA 5.3

В нашем кластере каждый узел осуществлял управление своей собственной группой ресурсов. Каждая группа ресурсов содержала группу томов приложения, сервисный IPадрес и сервер приложения. Топология была настроена на использование IPAT посредством замены, с целью протестировать переход на HACMP 5.3. Мы выполнили конфигурирование сетей RS232, использующих интегрированные порты на узлах для трафика пульса в сетях, отличных от IP. Хранилище содержало ESS LUN (2105-800) с подключением к коммутатору, а также скрипт подключения хоста (ibm2105.rte) и драйвер SDD.

Этапы циклической миграции: сценарий 1

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

Мы выполнили следующие предварительные действия:

  1. Сохранение снимка с рабочего кластера (со всеми активными узлами).
    Внимание! Не сохраняйте снимок в каталог /tmp, так как при установке AIX содержимое каталога /tmp удаляется. Сохраните снимок в другой каталог или на другой сервер. Не забудьте также сохранить скрипты запуска/остановки в надежный каталог.
  2. Создание резервной копии ( mksysb ).
  3. Создание alt_disk_install2Имеется в виду так называемое "клонирование" системы. как средства возврата к прежней конфигурации. Это было сделано с целью ускорения повторного тестирования.

Сценарий миграции

Ниже перечислены действия, выполняемые нами в нашем сценарии миграции.

  1. Остановка HACMP на узле panther (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover):
    • перемещение C10RG1 на узел tiger;
    • проверка с использованием /usr/es/sbin/cluster/utilities/clfindres.
  2. Инициация миграции AIX5.2/RSCT:
    • применение последних исправлений AIX 5.2 (ML06);
    • обновление и верификация уровней RSCT (rsct.basic.rte 2.3.6.2);
    • удаление и замена SDD текущим драйвером AIX 5.2;
      • stopsrc -s sddsrv;
      • rmdev -dl dpo -R;
      • деинсталляция SDD 5.1 с использованием smitty remove (devices.sdd.51.rte 1.6.0.2);установка SDD 5.2 (devices.sdd.52.rte 1.6.0.0 и 1.6.0.2 PTF).
  3. Выполнение smit update_all для обновления наборов файлов HACMP до версии 5.3.
  4. Перезагрузка узла panther:
    • в нашей конфигурации группа ресурсов C10RG1 была настроена на перемещение при сбое на узел с более высоким приоритетом при реинтеграции, вследствие чего группа ресурсов возвратилась на узел panther.
    • команда cldump отобразила корректное размещение и состояние всех ресурсов.
      Внимание! Выполнение синхронизации для кластера в гибридном состоянии нарушит миграцию и оставит кластер в несогласованном состоянии.
  5. Повторное выполнение действий для узла puma.
  6. Повторное выполнение действий для узла tiger.

После входа последнего узла в кластер выполняется преобразование ODM, после чего в объектных классах HACMPcluster и HACMPnode отображается версия cluster_ version = 8.

Результаты циклической миграции: сценарий 1

Миграция AIX представляла самый медленный этап обновления. Реинтеграция последнего узла кластера была успешной, и мы смогли убедиться в том, что различные разделы HACMP ODM были преобразованы корректно и что все узлы теперь выводили версию cluster_version = 8. Способы проверки номеров версий HACMP см. в табл. 5.2.

После завершения мы проверили состояние кластера с использованием утилиты clstat, а также состояние узлов по выходным данным команды lssrc -ls clstrmgrES.

#lssrc -ls clstrmgrES
Current state: ST_STABLE

После завершения мы использовали инструмент тестирования кластера (Cluster Test Tool) для запуска различных тестов и не обнаружили каких-либо проблем. Мы снова выполнили тестирование миграции и не обнаружили проблем с функционированием кластера.

Миграция с использованием снимков: сценарий 1

В том же кластере из трех узлов мы проверили работу метода преобразования снимков. Мы использовали образы установки на резервных дисках для возврата к прежней среде, после чего перезапустили службы кластера на всех узлах, на которых выполнялся HA 4.5. Тестирование содержало следующие действия:

  1. Остановка HACMP на всех узлах: panther, puma, tiger.
  2. Выполнение команды smit remove и деинсталляция всех наборов файлов cluster.* со всех узлов.
  3. Миграция кода AIX/RSCT с использованием NIM.
  4. Установка пакетов HACMP с текущими уровнями PTF на всех узлах.
  5. Перезагрузка всех узлов кластера.
  6. Копирование файла snapshot.odm, предварительно сохраненного в процессе циклической миграции и имеющего расположение /usr/es/sbin/cluster/utilities/ snapshot.odm.
  7. Выполнение следующей команды для преобразования снимка: #/usr/es/sbin/ cluster/conversion/clconvert_snapshot -v 4.5 -s snapshot.odm
  8. Применение снимка: smit hacmp > Extended Configuration (Расширенное конфигурирование) > Snapshot Configuration (Конфигурирование снимка) > Apply a Cluster Snapshot (Применение снимка кластера) > выбор снимка и нажатие Enter.
  9. Запуск служб кластера поочередно на каждом узле.

Результаты миграции с использованием снимков: сценарий 1

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

Замечание. Если вы планируете использовать метод снимков, помните о том, что при попытке повторного применения снимка на узлах в первую очередь HACMP попытается использовать путь для связи, заданный в объектном классе HACMPnode.
#odmget HACMPnode
HACMPnode:
name = "cobra"
object = "COMMUNICATION_PATH"
value = "10.10.32.33"
node_id = 2
node_handle = 2
version = 8
Это значение изначально устанавливается при первом определении узлов в кластере с указанием COMMUNICATION PATH. Рекомендуется всегда устанавливать этот путь в качестве постоянного IP-адреса. Если по какой-либо причине этот IP-адрес недоступен на момент применения снимка, следует вручную установить этот синоним на одном из интерфейсов. Последним файлом, в котором выполняется поиск пути для связи, является файл /usr/es/sbin/cluster/etc/rhosts, в котором при необходимости можно вручную задать все IP-адреса кластера. IP-адреса будут включать: базовые, сервисные и постоянные IP-адреса.

После завершения миграции мы убедились в корректности преобразования разделов HACMP ODM путем проверки версии кластера в объектных классах HACMPcluster и HACMPnode. Также мы использовали инструмент тестирования кластера (Cluster Test Tool) после завершения миграции и не обнаружили каких-либо проблем.

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Динар Валеев
Динар Валеев
Россия
Lichodedov Andrej
Lichodedov Andrej
Литва