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

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

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

Сценарий 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.

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

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

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

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

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

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

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

  1. Остановка HACMP на узле alexis (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
    Внимание. Не сохраняйте снимок в каталог /tmp, так как при миграции AIX содержимое каталога /tmp удаляется. Сохраните снимок в другой каталог или на другой сервер. Не забудьте также сохранить скрипты приложения в надежный каталог.
  2. Инициация установки базового кода 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).
  3. Выполнение smit update_all для загрузки наборов файлов HACMP 5.3.
  4. Перезагрузка узла alexis:
    • Верификация инсталляции AIX ( lppchk -l / -c / -v, instfix, oslevel, errpt );
    • lslpp -l | grep cluster => Нет следов версии 5.2 (проверка отсутствия наборов файлов);
    • odmget HACMPcluster => все еще отображалась версия 7.
  5. Реинтеграция узла alexis в кластер путем запуска служб кластера.
    Внимание. Выполнение синхронизации для кластера в гибридном состоянии нарушит миграцию.
  6. Остановка HACMP на узле jordan (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
  7. Повтор действий пп. 2–5 на узле jordan.
  8. Остановка HACMP на узле jessica (постепенная остановка с передачей ресурсов на резервный узел – graceful with takeover).
  9. Повтор действий пп. 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. Разрешение имен в нашей среде
Примечание. Конфигурация, представленная в примере 5.1 , основана на маске сети класса C (255.255.255.0). В качестве альтернативы мы изменили нашу топологию на топологию, представленную на рис. 5.4, и сконфигурировали наши базовые адреса в отдельной подсети от сервисных и постоянных IP-адресов.

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

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

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

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

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

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

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