Стальной глаз на страже жизни. HA-кластер LifeKeeper компании SteelEye::Журнал СА7.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1943
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1973
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1530
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1117
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1693
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Стальной глаз на страже жизни. HA-кластер LifeKeeper компании SteelEye

Архив номеров / 2004 / Выпуск №7 (20) / Стальной глаз на страже жизни. HA-кластер LifeKeeper компании SteelEye

Рубрика: Администрирование /  Оборудование

АНТОН БОРИСОВ

Стальной глаз на страже жизни
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-канал. В самом деле, название кластера обязывает к повышенной надежности.

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

Рисунок 1

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

Рисунок 2

Как я уже отмечал выше, поддерживается в первую очередь 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

Рисунок 3

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

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

Рисунок 4

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

Рисунок 5

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

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

Рисунок 6

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

Рисунок 7

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

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

Рисунок 8

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

Рисунок 9

Рисунок 10

Рисунок 11

Проверяем доступен ли новый 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, который создается аналогично предыдущим, показанным выше.

Рисунок 12

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

Рисунок 13

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

Рисунок 14

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

Рисунок 15

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

Рисунок 16

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

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

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

Рисунок 17

Чтобы переключить узел с активного состояния на пассивное или же перевести ресурсы с одного узла на другой, надо выбрать пункт 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:
         Machine pc-box1

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

$ 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

pc-box1:/var/www/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.

  1. http://www.openmosix.org.ru/docs/openMosix-HOWTO-multi/ch02.html
  2. http://www.cio-world.ru/techniques/effect/29933
  3. http://parallel.ru/parallel/russia/russian_clusters.html
  4. http://distributed.org.ru/?main&newsday=24-Mar-2004
  5. http://www.steeleye.com
  6. http://licensing.steeleye.com/support/download_get.php/configclusters.pdf?dir=0&file=configclusters.pdf
  7. http://licensing.steeleye.com/download
  8. http://lse.sf.net/numa/faq/index.html
  9. http://www.top500.org//lists/2003/11

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru