HA-кластер LifeKeeper компании SteelEye

Антон Борисов

Слово «кластер» означает «подмножество объектов с определенными наборами признаков».

Кластер – это две или более самостоятельные системы, соединенные в единую систему высокого уровня доступности посредством специального программного и аппаратного обеспечения.

Существует четыре основных преимущества использования кластерных систем:

n  высокая доступность (High Availability);

n  масштабируемость;

n  гибкость;

n  простота управления.

Кластер – это также возможность использовать вычислительные ресурсы системы так, что полученная система превосходит по своим возможностям суммарные возможности ее частей.

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

Из компьютерного словаря:

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

Cluster (кластер) – группа компьютеров, объединенных высокоскоростными каналами связи, и представляющая с точки зрения пользователя одну многопроцессорную машину. Кластерная архитектура обеспечивает высокую надежность и широкие возможности для масштабирования.

Кластеры, которые мы будем собирать, сконструированы из обычных персоналок, которые называются узлами, без использования разделяемой физической памяти. Сей факт, а также то, что на отдельно взятом узле запущена операционная система, отличает наш кластер от кластеров на платформе NUMA (Non-Uniform Memory Architecture) и SMP (Symmetric Multi-Processor). Более подробно смотрите в «вопросах и ответах» [8]. Однако никто не мешает построить кластер на основе и этих платформ. Кстати, в списке top 500 [9], содержащем самые быстродействующие кластеры планеты, есть несколько штук, собранных на PC-платформе. Их, в частности, можно определить по строчкам self-made (самособранные). Все остальное работает на основе специального оборудования. С точки зрения тепловыделения, потреблямых энергоресурсов и занимаемого пространства персоналки явно не лучший материал для создания сколько-нибудь быстродействующих кластеров.

Задача кластера заключается в обеспечении согласованной работы всех узлов для достижения поставленной цели. Целью может быть высокая устойчивость (HA – High Availability), высокая вычислительная способность (HP – High Performance), параллельное вычисление, параллельное обслуживание запросов. Наконец, кластер отличается от клиент-серверных распределенных вычислений тем, что кластерное взаимодействие – это все-таки равноценное взаимодействие каждого узла друг с другом, по принципу пиринговых сетей (peer-to-peer), когда каждый узел, в свою очередь, является членом более крупной системы. Условно в кластере выбирается мастер-узел, а другие являются «подшефными» узлами. В случае отказа мастер-узла выбирается по заранее выбранному алгоритму новый мастер-узел, который и курирует в дальнейшем весь кластер.

Типы кластеров

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

Кластерами с распределением нагрузки (балансировочными) являются Mosix-кластеры. Они позволяют пользователю одного узла прозрачно распределить нагрузку одного узла кластера по всем остальным. Применение целесообразно в тех случаях, когда требуется использовать задачи с интенсивными вычислительными запросами, которые, в частности, характеризуются высокой длительностью вычислений. К числу задач также следует отнести приложения, которые не были специально оптимизированы под параллельное вычисление.

Кластеры проекта LVS (Linux Virtual Server) и кластеры типа Piranha (RedHat Linux) считаются кластерами с параллельным обслуживанием запросов. Они в чем-то похожи на Mosix-кластеры, так как также занимаются распределением нагрузки, правда, в несколько другом ключе. Приходящие веб-запросы распределяются системой между набором стандартных веб-серверов. Данный тип кластера больше напоминает ферму, нежели кластер, так как узлы с веб-службами обычно не подозревают друг о друге и не взаимодействуют между собой. Включены же они были по одной простой причине – с течением времени техника обслуживания запросов, возможно, претерпит изменение, и узлы наконец-то начнут знать друг о друге. А может быть, узлы так и не будут знать о существовании друг друга. Время покажет.

Когда говорят о кластерах хранения информации, подразумевают системы, разработанные фирмой Sistina (GFS – Global FileSystem) и проектом OpenGFS. Кластеры состоят из узлов, которые обеспечивают параллельный и высоконадежный доступ к данным единой файловой системы.

Кластер баз данных – это Oracle Parallel Server (OPS; сейчас известный как Oracle 9I RAC), состоит из узлов, которые обеспечивают параллельное, согласованное и высоконадежное соединение с базой данных.

Высоконадежные кластеры представлены такими решениями, как LifeKeeper, FailSafe и Heartbeat. Они также называются отказоустойчивыми кластерами. Происходит мониторинг ресурсов, а именно приложений и состояния узлов. При обнаружении сбоя система замещает IP-адреса, дисковые устройства, файловые системы на резервные, т.е. другого узла. Также на новом узле происходит старт целевых приложений, которые упали на отказавшем узле. Приложения могут и не упасть. Например, в случае, если у элемента кластера всего лишь вышла из строя сетевая карта и он стал недоступен для контроля. Поэтому такой тип отказа оборудования равноценен падению узла.

Сегодня мы рассмотрим последний тип кластеров, а именно HA-кластеры, т.е. из семейства отказоустойчивых.

Остановим свое внимание на продукте LifeKeeper фирмы SteelEye.

Согласно техническим характеристикам поддерживается до 32 узлов в кластере. Узлы могут быть построены как на базе Linux (в первую очередь это Red Hat и совместимые с ней системы), так и на базе Windows 2000 и выше. Хотя я подозреваю, что есть и решения для узлов на базе Sun Solaris, впрочем, это не афишируется, но любознательные читатели всё равно посмотрят установочные и сервисные скрипты.

Как сервера узнают о нормальном функционировании друг друга? Очень просто – с помощью heartbeat-механизма, т.е. с помощью обмена информацией по выделенным каналам. Под термином heartbeat подразумевается сердцебиение. В нашем случае «сердцебиение» узлов кластера. Если один из серверов перестает отвечать другому, значит произошел отказ/сбой и предпринимаются аварийные меры. В нашем случае проверки происходят с помощью запросов, отправленных на порты 81, 82. Если удаленная машина не формирует правильный ответ по данным портам, то очевидно, что на узле не запущено кластерное ПО или же узел «упал». В этом случае происходит перемещение функций на другой узел. Выделенными каналами могут выступать как отдельное, дополнительное ethernet-соединение, так и соединение по RS-232 протоколу. В первом случае ethernet-соединение может использоваться серверами как дополнительный канал для обмена информацией по TCP/IP-протоколу. Рекомендуют делать не один канал для heartbeat-целей, а два и более. Подразумевается, что даже в случае отказа коммуникационного heartbeat-канала в системе будет задействован резервный heartbeat-канал. В самом деле, название кластера обязывает к повышенной надежности.

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

Для мультисерверной конфигурации узлов следует использовать схему, представленную на рисунке.

Как я уже отмечал выше, поддерживается в первую очередь Red Hat Linux. С выпуском LifeKeeper версии 4.4.3 кластер можно развернуть на следующих релизах:

Дистрибутив/Версия	Поддерживаемые версии ядер
Red Hat 7.x	2.4.9-31 (7.1, 7.2)
	2.4.9-34 (7.1, 7.2)
	2.4.18-5 (7.3)
	2.4.18-19.7.x
	2.4.18-24.7.x
	2.4.18-27.7.x
	2.4.20-18.7
	2.4.20-20.7
	2.4.20-28.7
Red Hat 8.0	2.4.18-14 (ядро по умолчанию)
	2.4.18-19.8.0
	2.4.18-24.8.0
	2.4.18-27.8.0
	2.4.20-18.8
	2.4.20-20.8
	2.4.20-28.8
Red Hat 9.0	2.4.20-28.9
Red Hat Enterprise Linux AS 2.1 and ES 2.1	2.4.9-e.3 (AS-ядро)
	2.4.9-e.8
	2.4.9-e.10
	2.4.9-e.12 (ES-ядро)
	2.4.9-e.16
	2.4.9-e.24
	2.4.9-e.25
	2.4.9-e.27
	2.4.9-e.35
	2.4.9-e.37
