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

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

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

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

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

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

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

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

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

  1. smitty chinet => жесткая установка прежнего базового адреса интерфейса.
  2. Мы закомментировали строки, добавленные в файл /etc/rc.net:
    /bin/hostname <hostname>
    /usr/sbin/ifconfig <en#> inet <IP> netmask 255.255.255.0
  3. 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, с которой выполняется обновление. При этом действия в целом совпадают с действиями при миграции с использованием снимков, описанными в разделе "Основные этапы миграции".

  1. Остановка служб кластера на всех узлах.
  2. Обновление программного обеспечения AIX и RSCT на всех узлах (если необходимо).
  3. Деинсталляция текущей версии HACMP и установка HACMP 5.3 на всех узлах (включая последние PTF, если они доступны).
  4. Перезагрузка узлов.
  5. Преобразование снимка.
  6. Применение снимка.
  7. Запуск служб кластера поочередно на каждом узле.
  8. Верификация и синхронизация кластера.
Примечание. Во всех наших тестовых сценариях миграции переход на HACMP 5.3 выполнялся автоматически без каких-либо проблем. Если у вас возникли проблемы, отличные от описанных в этом разделе, свяжитесь со службой поддержки программного обеспечения IBM для получения дальнейшей информации.
< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Анатолий Гречман
Анатолий Гречман
Казахстан, Экибастуз, Экибастузский Инженерно-технический Институт, 2014