 |
|
|
|
Стальной глаз на страже жизни. HA-кластер LifeKeeper компании SteelEye
Стальной глаз на страже жизни Кластеры, которые мы будем собирать, сконструированы из обычных персоналок, которые называются узлами, без использования разделяемой физической памяти. Сей факт, а также то, что на отдельно взятом узле запущена операционная система, отличает наш кластер от кластеров на платформе 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 кластер можно развернуть на следующих релизах:
Попытка установки «в лоб» кластера, например, на Slackware Linux, к сожалению, пока не удалась. Поэтому пришлось обратиться к дистрибутиву ASP Linux 9.2. Зароботало все достаточно быстро и беспроблемно. Кстати, запрос в компанию Nordicmind, а именно она осуществляет техническую поддержку для стран Европы, Балтии и СНГ, подтвердил, что на данный момент последним сертифицированным ядром является 2.4.21, т.е. работающие под 2.6.x. ядрами остаются пока не у дел, к сожалению. Итак, начинаем установку пакетов на ASP Linux-системе. Кластерное ПО можно взять по адресу [7], предварительно зарегистрировавшись. Там же получить ключи на испытательный срок в 30 дней. Маленькое отступление. Вашим идентификатором, на основе которого компания-разработчик сформирует вам ключи, является именно MAC-адрес сетевой карты. Что ж, время передать бразды правления root. Убедимся, что у вас присутствуют те же пакеты, что и у меня. # ls
По словам представителя службы технической поддержки из Nordicmind, подверсия ядра (т.е. -14, -19, -24) принципиальной разницы не играет. Поэтому ставим пакет HADR. # rpm -ih HADR-RedHat-2.4.18-14-4.4.2-3.i386.rpm Аналогично поставим пакеты:
[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 в вашей домашней директории.
В итоге программное обеспечение поставлено в директорию /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
Следующей нашей задачей будет создание ресурса для запуска веб-сервера 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
Как видите, я произвожу переключение кластера со второго узла, на который переедут ресурсы. $ nmap -v triton
Несколько слов о том, как перенести файлы с одного узла на другой средствами ПО самого кластера. Для этих целей существует утилита 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
Ошибок в ходе «переезда» не возникло. Единственное, что следует отметить – это прекращение срока деятельности лицензионного ключа. Впрочем, месяца на тестирование компонентов вполне должно хватить. Управлять кластером можно не только посредством GUI-приложения, но из-командной строки, а также окошка браузера. Впрочем, последнее не слишком сильно отличается от GUI-управления. Приведу несколько команд и их назначение. Для старта и остановки кластера LifeKeeper, GUI-приложения:
Мониторинг кластера:
Запуск ресурса на выполнение/остановку:
Команды для создания настроек коммуникационных путей:
Пример: 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 -d pc-box1 -a apache-tag app_list -d pc-box1 P.S. В брошюре, поставляемой с данным решением, прозвучало, что время простоя – около 50 минут в год. Будем надеяться, что это не только рекламный ход, но и действительно грамотное решение. Спасибо за поддержку сотрудникам Esko Wessman и Marko Lehtimaki из компании NordicMind, а также за техническую помощь сотрудникам Denise Hodges и Randy Hinz компании SteelEye.
|
АНТОН БОРИСОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