Red Hat Enterprise Linux 3.0 (AS and ES)	2.4.21-4.0.2.EL
	2.4.21-9.EL (Update 1)
SUSE SLES 7 *	2.4.7-(20,18,19) (ядро по умолчанию)
	2.4.18-(136,134,134) (Release 20020517)
	2.4.18-(243,223,224) (Release 20020903)
	2.4.18-(256,236,237) (Release 20021205)
	2.4.18-(262,243,244) (Release 20030324)
	2.4.18-275 (Release 20030718)
	2.4.18-280 (Release 20030815)
	2.4.18-281 (Release 20031203)
UnitedLinux.0 *	2.4.19-(120,115,113) (ядро по умолчанию)
	2.4.19-(155,145,151) (Release 20021115)
	2.4.19-(207,196,201) (Release 20030221)
	2.4.19-290
	2.4.19-304
	2.4.19-340
	2.4.21-138
	2.4.21-169
Miracle Linux 2.0	2.4.7-2.24ml (default kernel)

Попытка установки «в лоб» кластера, например, на Slackware Linux, к сожалению, пока не удалась. Поэтому пришлось обратиться к дистрибутиву ASP Linux 9.2. Зароботало все достаточно быстро и беспроблемно. Кстати, запрос в компанию Nordicmind, а именно она осуществляет техническую поддержку для стран Европы, Балтии и СНГ, подтвердил, что на данный момент последним сертифицированным ядром является 2.4.21, т.е. работающие под 2.6.x. ядрами остаются пока не у дел, к сожалению.

Итак, начинаем установку пакетов на ASP Linux-системе. Кластерное ПО можно взять по адресу [7], предварительно зарегистрировавшись. Там же получить ключи на испытательный срок в 30 дней. Маленькое отступление. Вашим идентификатором, на основе которого компания-разработчик сформирует вам ключи, является именно MAC-адрес сетевой карты. Что ж, время передать бразды правления root.

Убедимся, что у вас присутствуют те же пакеты, что и у меня.

# ls

HADR-RedHat-2.4.18-14-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-14smp-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-19.8.0-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-19.8.0smp-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-24.8.0-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-24.8.0smp-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-27.8.0-4.2.0-13.i386.rpm

HADR-RedHat-2.4.18-27.8.0smp-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-14-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-14smp-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-19.8.0-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-19.8.0smp-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-24.8.0-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-24.8.0smp-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-27.8.0-4.2.0-13.i386.rpm

HANFS-RedHat-2.4.18-27.8.0smp-4.2.0-13.i386.rpm

ips-RedHat-2.4.18-19.8.0-4.2.0-13.i386.rpm

ips-RedHat-2.4.18-19.8.0smp-4.2.0-13.i386.rpm

ips-RedHat-2.4.18-24.8.0-4.2.0-13.i386.rpm

ips-RedHat-2.4.18-24.8.0smp-4.2.0-13.i386.rpm

ips-RedHat-2.4.18-27.8.0-4.2.0-13.i386.rpm

ips-RedHat-2.4.18-27.8.0smp-4.2.0-13.i386.rpm

rc.sysinit80.diff

RedHat_license.txt

setup

steeleye-lkRedHat70-4.2.0-13.i386.rpm

По словам представителя службы технической поддержки из Nordicmind, подверсия ядра (т.е. -14, -19, -24) принципиальной разницы не играет. Поэтому ставим пакет HADR.

# rpm -ih HADR-RedHat-2.4.18-14-4.4.2-3.i386.rpm

 

Аналогично поставим пакеты:

n  HANFS-RedHat-2.4.18-14-4.4.2-3.i386.rpm – для NFS служб;

n  steeleye-lkRedHat70-4.2.0-13.i386.rpm – ядро LifeKeeper под RedHat-платформу;

n  steeleye-lkLIC-4.2.0-13.i386.rpm – пакет для управления лицензиями;

n  jre-1.3.1.i386.rpm – Java для GUI-интерфейса управления кластером.

 

