Содержание


Восстановление после сбоя ресурсов в кластере IBM PowerHA

Comments

Сегодня в центрах обработки данных многих организаций используются серверы на базе архитектуры Power. Многие организации используют программное обеспечение IBM AIX® для обеспечения высокой доступности и быстрого восстановления критически важных приложений. В этой статье мы расскажем об инструменте IBM PowerHA SystemMirror, который позволяет восстанавливать рабочее состояние кластеров после сбоев ресурсов или приложений, возникающих из-за ввода неправильных данных, и при этом не требует остановки кластерных служб. Случается, что из-за ввода неправильных данных при обращении к приложениям или ресурсам кластер переходит в нерабочее состояние, а его ресурсы – в состояние ошибки. В PowerHA предусмотрена возможность восстановления рабочего состояния кластера и ресурсов на основе политик после устранения ошибок, которые стали причиной остановки служб кластера. В статье рассматриваются ошибки ресурсов и ошибки приложений, возникающие в группе ресурсов.

Конфигурирование кластера PowerHA

За дополнительной информацией о решении высокой доступности IBM PowerHA и его настройке в операционной системе AIX обратитесь к статье Introduction to PowerHA (EN). В данной статье рассматривается базовая конфигурация кластера PowerHA с двумя узлами. Точно таким же образом можно создать кластер с произвольным количеством разнесенных узлов, использующих центральное хранилище данных. Кластер на основе централизованного хранилища может быть "растянутым" (хранилище и узлы кластера географически разнесены) или связанным (узлы и хранилище находятся в одном местоположении).

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

Рисунок 1. Конфигурация "растянутого" кластера PowerHA
Конфигурация растянутого кластера PowerHA
Конфигурация растянутого кластера PowerHA

В этом кластере созданы одна сеть и три группы ресурсов. Группа ресурсов RG1 непараллельная, а две другие группы – параллельные. Кластер создан на узле SiteANode1, а изменения передаются на остальные узлы кластера средствами Verify And Sync.

Основную информацию о кластере можно получить с помощью утилиты cltopinfo.

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
# cltopinfo
Cluster Name:    test_cluster
Cluster Type:    Stretched
Heartbeat Type:  Multicast
Repository Disk: hdisk11 (00f601bbb83e6a40)
Cluster IP Address: 228.40.0.25
Cluster Nodes:
        Site A (siteA):
                SiteANode1
                SiteANode2
        Site B (siteB):
                SiteBNode1
                SitebNode2

There are four node(s) and one network(s) defined.

NODE SiteANode1:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteANode1        10.40.0.25

NODE SiteANode2:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteANode2        10.40.0.26

NODE SiteBNode1:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteBNode1        10.40.0.43

NODE SiteBNode2:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteBNode2        10.40.0.44

Resource Group RG1_conc
        Startup Policy   Online On All Available Nodes
        Fallover Policy  Bring Offline (On Error Node Only)
        Fallback Policy  Never Fallback
        Participating Nodes      SiteANode1 SiteANode2 SiteBNode1 SitebNode2

Resource Group RG2_conc
        Startup Policy   Online On All Available Nodes
        Fallover Policy  Bring Offline (On Error Node Only)
        Fallback Policy  Never Fallback
        Participating Nodes      SiteANode1 SiteANode2 SiteBNode1 SitebNode2

Resource Group RG1
        Startup Policy   Online On Home Node Only
        Fallover Policy  Fallover To Next Priority Node In The List
        Fallback Policy  Fallback To Higher Priority Node In The List
        Participating Nodes      SiteANode1 SiteANode2 SiteBNode1 SitebNode2
        Service IP Label                 service_ip1

Добавление сценариев контроллера приложений в PowerHA

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

В примерах этой статьи мы будем рассматривать приложение app1, для которого создан контроллер app1_test, а также сценарии запуска, останова и мониторинга. Доступ к приложению осуществляется через файловую систему /fs1 и группу томов VG1. Приложение является ресурсом группы RG1.

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

