Реализация мультипроцессорных кластеров высокой доступности (HACMP)

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

Разбить на страницы
Показывать лекцию целиком

Выбор пути миграции

Внимание! Всегда просматривайте список действий в руководстве по планированию и установке, если вы незнакомы с процедурой.

Существует три пути миграции, с использованием которых можно обновить кластер до более поздней версии. (Выбор пути миграции осуществляется путем ответа на вопрос, допустим ли перерыв в работе целого кластера, или же требуется обеспечивать максимальную доступность).

  • Циклическая миграция (Rolling Migration) (с ES на ES). Этот метод обеспечивает доступность ресурсов как минимум на одном узле, пока происходит поочередное обновление остальных узлов кластера. Это означает, что во время миграции кластер будет находиться в смешанном режиме.
  • Метод снимков (Snapshot Method). Этот метод требует недоступности всех узлов кластера на некоторый период, а также того, чтобы на всех узлах была установлена новая версия HACMP, прежде чем преобразовывать и применять снимок до миграции.
  • Поузловая миграция (Node by Node) (с HAS на ES). Этот метод подобен методу циклической миграции. Однако во время обновления каждого узла обе версии кода HACMP будут отображаться как установленные одновременно, а непосредственное управление кластером осуществляют старые демоны. Только после обновления последнего узла и его интеграции в кластер выполняется итоговое преобразование.
    •  Замечание. Обратите внимание на то, что в прошлом понятия циклической миграции и поузловой миграции использовались как синонимы.

    Поддерживаемые пути миграции

    Поддерживаемые обновления версий до HACMP 5.3
    Текущая версия Циклическая миграция Метод снимков Поузловая миграция
    HACMP/ES 5.2 да да неприменимо
    HACMP/ES 5.1 да да неприменимо
    HACMP/ES 4.5 да да неприменимо
    HACMP 4.5 неприменимо да да

    Требования

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

    Требования к дисковому пространству (для миграции с HAS на HAES):

    Должно быть достаточно дискового пространства, чтобы в процессе миграции помещалось и программное обеспечение HAS, и программное обеспечение HAES:

  • приблизительно 120 Мб в каталоге /usr;
  • приблизительно 1.2 Mб в каталоге / (корневом каталоге).
    •

    Узлы должны иметь достаточно памяти, чтобы одновременно выполнять оба набора демонов HACMP. Минимальный объем оперативной памяти составляет 64 Мб, однако рекомендуется иметь 128 Мб оперативной памяти (не считая требований приложений).

    Требования программного обеспечения кластера и RSCT

    Требуется обеспечить одинаковый уровень наборов файлов программного обеспечения кластера и RSCT (включая PTF) на всех узлах до начала миграции. Кроме того, следует обеспечить перевод программного обеспечения в состояние committed (а не только в applied).

    Чтобы проверить, установлено ли программное обеспечение в состояние committed:

  • Выполните команду lslpp -h cluster.*
  • Если под заголовком действия выводится APPLY, введите smit install_commit перед установкой программного обеспечения HACMP. SMIT отобразит панель Commit Applied Software Updates (Remove Saved Files).
  • Введите следующие значения полей:
  • SOFTWARE name (Название программного обеспечения). Из списка выберите все требуемые наборы файлов.
  • COMMIT old version if above version used it? (COMMIT старую версию поверх используемой версии?). Установите для этого поля значение YesТакого поля в smit install_commit нет. (Проверялось в AIX 5.2 и 5.3). .
  • EXTEND file system if space needed? (Расширить файловую систему, если требуется пространство?). Установите для этого поля значение Yes.
    •

    Изучение конфигурации

    Нужно знать конфигурацию своего кластера. Нужно изучить и понять общую конфигурацию до выполнения обновления. Если среда вам незнакома, выполните команду cltopinfo или cldump, чтобы получить информацию о среде. Выходные данные команд cllsif и clshowres также позволяют получить представление о конфигурации кластера и ожидаемом выполнении перемещения при сбое. Эта информация также полезна при необходимости обращения в службу поддержки AIX.

  • /usr/es/sbin/cluster/utilities/cllsif
  • /usr/es/sbin/cluster/utilities/clshowres
    •

    Первая команда отображает текущую конфигурацию топологии. Это поможет определить доступные сети, соответствующие метки и IP-адреса и их текущие функции. Вторая команда выводит все группы ресурсов и связанные с ними атрибуты. Это может помочь в определении текущих выделенных ресурсов и их функционирования во время перемещения при сбое.

    Рекомендации и проверки перед миграцией

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

  • Всегда создавайте снимок перед выполнением миграции. Не забудьте сохранить его в нескольких безопасных местах. Всегда выполняйте резервное копирование системы (mksysb) с текущей конфигурацией. Следует проверить содержимое резервной копии и убедиться в том, что с ее помощью можно выполнить восстановление данных.
  • При наличии ресурсов рассмотрите вариант alternate disk installation1 для резервного диска на каждом узле кластера перед выполнением миграции. Это полезно в том случае, если вам придется быстро выполнить возврат к старой конфигурации. Для выполнения возврата нужно изменить список загрузочных устройств (bootlist), указав в нем резервный диск, после чего выполнить перезагрузку узлов, на которых была выполнена миграция.
  • Прежде чем начать миграцию, убедитесь, что на всех узлах установлен одинаковый набор файлов программного обеспечения кластера и RSCT (включая PTF).
  • Файл /.rhosts нужен только при миграции с более ранних версий, чем HACMP 5.1. После выполнения миграции рекомендуется удалить файл .rhosts в корневом каталоге (/), если другие приложения не требуют rsh для связи между узлами.Примечание. Если ваше приложение и/или скрипты пред- и постобработки требуют удаленного выполнения команд (на основе AIX rsh), необходимо сохранить файл ~/. rhosts даже после миграции.
  • Убедитесь в том, что ваш кластер успешно выполняет перемещение при сбое, до миграции; в противном случае оно может не работать и после обновления.
  • Проверьте состояние системы и установленных наборов файлов:
  • выполните команду lppchk -v, -l, -c ;
  • выполните команду instfix -i | grep ML ;
  • просмотрите выходные данные команды errpt -a на наличие последних соответствующих ошибок;
  • выполните команду df -k и проверьте заполненность файловых систем;
  • выполните команду lsps -s и убедитесь в том, что пространство страничной подкачки (paging space) не заполнено;
  • выполните команду emgr -l и проверьте наличие каких-либо исправлений efixes, загруженных в системе, прежде чем начинать обновление.
    •

    Аспекты

    Обратите внимание на множество изменений в HACMP 5.3 по сравнению с более ранними версиями. В некоторых случаях они вызывают изменения в работе кластера. Ниже перечислены аспекты, которые следует учитывать при выполнении обновления.

  • Что касается HACMP 5.2, типы групп ресурсов cascading (каскадная), rotating (ротационная) и concurrent (с одновременным доступом) были преобразованы в настраиваемые группы ресурсов с соответствующими политиками запуска, перемещения при сбое и возврата после восстановления. При миграции с версий до HACMP 5.2 выполняется преобразование групп ресурсов таким образом, чтобы каждая группа ресурсов использовала соответствующие политики. Подробное описание политик в настраиваемых группах ресурсов приведено в 1 лекции.
  • Настраиваемые значения в HACMP после обновления кластера будут сброшены. Это включает следующие параметры:
  • Параметры настройки сетевых модулей, такие, как скорость обнаружения отказов (failure detection rate), отсрочка (grace period) и скорость пульса (heartbeat rate). Для них устанавливаются значения по умолчанию.
  • Выполняется сброс изменений в событиях кластера, в частности скриптов преди постобработки событий. При сбросе этих изменений файлы и скрипты, используемые при настройке, не удаляются, однако HACMP перестает их видеть.
    •
  • Все изменения в стандартном наборе команд HACMP будут сброшены в значения по умолчанию.
  • После начала циклической миграции кластер будет работать в смешанном режиме до тех пор, пока не будет выполнено обновление последнего узла и его реинтеграция в кластер. В этот период не следует пытаться применять какие-либо изменения в топологии кластера или ресурсах:
  • не выполняйте верификацию или синхронизацию кластера;
  • не выполняйте принудительное отключение узла;
  • не пытайтесь выполнять какие-либо операции DARE или C-SPOC, кроме функций управления службами HACMP (Manage HACMP Services);
  • не используйте функцию Problem Determination Tools (Инструменты определения проблем) > View Current State (Просмотр текущего состояния);
  • не используйте опцию Extended Configuration (Расширенное конфигурирование) > Snapshot Configuration (Конфигурирование снимков) > Add a Cluster Snapshot (Добавить снимок кластера) и не выполняйте команду clsnapshot;
  • не используйте опцию Problem Determination Tools (Инструменты определения проблем) > Recover from HACMP Script Failure (Восстановление после отказа скрипта HACMP) и не выполняйте команду clruncmd, кроме случаев выполнения команды или опции SMIT с целевого узла, заданного командой.Важно! Не следует оставлять кластер в гибридном состоянии длительное время, чтобы избежать случайного вызова любой из этих операций.
  • При обновлении с версий до HACMP 5.2 инсталляция HACMP создает группу hacmp на всех узлах. Классы (ODM) базы данных конфигурации HACMP (HACMP Configuration Database) были обновлены, и теперь их владельцами являются пользователь root и группа hacmp:
  • Для большинства объектных классов HACMP установлены права доступа к файлам 640. Исключение представляет класс HACMPdisksubsystem, имеющий права доступа 600
  • Все двоичные файлы HACMP, предназначенные для применения пользователями без привилегий "root", устанавливаются с правами доступа 2555. Включается бит setgid, так что программа будет выполняться в контексте группы hacmp.
  • При использовании программ, осуществляющих прямой доступ к ODM, может возникнуть необходимость их перезаписи.Внимание! Использование информации, получаемой непосредственно из ODM, предназначено только для информационных целей, так как формат разделов (stanzas) может быть различным в разных обновлениях и/или в новых версиях. Таким образом, жесткое кодирование ODM-запросов в пользовательских приложениях не поддерживается и его следует избегать.
  • При использовании средства PSSP File Collections для обеспечения согласованности /etc/group новая группа hacmp может быть потеряна во время следующей синхронизации файлов. Чтобы этого избежать, нужно выполнить следующие действия:
  • отключить синхронизацию PSSP File Collection для /etc/group;
  • включить группу hacmp в мастер-файл (master file) /etc/group и распространить изменение на всех узлах.Примечание. В целях безопасности не следует расширять полномочия группы hacmp.
    • Политики динамического приоритета узлов в версиях до HACMP 5.2 были основаны на переменных ресурсов RSCT Event Management. Если ваша конфигурация включает группу ресурсов HACMP 5.1, в которой для политики динамического приоритета узла установлено значение Fallover using Dynamic Node Priority (Перемещение при сбое с использованием динамического приоритета узла), при миграции это значение будет сброшено. Утилита cl_convert изменит политику перемещения при сбое для этой группы ресурсов, установив для нее значение Fallover to Next Priority Node in the list (Перемещение при сбое на узел из списка со следующим приоритетом):
  • во время миграции используется политика перемещения при сбое по умолчанию;
  • обратите внимание на то, что HACMP 5.3 поддерживает только три политики:
  • cl_highest_free_mem;
  • cl_highest_idle_cpu;
  • cl_lowest_disk_busy.
    •
  • В HACMP 5.3 поддерживается только одна политика распределения групп ресурсов – политика распределения на основе узлов (node-based distribution policy). Ранее доступная политика распределения на основе сетей (network-based distribution policy) была удалена. Во время миграции она преобразуется в политику на основе узлов.
  • События кластера, определенные пользователем, могут не работать, так как emsvcs больше не применяются в HACMP. Для исправления проблем следует перезаписать их с использованием rmcd.
  • Диспетчер блокировки кластера (Cluster Lock Manager, cllockd или cllockdES) более недоступен в HACMP 5.3. Во время установки происходит удаление файлов и определений Lock Manager на узле. Проконсультируйтесь с производителем приложения относительно поддержки одновременного доступа.
  • Обратите внимание на то, что режим расширенного одновременного доступа поддерживается только в AIX 5L V5.1 и более поздних версиях. Режим одновременного доступа SSA (SSA concurrent mode) не поддерживается на 64-разрядном ядре. При использовании SSA-дисков в режиме одновременного доступа нельзя запустить 64-разрядное ядро до преобразования всех групп томов в режим расширенного одновременного доступа.

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

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

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

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

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

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

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

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

  • Остановка служб кластера на всех узлах.
  • Обновление программного обеспечения AIX и RSCT на всех узлах (если необходимо).
  • Деинсталляция текущей версии HACMP и установка HACMP 5.3 на всех узлах (включая последние PTF, если они доступны).
  • Перезагрузка.
  • Преобразование снимка.
    •  Замечание. Если вы планируете использовать метод снимков, помните о том, что при попытке повторного применения снимка на узлах в первую очередь 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-адреса.
  • Применение снимка (при этом конфигурация будет передана на все узлы).
  • Запуск служб кластера поочередно на каждом узле.
  • Верификация и синхронизация кластера.
    •

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

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

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

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

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

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

  • Остановка HACMP на узле panther (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover):
  • перемещение C10RG1 на узел tiger;
  • проверка с использованием /usr/es/sbin/cluster/utilities/clfindres.
    •
  • Инициация миграции 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).
  • Выполнение smit update_all для обновления наборов файлов HACMP до версии 5.3.
  • Перезагрузка узла panther:
  • в нашей конфигурации группа ресурсов C10RG1 была настроена на перемещение при сбое на узел с более высоким приоритетом при реинтеграции, вследствие чего группа ресурсов возвратилась на узел panther.
  • команда cldump отобразила корректное размещение и состояние всех ресурсов.Внимание! Выполнение синхронизации для кластера в гибридном состоянии нарушит миграцию и оставит кластер в несогласованном состоянии.
  • Повторное выполнение действий для узла puma.
  • Повторное выполнение действий для узла 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. Тестирование содержало следующие действия:

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

    Результаты миграции с использованием снимков: сценарий 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) после завершения миграции и не обнаружили каких-либо проблем.

    Сценарий 2: AIX 5.2 и HA 5.1

    Второй тестовый сценарий представлял собой миграцию двухузлового кластера AIX 5.2 / HA 5.1, настроенного на взаимный перехват ресурсов, на AIX 5.3 / HA 5.3. Мы использовали серверы p630 (7028-6C4) в конфигурации кластера. На рис. 5.3 представлена схема используемой конфигурации.

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

    (рис 5.3) Сценарий 2: среда миграции с HA 5.1 на HA 5.3

    Циклическая миграция: сценарий 2

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

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

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

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

    Сначала мы решили выполнить обновление узла cobra. Для этого мы выполнили следующие действия:

  • Остановка HACMP на узле cobra (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover):
  • перемещение C10RG1 на узел viper;
  • проверка с использованием /usr/es/sbin/cluster/utilities/clRGinfo.
    •
  • Инициация миграции AIX 5.3/RSCT с использованием кода NIM вместе с последними исправлениями: smit remove sdd – должно быть выполнено удаление и замена:
  • stopsrc -s sddsrv;
  • rmdev -dl dpo -R;
  • деинсталляция драйвера SDD 5.2 с использованием smitty remove (devices. sdd.52.rte 1.6.0.2);
  • установка драйвера SDD 5.3 (devices.sdd.53.rte 1.6.0.0 и 1.6.0.2).
  • Выполнение smit update_all для загрузки наборов файлов HA 5.3.
  • Перезагрузка узла cobra.
  • Реинтеграция узла cobra в кластер путем запуска служб кластера. Политика ресурсов была настроена на перемещение при сбое на узел с более высоким приоритетом, вследствие чего группа ресурсов C10RG1 возвратилась на узел cobra.Внимание. На этом этапе ODM-классы HACMP на узле cobra не были преобразованы и не соответствуют новой версии, тогда как наборы файлов соответствуют версии HA 5.3. На данном этапе кластер находится в смешанном режиме или, так называемом гибридном состоянии (hybrid state).
  • Остановка HACMP на узле viper (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover). Группа ресурсов C10RG2 перемещается на узел cobra.
  • Повтор операций установки AIX/RSCT и HACMP на узле viper.
  • Перезагрузка узла viper.
  • Реинтеграция узла viper в кластер путем запуска служб кластера.

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

    Общее тестирование циклической миграции было успешным. Как и в сценарии 1, миграция AIX представляла самый медленный этап обновления. После ее выполнения мы протестировали перемещение при сбое в кластере и не обнаружили проблем. Реинтеграция последнего узла была успешной, и мы убедились в том, что изменения в ODM соответствовали новой версии HACMP.

    В целях тестирования мы решили прервать миграцию, когда узлы были в смешанном режиме. Мы остановили узел cobra, когда на нем выполнялся HACMP 5.3 и он содержал обе группы ресурсов. В это время на узле viper выполнялся процесс установки HACMP 5.3. После перезагрузки узла cobra и перезапуска служб кластера, он подхватил свою группу ресурсов (C10RG1). После этого мы вручную подключили группу ресурсов узла viper:

    #smit hacmp > System Management (C-SPOC) > HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Bring a Resource Group online (Подключение группы ресурсов) > выбор C10RG2 и нажатие Enter.

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

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

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

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

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

    В целом миграция с использованием снимка также прошла успешно. Преобразование файла снимка заняло несколько секунд, и его применение на обоих узлах также произошло очень быстро. После завершения миграции мы убедились в корректности преобразования разделов HACMP ODM путем проверки версии кластера в объектных классах HACMPcluster и HACMPnode.

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

    Мы считаем, что, если ваша среда допускает перерыв в обслуживании в масштабе кластера, можно использовать этот быстрый и надежный метод, позволяющий полностью избежать функционирования узлов в смешанном режиме. Использование снимка для возврата конфигурации HACMP после обновления всех узлов позволяет избежать потенциальных проблем, которые могут возникнуть в процессе циклической миграции. Дополнительные сведения о потенциальных проблемах см. в разделе "Аспекты", в этой лекции.

    Сценарий 3: AIX 5.2 и HA 5.2

    Третий тестовый сценарий представлял собой миграцию кластера AIX 5.2 / HA 5.2 с двумя активными узлами и одним дежурным резервным узлом на AIX 5.3 / HA 5.3. В своей конфигурации мы использовали три одинаковых LPAR p690 (7040-681). На рис. 5.4 представлена схема используемой конфигурации.

    Топология была настроена на использование IP-синонимов вместе с мониторингом пульса через синонимы. Это было сделано, чтобы убедиться в том, что обновление сохранит смещение сети 10.10.1.1 и соответствующие синонимы и что впоследствии проблем в работе кластера не возникнет.

    Примечание. Помните, что при использовании мониторинга пульса через синонимы в вашей сетевой топологии мониторинг базовых адресов в HACMP не выполняется.

    Мы сконфигурировали базовые адреса для каждого узла в соответствующей подсети и поместили все сервисные и постоянные IP-адреса в другой диапазон подсети. Такая конфигурация IP используется для имитации университетской среды, где компьютеры могут быть разделены определенным расстоянием и могут использовать различные подсети, а также для того, чтобы убедиться в том, что для базовых адресов не выполняется мониторинг с использованием трафика пульса HACMP.

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

    (рис 5.4) Сценарий 3: среда миграции с HA 5.2 на HA 5.3

    Циклическая миграция: сценарий 3

    Для этого сценария мы использовали кластер в среде DLPAR, чтобы убедиться в том, что все работает после обновления. Мы выполнили следующие предварительные действия:

  • Сохранение снимка с рабочего кластера (со всеми активными узлами).
  • Создание резервной копии (mksysb).
  • Создание alt_disk_install как средства возврата к прежней конфигурации. Это было сделано с целью ускорения повторного тестирования.
    •

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

    Сначала мы решили выполнить обновление дежурного узла alexis, чтобы максимально сократить перерыв в работе узлов, содержащих группы ресурсов. Для этого мы выполнили следующие действия:

  • Остановка HACMP на узле alexis (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).Внимание. Не сохраняйте снимок в каталог /tmp, так как при миграции AIX содержимое каталога /tmp удаляется. Сохраните снимок в другой каталог или на другой сервер. Не забудьте также сохранить скрипты приложения в надежный каталог.
  • Инициация установки базового кода AIX 5.3/ RSCT с использованием NIM вместе с последними исправлениями. Удаление и замена SDD текущим драйвером AIX 5.3:
  • stopsrc -s sddsrv;
  • rmdev -dl dpo -R;
  • деинсталляция драйвера SDD 5.2 с использованием smitty remove (devices. sdd.52.rte 1.6.0.2);
  • установка драйвера SDD 5.3 (devices.sdd.53.rte 1.6.0.0 и 1.6.0.2 PTF).
    •
  • Выполнение smit update_all для загрузки наборов файлов HACMP 5.3.
  • Перезагрузка узла alexis:
  • Верификация инсталляции AIX ( lppchk -l / -c / -v, instfix, oslevel, errpt );
  • lslpp -l | grep cluster => Нет следов версии 5.2 (проверка отсутствия наборов файлов);
  • odmget HACMPcluster => все еще отображалась версия 7.
  • Реинтеграция узла alexis в кластер путем запуска служб кластера.Внимание. Выполнение синхронизации для кластера в гибридном состоянии нарушит миграцию.
  • Остановка HACMP на узле jordan (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
  • Повтор действий пп. 2–5 на узле jordan.
  • Остановка HACMP на узле jessica (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
  • Повтор действий пп. 2–5 на узле jessica.

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

    Как и в двух предыдущих сценариях, мы не столкнулись с какими-либо проблемами при циклической миграции HACMP. После интеграции последнего узла в кластер было выполнено преобразование разделов ODM-классов, и теперь для всех узлов выводилось cluster_version = 8, как и ожидалось. Номера версий HACMP см. в табл. 5.2.

    При первоначальной настройке топологии кластера мы выполнили конфигурирование базового, постоянного и сервисного IP-адресов в одной подсети. Хотя такая топология и допустима, она создает некоторые проблемы в среде NIM (Network Install Manager), так как NIM неспособен обрабатывать постоянные синонимы (что вызывает отказы при подключении NFS).

    Поэтому мы советуем быть осторожными при внедрении HACMP в среде NIM; это также относится к среде CSM (Cluster Systems Management), которая использует NIM для установки и обновления программного обеспечения на управляемых узлах. ( пример 5.1 представляет конфигурацию в файле hosts (которая создает проблемы с NIM):

    _:># more /etc/hosts
192.168.100.200 jordan_base1
192.168.100.201 jordan_base2
192.168.100.202 jessica_base1
192.168.100.203 jessica_base2
192.168.100.204 alexis_base1
192.168.100.205 alexis_base2
192.168.100.71 p690_1_lpar1 #persistent IP jordan
192.168.100.72 p690_1_lpar2 #persistent IP jessica
192.168.100.61 p690_2_lpar1 #persistent IP alexis
192.168.100.101 dlpar_app1_svc
192.168.100.102 dlpar_app1_svc
    Примечание. Конфигурация, представленная в примере 5.1 , основана на маске сети класса C (255.255.255.0). В качестве альтернативы мы изменили нашу топологию на топологию, представленную на рис. 5.4, и сконфигурировали наши базовые адреса в отдельной подсети от сервисных и постоянных IP-адресов.

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

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

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

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

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

    Мы считаем, что, если ваша среда допускает перерыв в обслуживании в масштабе кластера, можно использовать этот быстрый и надежный метод, позволяющий полностью избежать функционирования узлов в смешанном режиме. Использование снимка для возврата конфигурации HACMP после обновления всех узлов позволяет избежать потенциальных проблем, которые могут возникнуть в процессе циклической миграции. Дополнительные сведения о потенциальных проблемах см. в разделе "Аспекты", в этой главе.

    Действия после миграции

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

  • Проверьте наличие наборов файлов HACMP, оставшихся от прежней версии. Могли остаться старые наборы файлов документации, которые, хотя и не создают каких-либо проблем, также должны быть обновлены.
  • После выполнения любого типа миграции следует осуществить верификацию и синхронизацию конфигурации кластера.
  • После любой миграции следует протестировать выполнение перемещения при сбое и восстановления. Инструмент Cluster Test Tool позволяет выполнять несколько тестов и может быть настроен на использование дополнительных тестов.
  • Обратите внимание на то, что после версии 4.5 файл ~/.rhosts больше не нужен (и не используется) в HACMP. Если он не нужен в вашей среде, не забудьте его удалить.
    •

    Совет после миграции

    При выполнении миграций AIX/HACMP мы использовали NIM-сервер. Мы применяли постоянные IP-адреса в определениях компьютеров NIM-клиентов. В результате мы обнаружили, что при установке в качестве базового адреса для одного из интерфейсов была установлена постоянная IP-метка, тогда как базовый адрес был удален. Кроме того, в качестве имени хоста было установлено имя компьютера, заданное в определении NIM-клиента.

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

  • smitty chinet => жесткая установка прежнего базового адреса интерфейса.
  • Мы закомментировали строки, добавленные в файл /etc/rc.net:
    /bin/hostname <hostname>
/usr/sbin/ifconfig <en#> inet <IP> netmask 255.255.255.0
  • hostname <name> => установка прежнего имени хоста.
    •

    При использовании NIM следует проверить, были ли выполнены эти изменения; в противном случае вы получите неоднозначные результаты в HACMP после запуска служб кластера.

    Этой проблемы можно избежать путем настройки NIM (это предполагает создание собственного скрипта настройки).

    Устранение неполадок при отказе миграции

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

    Возврат после отказа миграции

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

    Внимание. В зависимости от этапа миграции, на котором возникли проблемы, может не потребоваться выполнять восстановление кластера целиком.

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

    На этом этапе у вас есть следующие варианты:

    Вариант 1 – включить узел и попытаться найти и устранить проблему.

    Вариант 2 – возвратиться к старой конфигурации.

    Вариант 3 – деинсталлировать старое программное обеспечение HACMP, уста новить новый код и применить способ миграции с использованием снимков (при условии, что у вас есть снимок).

    Вариант 1: устранение неполадок при отказе миграции

    В случае остановки работы узла включите узел. При включенном компьютере и неактивном HACMP можно попытаться определить причину остановки путем просмотра журналов кластера и системы. Рекомендуется просмотреть следующие журналы и отчеты:

  • Просмотрите отчет об ошибках (errpt -a| more). Запишите точное время отказа на основании записей в журнале ошибок. Проанализируйте все недавние релевантные ошибки и попытайтесь найти факты аварийного завершения демонов или создания файлов CORE.
  • Просмотрите файл /usr/es/adm/cluster.log на наличие любых релевантных событий кластера. Проанализируйте журнал на наличие событий кластера, имевших место во время отказа. Не забудьте просмотреть журналы на других узлах кластера на предмет возможных различий.
  • Просмотрите файл /tmp/clstrmgr.debug на наличие сообщений об аварийных остановках clstrmgrES. При аварийной остановке диспетчера кластера обычно происходит остановка работы компьютера. Большинство сообщений, содержащих время остановки, записываются в конец этого файла. Сообщения могут дать вам представление о причине отказа.
  • В зависимости от содержания errpt-сообщений можно прибегнуть к анализу файлов журналов служб групп в /var/ha/log, чтобы попытаться определить проблему. Анализ записей журналов, совпадающих по времени с возникновением проблемы, может помочь в определении причины аварийного завершения демона или других зарегистрированных проблем.
    •

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

    Замечание. При обращении в службу поддержки программного обеспечения IBM требуется выполнить сбор выходных данных команды snap -e на узле, на котором произошел отказ, для того чтобы ускорить анализ и разрешение проблемы.

    Вариант 2: возврат к старой конфигурации

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

    В том случае если вместе с обновлением программного обеспечения AIX и RSCT выполняется обновление HACMP, возврат к старой конфигурации затрудняется. Вам потребуется остановить HACMP на всех обновленных узлах и выполнить на них возврат к предыдущей версии AIX либо с использованием резервной копии системы (mksysb), либо с использованием образов установки на резервных дисках, созданных перед началом миграции. После восстановления узлов с резервного источника следует выполнить верификацию и синхронизацию с текущих активных узлов. При успешном завершении можно выполнять реинтеграцию восстановленных узлов в кластер.

    После успешного восстановления первоначальной версии кода кластера следует изучить этапы миграции и убедиться в том, что были выполнены действия, описанные в разделе "Требования".

    Вариант 3: деинсталляция HACMP и выполнение миграции с использованием снимков

    Для использования этой опции необходимо иметь снимок конфигурации кластера на момент выполнения версии HACMP, с которой выполняется обновление. При этом действия в целом совпадают с действиями при миграции с использованием снимков, описанными в разделе "Основные этапы миграции".

  • Остановка служб кластера на всех узлах.
  • Обновление программного обеспечения AIX и RSCT на всех узлах (если необходимо).
  • Деинсталляция текущей версии HACMP и установка HACMP 5.3 на всех узлах (включая последние PTF, если они доступны).
  • Перезагрузка узлов.
  • Преобразование снимка.
  • Применение снимка.
  • Запуск служб кластера поочередно на каждом узле.
  • Верификация и синхронизация кластера.
    •  Примечание. Во всех наших тестовых сценариях миграции переход на HACMP 5.3 выполнялся автоматически без каких-либо проблем. Если у вас возникли проблемы, отличные от описанных в этом разделе, свяжитесь со службой поддержки программного обеспечения IBM для получения дальнейшей информации.

    Информация о версии кластера в HACMP ODM

    Чтобы получить информацию о версии кластера, выполните команды odmget HACMPcluster или odmget HACMPnode. Важно отметить, что после завершения миграции на HACMP 5.3 уровень версии должен быть равен восьми.

    Версия HACMP в разделах ODM
    Версия HACMP В HACMPcluster В HACMPnode
    HACMP 5.3 cluster_version = 8 version = 8
    HACMP 5.2 cluster_version = 7 version = 7
    HACMP 5.1 cluster_version = 6 version = 6
    HACMP 4.5 cluster_version = 5 version = 5
    HACMP 4.4.1 cluster_version = 4 version = 4

    Если версия не была обновлена при циклической миграции после интеграции последнего узла в кластер, следует просмотреть файл clconvert.log на наличие записей о возникновении проблем при миграции. Изменение значений в ODM администратором или персоналом службы поддержки IBM применяется в последнюю очередь.

    Внимание! Хотя это и не одобряется, но если вы все же решили вручную отредактировать значения в ODM для исправления несоответствия, следует прежде обратиться в службу поддержки программного обеспечения IBM.

    Устранение неполадок при использовании снимков

    В некоторых случаях при миграции с использованием снимков вы можете столкнуться с возникновением ошибок при верификации и отказов при попытке применения снимков. В том случае, если при применении снимка возникает ошибка, просмотрите файлы журналов на возможность ее коррекции утилитой верификации HACMP 5.3. Помните, что даже в случае отказа при попытке применения снимка, некоторые обновления конфигурации можно выполнить путем изменения ODM-классов HACMP.

    Если ошибка соответствует критериям несогласованности, подлежащей исправлению функцией автокоррекции процесса верификации, можно продолжать процесс обновления с использованием опции принудительного применения снимка. После завершения следует выполнить процесс синхронизации и верификации, установив опцию Automatically Correct Errors during the Cluster Verification (Автоматическое исправление ошибок во время верификации кластера) в значение Interactively (Интерактивное).

    Внимание! Использование опции принудительного применения снимка допускается только в том случае, если вы уверены в том, что обнаруженная ошибка может быть автоматически исправлена.

    Могут выводиться предупреждения и ошибки следующего вида:

    WARNING: "The NFS mount/Filesystem specified for resource group rg1 is using incorrect syntax for specifying an NFS cross mount: /mnt/fs1" (ПРЕДУПРЕЖДЕНИЕ: "NFSподключение/файловая система, заданные для группы ресурсов rg1, используют некорректный синтаксис при указании перекрестного подключения NFS: /mnt/fs1").

    ERROR: "Disk Heartbeat Networks have been defined, but no Disk Heartbeat Devices. You must configure one device for each node in order for a Disk Heartbeat network to function" (ОШИБКА: "Были определены сети пульса через диски, но не были определены устройства пульса через диски. Для работы сети пульса через диски необходимо сконфигурировать по одному устройству на каждом узле").

    В этих случаях можно выполнять принудительное применение снимка для продолжения процесса миграции на HACMP 5.3. Несмотря на отказ при применении, кластер остается в согласованном состоянии. В этом случае принудительное применение снимка является безопасным.

    Ошибка DARE при синхронизации

    После выполнения миграции при попытке синхронизации может возникнуть следующее сообщение:

    cldare: Migration from HACMPversion to HACMP 5.3 
Detected. cldare cannot be run
until migration has completed 
(cldare: Обнаружена миграция с HACMPversion 
на HACMP 5.3. cldare не может быть 
запущен до завершения миграции)

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

  • Войти в smit hacmp.
  • Перейти в Problem Determination Tools (Инструменты определения проблем).
  • Выбрать Restore HACMP Configuration Database from Active Configuration (Восстановление базы данных конфигурации HACMP из активной конфигурации).
    •

    Если после этого проблема не разрешилась, проверьте наличие блокировочных файлов нулевой длины /usr/es/sbin/cluster/.esmig на всех узлах кластера. Эти файлы обычно автоматически удаляются при интеграции последнего узла в кластер.

    Внимание! При удалении этих файлов происходит удаление блокировки. Если эти файлы не были удалены в ходе стандартной процедуры, это может указывать на возникновение других ошибок; поэтому, прежде чем продолжить, советуем связаться со службой поддержки программного обеспечения IBM.

    Ошибка "config_too_long" во время миграции

    Если кластер был в рабочем состоянии до начала процесса миграции, маловероятно, чтобы он перешел в режим восстановления и выдал сообщение config_too_ long. В том случае, если это произойдет, следует предпринять следующие действия по восстановлению HACMP.

    В процессе обновления в каталоге /usr/lpp/save.config сохраняется множество файлов, включая следующие:

    /usr/lpp/save.config/usr/es/sbin/cluster/events/node_up.rp
/usr/lpp/save.config/usr/es/sbin/cluster/events/node_down.rp

    При обновлении с HACMP/ES 4.5 также сохраняется следующее событие:

    /usr/lpp/save.config/usr/es/sbin/cluster/events/rg_move.rp

    Если после интеграции последнего узла в кластер в конце миграции не происходит автоматического обновления разделов ODM, это может привести к возникновению сообщения config_too_long, так как система обработки событий кластера не сможет найти первоначальный путь к этим событиям: /usr/es/sbin/cluster/events.

    После просмотра файла clconvert.log на наличие отказов миграции можно выполнить удаление фрагмента /usr/lpp/save.config из разделов. Эта операция применяется в последнюю очередь под контролем персонала службы поддержки IBM.

    Важно! Если эти пути не были автоматически исправлены во время миграции, это может указывать на проблемы при преобразовании других элементов. В этом случае следует обратиться в службу поддержки программного обеспечения IBM.
    Страницы:

    Выбор пути миграции

    Внимание! Всегда просматривайте список действий в руководстве по планированию и установке, если вы незнакомы с процедурой.

    Существует три пути миграции, с использованием которых можно обновить кластер до более поздней версии. (Выбор пути миграции осуществляется путем ответа на вопрос, допустим ли перерыв в работе целого кластера, или же требуется обеспечивать максимальную доступность).

  • Циклическая миграция (Rolling Migration) (с ES на ES). Этот метод обеспечивает доступность ресурсов как минимум на одном узле, пока происходит поочередное обновление остальных узлов кластера. Это означает, что во время миграции кластер будет находиться в смешанном режиме.
  • Метод снимков (Snapshot Method). Этот метод требует недоступности всех узлов кластера на некоторый период, а также того, чтобы на всех узлах была установлена новая версия HACMP, прежде чем преобразовывать и применять снимок до миграции.
  • Поузловая миграция (Node by Node) (с HAS на ES). Этот метод подобен методу циклической миграции. Однако во время обновления каждого узла обе версии кода HACMP будут отображаться как установленные одновременно, а непосредственное управление кластером осуществляют старые демоны. Только после обновления последнего узла и его интеграции в кластер выполняется итоговое преобразование.
    •  Замечание. Обратите внимание на то, что в прошлом понятия циклической миграции и поузловой миграции использовались как синонимы.

    Поддерживаемые пути миграции

    Поддерживаемые обновления версий до HACMP 5.3
    Текущая версия Циклическая миграция Метод снимков Поузловая миграция
    HACMP/ES 5.2 да да неприменимо
    HACMP/ES 5.1 да да неприменимо
    HACMP/ES 4.5 да да неприменимо
    HACMP 4.5 неприменимо да да

    Требования

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

    Требования к дисковому пространству (для миграции с HAS на HAES):

    Должно быть достаточно дискового пространства, чтобы в процессе миграции помещалось и программное обеспечение HAS, и программное обеспечение HAES:

  • приблизительно 120 Мб в каталоге /usr;
  • приблизительно 1.2 Mб в каталоге / (корневом каталоге).
    •

    Узлы должны иметь достаточно памяти, чтобы одновременно выполнять оба набора демонов HACMP. Минимальный объем оперативной памяти составляет 64 Мб, однако рекомендуется иметь 128 Мб оперативной памяти (не считая требований приложений).

    Требования программного обеспечения кластера и RSCT

    Требуется обеспечить одинаковый уровень наборов файлов программного обеспечения кластера и RSCT (включая PTF) на всех узлах до начала миграции. Кроме того, следует обеспечить перевод программного обеспечения в состояние committed (а не только в applied).

    Чтобы проверить, установлено ли программное обеспечение в состояние committed:

  • Выполните команду lslpp -h cluster.*
  • Если под заголовком действия выводится APPLY, введите smit install_commit перед установкой программного обеспечения HACMP. SMIT отобразит панель Commit Applied Software Updates (Remove Saved Files).
  • Введите следующие значения полей:
  • SOFTWARE name (Название программного обеспечения). Из списка выберите все требуемые наборы файлов.
  • COMMIT old version if above version used it? (COMMIT старую версию поверх используемой версии?). Установите для этого поля значение YesТакого поля в smit install_commit нет. (Проверялось в AIX 5.2 и 5.3). .
  • EXTEND file system if space needed? (Расширить файловую систему, если требуется пространство?). Установите для этого поля значение Yes.
    •

    Изучение конфигурации

    Нужно знать конфигурацию своего кластера. Нужно изучить и понять общую конфигурацию до выполнения обновления. Если среда вам незнакома, выполните команду cltopinfo или cldump, чтобы получить информацию о среде. Выходные данные команд cllsif и clshowres также позволяют получить представление о конфигурации кластера и ожидаемом выполнении перемещения при сбое. Эта информация также полезна при необходимости обращения в службу поддержки AIX.

  • /usr/es/sbin/cluster/utilities/cllsif
  • /usr/es/sbin/cluster/utilities/clshowres
    •

    Первая команда отображает текущую конфигурацию топологии. Это поможет определить доступные сети, соответствующие метки и IP-адреса и их текущие функции. Вторая команда выводит все группы ресурсов и связанные с ними атрибуты. Это может помочь в определении текущих выделенных ресурсов и их функционирования во время перемещения при сбое.

    Рекомендации и проверки перед миграцией

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

  • Всегда создавайте снимок перед выполнением миграции. Не забудьте сохранить его в нескольких безопасных местах. Всегда выполняйте резервное копирование системы (mksysb) с текущей конфигурацией. Следует проверить содержимое резервной копии и убедиться в том, что с ее помощью можно выполнить восстановление данных.
  • При наличии ресурсов рассмотрите вариант alternate disk installation1 для резервного диска на каждом узле кластера перед выполнением миграции. Это полезно в том случае, если вам придется быстро выполнить возврат к старой конфигурации. Для выполнения возврата нужно изменить список загрузочных устройств (bootlist), указав в нем резервный диск, после чего выполнить перезагрузку узлов, на которых была выполнена миграция.
  • Прежде чем начать миграцию, убедитесь, что на всех узлах установлен одинаковый набор файлов программного обеспечения кластера и RSCT (включая PTF).
  • Файл /.rhosts нужен только при миграции с более ранних версий, чем HACMP 5.1. После выполнения миграции рекомендуется удалить файл .rhosts в корневом каталоге (/), если другие приложения не требуют rsh для связи между узлами.Примечание. Если ваше приложение и/или скрипты пред- и постобработки требуют удаленного выполнения команд (на основе AIX rsh), необходимо сохранить файл ~/. rhosts даже после миграции.
  • Убедитесь в том, что ваш кластер успешно выполняет перемещение при сбое, до миграции; в противном случае оно может не работать и после обновления.
  • Проверьте состояние системы и установленных наборов файлов:
  • выполните команду lppchk -v, -l, -c ;
  • выполните команду instfix -i | grep ML ;
  • просмотрите выходные данные команды errpt -a на наличие последних соответствующих ошибок;
  • выполните команду df -k и проверьте заполненность файловых систем;
  • выполните команду lsps -s и убедитесь в том, что пространство страничной подкачки (paging space) не заполнено;
  • выполните команду emgr -l и проверьте наличие каких-либо исправлений efixes, загруженных в системе, прежде чем начинать обновление.
    •

    Аспекты

    Обратите внимание на множество изменений в HACMP 5.3 по сравнению с более ранними версиями. В некоторых случаях они вызывают изменения в работе кластера. Ниже перечислены аспекты, которые следует учитывать при выполнении обновления.

  • Что касается HACMP 5.2, типы групп ресурсов cascading (каскадная), rotating (ротационная) и concurrent (с одновременным доступом) были преобразованы в настраиваемые группы ресурсов с соответствующими политиками запуска, перемещения при сбое и возврата после восстановления. При миграции с версий до HACMP 5.2 выполняется преобразование групп ресурсов таким образом, чтобы каждая группа ресурсов использовала соответствующие политики. Подробное описание политик в настраиваемых группах ресурсов приведено в 1 лекции.
  • Настраиваемые значения в HACMP после обновления кластера будут сброшены. Это включает следующие параметры:
  • Параметры настройки сетевых модулей, такие, как скорость обнаружения отказов (failure detection rate), отсрочка (grace period) и скорость пульса (heartbeat rate). Для них устанавливаются значения по умолчанию.
  • Выполняется сброс изменений в событиях кластера, в частности скриптов преди постобработки событий. При сбросе этих изменений файлы и скрипты, используемые при настройке, не удаляются, однако HACMP перестает их видеть.
    •
  • Все изменения в стандартном наборе команд HACMP будут сброшены в значения по умолчанию.
  • После начала циклической миграции кластер будет работать в смешанном режиме до тех пор, пока не будет выполнено обновление последнего узла и его реинтеграция в кластер. В этот период не следует пытаться применять какие-либо изменения в топологии кластера или ресурсах:
  • не выполняйте верификацию или синхронизацию кластера;
  • не выполняйте принудительное отключение узла;
  • не пытайтесь выполнять какие-либо операции DARE или C-SPOC, кроме функций управления службами HACMP (Manage HACMP Services);
  • не используйте функцию Problem Determination Tools (Инструменты определения проблем) > View Current State (Просмотр текущего состояния);
  • не используйте опцию Extended Configuration (Расширенное конфигурирование) > Snapshot Configuration (Конфигурирование снимков) > Add a Cluster Snapshot (Добавить снимок кластера) и не выполняйте команду clsnapshot;
  • не используйте опцию Problem Determination Tools (Инструменты определения проблем) > Recover from HACMP Script Failure (Восстановление после отказа скрипта HACMP) и не выполняйте команду clruncmd, кроме случаев выполнения команды или опции SMIT с целевого узла, заданного командой.Важно! Не следует оставлять кластер в гибридном состоянии длительное время, чтобы избежать случайного вызова любой из этих операций.
  • При обновлении с версий до HACMP 5.2 инсталляция HACMP создает группу hacmp на всех узлах. Классы (ODM) базы данных конфигурации HACMP (HACMP Configuration Database) были обновлены, и теперь их владельцами являются пользователь root и группа hacmp:
  • Для большинства объектных классов HACMP установлены права доступа к файлам 640. Исключение представляет класс HACMPdisksubsystem, имеющий права доступа 600
  • Все двоичные файлы HACMP, предназначенные для применения пользователями без привилегий "root", устанавливаются с правами доступа 2555. Включается бит setgid, так что программа будет выполняться в контексте группы hacmp.
  • При использовании программ, осуществляющих прямой доступ к ODM, может возникнуть необходимость их перезаписи.Внимание! Использование информации, получаемой непосредственно из ODM, предназначено только для информационных целей, так как формат разделов (stanzas) может быть различным в разных обновлениях и/или в новых версиях. Таким образом, жесткое кодирование ODM-запросов в пользовательских приложениях не поддерживается и его следует избегать.
  • При использовании средства PSSP File Collections для обеспечения согласованности /etc/group новая группа hacmp может быть потеряна во время следующей синхронизации файлов. Чтобы этого избежать, нужно выполнить следующие действия:
  • отключить синхронизацию PSSP File Collection для /etc/group;
  • включить группу hacmp в мастер-файл (master file) /etc/group и распространить изменение на всех узлах.Примечание. В целях безопасности не следует расширять полномочия группы hacmp.
    • Политики динамического приоритета узлов в версиях до HACMP 5.2 были основаны на переменных ресурсов RSCT Event Management. Если ваша конфигурация включает группу ресурсов HACMP 5.1, в которой для политики динамического приоритета узла установлено значение Fallover using Dynamic Node Priority (Перемещение при сбое с использованием динамического приоритета узла), при миграции это значение будет сброшено. Утилита cl_convert изменит политику перемещения при сбое для этой группы ресурсов, установив для нее значение Fallover to Next Priority Node in the list (Перемещение при сбое на узел из списка со следующим приоритетом):
  • во время миграции используется политика перемещения при сбое по умолчанию;
  • обратите внимание на то, что HACMP 5.3 поддерживает только три политики:
  • cl_highest_free_mem;
  • cl_highest_idle_cpu;
  • cl_lowest_disk_busy.
    •
  • В HACMP 5.3 поддерживается только одна политика распределения групп ресурсов – политика распределения на основе узлов (node-based distribution policy). Ранее доступная политика распределения на основе сетей (network-based distribution policy) была удалена. Во время миграции она преобразуется в политику на основе узлов.
  • События кластера, определенные пользователем, могут не работать, так как emsvcs больше не применяются в HACMP. Для исправления проблем следует перезаписать их с использованием rmcd.
  • Диспетчер блокировки кластера (Cluster Lock Manager, cllockd или cllockdES) более недоступен в HACMP 5.3. Во время установки происходит удаление файлов и определений Lock Manager на узле. Проконсультируйтесь с производителем приложения относительно поддержки одновременного доступа.
  • Обратите внимание на то, что режим расширенного одновременного доступа поддерживается только в AIX 5L V5.1 и более поздних версиях. Режим одновременного доступа SSA (SSA concurrent mode) не поддерживается на 64-разрядном ядре. При использовании SSA-дисков в режиме одновременного доступа нельзя запустить 64-разрядное ядро до преобразования всех групп томов в режим расширенного одновременного доступа.

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

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

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

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

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

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

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

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

  • Остановка служб кластера на всех узлах.
  • Обновление программного обеспечения AIX и RSCT на всех узлах (если необходимо).
  • Деинсталляция текущей версии HACMP и установка HACMP 5.3 на всех узлах (включая последние PTF, если они доступны).
  • Перезагрузка.
  • Преобразование снимка.
    •  Замечание. Если вы планируете использовать метод снимков, помните о том, что при попытке повторного применения снимка на узлах в первую очередь 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-адреса.
  • Применение снимка (при этом конфигурация будет передана на все узлы).
  • Запуск служб кластера поочередно на каждом узле.
  • Верификация и синхронизация кластера.
    •

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

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

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

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

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

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

  • Остановка HACMP на узле panther (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover):
  • перемещение C10RG1 на узел tiger;
  • проверка с использованием /usr/es/sbin/cluster/utilities/clfindres.
    •
  • Инициация миграции 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).
  • Выполнение smit update_all для обновления наборов файлов HACMP до версии 5.3.
  • Перезагрузка узла panther:
  • в нашей конфигурации группа ресурсов C10RG1 была настроена на перемещение при сбое на узел с более высоким приоритетом при реинтеграции, вследствие чего группа ресурсов возвратилась на узел panther.
  • команда cldump отобразила корректное размещение и состояние всех ресурсов.Внимание! Выполнение синхронизации для кластера в гибридном состоянии нарушит миграцию и оставит кластер в несогласованном состоянии.
  • Повторное выполнение действий для узла puma.
  • Повторное выполнение действий для узла 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. Тестирование содержало следующие действия:

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

    Результаты миграции с использованием снимков: сценарий 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) после завершения миграции и не обнаружили каких-либо проблем.

    Сценарий 2: AIX 5.2 и HA 5.1

    Второй тестовый сценарий представлял собой миграцию двухузлового кластера AIX 5.2 / HA 5.1, настроенного на взаимный перехват ресурсов, на AIX 5.3 / HA 5.3. Мы использовали серверы p630 (7028-6C4) в конфигурации кластера. На рис. 5.3 представлена схема используемой конфигурации.

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

    (рис 5.3) Сценарий 2: среда миграции с HA 5.1 на HA 5.3

    Циклическая миграция: сценарий 2

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

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

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

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

    Сначала мы решили выполнить обновление узла cobra. Для этого мы выполнили следующие действия:

  • Остановка HACMP на узле cobra (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover):
  • перемещение C10RG1 на узел viper;
  • проверка с использованием /usr/es/sbin/cluster/utilities/clRGinfo.
    •
  • Инициация миграции AIX 5.3/RSCT с использованием кода NIM вместе с последними исправлениями: smit remove sdd – должно быть выполнено удаление и замена:
  • stopsrc -s sddsrv;
  • rmdev -dl dpo -R;
  • деинсталляция драйвера SDD 5.2 с использованием smitty remove (devices. sdd.52.rte 1.6.0.2);
  • установка драйвера SDD 5.3 (devices.sdd.53.rte 1.6.0.0 и 1.6.0.2).
  • Выполнение smit update_all для загрузки наборов файлов HA 5.3.
  • Перезагрузка узла cobra.
  • Реинтеграция узла cobra в кластер путем запуска служб кластера. Политика ресурсов была настроена на перемещение при сбое на узел с более высоким приоритетом, вследствие чего группа ресурсов C10RG1 возвратилась на узел cobra.Внимание. На этом этапе ODM-классы HACMP на узле cobra не были преобразованы и не соответствуют новой версии, тогда как наборы файлов соответствуют версии HA 5.3. На данном этапе кластер находится в смешанном режиме или, так называемом гибридном состоянии (hybrid state).
  • Остановка HACMP на узле viper (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover). Группа ресурсов C10RG2 перемещается на узел cobra.
  • Повтор операций установки AIX/RSCT и HACMP на узле viper.
  • Перезагрузка узла viper.
  • Реинтеграция узла viper в кластер путем запуска служб кластера.

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

    Общее тестирование циклической миграции было успешным. Как и в сценарии 1, миграция AIX представляла самый медленный этап обновления. После ее выполнения мы протестировали перемещение при сбое в кластере и не обнаружили проблем. Реинтеграция последнего узла была успешной, и мы убедились в том, что изменения в ODM соответствовали новой версии HACMP.

    В целях тестирования мы решили прервать миграцию, когда узлы были в смешанном режиме. Мы остановили узел cobra, когда на нем выполнялся HACMP 5.3 и он содержал обе группы ресурсов. В это время на узле viper выполнялся процесс установки HACMP 5.3. После перезагрузки узла cobra и перезапуска служб кластера, он подхватил свою группу ресурсов (C10RG1). После этого мы вручную подключили группу ресурсов узла viper:

    #smit hacmp > System Management (C-SPOC) > HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Bring a Resource Group online (Подключение группы ресурсов) > выбор C10RG2 и нажатие Enter.

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

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

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

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

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

    В целом миграция с использованием снимка также прошла успешно. Преобразование файла снимка заняло несколько секунд, и его применение на обоих узлах также произошло очень быстро. После завершения миграции мы убедились в корректности преобразования разделов HACMP ODM путем проверки версии кластера в объектных классах HACMPcluster и HACMPnode.

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

    Мы считаем, что, если ваша среда допускает перерыв в обслуживании в масштабе кластера, можно использовать этот быстрый и надежный метод, позволяющий полностью избежать функционирования узлов в смешанном режиме. Использование снимка для возврата конфигурации HACMP после обновления всех узлов позволяет избежать потенциальных проблем, которые могут возникнуть в процессе циклической миграции. Дополнительные сведения о потенциальных проблемах см. в разделе "Аспекты", в этой лекции.

    Сценарий 3: AIX 5.2 и HA 5.2

    Третий тестовый сценарий представлял собой миграцию кластера AIX 5.2 / HA 5.2 с двумя активными узлами и одним дежурным резервным узлом на AIX 5.3 / HA 5.3. В своей конфигурации мы использовали три одинаковых LPAR p690 (7040-681). На рис. 5.4 представлена схема используемой конфигурации.

    Топология была настроена на использование IP-синонимов вместе с мониторингом пульса через синонимы. Это было сделано, чтобы убедиться в том, что обновление сохранит смещение сети 10.10.1.1 и соответствующие синонимы и что впоследствии проблем в работе кластера не возникнет.

    Примечание. Помните, что при использовании мониторинга пульса через синонимы в вашей сетевой топологии мониторинг базовых адресов в HACMP не выполняется.

    Мы сконфигурировали базовые адреса для каждого узла в соответствующей подсети и поместили все сервисные и постоянные IP-адреса в другой диапазон подсети. Такая конфигурация IP используется для имитации университетской среды, где компьютеры могут быть разделены определенным расстоянием и могут использовать различные подсети, а также для того, чтобы убедиться в том, что для базовых адресов не выполняется мониторинг с использованием трафика пульса HACMP.

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

    (рис 5.4) Сценарий 3: среда миграции с HA 5.2 на HA 5.3

    Циклическая миграция: сценарий 3

    Для этого сценария мы использовали кластер в среде DLPAR, чтобы убедиться в том, что все работает после обновления. Мы выполнили следующие предварительные действия:

  • Сохранение снимка с рабочего кластера (со всеми активными узлами).
  • Создание резервной копии (mksysb).
  • Создание alt_disk_install как средства возврата к прежней конфигурации. Это было сделано с целью ускорения повторного тестирования.
    •

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

    Сначала мы решили выполнить обновление дежурного узла alexis, чтобы максимально сократить перерыв в работе узлов, содержащих группы ресурсов. Для этого мы выполнили следующие действия:

  • Остановка HACMP на узле alexis (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).Внимание. Не сохраняйте снимок в каталог /tmp, так как при миграции AIX содержимое каталога /tmp удаляется. Сохраните снимок в другой каталог или на другой сервер. Не забудьте также сохранить скрипты приложения в надежный каталог.
  • Инициация установки базового кода AIX 5.3/ RSCT с использованием NIM вместе с последними исправлениями. Удаление и замена SDD текущим драйвером AIX 5.3:
  • stopsrc -s sddsrv;
  • rmdev -dl dpo -R;
  • деинсталляция драйвера SDD 5.2 с использованием smitty remove (devices. sdd.52.rte 1.6.0.2);
  • установка драйвера SDD 5.3 (devices.sdd.53.rte 1.6.0.0 и 1.6.0.2 PTF).
    •
  • Выполнение smit update_all для загрузки наборов файлов HACMP 5.3.
  • Перезагрузка узла alexis:
  • Верификация инсталляции AIX ( lppchk -l / -c / -v, instfix, oslevel, errpt );
  • lslpp -l | grep cluster => Нет следов версии 5.2 (проверка отсутствия наборов файлов);
  • odmget HACMPcluster => все еще отображалась версия 7.
  • Реинтеграция узла alexis в кластер путем запуска служб кластера.Внимание. Выполнение синхронизации для кластера в гибридном состоянии нарушит миграцию.
  • Остановка HACMP на узле jordan (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
  • Повтор действий пп. 2–5 на узле jordan.
  • Остановка HACMP на узле jessica (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
  • Повтор действий пп. 2–5 на узле jessica.

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

    Как и в двух предыдущих сценариях, мы не столкнулись с какими-либо проблемами при циклической миграции HACMP. После интеграции последнего узла в кластер было выполнено преобразование разделов ODM-классов, и теперь для всех узлов выводилось cluster_version = 8, как и ожидалось. Номера версий HACMP см. в табл. 5.2.

    При первоначальной настройке топологии кластера мы выполнили конфигурирование базового, постоянного и сервисного IP-адресов в одной подсети. Хотя такая топология и допустима, она создает некоторые проблемы в среде NIM (Network Install Manager), так как NIM неспособен обрабатывать постоянные синонимы (что вызывает отказы при подключении NFS).

    Поэтому мы советуем быть осторожными при внедрении HACMP в среде NIM; это также относится к среде CSM (Cluster Systems Management), которая использует NIM для установки и обновления программного обеспечения на управляемых узлах. ( пример 5.1 представляет конфигурацию в файле hosts (которая создает проблемы с NIM):

    _:># more /etc/hosts
192.168.100.200 jordan_base1
192.168.100.201 jordan_base2
192.168.100.202 jessica_base1
192.168.100.203 jessica_base2
192.168.100.204 alexis_base1
192.168.100.205 alexis_base2
192.168.100.71 p690_1_lpar1 #persistent IP jordan
192.168.100.72 p690_1_lpar2 #persistent IP jessica
192.168.100.61 p690_2_lpar1 #persistent IP alexis
192.168.100.101 dlpar_app1_svc
192.168.100.102 dlpar_app1_svc
    Примечание. Конфигурация, представленная в примере 5.1 , основана на маске сети класса C (255.255.255.0). В качестве альтернативы мы изменили нашу топологию на топологию, представленную на рис. 5.4, и сконфигурировали наши базовые адреса в отдельной подсети от сервисных и постоянных IP-адресов.

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

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

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

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

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

    Мы считаем, что, если ваша среда допускает перерыв в обслуживании в масштабе кластера, можно использовать этот быстрый и надежный метод, позволяющий полностью избежать функционирования узлов в смешанном режиме. Использование снимка для возврата конфигурации HACMP после обновления всех узлов позволяет избежать потенциальных проблем, которые могут возникнуть в процессе циклической миграции. Дополнительные сведения о потенциальных проблемах см. в разделе "Аспекты", в этой главе.

    Действия после миграции

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

  • Проверьте наличие наборов файлов HACMP, оставшихся от прежней версии. Могли остаться старые наборы файлов документации, которые, хотя и не создают каких-либо проблем, также должны быть обновлены.
  • После выполнения любого типа миграции следует осуществить верификацию и синхронизацию конфигурации кластера.
  • После любой миграции следует протестировать выполнение перемещения при сбое и восстановления. Инструмент Cluster Test Tool позволяет выполнять несколько тестов и может быть настроен на использование дополнительных тестов.
  • Обратите внимание на то, что после версии 4.5 файл ~/.rhosts больше не нужен (и не используется) в HACMP. Если он не нужен в вашей среде, не забудьте его удалить.
    •

    Совет после миграции

    При выполнении миграций AIX/HACMP мы использовали NIM-сервер. Мы применяли постоянные IP-адреса в определениях компьютеров NIM-клиентов. В результате мы обнаружили, что при установке в качестве базового адреса для одного из интерфейсов была установлена постоянная IP-метка, тогда как базовый адрес был удален. Кроме того, в качестве имени хоста было установлено имя компьютера, заданное в определении NIM-клиента.

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

  • smitty chinet => жесткая установка прежнего базового адреса интерфейса.
  • Мы закомментировали строки, добавленные в файл /etc/rc.net:
    /bin/hostname <hostname>
/usr/sbin/ifconfig <en#> inet <IP> netmask 255.255.255.0
  • hostname <name> => установка прежнего имени хоста.
    •

    При использовании NIM следует проверить, были ли выполнены эти изменения; в противном случае вы получите неоднозначные результаты в HACMP после запуска служб кластера.

    Этой проблемы можно избежать путем настройки NIM (это предполагает создание собственного скрипта настройки).

    Устранение неполадок при отказе миграции

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

    Возврат после отказа миграции

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

    Внимание. В зависимости от этапа миграции, на котором возникли проблемы, может не потребоваться выполнять восстановление кластера целиком.

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

    На этом этапе у вас есть следующие варианты:

    Вариант 1 – включить узел и попытаться найти и устранить проблему.

    Вариант 2 – возвратиться к старой конфигурации.

    Вариант 3 – деинсталлировать старое программное обеспечение HACMP, уста новить новый код и применить способ миграции с использованием снимков (при условии, что у вас есть снимок).

    Вариант 1: устранение неполадок при отказе миграции

    В случае остановки работы узла включите узел. При включенном компьютере и неактивном HACMP можно попытаться определить причину остановки путем просмотра журналов кластера и системы. Рекомендуется просмотреть следующие журналы и отчеты:

  • Просмотрите отчет об ошибках (errpt -a| more). Запишите точное время отказа на основании записей в журнале ошибок. Проанализируйте все недавние релевантные ошибки и попытайтесь найти факты аварийного завершения демонов или создания файлов CORE.
  • Просмотрите файл /usr/es/adm/cluster.log на наличие любых релевантных событий кластера. Проанализируйте журнал на наличие событий кластера, имевших место во время отказа. Не забудьте просмотреть журналы на других узлах кластера на предмет возможных различий.
  • Просмотрите файл /tmp/clstrmgr.debug на наличие сообщений об аварийных остановках clstrmgrES. При аварийной остановке диспетчера кластера обычно происходит остановка работы компьютера. Большинство сообщений, содержащих время остановки, записываются в конец этого файла. Сообщения могут дать вам представление о причине отказа.
  • В зависимости от содержания errpt-сообщений можно прибегнуть к анализу файлов журналов служб групп в /var/ha/log, чтобы попытаться определить проблему. Анализ записей журналов, совпадающих по времени с возникновением проблемы, может помочь в определении причины аварийного завершения демона или других зарегистрированных проблем.
    •

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

    Замечание. При обращении в службу поддержки программного обеспечения IBM требуется выполнить сбор выходных данных команды snap -e на узле, на котором произошел отказ, для того чтобы ускорить анализ и разрешение проблемы.

    Вариант 2: возврат к старой конфигурации

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

    В том случае если вместе с обновлением программного обеспечения AIX и RSCT выполняется обновление HACMP, возврат к старой конфигурации затрудняется. Вам потребуется остановить HACMP на всех обновленных узлах и выполнить на них возврат к предыдущей версии AIX либо с использованием резервной копии системы (mksysb), либо с использованием образов установки на резервных дисках, созданных перед началом миграции. После восстановления узлов с резервного источника следует выполнить верификацию и синхронизацию с текущих активных узлов. При успешном завершении можно выполнять реинтеграцию восстановленных узлов в кластер.

    После успешного восстановления первоначальной версии кода кластера следует изучить этапы миграции и убедиться в том, что были выполнены действия, описанные в разделе "Требования".

    Вариант 3: деинсталляция HACMP и выполнение миграции с использованием снимков

    Для использования этой опции необходимо иметь снимок конфигурации кластера на момент выполнения версии HACMP, с которой выполняется обновление. При этом действия в целом совпадают с действиями при миграции с использованием снимков, описанными в разделе "Основные этапы миграции".

  • Остановка служб кластера на всех узлах.
  • Обновление программного обеспечения AIX и RSCT на всех узлах (если необходимо).
  • Деинсталляция текущей версии HACMP и установка HACMP 5.3 на всех узлах (включая последние PTF, если они доступны).
  • Перезагрузка узлов.
  • Преобразование снимка.
  • Применение снимка.
  • Запуск служб кластера поочередно на каждом узле.
  • Верификация и синхронизация кластера.
    •  Примечание. Во всех наших тестовых сценариях миграции переход на HACMP 5.3 выполнялся автоматически без каких-либо проблем. Если у вас возникли проблемы, отличные от описанных в этом разделе, свяжитесь со службой поддержки программного обеспечения IBM для получения дальнейшей информации.

    Информация о версии кластера в HACMP ODM

    Чтобы получить информацию о версии кластера, выполните команды odmget HACMPcluster или odmget HACMPnode. Важно отметить, что после завершения миграции на HACMP 5.3 уровень версии должен быть равен восьми.

    Версия HACMP в разделах ODM
    Версия HACMP В HACMPcluster В HACMPnode
    HACMP 5.3 cluster_version = 8 version = 8
    HACMP 5.2 cluster_version = 7 version = 7
    HACMP 5.1 cluster_version = 6 version = 6
    HACMP 4.5 cluster_version = 5 version = 5
    HACMP 4.4.1 cluster_version = 4 version = 4

    Если версия не была обновлена при циклической миграции после интеграции последнего узла в кластер, следует просмотреть файл clconvert.log на наличие записей о возникновении проблем при миграции. Изменение значений в ODM администратором или персоналом службы поддержки IBM применяется в последнюю очередь.

    Внимание! Хотя это и не одобряется, но если вы все же решили вручную отредактировать значения в ODM для исправления несоответствия, следует прежде обратиться в службу поддержки программного обеспечения IBM.

    Устранение неполадок при использовании снимков

    В некоторых случаях при миграции с использованием снимков вы можете столкнуться с возникновением ошибок при верификации и отказов при попытке применения снимков. В том случае, если при применении снимка возникает ошибка, просмотрите файлы журналов на возможность ее коррекции утилитой верификации HACMP 5.3. Помните, что даже в случае отказа при попытке применения снимка, некоторые обновления конфигурации можно выполнить путем изменения ODM-классов HACMP.

    Если ошибка соответствует критериям несогласованности, подлежащей исправлению функцией автокоррекции процесса верификации, можно продолжать процесс обновления с использованием опции принудительного применения снимка. После завершения следует выполнить процесс синхронизации и верификации, установив опцию Automatically Correct Errors during the Cluster Verification (Автоматическое исправление ошибок во время верификации кластера) в значение Interactively (Интерактивное).

    Внимание! Использование опции принудительного применения снимка допускается только в том случае, если вы уверены в том, что обнаруженная ошибка может быть автоматически исправлена.

    Могут выводиться предупреждения и ошибки следующего вида:

    WARNING: "The NFS mount/Filesystem specified for resource group rg1 is using incorrect syntax for specifying an NFS cross mount: /mnt/fs1" (ПРЕДУПРЕЖДЕНИЕ: "NFSподключение/файловая система, заданные для группы ресурсов rg1, используют некорректный синтаксис при указании перекрестного подключения NFS: /mnt/fs1").

    ERROR: "Disk Heartbeat Networks have been defined, but no Disk Heartbeat Devices. You must configure one device for each node in order for a Disk Heartbeat network to function" (ОШИБКА: "Были определены сети пульса через диски, но не были определены устройства пульса через диски. Для работы сети пульса через диски необходимо сконфигурировать по одному устройству на каждом узле").

    В этих случаях можно выполнять принудительное применение снимка для продолжения процесса миграции на HACMP 5.3. Несмотря на отказ при применении, кластер остается в согласованном состоянии. В этом случае принудительное применение снимка является безопасным.

    Ошибка DARE при синхронизации

    После выполнения миграции при попытке синхронизации может возникнуть следующее сообщение:

    cldare: Migration from HACMPversion to HACMP 5.3 
Detected. cldare cannot be run
until migration has completed 
(cldare: Обнаружена миграция с HACMPversion 
на HACMP 5.3. cldare не может быть 
запущен до завершения миграции)

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

  • Войти в smit hacmp.
  • Перейти в Problem Determination Tools (Инструменты определения проблем).
  • Выбрать Restore HACMP Configuration Database from Active Configuration (Восстановление базы данных конфигурации HACMP из активной конфигурации).
    •

    Если после этого проблема не разрешилась, проверьте наличие блокировочных файлов нулевой длины /usr/es/sbin/cluster/.esmig на всех узлах кластера. Эти файлы обычно автоматически удаляются при интеграции последнего узла в кластер.

    Внимание! При удалении этих файлов происходит удаление блокировки. Если эти файлы не были удалены в ходе стандартной процедуры, это может указывать на возникновение других ошибок; поэтому, прежде чем продолжить, советуем связаться со службой поддержки программного обеспечения IBM.

    Ошибка "config_too_long" во время миграции

    Если кластер был в рабочем состоянии до начала процесса миграции, маловероятно, чтобы он перешел в режим восстановления и выдал сообщение config_too_ long. В том случае, если это произойдет, следует предпринять следующие действия по восстановлению HACMP.

    В процессе обновления в каталоге /usr/lpp/save.config сохраняется множество файлов, включая следующие:

    /usr/lpp/save.config/usr/es/sbin/cluster/events/node_up.rp
/usr/lpp/save.config/usr/es/sbin/cluster/events/node_down.rp

    При обновлении с HACMP/ES 4.5 также сохраняется следующее событие:

    /usr/lpp/save.config/usr/es/sbin/cluster/events/rg_move.rp

    Если после интеграции последнего узла в кластер в конце миграции не происходит автоматического обновления разделов ODM, это может привести к возникновению сообщения config_too_long, так как система обработки событий кластера не сможет найти первоначальный путь к этим событиям: /usr/es/sbin/cluster/events.

    После просмотра файла clconvert.log на наличие отказов миграции можно выполнить удаление фрагмента /usr/lpp/save.config из разделов. Эта операция применяется в последнюю очередь под контролем персонала службы поддержки IBM.

    Важно! Если эти пути не были автоматически исправлены во время миграции, это может указывать на проблемы при преобразовании других элементов. В этом случае следует обратиться в службу поддержки программного обеспечения IBM.
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^