[root@pc-box1 java]# rpm -ih jre-1.3.1.i386.rpm

Из директории licensing установим пакет управления лицензиями.

# cd licensing/

# rpm -ih steeleye-lkLIC-4.4.2-3.i386.rpm

И наконец устанавливаем основные пакеты для кластера:

steeleye-lk-4.4.2-2.i386.rpm    

steeleye-lkIP-4.4.2-2.i386.rpm

steeleye-lkAPA-4.4.0-1.i386.rpm 

steeleye-lkMAN-4.4.2-2.i386.rpm

steeleye-lkGUI-4.4.2-2.i386.rpm 

steeleye-lkRAW-4.4.2-2.i386.rpm

steeleye-lkHLP-4.4.2-2.i386.rpm

 

[root@pc-box1]# rpm -ih steeleye-lk*

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

The LifeKeeper GUI requires installation of the Java

 Runtime Environment (JRE) 1.3.1 on each server.

To access online help outside the GUI, open the URL

http://<server>:81/help/lksstart.htm directly from your browser.

To access the LifeKeeper man pages, add the following to your .profile

or .bash_profile.

MANPATH=/opt/LifeKeeper/man:$MANPATH;export MANPATH

В итоге программное обеспечение поставлено в директорию /opt/LifeKeeper, параметры управления кластером лежат в директории /etc/default/LifeKeeper.

Не забудьте записать ключи, полученные вами от компании steeleye или её представителя, в директорию /var/LifeKeeper/license.

Затем запускаем кластер – /opt/LifeKeeper/bin/lkstart. В /etc/inittab пропишутся необходимые для работы сервисы. Также следует прописать в файл /etc/default/LifeKeeper строку NOBCASTPING=1, т.к. тестировать кластер мы будем, вероятно, в отдельной сетке, где нет дополнительных машин. Она означает, что кластерное ПО будет игнорировать пакеты бродкастов. При переносе в дикую среду не забудьте раскомментировать её.

Следует обратить внимание, что в /etc/hosts (или в DNS-сервер) следует прописать как названия машин с их IP-адресами, так и информацию о тех ресурсах, которые будут считаться разделяемыми.

Например, на каждом узле мой файл hosts выглядит следующим образом:

10.0.0.100 pc-box1

10.0.0.101 bb-box1

 

10.0.0.200 pc-box2

10.0.0.201 bb-box2

 

10.0.0.150 triton

где pc-box1, pc-box2 – названия узлов; bb-box1, bb-box2 – названия plip-интерфейсов, которые будут использоваться как heartbeat-каналы; triton – собственно разделяемый ресурс.

Ну а теперь запускаем приложение, управляющее кластером.

[root@pc-box1]# /opt/LifeKeeper/bin/lkGUIapp

Вводим названия узла, к которому подключаемся, имя пользователя и его пароль. Обычно это суперпользователь, но рекомендуется создать отдельного, который и будет заведовать кластером. Аналогичную процедуру проводим для 2-го узла кластера.

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

Для того чтобы узлы «знали» о состоянии друг друга, необходимо установить коммуникационный канал.

Этим мы сейчас и займемся. Начало процесса приведено на lk-step2.png. Начинаем настройку с узла pc-box1. Локальный IP-адрес выбираем такой же, что и в /etc/hosts, а именно 10.0.0.100. Собственно говоря, LifeKeeper оттуда все и берет. Но помним, что 10.0.0.101 зарезервирован в качестве backbone-канала (или в данном случае как heartbeat-соединение).

Далее заполняем необходимые значения для второго узла.

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

Дальнейшая наша задача – создать ресурс, который будет отказоустойчивым. В данном случае это IP-адрес с кодовым названием «triton». Он-то и является ключевой фигурой нашего повествования. Ведь именно он находится в иерархии отказоустойчивых ресурсов, которыми мы сегодня занимаемся.

Создание ресурса comm/ip напоминает наши предыдущие действия по созданию коммуникационного канала. Отмечу, что ресурс я создал под названием «ip-triton-tag». Можно назвать его по-другому, на ваше усмотрение.

