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

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

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Аннотация: Эта лекция описывает различные способы миграции кластера на HACMP 5.3. Перед миграцией следует провести планирование и рассмотреть аспекты миграции. Прежде чем начать, вы должны быть знакомы с использованием утилиты создания снимков кластера (cluster snapshot utility). Кроме того, изучите текущую конфигурацию, ее работу и изменения в каждом релизе, до которого выполняется обновление, так как в конечном результате все может работать не так, как ожидается.

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

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

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

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

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

Таблица 5.1. Поддерживаемые обновления версий до 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:

  1. Выполните команду lslpp -h cluster.*
  2. Если под заголовком действия выводится APPLY, введите smit install_commit перед установкой программного обеспечения HACMP. SMIT отобразит панель Commit Applied Software Updates (Remove Saved Files).
  3. Введите следующие значения полей:
    • SOFTWARE name (Название программного обеспечения). Из списка выберите все требуемые наборы файлов.
    • COMMIT old version if above version used it? (COMMIT старую версию поверх используемой версии?). Установите для этого поля значение Yes1Такого поля в 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 выполняется преобразование групп ресурсов таким образом, чтобы каждая группа ресурсов использовала соответствующие политики. Подробное описание политик в настраиваемых группах ресурсов приведено в "Введение в HACMP" .
  • Настраиваемые значения в 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-разрядное ядро до преобразования всех групп томов в режим расширенного одновременного доступа.
< Лекция 4 || Лекция 5: 123456 || Лекция 6 >