Конфигурирование сервера высокой готовности для red hat Linux

Мы живем в мире, который существует по схеме 24х7, и во многих сферах бизнеса требуется непрерывная круглосуточная надежная обработка данных. Ряд производителей ОС UNIX выпускает сегодня собственные версии систем высокой готовности. Постепенный переход рынка на Linux вызывает соответствующий рост потребности в решениях высокой готовности на базе этой популярной реализации UNIX. В данной статье дается краткий обзор процесса конфигурирования сервера высокой готовности Red Hat High-Availability Server, он работает под управлением Rad Hat Linux 6.2 и поддерживает кластеризацию для миграции приложений и служб в случае отказов (failover) и баланса нагрузки (load balancing).

У термина "высокая готовность" (High Availability, HA) имеется множество определений. Общим во всех решениях высокой готовности является то, что они минимизируют время простоев системы. Однако способы достижения этой цели разные - от обеспечения отказоустойчивости на базе специализированных аппаратных решений до объединения в кластер стандартных компьютеров. Для поддержания высокой готовности кластеры компьютеров обычно задействуют механизм миграции приложений и служб при отказах (FailOver Server, FOS), при этом один компьютер (называемый сервером миграции, или резервным сервером) резервирует другой - первичный сервер. В нормальном режиме работы услуги резервируемых приложений и служб оказывает конечным пользователям первичный сервер.

Серверы кластера в конфигурации FOS используют два типа сетевых адресов. Для взаимной проверки, осуществляемой с помощью периодических тестовых сообщений (heartbeat) по внутренней сети, серверам назначаются частные адреса, а конечные пользователи обращаются к услугам серверов с помощью адресов общего назначения (public). Первоначально все адреса общего назначения присваиваются первичному серверу. В случае отказа первичного (аппаратного или программного) всю его работу берет на себя резервный сервер. Этот процесс прозрачен для конечного пользователя, так как сетевые адреса общего назначения мигрируют с первичного сервера на вторичный. Пользователь по-прежнему использует для соединения тот же адрес и не видит никаких изменений в обслуживании, так как на резервном сервере работают те же службы и приложения, что и на первичном, при этом доступны те же данные. Одним из примеров может служить сервер Web в конфигурации, когда два идентичных компьютера резервируют друг друга. Первичный и резервный серверы подключены к дисковому массиву RAID или другому типу системы хранения, например к системе хранения компании EMC. Конфигурация кластера высокой готовности, использующего механизм миграции, показана на Рисунке 1.

Для доступа клиентов из внешней сети используется так называемый виртуальный IP-адрес (Virtual IP, VIP). Все услуги, которые кластер оказывает своим пользователям, предоставляются с помощью этого адреса. Адрес VIP по мере необходимости может переходить от первичного сервера к резервному, и наоборот. Этот адрес всегда принадлежит активному серверу, так что пользователи направляют запросы только ему. При отказе первичного резервный сервер присваивает VIP одному из своих сетевых адаптеров, подключенных к общедоступной сети. Внутренняя сеть обычно используется для периодического взаимного мониторинга, в процессе которого один узел выясняет работоспособность других узлов кластера. Сеть для мониторинга и общедоступная сеть могут физически представлять собой одно и то же, а могут быть и различными.

Сервер высокой готовности Red Hat может применяться в двух различных конфигурациях. Первой является конфигурация для миграции служб и приложений при отказах (FOS), которая и описывается в данной статье, а второй - конфигурация виртуального сервера Linux (Linux Virtual Server, LVS). В конфигурации LVS сервер Red Hat используется для мониторинга и баланса нагрузки других серверов, работающих под управлением произвольной операционной системы.

ТРЕБОВАНИЯ К СИСТЕМЕ

Системные требования к серверу высокой готовности зависят от приложений или служб, которые будут работать на составляющих кластер компьютерах. Применение в кластере FOS двух идентичных компьютеров облегчает работу администратора, хотя это и не является обязательным требованием. Естественно, что процессор должен быть как можно более быстрым, а объем оперативной памяти - максимально возможным, при этом рекомендуемый минимальный объем памяти составляет 64 Мбайт. В документации Red Hat указан рекомендуемый объем дискового пространства для сервера высокой готовности в 1,2 Гбайт, однако мне понадобилось для инсталляции этого сервера всего 300 Мбайт. С моей точки зрения, этот объем можно еще уменьшить, приложив некоторые усилия. Но для приложений и данных может понадобиться дополнительное дисковое пространство.

УСТАНОВКА