Теперь «расширяем» ресурс на второй узел.

Проверяем доступен ли новый IP-адрес. Да, он откликается, причем с каждого из узлов. Достигается это следующим образом. На устройство eth0 добавляется алиас в виде eth0:1 с новым IP-адресом. При переезде с одного узла на другой алиас с первого узла удаляется и создается на новом.

[anthony@pc-box1 anthony]$ /sbin/ifconfig

 

eth0      Link encap:Ethernet  HWaddr 00:0C:6E:78:44:08

          inet addr:10.0.0.100  Bcast:10.0.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:39090 errors:0 dropped:0 overruns:0 frame:0

          TX packets:35215 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:19128730 (18.2 Mb)  TX bytes:9259656 (8.8 Mb)

          Interrupt:11 Base address:0xb400

 

eth0:1    Link encap:Ethernet  HWaddr 00:0C:6E:78:44:08

          inet addr:10.0.0.150  Bcast:10.0.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:11 Base address:0xb400

Следующей нашей задачей будет создание ресурса для запуска веб-сервера Apache, который создается аналогично предыдущим, показанным выше.

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

Видим, что на первом узле создался новый ресурс.

Теперь предстоит «расширить» настройки на второй узел и завершить на этом настройку ресурсов.

Убедимся, что на двух узлах у нас стоят одинаковые версии.

При обновлении следите также за тем, чтобы ключи от кластера не затерлись в /var/LifeKeeper/license.

Установку кластера можно считать законченной. Несколько слов о конфигурации apache. В файле httpd.conf команду Listen следует применять по отношению к нашему «устойчивому» ресурсу triton. У меня она выглядит на обоих узлах как Listen 10.0.0.150:80. Остальные опции не изменялись. Маленький нюанс: при падении одного из узлов также упадет и вся статистика от веб-сервера, т.к. в этой статье мы не рассматривали создание отказоустойчивого ресурса для файловой системы. Очевидно, что конфигурация на каждом из узлов должна совпадать.

Условимся, что первый узел является основным, а второй – резервным. Тогда при остановке основного узла ресурсы «переедут» на второй. Что мы и можем видеть на приведенном рисунке.

Чтобы переключить узел с активного состояния на пассивное или же перевести ресурсы с одного узла на другой, надо выбрать пункт In Service/Out of Service на вкладке конкретного узла. Это производится через GUI-приложение. Вполне возможно произвести эту операцию через командную строку:

[root@pc-box2]# /opt/LifeKeeper/bin/perform_action -a restore -t ip-triton-tag

 

/opt/LifeKeeper/bin/perform_action: LRACI(dorestore) attempting remote remove

         of resource "ip-triton-tag" on machine "pc-box1"

/opt/LifeKeeper/bin/lcdrecover: resource "ip-triton-tag" is being removed

         because of request from machine "pc-box2"

lcdrecover[409,lcdrecover.C]Thu May  6 22:49:09 MSD 2004: remote request by

         "pc-box2" for removal of resources "ip-triton-tag" on "pc-box1"

         successful

/opt/LifeKeeper/bin/perform_action: LRACI(dorestore) remote remove of resource

         "ip-triton-tag" on machine "pc-box1" successful

LifeKeeper: RESTORE COMMUNICATION RESOURCE ip-triton-tag START AT:

        Thu May 6 22:49:25 MSD 2004

LifeKeeper: RESTORE COMMUNICATION RESOURCE ip-triton-tag END err=0 AT:

        Thu May 6 22:49:26 MSD 2004

perform_action[725,lraci.C]Thu May  6 22:49:27 MSD 2004:

         pc-box2,priv_globact(1,remove): Running Post Global remove Scripts On

         Machine pc-box1

Как видите, я произвожу переключение кластера со второго узла, на который переедут ресурсы.

[anthony@pc-box1 anthony]$ nmap -v triton

 

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2004-05-06 22:59 MSD

Machine 10.0.0.150 MIGHT actually be listening on probe port 80

