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

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

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

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

увеличить изображение
Рис. 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. Преобразование снимка.

#odmget HACMPnode HACMPnode:
name = Ccobra"
object = "COMMUNICATION_PATH"
value = "10.10.32.33"
node_id = 2
node_handle = 2
version = 8

6. Применение снимка (при этом конфигурация будет передана на все узлы).
7. Запуск служб кластера поочередно на каждом узле.
8. Верификация и синхронизация кластера.

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

В процессе написание этой книги мы протестировали выполнение миграции на 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 представлена диаграмма конфигурации, используемой в нашей тестовой среде.

увеличить изображение
Рис. 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_install^{2Имеется в виду так называемое "клонирование" системы.} как средства возврата к прежней конфигурации. Это было сделано с целью ускорения повторного тестирования.

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

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

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

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

#odmget HACMPnode
HACMPnode:
name = "cobra"
object = "COMMUNICATION_PATH"
value = "10.10.32.33"
node_id = 2
node_handle = 2
version = 8

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