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

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

< Лекция 6 || Лекция 7: 123456 || Лекция 8 >
Аннотация: В этой лекции описываются основные практические методы осуществления планирования и выполнения операций обслуживания кластера HACMP. Основная цель состоит в том, чтобы максимально долго обеспечивать активность приложений кластера. Для выполнения этих операций мы используем функциональные возможности HACMP и AIX 5L. Конечно же, приведенные сценарии не являются исчерпывающими. В этой лекции предполагается знание общих процедур устранения неполадок в AIX, а также мониторинга журнала ошибок. Мы не описываем, как определить существующие проблемы как во время устранения проблем, так и при выполнении профилактического обслуживания.

Контроль и тестирование изменений

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

Управление изменениями среди прочего включает:

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

Тестовый кластер

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

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

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

Например, часто используются логические разделы (LPAR) и несколько различных образов rootvg с применением alt_disk_install. Логические разделы позволяют без труда создать тестовый кластер с минимальным использованием физических ресурсов; например, тестовый кластер даже может разместиться на одном физическом компьютере. Использование нескольких загрузочных образов позволяет клиентам легко сменить кластерную среду путем перезагрузки раздела с другого образа. Это также позволяет осуществлять тестирование многих программных процедур:

  • обслуживание AIX;
  • применение исправлений HACMP;
  • обслуживание приложений.

Этот тип тестового кластера требует употребления как минимум одного диска на образ на LPAR. Например, если тестовый кластер содержит два узла и три разных образа rootvg, требуется использовать по меньшей мере шесть жестких дисков. Тем не менее это гораздо проще, чем применять шесть отдельных узлов в трех тестовых кластерах.

Общую стоимость тестового кластера можно еще больше сократить с использованием расширенной виртуализации Power5. Расширенная виртуализация (advanced virtualization) позволяет располагать несколько образов rootvg на одном физическом диске. Она также позволяет логическим разделам использовать общую физическую сеть и DASD-адаптеры через VLAN и VSCSI. Дополнительные сведения об этих возможностях см. в книге Advanced POWER Virtualization on IBM Eserver p5 Servers: Introduction and Basic Configuration, SG24-7940

Тестовый кластер также позволяет выполнять тестирование процедур обслуживания оборудования. Эти процедуры в числе прочего включают:

  • обновление микрокода компьютера;
  • обновление микрокода адаптера;
  • замена адаптера;
  • замена диска.

Другие операции тестирования можно выполнить с использованием инструмента тестирования кластера (Cluster Test Tool) и/или эмуляции событий.

Запуск и остановка кластера

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

Важно! Начиная с HACMP V5.3 процесс диспетчера кластера (clstrmgrES) всегда выполняется. Он может находиться в одном из двух состояний, выводимых следующей командой:
lssrc -ls clstrmgrES
ST_INIT (событие запуска выполняется)
ST_NOTCONFIGURED (событие запуска не выполняется)

Изменения в состоянии кластера называются событиями кластера (cluster events). Диспетчер кластера (Cluster Manager) на каждом узле осуществляет мониторинг локальной аппаратной и программной подсистем на такие события, как, например, событие отказа приложения (application failure). При возникновении таких событий диспетчер кластера выполняет один или несколько скриптов, например скрипт перезапуска приложения (restart application). Диспетчеры кластера, выполняющиеся на всех узлах, обмениваются сообщениями в целях согласования необходимых действий в при возникновении событий.

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

Службы кластера