Host triton (10.0.0.150) appears to be up ... good.

Initiating Connect() Scan against triton (10.0.0.150) at 22:59

Adding open port 6000/tcp

Adding open port 82/tcp

Adding open port 21/tcp

Adding open port 111/tcp

Adding open port 22/tcp

Adding open port 81/tcp

Adding open port 80/tcp

The Connect() Scan took 1 second to scan 1657 ports.

Interesting ports on triton (10.0.0.150):

(The 1650 ports scanned but not shown below are in state: closed)

PORT     STATE SERVICE

21/tcp   open  ftp

22/tcp   open  ssh

80/tcp   open  http

81/tcp   open  hosts2-ns

82/tcp   open  xfer

111/tcp  open  rpcbind

6000/tcp open  X11

 

Nmap run completed -- 1 IP address (1 host up) scanned in 0.693 seconds

Несколько слов о том, как перенести файлы с одного узла на другой средствами ПО самого кластера. Для этих целей существует утилита lcdrcp. Я нахожусь на втором узле в директории /var/www/html, и требуется перенести файл index.html на первый узел. Запускаем следующим образом:

[root@pc-box2 html]# /opt/LifeKeeper/bin/lcdrcp index.html

pc-box1:/var/www/html

Уточняем, куда именно следует положить файл – в директорию /var/www/html, но уже на первом узле.

В первом примере мы переводили ресурс ip-triton-tag с узла на узел, но тогда в иерархии он не был связан с ресурсом apache-tag. Сейчас же давайте посмотрим, как пройдет процесс переезда двух ресурсов. Уже скопировали индексный файл для apache и хотим посмотреть, как запустятся ресурсы на первом узле.

[root@pc-box1 bin]# ./perform_action -a restore -t apache-tag

./perform_action: LRACI(dorestore) attempting remote remove of resource

         "ip-triton-tag" on machine "pc-box2"

/opt/LifeKeeper/bin/lcdrecover: resource "ip-triton-tag" is being removed

         because of request from machine "pc-box1"

lcdrecover[409,lcdrecover.C]Thu May  6 23:18:20 MSD 2004: remote request by

         "pc-box1" for removal of resources "ip-triton-tag" on "pc-box2"

         successful

./perform_action: LRACI(dorestore) remote remove of resource "ip-triton-tag"

on machine "pc-box2" successful

LifeKeeper: RESTORE COMMUNICATION RESOURCE ip-triton-tag START AT:

        Thu May 6 23:18:08 MSD 2004

LifeKeeper: RESTORE COMMUNICATION RESOURCE ip-triton-tag END err=0 AT:

        Thu May 6 23:18:09 MSD 2004

***WARNING*** perform_action;Thu May  6 23:18:10 MSD 2004: License key (for

Kit webserver/apache) will expire at midnight in 21 days

LifeKeeper: RESTORE: APACHE: RESTORING apache-tag TO SERVICE START AT:

        Thu May 6 23:18:11 MSD 2004

LifeKeeper: RESTORE APACHE RESOURCE apache-tag END err=0 AT:

        Thu May 6 23:18:14 MSD 2004

perform_action[725,lraci.C]Thu May  6 23:18:15 MSD 2004:

         pc-box1,priv_globact(1,remove): Running Post Global remove Scripts On

         Machine pc-box2

Ошибок в ходе «переезда» не возникло. Единственное, что следует отметить – это прекращение срока деятельности лицензионного ключа. Впрочем, месяца на тестирование компонентов вполне должно хватить.

Управлять кластером можно не только посредством GUI-приложения, но из-командной строки, а также окошка браузера. Впрочем, последнее не слишком сильно отличается от GUI-управления. Приведу несколько команд и их назначение.

Для старта и остановки кластера LifeKeeper, GUI-приложения:

lkstart	Выполнить старт ядра кластера
lkstop	Остановить ядро кластера
lktest	Выполнить проверку, а запущен ли кластер
lkGUIserver	Выполнить/остановить GUI-процессы кластера