?При покупке High-Availability Server у Red Hat вы получаете коробку с тремя CD и руководство по установке. Первый диск содержит дистрибутивы Red Hat Linux 6.2 и самого сервера Red Hat High-Availability Server. Это все, что нужно для инсталляции сервера, процедура которой хорошо описана в руководстве. По существу, она мало отличается от обычной установки Red Hat Linux на ПК или на сервер. Разница заключается в некоторых опциях и фоновых картинках. При запросе о типе установки (Install or Upgrade) нужно согласиться с предлагаемым по умолчанию ответом "Cluster Server". В остальном - это знакомый процесс инсталляции Linux, который коротко описан ниже.

Для начала установки вставьте первый компакт-диск в накопитель и перезагрузите компьютер. После рестарта начнется загрузка инсталлятора ОС Red Hat Linux 6.2. На этом этапе вы можете выбрать режим инсталляции. Я всегда выбираю режим Expert, так как он предоставляет наибольшую гибкость. Затем нужно выбрать параметры установки для языка, клавиатуры и мыши. После появления на экране заставки-приглашения в качестве типа устанавливаемого продукта следует выбрать Cluster Server. За этим следуют обычные этапы разбиения диска на разделы, выбор точек монтирования, форматирование разделов и т. д. Следующие этапы включают конфигурирование загрузчика lilo, выбор зоны времени и задание пароля для администратора. На последнем этапе Package Group Selection вы должны задать параметры пакетов приложений, которые хотели бы установить. Объем требуемого дискового пространства зависит от того, что вы выберете на этом этапе. Если необходимо установить все, то требования вырастут до 1,5 Гбайт. Для того чтобы сервер можно было в дальнейшем конфигурировать, используя интерфейс Web, необходимо установить сервер Apache Web и Netscape Communicator - оба продукта включены в инсталляционный компакт-диск и по умолчанию выбраны для установки.

Существуют и другие методы установки данного сервера, но самый простой связан с использованием загружаемого компакт-диска. Те, кто уже устанавливал Red Hat 6.2, не испытают никаких затруднений при установке сервера высокой готовности.

КОНФИГУРИРОВАНИЕ

После завершения инсталляции сервер высокой готовности надо сконфигурировать. Необходимое условие для этого - установленный и сконфигурированный стек TCP/IP как на первичном, так и на резервном серверах. Вы должны убедиться, что с каждого сервера команда ping успешно проходит по адресу другого сервера. Я использовал для первичного сервера частный IP-адрес 192.168.2.100, а для резервного - 192.168.2.200. Эти адреса служат для взаимного периодического тестирования серверов. После этого необходимо сконфигурировать оба сервера так, чтобы администратор (пользователь root) мог удаленно входить на другой сервер по команде rlogin без пароля. Всем остальным пользователям нужно запретить вход по этой команде. Первый шаг состоит в конфигурировании файлов /etc/hosts.allow и /etc/hosts.deny на обоих серверах. Например, на моем первичном сервере эти файлы выглядят следующим образом. В файле /etc/hosts.deny имеется только одна активная строка:

#
# Этот файл описывает имена хостов,
 которым не разрешено пользоваться
# локальными сервисами INET
#
ALL:  ALL

Эта строка запрещает доступ для всех хостов, за исключением тех, которые перечислены в файле /etc/hosts.allow, содержимое которого приведено ниже:

#
# Этот файл описывает имена хостов,
 которым разрешено пользоваться
# локальными сервисами INET
#
ALL:  192.168.2.200

Этот файл разрешает доступ хосту 192.168.2.200, который является резервным сервером кластера.

Затем в домашнем каталоге пользователя root нужно создать файл .rhosts на каждом из серверов. Это обеспечит для root удаленный доступ с любой из двух систем к другой без набора пароля. В простейшем случае в этот файл можно просто добавить имя второго сервера, входящего в кластер. Кроме того, необходимо отредактировать файл /etc/hosts, который отображает имена хостов на IP-адреса, чтобы обеспечить разрешение имен обоих серверов.

Файл /etc/lvs.cf управляет загрузкой кластера и определяет, какой из серверов является первичным. Прежде чем познакомиться с содержимым этого файла, рассмотрим пример файла /etc/lvs.cf, который я создал при тестировании кластера:

Primary = 192.168.2.100
Service = fos
rsh_command = rsh
backup_active = 1
backup = 192.168.2.200
heartbeat = 1
heartbeat_port = 539
keepalive = 6
deadtime = 18
network = direct
failover Web_Server {
address = 192.168.2.11 eth0:1
active = 1
port = 80
timeout = 6
send = "GET /HTTP/1.0

"
expect = "HTTP"
start_cmd = "/etc/rc.d/init.d/httpd start"
stop_cmd = "/etc/rc.d/init.d/httpd stop"
}