Ниже перечислены основные демоны HACMP и RSCT.

  • Демон диспетчера кластера (Cluster Manager daemon, clstrmgrES). Основной демон HACMP. Он обеспечивает глобальное представление топологии кластера и ресурсов, а также запускает скрипты обработки событий в ответ на изменения состояния узлов, интерфейсов или ресурсов (или по запросу пользователя). Диспетчер кластера получает информацию о состоянии интерфейсов от служб топологии (Topology Services). Диспетчер кластера обеспечивает актуальную информацию о расположении и состоянии всех групп ресурсов. Диспетчер кластера является клиентом служб групп (Group Services) и использует последние для обеспечения надежной связи между демонами. В версиях 5.1 и 5.2 этот демон запускается после служб кластера. В версии 5.3 демон clstrmgr запускается через процесс init и должен выполняться постоянно. Кроме того, так как в версии 5.3 демон clstrmgr является постоянно выполняющимся процессом, нельзя использовать команду lssrc -s clstrmgrES для определения состояния кластера. Вместо этого следует использовать команду /usr/es/ sbin/cluster/utilities/clcheck_server grpsvcs.
  • Демон диспетчера блокировки кластера (Cluster Lock Manager daemon, cllockd). Этот демон представляет информационные службы блокировки. Использование демона cllockd на узлах кластера необходимо только в том случае, если эти узлы входят в конфигурацию с одновременным доступом. Обратите внимание на то, что диспетчер блокировки не поддерживается на 64-разрядном ядре и полностью удален начиная с HACMP V5.2.
  • Демон коммуникаций кластера (Cluster Communication Daemon, clcomdES). Этот демон, впервые появившийся в версии 5.1, обеспечивает безопасную связь между узлами кластера для всех утилит кластера, в частности утилит верификации и синхронизации и управления системой (C-SPOC). Демон clcomd запускается автоматически при загрузке через процесс init. Начиная с версии 5.2, clcomdES должен быть запущен, прежде чем можно будет запустить какие-либо службы кластера.
  • Демон информации кластера (Cluster Information Program, clinfoES). Этот демон предоставляет информацию о состоянии кластера узлам кластера и клиентам, а также вызывает скрипт /usr/es/sbin/cluster/etc/clinfo.rc при возникновении событий кластера. Демон clinfo является необязательным на узлах кластера и клиентах.
  • Демон Cluster SMUX Peer daemon (clsmuxpd). Этот демон предоставляет информацию о состоянии объектов кластера. Он публикует информацию о состоянии топологии и ресурсов кластера для MIB. Он является клиентом диспетчера кластера (Cluster Manager). Этот демон работает совместно с демоном протокола SNMP (snmpd). Демон clsmuxpd должен выполняться на всех узлах кластера.
    Примечание. Демон clsmuxpd нельзя запустить при отключенном демоне snmpd. В HACMP 5.3 clsmuxpd больше не используется.
  • Подсистема служб топологии кластера (Cluster Topology Services Subsystem). Подсистема служб топологии кластера RSCT обеспечивает мониторинг состояния сетевых интерфейсов и публикует состояние для клиентов, осуществляющих доступ к информации посредством членства в службах групп. Основным демоном является демон hatsd. Службы топологии также включают сетевые интерфейсные модули hats_nim*, отправляющие и получающие пакеты пульса. Подсистема служб топологии кластера должна выполняться на всех узлах кластера.
  • Подсистема управления событиями кластера (Cluster Event Management Subsystem). Эта подсистема RSCT сопоставляет информацию о состоянии системных ресурсов с информацией о состоянии ресурсов, требуемых для клиентских программ (приложений, подсистем и прочих программ). Демон haemd выполняется на всех узлах домена.
    Примечание. Подсистема управления событиями кластера используется только в Oracle 9i; в HACMP 5.2 и более поздних версиях он заменен подсистемой RMC (Resource Monitoring and Control).
  • Монитор ресурсов подсистемы управления событиями операционной системы AIX (Event Management AIX Operating System Resource Monitor). Этот демон RSCT выступает в качестве монитора ресурсов для подсистемы управления событиями и обеспечивает информацию о параметрах и использовании операционной системы. Демон emaixos автоматически запускается подсистемой управления событиями.
  • Подсистема служб групп кластера (Cluster Group Services Subsystem). Эта подсистема RSCT обеспечивает надежную связь и протоколы, необходимые для работы кластера. Клиенты – это распределенные демоны, такие, как диспетчер кластера HACMP (HACMP Cluster Manager) и диспетчер логических томов с расширенным одновременным доступом (Enhanced Concurrent Logical Volume Manager). Демон hagsd должен выполняться на всех узлах кластера.
  • Демон сервера глобализации кластера (Cluster Globalized Server daemon, grpglsmd). Этот демон RSCT выполняется в качестве клиента служб групп; его функция состоит в том, чтобы обеспечить глобальное членство адаптера коммутатора по всем узлам кластера. Демон grpglsmd должен выполняться на всех узлах кластера.
  • Подсистема мониторинга и управления ресурсами (Resource Monitoring and Control Subsystem). Эта подсистема RSCT выполняется в качестве монитора ресурсов для подсистемы управления событиями и обеспечивает информацию о параметрах и использовании операционной системы. Подсистема RMC должна выполняться на всех узлах кластера. По умолчанию демон rmcd после установки настроен на запуск из inittab. Скрипт rc.cluster обеспечивает работу подсистемы RMC.
< Лекция 6 || Лекция 7: 123456 || Лекция 8 >