Рубрика:
Администрирование /
Оборудование
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
АНТОН БОРИСОВ
Стальной глаз на страже жизни HA-кластер LifeKeeper компании SteelEye
Кластеры, которые мы будем собирать, сконструированы из обычных персоналок, которые называются узлами, без использования разделяемой физической памяти. Сей факт, а также то, что на отдельно взятом узле запущена операционная система, отличает наш кластер от кластеров на платформе NUMA (Non-Uniform Memory Architecture) и SMP (Symmetric Multi-Processor). Более подробно смотрите в «вопросах и ответах» [8]. Однако никто не мешает построить кластер на основе и этих платформ. Кстати, в списке top 500 [9], содержащем самые быстродействующие кластеры планеты, есть несколько штук, собранных на PC-платформе. Их, в частности, можно определить по строчкам self-made (самособранные). Все остальное работает на основе специального оборудования. С точки зрения тепловыделения, потреблямых энергоресурсов и занимаемого пространства персоналки явно не лучший материал для создания сколько-нибудь быстродействующих кластеров
Слово «кластер» означает «подмножество объектов с определенными наборами признаков».
Кластер – это две или более самостоятельные системы, соединенные в единую систему высокого уровня доступности посредством специального программного и аппаратного обеспечения.
Существует четыре основных преимущества использования кластерных систем:
- высокая доступность (High Availability);
- масштабируемость;
- гибкость;
- простота управления.
Кластер – это также возможность использовать вычислительные ресурсы системы так, что полученная система превосходит по своим возможностям суммарные возможности ее частей.
Кластеры имеют свою специализацию, но тем не менее все они обладают схожими чертами, присущими только кластерам, что в свою очередь отличает их от других вычислительных платформ.
Из компьютерного словаря:
- Cluster (кластер) – группа терминалов или рабочих станций, подключенных к общему серверу, или группа нескольких серверов, которые совместно выполняют общую задачу и способны заменить друг друга, если одно из устройств выйдет из строя.
- Cluster (кластер) – группа компьютеров, объединенных высокоскоростными каналами связи, и представляющая с точки зрения пользователя одну многопроцессорную машину. Кластерная архитектура обеспечивает высокую надежность и широкие возможности для масштабирования.
Задача кластера заключается в обеспечении согласованной работы всех узлов для достижения поставленной цели. Целью может быть высокая устойчивость (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
Аналогично поставим пакеты:
- HANFS-RedHat-2.4.18-14-4.4.2-3.i386.rpm – для NFS служб;
- steeleye-lkRedHat70-4.2.0-13.i386.rpm – ядро LifeKeeper под RedHat-платформу;
- steeleye-lkLIC-4.2.0-13.i386.rpm – пакет для управления лицензиями;
- 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://: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-адресом. При переезде с одного узла на другой алиас с первого узла удаляется и создается на новом.
$ /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-приложение. Вполне возможно произвести эту операцию через командную строку:
# /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: |
Как видите, я произвожу переключение кластера со второго узла, на который переедут ресурсы.
$ 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 на первый узел. Запускаем следующим образом:
# /opt/LifeKeeper/bin/lcdrcp index.html
Уточняем, куда именно следует положить файл – в директорию /var/www/html, но уже на первом узле.
В первом примере мы переводили ресурс ip-triton-tag с узла на узел, но тогда в иерархии он не был связан с ресурсом apache-tag. Сейчас же давайте посмотрим, как пройдет процесс переезда двух ресурсов. Уже скопировали индексный файл для apache и хотим посмотреть, как запустятся ресурсы на первом узле.
# ./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: Machine pc-box2 |
Ошибок в ходе «переезда» не возникло. Единственное, что следует отметить – это прекращение срока деятельности лицензионного ключа. Впрочем, месяца на тестирование компонентов вполне должно хватить.
Управлять кластером можно не только посредством GUI-приложения, но из-командной строки, а также окошка браузера. Впрочем, последнее не слишком сильно отличается от GUI-управления. Приведу несколько команд и их назначение.
Для старта и остановки кластера LifeKeeper, GUI-приложения:
lkstart |
Выполнить старт ядра кластера |
lkstop |
Остановить ядро кластера |
lktest |
Выполнить проверку, а запущен ли кластер |
lkGUIserver |
Выполнить/остановить GUI-процессы кластера |
lkGUIapp |
Выполнить Java-приложение управления кластером |
Мониторинг кластера:
lk_log |
Вывод статистики по работе кластера |
lcdstatus |
Вывод состояния ресурсов, коммуникационных настроек и т.п. |
lcdsync |
Запись конфигурации кластера из памяти на диск |
lcdrcp |
Перенос файлов с одного узла кластера на другой через коммуникационный ресурс |
lcdremexec |
Выполнить команду на указанном узле кластера |
lcdrecover |
Проверить и установить иерархии ресурсов |
Запуск ресурса на выполнение/остановку:
perform_action a restore t $LKTag |
Запустить сервис |
perform_action a remove t $LKTag |
Остановить сервис |
Команды для создания настроек коммуникационных путей:
net_create |
Создать коммуникационный путь между 2 узлами кластера |
net_remove |
Удалить коммуникационный путь |
net_list |
Просмотреть информацию о коммуникационном пути |
net_change |
Внести изменения в указанный коммуникационный путь |
crelcm |
Создать коммуникационный путь |
portio |
Протестировать соединение через COM-порт между 2 узлами |
Пример:
net_create -d pc-box1 -s pc-box2 -D MyPath -n TCP -r 10.0.0.200 -l 10.0.0.100 -p 1
crelcm pc-box1 pc-box2 TCP 10.0.0.100 10.0.0.200 10
Команды по управлению приложениями:
app_create |
Создать ресурс на узле |
app_remove |
Удалить ресурс |
app_list |
Просмотреть все ресурсы на данном узле |
Пример:
app_create -d pc-box1 -a apache-tag
app_list -d pc-box1
P.S. В брошюре, поставляемой с данным решением, прозвучало, что время простоя – около 50 минут в год. Будем надеяться, что это не только рекламный ход, но и действительно грамотное решение.
Спасибо за поддержку сотрудникам Esko Wessman и Marko Lehtimaki из компании NordicMind, а также за техническую помощь сотрудникам Denise Hodges и Randy Hinz компании SteelEye.
- http://www.openmosix.org.ru/docs/openMosix-HOWTO-multi/ch02.html
- http://www.cio-world.ru/techniques/effect/29933
- http://parallel.ru/parallel/russia/russian_clusters.html
- http://distributed.org.ru/?main&newsday=24-Mar-2004
- http://www.steeleye.com
- http://licensing.steeleye.com/support/download_get.php/configclusters.pdf?dir=0&file=configclusters.pdf
- http://licensing.steeleye.com/download
- http://lse.sf.net/numa/faq/index.html
- http://www.top500.org//lists/2003/11
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|