Первая часть этого файла (напечатанная без отступа) содержит общие конфигурационные данные - адреса для взаимной проверки (heartbeat) первичного и резервного серверов, тип сервера (в данном случае это сервер миграции приложений при отказах - fos), номера портов взаимной проверки и тайм-ауты работоспособного состояния (keepalive). Во второй части содержатся параметры, определяющие миграцию при отказе сервера Web, использующего порт 80. Параметры показывают, что сервер Web настроен на адрес 192.168.2.11, который принадлежит интерфейсу eth0:1. Это виртуальный IP-адрес, о котором клиенты узнают от службы DNS. Во время тестирования я использовал только один сетевой интерфейс, но я настоятельно рекомендую использовать для взаимной проверки в реальных ситуациях отдельные сетевые интерфейсы. Для всех внешних пользователей общедоступным IP-адресом сервера Web является адрес 192.168.2.11, который изначально конфигурируется на первичном сервере. Если на первичном сервере происходит сбой, то резервный сервер обнаруживает это событие с помощью взаимной проверки, присваивает этот же адрес своему интерфейсу eth0:1 и запускает сервер Web. Как показано, конфигурационный файл содержит командные строки для старта и остановки этого сервера.

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

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

/etc/rc.d/init.d/pulse start

При внесении изменений в конфигурационный файл он должен быть скопирован на все компьютеры кластера.

При работающем кластере всегда можно получить информацию об имеющихся адаптерах Ethernet и сконфигурированных IP-адресах с помощью команды ifconfig -a. Ответ на такую команду может иметь следующий вид:

eth0	Link	encap:Ethernet
	Hwaddr	00:E0:29:89:28:59
inet	addr:192.168.2.100
	Bcast:192.168.2.255
Mask:255.255.255.0
Inet6	addr:fe80::e0:2989:2859/10
	Scope:Link
UP	BROADCAST RUNNING	MULTICAST
	MTU:1500	Metric:1
RX	packets:1389  errors:0  dropped:0
  overruns:0  frame:0
TX	packets:2891  errors:0  dropped:0
  overruns:0  carrier:0
collisions:5  txqueuelen:100
Interrupt:11  Base  address:0xe800
eth0:1	Link	encap:Ethernet
	Hwaddr	00:E0:29:89:28:59
inet	addr:192.168.2.11
	Bcast:192.168.2.255
Mask:255.255.255.0
UP	BROADCAST RUNNING	MULTICAST
	MTU:1500	Metric:1
Interrupt:11  Base  address:0xe800
lo	Link	encap:Local  Loopback
inet	addr:127.0.0.1	Mask:255.0.0.0
Inet6	addr: ::1/128	Scope:Host
UP	LOOPBACK RUNNING	MTU:3924
	Metric:1
RX	packets:1408  errors:0  dropped:0
  overruns:0  frame:0
TX	packets:1408  errors:0  dropped:0
  overruns:0  carrier:0
collisions:5  txqueuelen:100

Интерфейс eth0:1 становится активным, как только один из узлов начинает выполнять роль первичного сервера.

ИСПОЛЬЗОВАНИЕ ИНТЕРФЕЙСА WEB ДЛЯ КОНФИГУРИРОВАНИЯ КЛАСТЕРА

Рисунок 2. Начальный экран средств конфигурирования с помощью интерфейса Web.

Все удобство процесса конфигурирования заключается в том, что при использовании интерфейса Web он оказывается очень простым, даже для не очень опытного администратора. Приведенный выше конфигурационный файл /etc/lvs.cf создан не вручную. Я применил интерфейс Web, который сгенерировал файл автоматически. Для этого необходимо запустить Netscape Communicator и перейти к следующему URL:

http://localhost/piranha

В окне вашего браузера появится картинка, похожая на ту, которая показана на Рисунке 2. С помощью этого экрана нужно выполнить логический вход в систему администрирования кластера. Для этого используется имя piranha и пароль, который создается командой:

/usr/sbin/piranha  -passwd   

Рисунок 3. Главный экран средств конфигурирования с помощью интерфейса Web.

После входа в систему на экране появляется главное окно конфигурирования (см. Рисунок 3), в котором нужно определить адреса для процесса взаимного тестирования и другие конфигурируемые адреса для обоих серверов. Необходимо также указать службы и приложения, которые должны мигрировать в случае отказа. С помощью четырех ссылок, помещенных под закладкой CONTROL/MONITORING ("Управление/Мониторинг") можно изменить различные установки кластера. Я надеюсь, что вам будут полезны эти советы по конфигурации.