(0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/scripts/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null &

(0) root @ SiteANode1: /home/scripts ----------------- Stop script
# cat  app1_stop
#!/usr/bin/ksh
ps -ef | grep -w /home/scripts/app1 | grep -v grep | awk '{print $2}' | read pid
if [ $pid ]
then
       echo "printing that app1 is stopped"
        kill -9 $pid
fi

(0) root @ SiteANode1: /home/scripts --------------- Monitor scripts 
# cat app_mon1
#!/usr/bin/ksh
ps -ef | grep -w /home/scripts/app1  | grep -v grep | awk '{print $2}'| read pid
if [ $pid ]
then
        return 0
fi
return 1

Ниже показано, как добавить контроллер приложения и сценарии мониторинга в кластер PowerHA.

  1. Добавление контроллера приложения

Откройте оснастку System Management Interface Tool (SMIT) для PowerHA с помощью команды smit. Выполните в командной строке команду smit hacmp. В открывшемся окне Cluster Applications and Resource выберите следующий пункт.

Cluster Applications and Resource → Resource → Configure User Applications (Scripts and Monitors) → Application Controller Scripts → Add Application Controller Scripts.

На рисунке 2 изображено окно для добавления сценариев контроллера приложения. Первое поле является обязательным – в нем указывается имя контроллера, которое вы можете выбрать самостоятельно. Во втором поле можно добавить сценарий запуска, а в третьем поле – сценарий останова. Сценарий мониторинга на этом этапе еще не добавлен, поэтому он не отображается на экране. Сценарий мониторинга можно добавить либо до, либо после создания контроллера приложения/

Рисунок 2. Окно оснастки SMIT для добавления сценариев контроллера приложения
Окно оснастки SMIT для добавления сценариев контроллера приложения
Окно оснастки SMIT для добавления сценариев контроллера приложения
  1. Добавление сценария запуска для контроллера приложения

Откройте оснастку SMIT с помощью команды smit hacmp и откройте окно Add a Custom and Application Monitor, выбрав для этого следующий пункт.

Cluster Applications and Resource → Resource → Configure User Applications (Scripts and Monitors) → Application Monitors → Configure Custom Application Monitors → Add a Custom Application Monitor.

Рисунок 3. Окно оснастки SMIT для добавления монитора приложения
Окно оснастки SMIT для добавления монитора приложения
Окно оснастки SMIT для добавления монитора приложения

Ниже описываются параметры (рисунок 3), которые необходимо задать при создании монитора приложения.

  • Monitor Name – название монитора. Значение этого параметра задается пользователем, а добавленный монитор может отслеживать сценарии контроллера приложения.
  • Application Controller to Monitor – отслеживаемый контроллер приложения (контроллер приложения, созданный на рисунке 1).
  • Monitor Mode – режим работы монитора. Режим, в котором будет осуществляться мониторинг контроллера приложения.
  • Monitor Method – метод мониторинга. Здесь указывается полный путь к сценариям мониторинга.
  • Stabilization Interval – интервал стабилизации. Значение этого параметра задается пользователем и определяет время, которое отводится на успешный запуск приложения. Если, например, интервал стабилизации равен 30 секундам, и в течение этого времени приложение корректно запустилось, то кластер переводится в рабочее состояние, а ресурсы – в онлайновый режим. Если же в течение этого времени приложение не запустилось по какой-либо причине, оно будет перезапущено.
  • Restart Count – счетчик перезапусков. Контроллер будет перезапускать приложение указанное количество раз. Если значение этого параметра не задано, выполняется переход на следующий узел. В нашем случае этот параметр имеет значение 3, следовательно, если приложение не запустится с трех попыток, оно будет перемещено на следующий приоритетный узел. В таком случае группа ресурсов на текущем узле перейдет в состояние ошибки (ERROR), а кластер перейдет в состояние UNSTABLE, и если группа ресурсов находится в состоянии ERROR то кластер перейдет в состояние RP_FAILED.
  1. Добавление созданных приложений в группу ресурсов

Откройте оснастку SMIT с помощью команды smit hacmp и откройте окно Change/Show Resources and Attributes for a Resource Group, выбрав для этого следующий пункт.

Cluster Applications and Resources → Resource Groups → Change/Show Resources and Attributes for a Resource Group.

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

Рисунок 4. Выбор группы ресурсов для добавления приложения и файловой системы
Выбор группы ресурсов для добавления приложения и файловой системы
Выбор группы ресурсов для добавления приложения и файловой системы

В этом примере мы добавили приложения и файловую систему в группу ресурсов RG1.

Рисунок 5. Окно оснастки SMIT для добавления ресурсов и атрибутов в группу RG1
Окно оснастки SMIT для добавления ресурсов и атрибутов в группу RG1
Окно оснастки SMIT для добавления ресурсов и атрибутов в группу RG1

Чтобы понять, как функция восстановления кластера работает с приложением, мы добавим контроллер приложения app1_test в группу ресурсов RG1. Это приложение расположено в файловой системе /fs1 группы томов VG1.

  1. Восстановление кластера после сбоя

Чтобы продемонстрировать восстановление кластера, мы изменим путь к приложению в сценариях запуска на всех узлах. Изначально приложение находится в директории /home/scripts. Мы изменим этот путь в сценарии запуска, тем самым вызвав сбой приложения.

Исходный сценарий запуска

(0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/scripts/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null &

Измененный сценарий запуска

0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/test/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null &

После запуска служб кластера из-за неправильно введенных данных возникнет ошибка, и контроллер приложения будет пытаться перезапустить его в соответствии со значением счетчика перезапусков. Из-за неправильных данных контроллера приложения кластер не сможет перейти в рабочее состояние, а соответствующая информация будет занесена в файл /var/hacmp/log/hacmp.out. Приложение не сможет запуститься из-за неправильно указанного пути к нему.

Если ошибка в сценарии запуска присутствует только на одном узле, то произойдет следующее. Группа ресурсов попытается перейти в состояние ONLINE на этом узле и после трех попыток перезапуска (в соответствии со значением, заданном на рисунке 3) попытается перейти на следующий узел. Если сценарий запуска на новом узле не содержит ошибок, то кластер перейдет в рабочее состояние, а группа ресурсов на этом узле – в состояние ONLINE.

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
# clRGinfo
-----------------------------------------------------------------------------
Group Name                   State            Node
-----------------------------------------------------------------------------
RG1_conc            ONLINE           SiteANode1
                    ONLINE           SiteANode2
                    ONLINE           SiteBNode1
                    ONLINE           SitebNode2

RG2_conc            ONLINE           SiteANode1
                    ONLINE           SiteANode2
                    ONLINE           SiteBNode1
                    ONLINE           SiteBNode2

RG1                 ERROR           SiteANode1@siteA
                    OFFLINE         SiteANode2@siteA
                    OFFLINE         SiteBNode1@siteB
                    OFFLINE         SiteBNode2@siteB


(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_RP_RUNNING
Current state: ST_RP_RUNNING
Current state: ST_RP_RUNNING
Current state: ST_RP_RUNNING

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_CBARRIER
Current state: ST_CBARRIER
Current state: ST_CBARRIER
Current state: ST_CBARRIER

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_UNSTABLE
Current state: ST_UNSTABLE
Current state: ST_UNSTABLE
Current state: ST_UNSTABLE

Приложение в данной группе ресурсов также не запустилось

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
# ps -ef| grep app1
    root 16187668 15598018   0 10:13:36  pts/0  0:00 grep app1

В этом случае приложение app1 не запускается из-за неправильно указанного пути в сценарии запуска, и в файл /var/hacmp/log/hacmp.out помещается соответствующая запись об ошибке, как показано на рисунке 6. Согласно сообщению из log-файла, для исправления ошибки потребуется ручное вмешательство. Изменим вручную путь к приложению в сценарии запуска, чтобы вывести группу ресурсов из состояния ERROR, а кластер – из состояния UNSTABLE или RP_FAILED.

0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/scripts/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null & ---- >  correct path .
Рисунок 6. Сообщение об ошибке приложения в log-файле hacmp.out
Сообщение об ошибке приложения в log-файле hacmp.out
Сообщение об ошибке приложения в log-файле hacmp.out

После устранения ошибок в сценарии запуска система HACMP позволяет восстановить кластер посредством сценарияclruncmd, входящего в состав набора кластерных утилит. Также опция восстановления кластера после сбоя сценария предусмотрена в оснастке SMIT. Выполните в командной строке команду smit hacmp и выберите следующий пункт.

Problem Determination Tools → Recover From PowerHA SystemMirror Script Failure.

Здесь можно поочередно выбрать требуемые узлы.

Рисунок 7. Окно оснастки SMIT для восстановления после сбоя сценария
Окно оснастки SMIT для восстановления после сбоя сценария
Окно оснастки SMIT для восстановления после сбоя сценария

Для восстановления после сбоя сценария запускается команда /usr/es/sbin/cluster/utilities/clruncmd, которая посылает сообщение демону управления кластером на указанном узле. В результате кластер переходит в рабочее состояние на этом узле, и если сценарий не содержит ошибок, то группа ресурсов этого узла переходит в онлайновый режим. После успешного восстановления в файл /var/hacmp/log/hacmp.out заносится соответствующая запись. Если группа ресурсов переходит в состояние ошибки (ERROR) на всех узлах, значит, все эти узлы содержат ошибки данных. В этом случае необходимо устранить ошибки ввода на всех узлах, после чего вручную перевести группу ресурсов в состояние ONLINE. Если же группа ресурсов переходит в состояние ошибки только на одном узле, значит, достаточно исправить неверно введенные данные на этом отдельном узле.

Если сценарий не может запуститься из-за ввода неправильных данных PowerHA, то менеджер кластера делает запись об ошибке в файле hacmp.out. После исправления неверно введенных данных менеджер кластера переводит кластер в рабочий (STABLE) режим. Для восстановления после сбоя сценария выполняется команда PowerHA clruncmd, которая посылает сообщение демону управления кластером на указанном узле, В результате кластер переходит в рабочее состояние, а группа ресурсов – в онлайновый режим (в случае, если она находилась в состоянии ошибки по причине сбоя ресурсов из-за неверно введенных данных). При обнаружении ошибки в файле hacmp.out может потребоваться ручное исправление неправильных данных, после чего процедура восстановления переведет кластер в рабочее состояние, а запись о событии в файле hacmp.out будет дополнена.

Заключение

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

Ресурсы


Ресурсы для скачивания


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=1024757
ArticleTitle=Восстановление после сбоя ресурсов в кластере IBM PowerHA
publish-date=07302015