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

Обслуживание кластера

< Лекция 6 || Лекция 7: 123456 || Лекция 8 >

Хранение

В большинстве современных общих сред хранения применяется определенный уровень технологии RAID для защиты и дублирования данных. При использовании устройств RAID (1, 5 или 10) отказы отдельных дисков обычно не требуют выполнения обслуживания AIX LVM. Все требуемые процедуры часто являются внешними по отношению к узлам кластера и не влияют на сам кластер. Однако если защита осуществляется с использованием зеркального отображения (mirroring) LVM, то необходимо выполнять процедуры обслуживания LVM.

C-SPOC содержит средство поддержки при замене отказавшего диска с зеркальным отображением LVM. Это средство имеет название Cluster Disk Replacement и выполняет все необходимые операции LVM по замене диска с зеркальным отображением LVM. Для использования этого средства необходимо следующее:

  • наличие привилегий пользователя "root";
  • должно осуществляться зеркальное отображение отказавшего диска (и желательно всей группы томов);

требуемый резервный диск должен быть доступен для всех узлов; ему уже должен быть назначен PVID, который должен отображаться на всех узлах при вводе команды lspv.

При физической замене существующего диска следует удалить старый диск и установить на его место новый диск. Это, конечно же, предполагает, что привод допускает "горячую замену", что в настоящее время является стандартом.

Для замены диска с зеркальным отображением через C-SPOC проделайте следующее:

  1. Найдите отказавший диск. Запишите PVID для физического тома (диска).
  2. Введите smitty cl_admin.
  3. В SMIT выберите HACMP Physical Volume Management (Управление физическими томами HACMP) > Cluster Disk Replacement (Замена дисков кластера) и нажмите Enter. SMIT выводит список дисков, входящих в группы томов, содержащихся в группах ресурсов кластера. Группа томов, в которой расположен отказавший диск, должна содержать два диска или более. Список включает группу томов, hdisk, PVID диска и опорный узел кластера (reference cluster node; обычно подразумевается узел кластера, на котором активизирована группа томов).
  4. Выберите диск, для которого требуется выполнить замену (исходный диск; source disk) и нажмите Enter. SMIT выводит список доступных дисков, которым назначен PVID и которые можно использовать для замены (для замены отказавшего диска подходят только диски такого же или большего объема).
  5. Выберите требуемый диск для замены (целевой диск; destination disk) и нажмите Enter. SMIT выводит выбранные вами параметры с двух предыдущих панелей.
  6. Нажмите Enter для продолжения или Cancel для отмены процесса замены дисков. Появится предупреждение, сообщающее о том, что продолжение операции удалит всю информацию, хранящуюся на целевом диске.
  7. Нажмите Enter для продолжения или Cancel для отмены. SMIT отображает панель состояния команды и отображает каталог восстановления replacepv. Если при отказе дисковой конфигурации требуется продолжить замену дисков, необходимо сконфигурировать целевой диск вручную. Учтите, что при отмене процедуры на данном этапе целевой диск может быть сконфигурирован на нескольких узлах в кластере.

Утилита replacepv выполняет обновление группы томов, используемой в процессе замены дисков (только на опорном узле).

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

Выполняется конфигурирование целевого диска на всех узлах в группе ресурсов.

В случае неудачного импортирования обновленной группы томов узлом в группе ресурсов можно использовать средство C-SPOC Import a Shared Volume Group.

C-SPOC не удаляет информацию об отказавшем дисковом устройстве с узлов кластера. Это нужно сделать вручную командой rmdev -dl <devicename>.

Приложения

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

В многоуровневой среде (multi-tier environment), где сервер приложения зависит от базы данных, и следует производить обслуживание базы данных обычно нужно останавливать как приложение, так и базу данных. Чаще всего хотя бы база данных находится в кластере. При использовании зависимостей группы ресурсов сервер приложения можно легко реализовать в этом же кластере.

Кроме того, для того чтобы сократить общее время простоя приложения, часто обслуживание приложения сначала выполняется на нерабочих узлах. Традиционно под такими узлами подразумеваются дежурные узлы (standby nodes), однако очень редко резервные узлы (backup/fallover node) используются только как дежурные. В таких случаях следует учитывать текущую рабочую нагрузку или приложения, выполняющиеся на этом узле, чтобы свести к минимуму неблагоприятное воздействие процесса обслуживания. Рекомендуется прежде выполнить тестирование в тестовом кластере.

В большинстве случаев останавливать службы кластера не требуется. Можно просто перевести группу ресурсов в отключенное состояние, как описано в разделе "Перевод группы ресурсов в отключенное состояние через SMIT". Если общая группа томов должна быть подключена во время обслуживания, можно просто приостановить мониторинг приложения и выполнить скрипт остановки сервера приложения, чтобы перевести приложение в отключенное состояние. Однако при этом сервисный IP-адрес останется подключенным, что может быть нежелательным.

В среде, где несколько групп ресурсов и/или несколько приложений выполняются на одном узле, остановка служб кластера на локальном узле может быть невозможна. Помните о возможных последствиях остановки служб кластера на узле, на котором выполняется обслуживание приложения.

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

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

Если при использовании постоянных адресов выполняется остановка служба кластера, защита от переключения локального адаптера (local adapter swap protection) отключается. Хотя опять же такие ситуации редки, существует вероятность того, что в случае отказа содержащей адрес сетевой карты при использовании постоянного адреса для выполнения обслуживания подключение будет разорвано.

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

< Лекция 6 || Лекция 7: 123456 || Лекция 8 >