Language:
Format:

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Администрирование кластера

Red Hat Enterprise Linux 6

Red Hat High Availability

Редакция 0

Юридическое уведомление

Аннотация

В этом документе рассматривается настройка и управление комплектом высокой готовности в Red Hat Enterprise Linux 6.

Введение

В этом документе приведена информация об установке, настройке и управлении компонентами комплекта высокой степени готовности (Red Hat High Availability), который позволяет объединить группу компьютеров (так называемых узлов) в кластер. В рамках этого руководства подразумевается, что в кластере выполняются программы Red Hat High Availability.

Материал ориентирован на системных администраторов с опытом работы с Red Hat Enterprise Linux, знакомых с концепциями кластеров и серверных вычислений.

Информация о Red Hat Enterprise Linux 6 может быть найдена в следующих руководствах:

Руководство по установке Red Hat Enterprise Linux 6.
Руководство по развертыванию предоставляет информацию по установке, настройке и администрированию Red Hat Enterprise Linux 6.

Информацию о Red Hat High Availability и других продуктах Red Hat Enterprise Linux 6 можно найти в следующих документах:

Обзор комплекта Red Hat High Availability.
Администрирование LVM содержит информацию об управлении логическими томами (LVM, Logical Volume Manager), в том числе о работе LVM в кластерном окружении.
Администрирование GFS2 предоставляет информацию об установке, настройке и поддержке Red Hat GFS2 (Global File System 2).
DM Multipath предоставляет информацию о многопутевых возможностях Red Hat Enterprise Linux.
Распределение нагрузки предоставляет информацию о настройке высокопроизводительных систем и служб с помощью комплекта распределения нагрузки.
Примечания к выпуску содержат краткий обзор последнего выпуска Red Hat.

Полный диапазон документов Red Hat доступен в виде HTML, PDF и RPM на диске документации Red Hat Enterprise Linux и на сайте http://docs.redhat.com/docs/en-US/index.html.

1. Отзывы и предложения

Если вы нашли опечатку, или у вас есть предложения по усовершенствованию руководства, создайте запрос в Bugzilla для компонента doc-Cluster_Administration.

Укажите код:

Cluster_Administration(EN)-6 (2013-2-15T16:26)

Он идентифицирует эту версию руководства.

Подробно опишите свои предложения. Для облегчения поиска ошибок и опечаток укажите номер раздела и окружающий текст.

Глава 1. Обзор

Red Hat High Availability позволяет объединить группу компьютеров (так называемых узлов) в кластер. Кластер помогает облегчить организацию совместного доступа к файлам в GFS2 и решить задачи обеспечения отказоустойчивости служб.

Примечание

Информацию о создании кластеров Red Hat Enterprise Linux на основе Red Hat Global File System 2 (GFS2) и High Availability можно найти в статье «Основные приемы развертывания кластера Red Hat Enterprise Linux, комплекта High Availability и GFS2» по адресу https://access.redhat.com/kb/docs/DOC-40821.

В этой главе приведен список основных изменений функциональности комплекта Red Hat High Availability с тех пор, как он был впервые представлен в Red Hat Enterprise Linux 6.

1.1. Основные изменения

Далее рассматриваются новые и измененные характеристики комплекта Red Hat High Availability.

1.1.1. Red Hat Enterprise Linux 6.1

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.1.

Реализована функциональность ловушек SNMP (см. Глава 10, Настройка SNMP).
Добавлена команда ccs (см. Глава 5, Настройка кластера с помощью ccs , Глава 6, Управление кластером с помощью ccs).
Обновлена документация Conga.
Начиная с Red Hat Enterprise Linux 6.1 при выполнении ricci требуется ввести пароль при копировании изменений конфигурации кластера с определенного узла (см. Раздел 2.13, «ricci»).
Добавлено правило восстановления под названием Restart-Disable: попытка перезапуска службы с последующим отключением в случае неудачи (см. Раздел 3.10, «Добавление службы в кластер», Приложение B, Параметры ресурсов).
Структуру ресурсов можно настроить как некритическую, то есть в случае сбоя ресурса будет отключен только этот ресурс (см. Раздел 3.10, «Добавление службы в кластер», Раздел C.4, «Восстановление и независимые деревья»).
Добавлена Глава 9, Диагностика и решение конфликтов в кластере.

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

1.1.2. Red Hat Enterprise Linux 6.2

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.2.

Добавлена поддержка кластерных схем Samba (см. Глава 11, Кластерная конфигурация Samba).
Для авторизации можно использовать данные любого пользователя системы, где установлено приложение luci, но начиная с Red Hat Enterprise Linux 6.2 изначально только root обладает правами доступа к компонентам luci. Раздел 3.3, «Управление доступом к luci» содержит информацию о предоставлении разрешений другим пользователям.
Взаимодействие узлов кластера может осуществляться с помощью одноадресной передачи UDP (см. Раздел 2.12, «Одноадресная передача UDP»).
Некоторые характеристики luci (например, IP-адрес для доступа к luci) можно определить напрямую в файле /etc/sysconfig/luci (см. Таблица 2.2, «Открытые порты на компьютере с работающим процессом luci», Раздел 2.4, «/etc/sysconfig/luci»).
Команда ccs теперь включает параметры --lsfenceopts для вывода доступных устройств изоляции и --lsfenceopts тип для вывода типов изоляции (см. Раздел 5.6, «Список устройств и их параметров»).
ccs теперь включает параметры --lsserviceopts для вывода списка доступных кластерных служб и --lsserviceopts тип для вывода параметров для выбранного типа службы (см. Раздел 5.11, «Получение списка доступных служб»).
Добавлена поддержка агента VMware SOAP (см. Приложение A, Параметры устройств изоляции).
Добавлена поддержка агента RHEV-M REST API для RHEV 3.0+ (см. Приложение A, Параметры устройств изоляции).
При настройке виртуальных машин в кластере теперь можно использовать ccs c аргументом --addvm вместо addservice. Это позволяет разместить определение vm в файле конфигурации сразу под rm (см. Раздел 5.12, «Ресурсы виртуальных машин»).
Добавлено Приложение D, Проверка ресурсов кластерных служб и ожидание восстановления, где рассказывается о наблюдении за состоянием кластерных ресурсов и изменении интервала ожидания ответа.
Раздел 2.3.3, «Настройка правил iptables» содержит информацию о фильтрации трафика при помощи iptables.

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

1.1.3. Red Hat Enterprise Linux 6.3

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.3.

Добавлена поддержка агента ресурсов condor (см. Приложение B, Параметры ресурсов).
Добавлено Приложение F, HA-LVM.
Добавлены уточнения о необходимости перезапуска кластера при изменении конфигурации (см. Раздел 9.1, «Изменения конфигурации не вступают в силу»).
Добавлено примечание о завершении неактивного сеанса luci после 15 минут (см. Раздел 3.2, «Запуск luci»).
Добавлен параметр privlvl для fence_ipmilan (см. Приложение A, Параметры устройств изоляции).
Добавлен Раздел 2.14, «Виртуальные машины в кластере».
Добавлен Раздел 4.6, «Создание резервной копии и восстановление конфигурации luci».
Добавлен Раздел 9.4, «Сбой rgmanager».
Раздел 5.14.4, «Ведение журналов», Раздел 7.7, «Ведение журналов» и Раздел 9.13, «Журналирование для DLM» рассказывают о журналах и параметрах отладки.
В Red Hat Enterprise Linux 6.3 пользователь root и администраторы luci получили возможности добавления пользователей в окне интерфейса luci (см. Раздел 3.3, «Управление доступом к luci»).
При создании файла конфигурации с помощью ccs его формат проверяется в соответствии со схемой в /usr/share/cluster/cluster.rng на узле, который задан параметром -h, в то время как раньше использовалась встроенная схема из /usr/share/ccs/cluster.rng (см. Раздел 5.1.6, «Проверка формата»).
Приложение A, Параметры устройств изоляции и Приложение B, Параметры ресурсов теперь включают соответствующие имена параметров в cluster.conf.

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

1.1.4. Red Hat Enterprise Linux 6.4

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.4.

Добавлена поддержка агентов изоляции на основе контроллеров Eaton (SNMP), HP Bladesystem и IBM iPDU (см. Приложение A, Параметры устройств изоляции).
Приложение B, Параметры ресурсов теперь содержит описание агента ресурсов NFS-сервера.
Пользователь root и администраторы luci получили возможности удаления пользователей в окне интерфейса luci (см. Раздел 3.3, «Управление доступом к luci»).
Приложение B, Параметры ресурсов содержит описание нового параметра nfsrestart.
Добавлен новый Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки».
Раздел 2.3, «Доступ к портам IP» включает информацию о фильтрации igmp при помощи iptables.
Агент изоляции LAN IPMI теперь использует параметр для настройки уровня привилегий для устройства IPMI (см. Приложение A, Параметры устройств изоляции).
Добавлена поддержка режимов агрегации 0 и 2. Подсказка при диагностике конфликтов предлагает убедиться в том, что выбран один из поддерживаемых режимов.
Устройства VLAN теперь могут принимать участие в обмене сообщениями подтверждения соединения.
Red Hat High Availability теперь поддерживает возможности настройки протокола избыточного кольца. Раздел 7.6, «Настройка протокола избыточного кольца» содержит информацию о его настройке в файле cluster.conf, Раздел 3.5.4, «Настройка протокола избыточного кольца» — при помощи luci, а Раздел 5.14.5, «Настройка протокола избыточного кольца» — при помощи ccs.

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

1.2. Обзор конфигурации

Этапы настройки кластера:

Раздел 1.3, «Подготовка оборудования»
Раздел 1.4, «Установка программ Red Hat High Availability»
Раздел 1.5, «Настройка программ Red Hat High Availability»

1.3. Подготовка оборудования

Подготовка подразумевает подключение оборудования, необходимого для работы комплекта Red Hat High Availability. Ниже перечислены устройства, которые потребуются для создания кластера (см. Рисунок 1.1, «Схема оборудования»). Глава 2, Подготовка системы содержит дополнительную информацию.

Узлы кластера — компьютеры с Red Hat Enterprise Linux 6 и как минимум 1 ГБ ОЗУ.
Для доступа клиентов к кластеру потребуется коммутатор Ethernet или концентратор для открытой сети.
Для взаимодействия оборудования и узлов кластера потребуется коммутатор Ethernet или концентратор для закрытой сети.
Для изоляции неисправных узлов рекомендуется использование сетевого коммутатора питания.
Коммутатор Fibre Channel контролирует доступ к хранилищу Fibre Channel. В зависимости от типа интерфейса могут быть доступны другие варианты, например iSCSI.
Тип хранилища зависит от того, для каких целей предназначен кластер.

Рисунок 1.1. Схема оборудования

1.4. Установка программ Red Hat High Availability

Для установки комплекта высокой готовности необходимы соответствующие разрешения доступа. При наличии luci кластерные программы можно будет установить из его интерфейса. Если конфигурация кластера осуществляется с помощью других инструментов, установка кластерных программ выполняется аналогично установке других программ Red Hat Enterprise Linux.

Следующая команда установит кластерные программы:

# yum install rgmanager lvm2-cluster gfs2-utils

Даже если устанавливается только rgmanager, из канала HighAvailability будут получены все необходимые для создания кластера пакеты. Некоторые пакеты, такие как lvm2-cluster и gfs2-utils, входят в состав канала ResilientStorage и могут не требоваться.

1.4.1. Обновление программ

При обновлении версии Red Hat Enterprise Linux программы кластера можно обновить без необходимости остановки кластера. Для этого требуется лишь остановить, обновить и перезапустить программы поочередно на каждом узле.

Остановите работу служб кластера (см. Раздел 8.1.2, «Остановка кластерных программ»). В некоторых случаях может быть рекомендовано перенести кластерные службы и виртуальные машины на другой узел и уже после этого остановить rgmanager.
Обновите пакеты с помощью yum update.
Перезапустите службы или перезагрузите узел (см. Раздел 8.1.1, «Запуск кластерных программ»).

1.5. Настройка программ Red Hat High Availability

Настройка комплекта Red Hat High Availability осуществляется с помощью специальных утилит:

Conga — графический интерфейс для установки, настройки и управления комплектом (см. Глава 3, Настройка кластера в Conga и Глава 4, Управление кластером с помощью Conga).
Команда ccs (см. Глава 5, Настройка кластера с помощью ccs , Глава 6, Управление кластером с помощью ccs).
Программы командной строки (см. Глава 7, Настройка кластера в командной строке, Глава 8, Управление кластером в командной строке, Приложение E, Обзор команд).

Примечание

RHEL 6 не включает в свой состав system-config-cluster.

Глава 2. Подготовка системы

В этой главе рассматриваются задачи подготовки системы к установке комплекта Red Hat High Availability.

Важно

До ввода комплекта в эксплуатацию рекомендуется проконсультироваться с представителем Red Hat на предмет соответствия конфигурации системы требованиям.

Раздел 2.1, «Общие требования»
Раздел 2.2, «Совместимость оборудования»
Раздел 2.3, «Доступ к портам IP»
Раздел 2.4, «/etc/sysconfig/luci»
Раздел 2.5, «ACPI и интегрированные устройства изоляции»
Раздел 2.6, «Особенности настройки служб высокой готовности»
Раздел 2.7, «Валидация cluster.conf»
Раздел 2.8, «NetworkManager»
Раздел 2.9, «Диск кворума»
Раздел 2.10, «SELinux»
Раздел 2.11, «Многоадресная рассылка»
Раздел 2.12, «Одноадресная передача UDP»
Раздел 2.13, «ricci»
Раздел 2.14, «Виртуальные машины в кластере»

2.1. Общие требования

Существует несколько вариантов конфигурации комплекта. Ниже перечислены характеристики, которые нужно учесть при планировании кластерной структуры.

Число узлов: Максимально допустимое число узлов — 16.
Локальные кластеры: Распределенные кластеры пока не поддерживаются. Подробную информацию можно запросить у представителя Red Hat.
GFS2: GFS2 может быть создана отдельно в одной системе или как часть кластерной структуры, но Red Hat Enterprise Linux не поддерживает GFS2 в отдельных системах. Red Hat поддерживает целый набор высокопроизводительных файловых систем, специально предназначенных для работы на индивидуальных узлах, поэтому при наличии лишь одного узла рекомендуется использовать их, а не GFS2.
При настройке кластерной GFS2 необходимо обеспечить доступ всех узлов к файловой системе. Структуры, где одни узлы имеют доступ к файловой системе, а другие — нет, не поддерживаются. При этом не требуется, чтобы GFS2 была смонтирована на абсолютно всех узлах.
Отказоустойчивая структура: Кластеры могут включать RAID-массивы с двумя контроллерами, объединенные сетевые каналы, разные пути подключения узлов к хранилищу и избыточные UPS с целью повышения отказоустойчивости.
При необходимости снижения себестоимости кластера можно исключить избыточные компоненты, но это сделает его более уязвимым.
Некоторые экономичные решения (RAID-контроллеры хоста, программные RAID без кластерной поддержки, многоинициаторные SCSI-конфигурации) несовместимы или не могут использоваться в качестве общего хранилища.
Целостность данных: Чтобы обеспечить целостность данных, необходимо, чтобы кластерные службы выполнялись только на одном узле. При наличии переключателя питания в кластере можно будет подключить другой узел и перезапустить на нем службы. Это позволяет предотвратить одновременное обращение двух узлов в одним и тем же данным. Для поддержки целостности данных используются так называемые устройства изоляции — физические устройства или программные решения для удаленной перезагрузки и отключения узлов.
Агрегация каналов Ethernet: Кворум кластера и статус узлов определяется в ходе обмена сообщениями между узлами через Ethernet. Агрегация каналов позволяет использовать несколько интерфейсов Ethernet как один, что исключает уязвимость при сбое одного интерфейса.
Red Hat Enterprise Linux 6.4 поддерживает режимы агрегации 0, 1 и 2.
IPv4 и IPv6: Комплект высокой готовности поддерживает протоколы IPv4 и IPv6.

2.2. Совместимость оборудования

Перед началом настройки программ Red Hat High Availability необходимо убедиться, что для организации кластера используется совместимое оборудование (устройства изоляции, хранилище, коммутаторы Fibre Channel). Информацию о совместимом оборудовании можно найти на http://www.redhat.com/cluster_suite/hardware/.

2.3. Доступ к портам IP

Прежде чем ввести Red Hat High Availability в эксплуатацию, необходимо открыть порты на узлах кластера и на компьютерах, где будет работать luci (интерфейс пользователя Conga):

Раздел 2.3.1, «Доступ к портам IP на узлах кластера»
Раздел 2.3.2, «Порт для luci»

Следующий раздел содержит информацию о правилах iptables для активации портов, необходимых для нормальной работы Red Hat High Availability:

Раздел 2.3.3, «Настройка правил iptables»

2.3.1. Доступ к портам IP на узлах кластера

Для взаимодействия узлов кластера друг с другом потребуется открыть порты (см. Таблица 2.1, «Открытые порты»). Активация портов на каждом узле осуществляется с помощью system-config-firewall.

Таблица 2.1. Открытые порты

Порт	Протокол	Компонент
5404, 5405	UDP	`corosync/cman`
11111	TCP	`ricci`
21064	TCP	`dlm` (Distributed Lock Manager)
16851	TCP	`modclusterd`

2.3.2. Порт для luci

Чтобы клиенты могли подключаться к машине, где выполняется luci (интерфейс пользователя Conga), необходимо открыть порт 8084 (см. Таблица 2.2, «Открытые порты на компьютере с работающим процессом luci»).

Примечание

Если служба luci выполняется на узле кластера, необходимо дополнительно открыть порт 11111.

Таблица 2.2. Открытые порты на компьютере с работающим процессом luci

Порт	Протокол	Компонент
8084	TCP	luci

В Red Hat Enterprise Linux 6.1 стало разрешено определять параметры конфигурации в файле /etc/sysconfig/luci, где можно изменить порт обслуживания luci. Этот подход является оптимальным при наличии нескольких сетей, если вы хотите разрешить доступ к luci только из локальной сети. Для этого снимите комментарий со строки host и откорректируйте ее. Пример:

host = 10.10.10.10

Раздел 2.4, «/etc/sysconfig/luci» содержит информацию о /etc/sysconfig/luci.

2.3.3. Настройка правил iptables

Ниже приведены правила активации портов для Red Hat High Availability. Адрес подсети (192.168.1.0/24) следует заменить подходящим значением.

Для cman:

$ iptables -I INPUT -m state --state NEW -m multiport -p udp -s 192.168.1.0/24 -d 192.168.1.0/24 --dports 5404,5405 -j ACCEPT
$ iptables -I INPUT -m addrtype --dst-type MULTICAST -m state --state NEW -m multiport -p udp -s 192.168.1.0/24 --dports 5404,5405 -j ACCEPT

Для dlm:

$ iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 21064 -j ACCEPT

Для ricci:

$ iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 11111 -j ACCEPT

Для modclusterd:

$ iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 16851 -j ACCEPT

Для luci:

$ iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 16851 -j ACCEPT

Для igmp:

$ iptables -I INPUT -p igmp -j ACCEPT

После настройки правил следует их сохранить и перезапустить службу.

$ service iptables save ; service iptables restart

2.4. `/etc/sysconfig/luci`

Начиная с Red Hat Enterprise Linux 6.1 некоторые параметры luci можно определить в файле /etc/sysconfig/luci. Так, здесь можно изменить параметры окружения, используемые сценарием init, и конфигурацию сервера. Сам файл содержит инструкции и комментарии.

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

Ниже приведен пример изменения порта обслуживания luci.

Снимите комментарий со строки:
```
#port = 4443
```
Измените номер порта (должен быть больше 1024), например:
```
port = 8084
```
Перезапустите luci.

Важно

После изменения значения в /etc/sysconfig/luci необходимо убедиться, что новое значение будет использоваться по умолчанию. Так, например, изменив порт обслуживания luci, надо соответственно изменить номер при активации порта (см. Раздел 2.3.2, «Порт для luci»).

При запуске службы luci изменения будут автоматически отражены в URL (см. Раздел 3.2, «Запуск luci»). Этот адрес и будет использоваться для доступа к luci.

Дальнейшую информацию можно найти в самом файле /etc/sysconfig/luci.

2.5. ACPI и интегрированные устройства изоляции

Если в кластере используются интегрированные устройства изоляции, необходимо настроить ACPI (Advanced Configuration and Power Interface) для отключения питания узла.

Примечание

Информацию о совместимых устройствах можно найти на http://www.redhat.com/cluster_suite/hardware/.

Если для изоляции узла используется подобное устройство, для него следует отключить функцию ACPI Soft-Off, что позволит немедленно его отключить вместо последовательного завершения работы (shutdown -h now). При включенной функции ACPI Soft-Off отключение узла может занять несколько секунд (см. примечание). Если ACPI Soft-Off включена, но узел завис при выключении, устройство изоляции не сможет его отключить. В этих условиях отключение будет отложено или даже завершится неудачей. Соответственно восстановление кластера в такой ситуации будет происходить медленно и может требовать вмешательства администратора.

Примечание

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

Для отключения ACPI Soft-Off рекомендуется использовать chkconfig. Существуют и другие методы:

Изменение поведения кнопки питания в BIOS на "instant-off", что означает немедленное отключение.
Примечание
Отключение ACPI Soft-Off в BIOS на некоторых компьютерах может быть недоступно.
Добавление параметра acpi=off в команду загрузки ядра в файле /boot/grub/grub.conf.
Важно
Этот метод полностью отключает ACPI, что может нарушить процесс загрузки некоторых компьютеров. Его следует использовать только в случаях, если остальные способы неэффективны.

Далее методы отключения ACPI Soft-Off будут рассмотрены подробно:

Раздел 2.5.1, «Отключение ACPI Soft-Off с помощью chkconfig» (предпочтительно).
Раздел 2.5.2, «Отключение ACPI Soft-Off в BIOS» (дополнительно).
Раздел 2.5.3, «Отключение ACPI в grub.conf» (дополнительно).

2.5.1. Отключение ACPI Soft-Off с помощью `chkconfig`

Чтобы отключить ACPI Soft-Off, можно выключить процесс acpid или удалить его из списка служб под управлением chkconfig.

Примечание

Этот метод является предпочтительным.

Порядок отключения ACPI Soft-Off на каждом узле:

Выполните:
- chkconfig --del acpid (удаляет acpid из списка служб под управлением chkconfig)
  ИЛИ
- chkconfig --level 2345 acpid off (отключает acpid).
Перезагрузите узел.
После настройки и запуска кластера убедитесь, что в результате процедуры изоляции узел немедленно отключается.
Примечание
Процесс изоляции узла можно инициировать из интерфейса Conga или с помощью команды fence_node.

2.5.2. Отключение ACPI Soft-Off в BIOS

Для отключения ACPI Soft-Off рекомендуется использовать chkconfig (см. Раздел 2.5.1, «Отключение ACPI Soft-Off с помощью chkconfig»). Если этот метод не подходит, доступны другие варианты.

Примечание

Отключение ACPI Soft-Off в BIOS на некоторых компьютерах может быть недоступно.

Порядок отключения ACPI Soft-Off в BIOS на каждом узле:

Перезагрузите компьютер и войдите в BIOS.
Перейдите в меню настройки питания.
Измените значение Soft-Off by PWR-BTTN на Instant-Off (или его эквивалент для немедленного выключения компьютера при нажатии кнопки питания). Пример 2.1, «Параметр Soft-Off by PWR-BTTN в BIOS установлен в Instant-Off» демонстрирует установленные значения ACPI Function и Soft-Off by PWR-BTTN.
Примечание
В разных BIOS названия параметров ACPI Function, Soft-Off by PWR-BTTN, and Instant-Off могут отличаться. Цель этой процедуры — настроить BIOS таким образом, чтобы компьютер выключался сразу же после нажатия кнопки питания.
Сохраните изменения и выйдите из BIOS.
После настройки и запуска кластера убедитесь, что в результате процедуры изоляции узел немедленно отключается.
Примечание
Процесс изоляции узла можно инициировать из интерфейса Conga или с помощью команды fence_node.

Пример 2.1. Параметр Soft-Off by PWR-BTTN в BIOS установлен в Instant-Off

+---------------------------------------------|-------------------+
|    ACPI Function             [Enabled]      |    Item Help      |
|    ACPI Suspend Type         [S1(POS)]      |-------------------|
|  x Run VGABIOS if S3 Resume   Auto          |   Menu Level   *  |
|    Suspend Mode              [Disabled]     |                   |
|    HDD Power Down            [Disabled]     |                   |
|    Soft-Off by PWR-BTTN      [Instant-Off   |                   |
|    CPU THRM-Throttling       [50.0%]        |                   |
|    Wake-Up by PCI card       [Enabled]      |                   |
|    Power On by Ring          [Enabled]      |                   |
|    Wake Up On LAN            [Enabled]      |                   |
|  x USB KB Wake-Up From S3     Disabled      |                   |
|    Resume by Alarm           [Disabled]     |                   |
|  x  Date(of Month) Alarm       0            |                   |
|  x  Time(hh:mm:ss) Alarm       0 :  0 :     |                   |
|    POWER ON Function         [BUTTON ONLY   |                   |
|  x KB Power ON Password       Enter         |                   |
|  x Hot Key Power ON           Ctrl-F1       |                   |
|                                             |                   |
|                                             |                   |
+---------------------------------------------|-------------------+

Параметру ACPI Function присвоено значение Enabled, а Soft-Off by PWR-BTTN — Instant-Off.

2.5.3. Отключение ACPI в `grub.conf`

Для отключения ACPI Soft-Off рекомендуется использовать chkconfig (см. Раздел 2.5.1, «Отключение ACPI Soft-Off с помощью chkconfig») . Если этот метод не подходит, можно отключить ACPI Soft-Off в разделе управления питанием BIOS (см. Раздел 2.5.2, «Отключение ACPI Soft-Off в BIOS»). В случае неэффективности этих методов можно полностью отключить ACPI, добавив acpi=off в строку параметров ядра в файле grub.conf.

Важно

Этот метод полностью отключает ACPI, что может нарушить процесс загрузки некоторых компьютеров. Его следует использовать только в случаях, если остальные способы неэффективны.

ACPI можно отключить, отредактировав grub.conf на всех узлах кластера:

Откройте /boot/grub/grub.conf в текстовом редакторе.
Добавьте acpi=off в команду загрузки ядра (см. Пример 2.2, «Команда загрузки ядра с параметром acpi=off»).
Перезагрузите узел.
После настройки и запуска кластера убедитесь, что в результате процедуры изоляции узел немедленно отключается.
Примечание
Процесс изоляции узла можно инициировать из интерфейса Conga или с помощью команды fence_node.

Пример 2.2. Команда загрузки ядра с параметром acpi=off

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/mapper/vg_doc01-lv_root 
#          initrd /initrd-[generic-]version.img
#boot=/dev/hda
default=0
timeout=5
serial --unit=0 --speed=115200
terminal --timeout=5 serial console
title Red Hat Enterprise Linux Server (2.6.32-193.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-193.el6.x86_64 ro root=/dev/mapper/vg_doc01-lv_root console=ttyS0,115200n8 acpi=off
        initrd /initramrs-2.6.32-131.0.15.el6.x86_64.img

В этом примере в строке, начинающейся с "kernel /vmlinuz-2.6.32-193.el6.x86_64.img", добавлен параметр acpi=off.

2.6. Особенности настройки служб высокой готовности

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

При создании службы высокой готовности необходимо настроить ее в файле конфигурации кластера. Такая служба включает ресурсы кластера — структурные единицы, настраиваемые в файле конфигурации (адреса IP, сценарии инициализации приложений, общие разделы Red Hat GFS2).

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

Рисунок 2.1, «Пример кластерной службы веб-сервера» демонстрирует схему под названием «content-webserver». Служба запущена на узле B в домене, который включает узлы A, B, D. Узел D имеет более высокий приоритет по сравнению с A. Выбор запасного узла ограничивается пределами домена. Служба охватывает следующие ресурсы:

IP-адрес 10.10.10.201.
Приложение "httpd-content": сценарий инициализации веб-сервера /etc/init.d/httpd (httpd).
Файловая система Red Hat GFS2 под названием "gfs2-content-webserver".

Рисунок 2.1. Пример кластерной службы веб-сервера

Клиенты обращаются к службе по адресу 10.10.10.201. Приложение httpd-content использует файловую систему gfs-content-webserver. Если узел B перестает функционировать, работа службы будет восстановлена на узле D. Если D недоступен, будет выполнен переход на узел A. Как следствие, перерывы в работе клиентов будут минимальны. Так, в приведенном примере может быть потеряна информация о состоянии (данные текущего сеанса). После восстановления на другом узле служба будет доступна по тому же адресу.

Примечание

Глава 3, Настройка кластера в Conga и Глава 7, Настройка кластера в командной строке содержат информацию о настройке резервных доменов.

Служба высокой готовности объединяет в своем составе группу кластерных ресурсов. В файле /etc/cluster/cluster.conf эта структура представлена в виде дерева ресурсов в формате XML.

Примечание

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

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

При настройке групп ресурсов следует принять во внимание:

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

Типы ресурсов и иерархия зависят от типа настраиваемой службы.

Приложение B, Параметры ресурсов и Приложение C, Поведение ресурсов высокой готовности содержат дальнейшую информацию.

2.7. Валидация cluster.conf

Проверка конфигурации осуществляется автоматически во время запуска кластера и перезагрузки конфигурации в соответствии с определениями в /usr/share/cluster/cluster.rng. Дополнительно проверку можно выполнить с помощью ccs_config_validate и ccs (см. Раздел 5.1.6, «Проверка формата»).

/usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html) содержит пример схемы с комментариями.

Будет проверено следующее:

структура XML;
параметры конфигурации;
значения параметров.

Ниже приведено несколько примеров:

Пример 2.3, «Пример неверного файла cluster.conf»;
Пример 2.4, «Пример неверной структуры XML в cluster.conf»;
Пример 2.5, «Пример неверного параметра в cluster.conf»;
Пример 2.6, «Пример неверного значения в cluster.conf».

Пример 2.3. Пример неверного файла cluster.conf


<cluster name="mycluster" config_version="1">
  <logging debug="off"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Пример 2.4. Пример неверной структуры XML в cluster.conf


<cluster name="mycluster" config_version="1">
  <logging debug="off"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
<cluster>         <----------------ОШИБКА

В последней строке должен быть закрывающий тег </cluster>.

Пример 2.5. Пример неверного параметра в cluster.conf


<cluster name="mycluster" config_version="1">
  <loging debug="off"/>         <----------------ОШИБКА
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
<cluster>

Ошибка во второй строке: опечатка в имени параметра logging (указано loging).

Пример 2.6. Пример неверного значения в cluster.conf


<cluster name="mycluster" config_version="1">
  <loging debug="off"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="-1">  <--------ОШИБКА
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
<cluster>

Неверное значение параметра nodeid в четвертой строке: он не может принимать отрицательные значения.

2.8. NetworkManager

Выполнение NetworkManager на узлах кластера не поддерживается. Для корректной работы узла потребуется его удалить или отключить.

Примечание

При наличии NetworkManager процесс cman будет невозможно запустить.

2.9. Диск кворума

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

Примечание

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

Важно

Поведение qdiskd можно изменить в соответствии с индивидуальными требованиями. Подробную информацию можно найти на справочной странице qdisk(5). За помощью рекомендуется обратиться к официальному представителю службы технической поддержки Red Hat.

Ниже перечислены основные характеристики, которые нужно учесть при организации кластера с qdiskd.

Число голосов: Каждый узел должен иметь один голос.
Время ожидания CMAN: Время ожидания ответа узла, по истечении которого узел будет исключен из кластера. Обычно это значение как минимум в два раза больше времени ожидания qdiskd, но при необходимости может быть изменено. Дело в том, что qdiskd должен самостоятельно определять сбойные узлы, что может занять больше времени по сравнению с аналогичными операциями CMAN. По умолчанию время ожидания CMAN равно 10 секундам. За помощью при определении оптимального значения рекомендуется обратиться к официальному представителю службы технической поддержки Red Hat.
Отключение узлов: При необходимости изоляции узла в кластере с qdiskd рекомендуется предпочесть метод отключения питания в силу его надежности.
Максимальное число узлов: Кластер с qdiskd может содержать до 16 узлов. Ограничение объясняется сложностями масштабирования при увеличении числа узлов, так как при этом возрастает риск конфликтов ввода-вывода на общем диске кворума.
Диск кворума: Диск кворума представляет собой общее устройство с параллельным доступом чтения и записи для всех узлов. Минимальный размер — 10 МБ. Примерами устройств, на основе которых можно создать диск кворума, являются многопортовый RAID-массив SCSI, Fibre Channel RAID SAN и цель iSCSI. Создать диск кворума можно с помощью mkqdisk. Подробную информацию можно найти на справочной странице mkqdisk(8).
Примечание
В качестве диска кворума не рекомендуется использовать JBOD, так как он не может обеспечить необходимую скорость записи. Это, в свою очередь, может привести к ошибочному исключению узла из кластера.

2.10. SELinux

Комплект высокой доступности поддерживает строгий (принудительный) режим SELinux и целевой тип политики.

Информацию о SELinux можно найти в руководстве по развертыванию Red Hat Enterprise Linux 6.

2.11. Многоадресная рассылка

Узлы кластера взаимодействуют друг с другом при помощи многоадресной передачи, поэтому настройки сетевого оборудования должны разрешать многоадресную рассылку и поддерживать IGMP (Internet Group Management Protocol). В противном случае некоторые узлы могут не войти в состав кластера, что вызовет его сбой. В таких окружениях рекомендуется использовать одноадресную передачу UDP (см. Раздел 2.12, «Одноадресная передача UDP»).

Примечание

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

2.12. Одноадресная передача UDP

Начиная с Red Hat Enterprise Linux 6.2 взаимодействие узлов кластера может осуществляться с помощью механизма одноадресной передачи UDP. Тем не менее, рекомендуемым методом все же является многоадресная передача. Одноадресную передачу можно использовать, если функции многоадресной рассылки недоступны.

Чтобы включить одноадресную передачу, в cluster.conf добавьте cman transport="udpu" или на странице конфигурации сети в окне Conga выберите Unicast (см. Раздел 3.5.3, «Настройка сети»).

2.13. `ricci`

В Red Hat Enterprise Linux 6 ccsd был заменен на ricci. Для успешного обновления конфигурации кластера на каждом узле в текстовом (cman_tool version -r) или графическом режиме luci на всех узлах должен быть запущен процесс ricci. Запуск ricci осуществляется с помощью service ricci start или chkconfig (во время загрузки системы). Раздел 2.3.1, «Доступ к портам IP на узлах кластера» содержит информацию о доступе ricci к портам.

Начиная с Red Hat Enterprise Linux 6.1, при передаче обновленной конфигурации кластера с одного узла на другие с помощью ricci в первый раз потребуется указать пароль. Пароль изначально задается после установки ricci посредством выполнения passwd ricci в режиме root.

2.14. Виртуальные машины в кластере

Запуск и остановку виртуальных машин в кластере рекомендуется осуществлять с помощью rgmanager, так как virsh может привести к запуску нескольких копий, что может повредить данные.

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

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

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

Предупреждение

На узлах, где работает rgmanager, необходимо отключить службу libvirt-guests, так как автоматический запуск и возобновление работы виртуальной машины может привести к запуску нескольких копий.

Таблица B.24, «Виртуальная машина» содержит описание атрибутов ресурсов виртуальных машин.

Глава 3. Настройка кластера в Conga

В этой главе рассматривается настройка программных компонентов кластера при помощи Conga. Глава 4, Управление кластером с помощью Conga содержит информацию об управлении работающим кластером.

Примечание

Conga позволяет осуществить централизованную настройку комплекта Red Hat High Availability в графическом режиме. Но чтобы использовать ее возможности максимально эффективно, необходимо понимать принципы организации кластера. Следует избегать излишних экспериментов с настройками, так как это может привести к снижению работоспособности кластера и сбою служб.

Содержание главы:

Раздел 3.1, «Задачи настройки»
Раздел 3.2, «Запуск luci»
Раздел 3.3, «Управление доступом к luci»
Раздел 3.4, «Создание кластера»
Раздел 3.5, «Глобальные параметры кластера»
Раздел 3.6, «Настройка устройств изоляции»
Раздел 3.7, «Исключение узлов из кластера»
Раздел 3.8, «Настройка резервного домена»
Раздел 3.9, «Настройка глобальных ресурсов кластера»
Раздел 3.10, «Добавление службы в кластер»

3.1. Задачи настройки

Ниже перечислены основные этапы настройки программных компонентов кластера в Conga.

Раздел 3.2, «Запуск luci».
Раздел 3.4, «Создание кластера».
Раздел 3.5, «Глобальные параметры кластера».
Раздел 3.6, «Настройка устройств изоляции».
Раздел 3.7, «Исключение узлов из кластера».
Раздел 3.8, «Настройка резервного домена».
Раздел 3.9, «Настройка глобальных ресурсов кластера».
Раздел 3.10, «Добавление службы в кластер».

3.2. Запуск luci

Примечание

На каждом узле кластера под управлением luci необходимо установить ricci (см. Раздел 2.13, «ricci»). Как уже упоминалось, при добавлении нового узла в кластер потребуется ввести пароль ricci (см. Раздел 3.4, «Создание кластера»).

Предварительно на узлах кластера надо открыть порт 11111 для разрешения подключений с сервера luci (см. Раздел 2.3.1, «Доступ к портам IP на узлах кластера»).

Далее рассматривается порядок установки luci.

Выберите компьютер для установки luci и выполните:
```
# yum install luci
```
Примечание
Обычно для luci выделяется отдельный компьютер в центре обработки данных; тем не менее, luci можно установить и на узле в составе кластера.
Запустите luci:
```
# service luci start
Starting luci: generating https SSL certificates...  done
                                                           [  OK  ]

Please, point your web browser to https://nano-01:8084 to access luci
```
Примечание
Начиная с Red Hat Enterprise Linux 6.1 некоторые параметры luci можно определить в файле /etc/sysconfig/luci. Так, здесь можно изменить порт и параметры узла (см. Раздел 2.4, «/etc/sysconfig/luci»). При следующем запуске luci строка адреса будет содержать новый номер порта.
В адресной строке веб-браузера введите адрес сервера luci в формате https://узел:порт. По умолчанию используется порт 8084.
При первом обращении к luci появится окно подтверждения сертификата SSL. После этого откроется форма авторизации в luci.
Для авторизации можно использовать данные любого пользователя системы, где установлено приложение luci, но начиная с Red Hat Enterprise Linux 6.2 только пользователь root изначально обладает правами доступа к компонентам luci (см. Раздел 3.3, «Управление доступом к luci»).
После успешной авторизации будет показана домашняя страница (см. Рисунок 3.1, «Домашняя страница luci»).
Рисунок 3.1. Домашняя страница luci

Примечание

Неактивный сеанс будет автоматически завершен после 15 минут.

3.3. Управление доступом к luci

В Red Hat Enterprise Linux 6 постепенно добавлялись новые функции на странице Users and Permisions.

Начиная с Red Hat Enterprise Linux 6.2 пользователь root и администраторы luci могут управлять правами доступа пользователей к компонентам luci.
В Red Hat Enterprise Linux 6.3 пользователь root и администраторы luci получили возможность добавления пользователей в окне интерфейса luci.
В Red Hat Enterprise Linux 6.4 пользователь root и администраторы luci дополнительно получили возможность удаления пользователей.

Для этого надо сначала войти в luci как root или администратор и выбрать Admin в правом верхнем углу. Появится список существующих пользователей.

Чтобы удалить пользователей, выберите их и нажмите Delete Selected.

Чтобы добавить пользователя, нажмите Add a User и введите его имя.

Дополнительно можно изменить разрешения для выбранного пользователя:

Luci Administrator (администратор luci): Предоставляет пользователю права администратора: полный доступ ко всем кластерам, возможность предоставления и запрета разрешений для всех пользователей кроме root.
Can Create Clusters (может создавать кластер): Разрешает создание новых кластеров (см. Раздел 3.4, «Создание кластера»).
Can Import Existing Clusters (может импортировать кластеры): Разрешает добавлять существующие кластеры в luci (см. Раздел 4.1, «Добавление кластера в luci»).

После создания или добавления кластера можно настроить правила доступа для отдельных пользователей:

Can View This Cluster (просмотр кластера): Разрешение просмотра кластера.
Can Change the Cluster Configuration (изменение конфигурации кластера): Разрешение изменения конфигурации кластера за исключением добавления и удаления узлов.
Can Enable, Disable, Relocate, and Migrate Service Groups (может включать, выключать, осуществлять перенос и миграцию групп служб): Разрешение управления службами высокой готовоности (см. Раздел 4.5, «Управление службами высокой готовности»).
Can Stop, Start, and Reboot Cluster Nodes (может останавливать, запускать и перезагружать узлы кластера): Разрешение управления отдельными узлами кластера (см. Раздел 4.3, «Управление узлами кластера»).
Can Add and Delete Nodes (может добавлять и удалять узлы): Разрешение добавления и удаления узлов (см. Раздел 3.4, «Создание кластера»).
Can Remove This Cluster from Luci (может удалять кластер из Luci): Разрешение удаления кластера из luci (см. Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера»).

Нажмите Submit, чтобы применить изменения, или Reset, чтобы восстановить исходные значения.

3.4. Создание кластера

Для создания кластера при помощи luci потребуется определить его имя, добавить узлы в его состав, указав пароль ricci для каждого узла. После этого Conga установит необходимые программы на узлах и запустит кластер.

В левой панели навигации выберите пункт Manage Clusters. Появится окно управления (см. Рисунок 3.2, «Окно управления кластером»).
Рисунок 3.2. Окно управления кластером
Выберите пункт создания кластера (см. Рисунок 3.3, «Диалог создания кластера luci»).
Рисунок 3.3. Диалог создания кластера luci
Ниже перечислены поля, которые следует заполнить.
- В поле Cluster Name введите имя кластера. Его длина не должна превышать 15 знаков.
- Если пароли ricci одинаковы для всех узлов, установите флажок Use the same password for all nodes.
- В поле Node Name введите имя узла, а в поле Password — пароль ricci.
- Если компьютер входит в состав закрытой сети, в поле Ricci Hostname введите адрес этой сети.
- Если ricci должен использовать нестандартный порт (по умолчанию — 11111), измените номер порта.
- Чтобы добавить другой узел, нажмите Add Another Node.
- Выберите Use locally installed packages, чтобы не обновлять кластерные программы на узле. В противном случае выберите Download Packages.
  Примечание
  Недостающие критические программы кластера будут установлены в любом случае, независимо от выбранного выше варианта. К критическим программам относятся cman, rgmanager, modcluster и их зависимости. Если не удалось их установить, узел создать тоже не получится.
- Дополнительно можно выбрать перезагрузку узлов (Reboot nodes before joining cluster).
- Для организации кластерного хранилища выберите Enable shared storage support: будут загружены необходимые пакеты и включены возможности LVM. Не следует выбирать этот пункт при отсутствии комплектов отказоустойчивого хранилища и масштабируемой файловой системы.
Нажмите кнопку создания кластера. Будут выполнены следующие действия:
1. Если был выбран пункт Download Packages, на добавляемые компьютеры будут загружены необходимые программы.
2. Загруженные программы кластера будут установлены на всех компьютерах.
3. Файл конфигурации кластера будет обновлен и передан всем узлам кластера.
4. Перечисленные компьютеры будут добавлены в состав кластера.
Наконец, появится окно состояния полученного кластера (см. Рисунок 3.4, «Список компонентов кластера»). Стоит отметить, что если процесс ricci выполняется не на всех узлах, создание кластера завершится неудачей.
Рисунок 3.4. Список компонентов кластера
С помощью кнопок добавления и удаления узлов в верхней строке меню можно изменить состав кластера. Удаляемые узлы сначала надо остановить (см. Раздел 4.3.4, «Удаление узла из кластера»).
Примечание
Операция удаления узла из кластера не может быть отменена.

3.5. Глобальные параметры кластера

Для перехода к странице глобальных параметров в верхней строке меню выберите Configure. В открывшемся окне будут доступны вкладки General, Fence Daemon, Network, Redundant Ring, QDisk и Logging. Ниже содержимое этих вкладок будет рассмотено более подробно.

3.5.1. Настройка глобальных параметров

На вкладке General можно просмотреть и изменить общие настройки.

Поле Cluster Name содержит имя кластера. Это значение изменить нельзя. Единственным способом изменения имени является создание новой конфигурации кластера с другим именем.
Значение Configuration Version изначально равно 1 и автоматически увеличивается на единицу каждый раз при изменении конфигурации. По желанию можно установить другое значение, указав его в этом поле.

Чтобы применить изменения, нажмите Apply.

3.5.2. Настройка fenced

Глобальные настройки процесса fenced можно изменить на вкладке Fence Daemon, в том числе длительность интервалов ожидания Post Fail Delay и Post Join Delay. Чтобы настроить отдельные устройства для отключения узлов, выберите пункт Fence Devices (см. Раздел 3.6, «Настройка устройств изоляции»).

Post fail delay — время ожидания (в секундах), которое должно истечь, прежде чем сбойный узел будет отключен. По умолчанию установлен в 0.
Post Join Delay — время ожидания (в секундах), которое должно истечь, прежде чем fenced отключит узел после его перехода в резервный домен. Обычно равен 20-30 секундам (по умолчанию — 6).

Чтобы применить изменения, нажмите Apply.

Примечание

Подробную информацию о перечисленных параметрах можно найти на справочной странице fenced(8).

3.5.3. Настройка сети

На вкладке Network можно изменить настройки сетевых подключений.

Ниже перечислены доступные параметры.

UDP multicast and let cluster choose the multicast address (многоадресная рассылка UDP и выбор многоадресной передачи)
Этот параметр установлен по умолчанию. Red Hat High Availability создаст широковещательный адрес исходя из идентификатора кластера. Так, будут сгенерированы последние 16 бит, которые будут добавлены к первой части адреса, которая определяется протоколом (IPv4 или IPv6). Адрес формируется следующим образом:
- Для IPv4 — 239.192. плюс 16 бит, сформированных комплектом Red Hat High Availability.
- Для IPv6 — FF15:: плюс 16 бит, сгенерированных комплектом Red Hat High Availability.
Примечание
cman генерирует уникальный идентификатор кластера. Чтобы его узнать, выполните cman_tool status.
UDP Multicast and Specify the Multicast Address Manually (многоадресная рассылка UDP и многоадресная передача вручную)
Этот пункт разрешает указать конкретный адрес в поле Multicast Address.
Адрес должен быть определен в формате 239.192.x.x (или FF15:: для IPv6), совместимом с cman. Неверный адрес может привести к непредсказуемым результатам, например может оказаться так, что адрес 224.0.0.x, охватывающий все узлы в сети, неверно маршрутизируется оборудованием.
Чтобы изменения вступили в силу, потребуется перезагрузить кластер (см. Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера»).
Примечание
При указании широковещательного адреса необходимо убедиться, что настройки маршрутизаторов допускают прохождение пакетов кластера. Некоторые маршрутизаторы не сразу распознают подобные адреса, что отрицательно сказывается на производительности.
UDP Unicast (UDPU)
Начиная с Red Hat Enterprise Linux 6.2 взаимодействие узлов в кластере может осуществляться с помощью механизма одноадресной передачи UDP. Тем не менее, рекомендуемым методом все так же является многоадресная передача, особенно в окружениях GFS2. Одноадресная передача может выступать в роли запасного варианта, если возможности многоадресной рассылки недоступны.

Чтобы применить изменения, нажмите Apply. Если был изменен тип протокола, потребуется перезагрузить кластер.

3.5.4. Настройка протокола избыточного кольца

Начиная с Red Hat Enterprise Linux 6.4 комплект Red Hat High Availability поддерживает возможности настройки протокола избыточного кольца (см. Раздел 7.6, «Настройка протокола избыточного кольца»).

На вкладке Redundant Ring представлен список узлов кластера. Если настройки системы допускают использование избыточного кольца, в поле Alternate Name необходимо определить имена узлов для второго кольца.

На странице конфигурации протокола можно дополнительно заполнить поля Alternate Ring Multicast Address, Alternate Ring CMAN Port, Alternate Ring Multicast Packet TTL для второго кольца.

Если для второго кольца был определен адрес многоадресной рассылки, он должен отличаться от адреса первого кольца. Если вы определили дополнительный порт, номера портов первого и второго кольца должны отличаться как минимум на два, так как сама система использует основной порт и порт с номером на единицу меньше. Если же дополнительный адрес не задан, он будет выбран автоматически.

3.5.5. Настройка диска кворума

На вкладке QDisk можно изменить настройки диска кворума.

Примечание

Поведение qdiskd можно изменить в соответствии с требованиями окружения. Подробную информацию можно найти на справочной странице qdisk(5). За дополнительной помощью рекомендуется обратиться к официальному представителю службы технической поддержки Red Hat.

Параметр Do not use a Quorum Disk по умолчанию установлен. Если необходимо использовать диск кворума, выберите Use a Quorum Disk, нажмите Apply и перезапустите кластер.

Таблица 3.1, «Параметры диска кворума» содержит список параметров.

Таблица 3.1. Параметры диска кворума

Параметр Описание

Specify Physical Device: By Device Label Метка диска, присвоенная утилитой mkqdisk. Если это поле заполнено, qdiskd осуществит чтение /proc/partitions и проверит соответствие подписи qdisk каждого блочного устройства указанной метке. Обычно используется, если имя устройства кворума на разных узлах отличается.

Heuristics

Path to Program — путь к программе эвристического метода. Можно выбрать любую программу, которую можно запустить с помощью /bin/sh -c. Нулевой результат обозначает успех. Это поле является обязательным.

Interval — частота опроса эвристического алгоритма в секундах. По умолчанию опрос осуществляется каждые 2 секунды.

Score — вес эвристического алгоритма (по умолчанию равен 1).

TKO — число неудачных попыток, после чего метод будет признан недоступным.

Minimum Total Score Минимальное число баллов, необходимое для признания узла активным. Если не указано или равно нулю, будет использоваться стандартная функция floor((n+1)/2) (где n — сумма баллов эвристического алгоритма). Значение Minimum Score не может быть больше суммы баллов эвристического алгоритма, в противном случае диск кворума будет недоступен.

Примечание

Нажмите Apply. Изменения будут сохранены в /etc/cluster/cluster.conf на всех узлах кластера. Для перезапуска qdiskd следует перезагрузить кластер (см. Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера»).

3.5.6. Настройка журналирования

На вкладке Logging можно изменить настройки журналирования.

Ниже перечислены глобальные настройки.

Log debugging messages — регистрация сообщений отладки в журнале.
Log messages to syslog — регистрация сообщений отладки в syslog. Дополнительно можно выбрать Syslog message priority (сохранение сообщений с выбранным приоритетом) и Syslog message facility.
Log messages to log file — регистрация событий в журнале. В поле Log File Path можно указать путь к файлу. Дополнительно можно выбрать Syslog message priority (сохранение сообщений с выбранным приоритетом).

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

Нажмите Apply.

3.6. Настройка устройств изоляции

Настройка исключающих устройств охватывает их создание, удаление и изменение конфигурации.

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

Содержание этой секции:

Раздел 3.6.1, «Создание устройства изоляции». После его успешного создания можно отдельно настроить устройства для каждого узла в кластере (см. Раздел 3.7, «Исключение узлов из кластера»).
Раздел 3.6.2, «Изменение параметров устройств изоляции».
Раздел 3.6.3, «Удаление устройства изоляции».

Чтобы настроить устройства изоляции, выберите Fence Devices в верхней части страницы кластера. Появится список устройств и кнопки изменения, удаления и добавления новых устройств.

Примечание

Изначально список устройств будет пуст.

Рисунок 3.5, «Окно настройки устройств изоляции в luci» демонстрирует окно устройств с пустым списком.

Рисунок 3.5. Окно настройки устройств изоляции в luci

3.6.1. Создание устройства изоляции

Порядок создания устройства:

На странице Fence Devices нажмите Add и выберите тип добавляемого устройства.
Заполните форму Add Fence Device (Instance) в соответствии с выбранным типом (см. Приложение A, Параметры устройств изоляции). Дополнительно может потребоваться определить параметры устройства для конкретных узлов (см. Раздел 3.7, «Исключение узлов из кластера»).
Нажмите Submit.

Устройство будет добавлено в общий список устройств.

3.6.2. Изменение параметров устройств изоляции

Порядок изменения параметров:

Выберите устройство в окне Fence Devices для перехода к его настройкам.
Внесите изменения (см. Приложение A, Параметры устройств изоляции).
Нажмите Apply.

3.6.3. Удаление устройства изоляции

Примечание

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

Порядок удаления:

Выберите устройства в окне Fence Devices.
Нажмите Delete и дождитесь подтверждения.

Устройство будет удалено из списка.

3.7. Исключение узлов из кластера

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

Содержание этой главы:

Раздел 3.7.1, «Настройка устройства изоляции»
Раздел 3.7.2, «Настройка запасного устройства изоляции»
Раздел 3.7.3, «Настройка запасных источников питания»

3.7.1. Настройка устройства изоляции

Ниже рассматривается порядок настройки единственного устройства изоляции для узла.

В главном меню кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
Щелкните на имени узла для перехода к его настройкам.
На этой странице будут показаны активные службы и резервные домены, в состав которых входит данный компьютер (см. Раздел 3.8, «Настройка резервного домена»).
В секции Fence Devices выберите Add Fence Method — появится окно Add Fence Method to Node.
В поле Method Name введите произвольное имя.
Нажмите Submit.
Чтобы добавить устройство для этого метода, нажмите Add Fence Instance и выберите настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
Если устройство требует отдельно определить параметры для узла, будет предложено их настроить (см. Приложение A, Параметры устройств изоляции).
Примечание
Для методов управления доступом к хранилищу/SAN пункт Unfencing в списке параметров будет выбран по умолчанию. Этот параметр предотвращает подключение исключенного узла к хранилищу до тех пор, пока он не будет перезагружен. Подробную информацию можно найти на справочной странице fence_node(8).
Нажмите Submit.

3.7.2. Настройка запасного устройства изоляции

Для одного узла можно определить несколько алгоритмов изоляции. Если один метод не работает, будет выбран следующий и т.п.

Ниже рассматривается порядок настройки запасного устройства для узла.

Настройте основной алгоритм (см. Раздел 3.7.1, «Настройка устройства изоляции»).
В нижней части окна алгоритма нажмите Add Fence Method.
Введите имя алгоритма и нажмите Submit. Новый алгоритм появится в списке следом за основным методом.
Чтобы добавить устройство для этого метода, нажмите Add Fence Instance под его именем и выберите предварительно настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
Если устройство требует отдельно определить параметры для узла, будет предложено их настроить (см. Приложение A, Параметры устройств изоляции).
Нажмите Submit.

При необходимости можно добавить другие алгоритмы. Их порядок можно изменить с помощью кнопок Move Up и Move Down.

3.7.3. Настройка запасных источников питания

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

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

Сначала надо определить оба источника питания как устройства изоляции (см. Раздел 3.6, «Настройка устройств изоляции»).
В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
Щелкните на имени узла для перехода к его настройкам.
На странице узла нажмите Add Fence Method.
Введите имя метода изоляции.
Нажмите Submit.
Добавьте первый источник питания, нажав Add Fence Instance под названием алгоритма. В открывшемся меню выберите предварительно настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
Выберите источник питания и заполните его параметры.
Нажмите Submit.
Добавьте второй источник питания, нажав Add Fence Instance. В открывшемся меню выберите предварительно настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
Выберите второй источник питания и заполните его параметры.
Нажмите Submit. Появится окно узла со списком настроенных алгоритмов и устройств (см. Рисунок 3.6, «Конфигурация с двумя источниками питания»).
Рисунок 3.6. Конфигурация с двумя источниками питания

3.8. Настройка резервного домена

Резервный домен — подмножество узлов кластера, где будет восстановлена работа кластерной службы в случае сбоя узла. Ниже перечислены основные типы резервных доменов.

Неограниченный — позволяет указать предпочитаемую группу узлов. При этом служба, закрепленная за этим доменом, может работать на любом доступном узле.
Ограниченный — кластерная служба может выполняться только на заранее определенных узлах. Если в домене не осталось доступных узлов, кластерная служба не сможет быть запущена.
Неупорядоченный — восстановление службы после сбоя может происходить на любом узле в составе домена без каких-либо предпочтений.
Упорядоченный — позволяет определить порядок выбора узлов для восстановления службы. Узел в начале списка является наиболее предпочтительным, в конце — наименее предпочтительным.
С возвратом — разрешает возврат службы на исходный узел после его восстановления. Это помогает при периодических сбоях узла, входящего в состав упорядоченного домена, так как если узел является предпочтительным, может оказаться так, что служба будет бесконечно переноситься с него на другой узел и обратно, что значительно снизит производительность.
Примечание
Функция возврата доступна только для упорядоченного типа.

Примечание

Изменение конфигурации резервного домена не окажет влияния на уже запущенные службы.

Примечание

Для нормальной работы кластера резервные домены необязательны.

По умолчанию используется неограниченный и неупорядоченный тип домена.

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

Примечание

Для настройки приоритетного узла можно создать неограниченный домен, включающий всего один узел. Это гарантирует, что служба будет выполняться именно на этом узле, а в случае сбоя будет перенесена на любой другой узел кластера.

Дальнейшее содержимое этой главы:

Раздел 3.8.1, «Добавление резервного домена»
Раздел 3.8.2, «Изменение резервного домена»
Раздел 3.8.3, «Удаление резервного домена»

3.8.1. Добавление резервного домена

Ниже рассматривается порядок добавления резервного домена.

В главном меню кластера выберите Failover Domains для перехода к списку его резервных доменов.
Нажмите Add для перехода к диалогу добавления домена (см. Рисунок 3.7, «Окно настройки резервного домена»).
Рисунок 3.7. Окно настройки резервного домена
В поле Name введите имя домена.
Примечание
Рекомендуется указать информативное имя, которое поможет легко идентифицировать домен.
Если при выборе запасного узла должен учитываться приоритет, установите флажок Prioritized и укажите приоритет в поле Priority.
Пункт Restricted отвечает за восстановление работы сбойной службы только на узлах, входящих в состав резервного домена.
Если установлен флажок No Failback, то при возобновлении работы исходного узла выполняемая на запасном узле служба не будет переноситься обратно.
Чтобы добавить узел в домен, установите флажок Member напротив его имени. Если выше был выбран пункт Prioritized, укажите значение в поле Priority.
Нажмите Create. Появится подтверждение создания домена.

3.8.2. Изменение резервного домена

Ниже рассматривается порядок изменения резервного домена.

В главном меню кластера выберите Failover Domains для перехода к списку его резервных доменов.
Выберите домен для перехода к странице его настроек.
Измените параметры Prioritized, Restricted, No Failback в соответствии со своими требованиями и нажмите Update Properties, чтобы применить изменения.
Чтобы добавить узлы или исключить их из кластера, измените статус Member напротив каждого узла. Для упорядоченных доменов можно дополнительно изменить приоритет узлов. Завершив, нажмите Update Properties.

3.8.3. Удаление резервного домена

Ниже рассматривается порядок удаления резервного домена.

В главном меню кластера выберите Failover Domains для перехода к списку его резервных доменов.
Выберите домен для удаления.
Нажмите Delete.

3.9. Настройка глобальных ресурсов кластера

В кластер можно добавить глобальные ресурсы (будут доступны всем службам) и частные (будут доступны выборочным службам).

Ниже рассматривается порядок добавления глобальных кластерных ресурсов. Информацию о добавлении локальных ресурсов для отдельных служб можно найти в следующем разделе (см. Раздел 3.10, «Добавление службы в кластер»).

В главном меню страницы кластера выберите Resources для перехода к списку настроенных ресурсов.
Нажмите Add для перехода к диалогу добавления ресурсов.
Из выпадающего списка выберите тип ресурса.
Введите параметры (см. Приложение B, Параметры ресурсов).
Нажмите Submit. Новый ресурс будет добавлен в список ресурсов кластера.

Порядок изменения ресурса:

Выберите ресурс на странице Resources.
Измените параметры.
Нажмите Apply.

Порядок удаления ресурса:

Выберите ресурс на странице Resources.
Нажмите Delete.

3.10. Добавление службы в кластер

Ниже рассматривается порядок добавления кластерных служб в кластер.

В главном меню страницы кластера выберите Service Groups для перехода к списку служб (см. Раздел 4.5, «Управление службами высокой готовности»).
Чтобы добавить службу, нажмите Add.
В поле Service name введите имя службы.
Примечание
Рекомендуется выбрать информативное имя, которое поможет легко идентифицировать службу.
Флажок Automatically start this service отвечает за автоматический запуск службы при запуске кластера. Если не установлен, службу надо будет запустить вручную.
Run exclusive разрешает запуск службы при условии, если на узле не выполняются другие службы.
Если резервные домены уже настроены, выберите домен из списка Failover domain (см. Раздел 3.8, «Настройка резервного домена»).
В списке Recovery policy доступны следующие значения: Relocate, Restart, Restart-Disable, Disable.
При выборе Restart система попытается перезапустить сбойную службу до ее переноса на другой узел. Relocate подразумевает перезапуск службы на другом узле, Disable отключит группу ресурсов при сбое ее компонентов. При выборе Restart-Disable система будет пытаться запустить службу, но в случае неудачи она будет отключена.
Если выбрана политика Restart или Restart-Disable, можно указать максимальное число попыток перезапуска службы и время ожидания, по истечении которого перезапуск будет отменен.
Нажмите Add resource для перехода к диалогу, где можно добавить существующий глобальный ресурс или создать новый ресурс исключительно для выбранной службы.
- Чтобы добавить глобальный ресурс, выберите его из списка Add Resource To Service (см. Раздел 3.9, «Настройка глобальных ресурсов кластера»).
- Чтобы добавить новый ресурс для конкретной службы, выберите тип из списка Add a resource и определите его настройки (см. Приложение B, Параметры ресурсов).
- Для обоих типов ресурсов можно выбрать Independent subtree или Non-critical resource.
  Если выбрано Independent subtree, в случае сбоя ресурса будет перезапущен только сам ресурс, а не вся служба. Дополнительно можно определить максимальное число попыток перезапуска, после чего управление будет передано политике восстановления. Также можно указать время ожидания, по истечении которого политика восстановления вступит в силу.
  Если ресурс определен как некритический, то при его сбое будет перезапущен только он. Если перезапуск не помог, будет отключен только этот ресурс, в то время как служба отключаться не будет. Дополнительно можно определить максимальное число попыток перезапуска, после чего ресурс будет отключен. Также можно указать время ожидания, по истечении которого будет выполнено его отключение.
Дополнительно можно добавить подчиненные ресурсы. Для этого нажмите Add a child resource для перехода к диалогу добавления ресурсов.
Примечание
Ресурсы Samba не могут быть подчиненными и должны быть добавлены напрямую.
Завершив добавление, нажмите Submit.

Примечание

Чтобы проверить наличие ресурса IP-службы, используемого кластерной службой, на узле кластера можно выполнить /sbin/ip addr show вместо устаревшей команды ifconfig. Ниже приведен пример вывода:

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1356 qdisc pfifo_fast qlen 1000
    link/ether 00:05:5d:9a:d8:91 brd ff:ff:ff:ff:ff:ff
    inet 10.11.4.31/22 brd 10.11.7.255 scope global eth0
    inet6 fe80::205:5dff:fe9a:d891/64 scope link
    inet 10.11.4.240/22 scope global secondary eth0
       valid_lft forever preferred_lft forever

Порядок изменения существующей службы:

Выберите службу на странице Service Groups для перехода к странице ее настроек.
Измените параметры.
Нажмите Submit.

Порядок удаления служб:

Выберите службы на странице Service Groups.
Нажмите Delete.
В Red Hat Enterprise Linux 6.3 сначала появится запрос подтверждения удаления. Cancel закроет диалог без удаления, а Proceed удалит службы.

Глава 4. Управление кластером с помощью Conga

В этой главе рассматриваются задачи управления комплектом Red Hat High Availability. Содержание:

Раздел 4.1, «Добавление кластера в luci»
Раздел 4.2, «Удаление кластера из luci»
Раздел 4.3, «Управление узлами кластера»
Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера»
Раздел 4.5, «Управление службами высокой готовности»
Раздел 4.6, «Создание резервной копии и восстановление конфигурации luci»

4.1. Добавление кластера в luci

Прежде чем приступить к управлению настройками кластера, надо его зарегистрировать в Conga.

Выполните следующее:

В левой панели навигации выберите пункт Manage Clusters. Появится окно управления кластерами.
Нажмите Add.
Введите имена узлов и пароли ricci для всех узлов в кластере. Этого должно быть достаточно для добавления кластера, так как узлы включают информацию о его конфигурации.
Нажмите Connect. В открывшемся окне будет показано имя кластера и перечислены остальные узлы.
Если пароли ricci одинаковы для всех узлов, установите флажок Use the same password for all nodes.
Нажмите Add Cluster. Кластер станет доступен на странице Manage Clusters.

4.2. Удаление кластера из luci

Кластер может быть удален из интерфейса luci. Это не скажется на его составе и работе служб. Удаленный кластер можно будет впоследствии снова добавить (см. Раздел 4.1, «Добавление кластера в luci»).

Чтобы удалить кластер из интерфейса luci, выполните следующее:

В левой панели навигации выберите пункт Manage Clusters. Появится окно управления кластерами.
Выберите кластеры для удаления.
Нажмите Remove.

Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера» содержит информацию об остановке служб кластера, удалении конфигурации с узлов и удалении кластера полностью.

4.3. Управление узлами кластера

В этой секции рассматриваются основные функции управления узлами кластера.

Раздел 4.3.1, «Перезагрузка узла»
Раздел 4.3.2, «Добавление и удаление узлов»
Раздел 4.3.3, «Добавление узла в работающий кластер»
Раздел 4.3.4, «Удаление узла из кластера»

4.3.1. Перезагрузка узла

Порядок перезагрузки узла:

В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
Выберите узел.
В верхнем меню выберите Reboot. Появится подтверждение.
Чтобы получить текущий статус, обновите страницу.

Чтобы перезагрузить несколько узлов сразу, отметьте их и нажмите Reboot.

4.3.2. Добавление и удаление узлов

С помощью Conga можно добавить или исключить узел из кластера, предварительно остановив работающие кластерные службы.

При исключении узла настройки кластера не будут удалены, а сам узел будет доступен в списке узлов со статусом Not a cluster member (см Раздел 4.3.4, «Удаление узла из кластера»).

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

В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
Выберите узел.
В верхнем меню выберите Leave Cluster. Появится сообщение об остановке узла.
Чтобы получить текущий статус, обновите страницу.

Чтобы удалить несколько узлов, отметьте их и нажмите Leave Cluster.

Чтобы вернуть узлы в состав кластера, выберите их и нажмите Join Cluster.

4.3.3. Добавление узла в работающий кластер

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

В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
Нажмите Add для перехода к диалогу добавления узлов.
В поле Node Hostname введите имя узла, а в поле Password — пароль ricci. Если ricci использует нестандартный порт (по умолчанию — 11111), измените номер порта.
Для организации кластерного хранилища выберите Enable shared storage support: будут загружены необходимые пакеты и включены возможности LVM. Не следует выбирать этот пункт при отсутствии комплектов отказоустойчивого хранилища и масштабируемой файловой системы.
Чтобы добавить другой узел, нажмите Add Another Node.
Нажмите Add Nodes.
1. Если был выбран пункт Download Packages, на добавляемые компьютеры будут загружены необходимые программы.
2. Загруженные программы будут установлены.
3. Файл конфигурации кластера будет обновлен и передан всем узлам кластера.
4. Узел будет добавлен в состав кластера.
Появится страница Nodes и подтверждение добавления узла в кластер. Чтобы получить текущий статус, обновите страницу.
Чтобы настроить изоляцию узла, щелкните на его имени (см. Раздел 3.6, «Настройка устройств изоляции»).

4.3.4. Удаление узла из кластера

Ниже рассматривается удаление узла из работающего кластера. Сначала потребуется остановить узел за исключением случаев, когда одновременно удаляются все узлы.

В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
Примечание
Чтобы инициировать восстановление работающих служб при удалении узла, перейдите к следующему шагу.
Отключите или переместите службы, которые будут удалены (см. Раздел 4.5, «Управление службами высокой готовности»).
Выберите узлы для удаления.
Нажмите Delete. Появится страница Nodes и подтверждение удаления. Чтобы получить текущий статус, обновите страницу.

Важно

Операцию удаления узла из кластера нельзя отменить.

4.4. Запуск, остановка, перезапуск и удаление кластера

На вкладке Nodes страницы кластера можно запустить, остановить и перезапустить его узлы.

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

Ниже рассматривается порядок остановки кластера, что подразумевает завершение работы всех программ на узлах без удаления конфигурации кластера. Узлы по-прежнему будут доступны в окне содержимого кластера со статусом Not a cluster member.

Отметьте все узлы в списке.
В верхнем меню выберите Leave Cluster. Появится сообщение об остановке узла.
Чтобы получить текущий статус, обновите страницу.

Порядок запуска кластера:

Отметьте все узлы в списке.
В верхнем меню выберите Join Cluster.
Чтобы получить текущий статус, обновите страницу.

Чтобы перезапустить работающий кластер, надо остановить и перезапустить узлы в его составе (см. выше).

Ниже приведен порядок удаления кластера. При этом его службы будут остановлены, конфигурация кластера удалена со всех узлов, а узлы будут удалены из списка элементов кластера. Повторные попытки добавления этих узлов приведут к генерации сообщения о том, что узел не принадлежит какому-либо кластеру.

Важно

Удаление является необратимой операцией. Чтобы восстановить кластер, потребуется создать его заново.

Отметьте все узлы в списке.
В верхнем меню выберите Delete.

За удаление кластера из интерфейса luci без остановки служб и изменения его состава отвечает параметр Remove на странице Manage Clusters (см. Раздел 4.2, «Удаление кластера из luci»).

4.5. Управление службами высокой готовности

Помимо стандартных операций добавления и изменения служб (см. Раздел 3.10, «Добавление службы в кластер») доступны следующие функции:

Запуск служб
Перезапуск служб
Отключение служб
Удаление служб
Перенос служб

В главном меню страницы кластера выберите Service Groups для перехода к списку служб кластера.

Запуск служб. Установите флажок напротив служб, которые следует запустить, и нажмите Start.
Перезапуск служб. Установите флажок напротив служб, которые следует перезапустить, и нажмите Restart.
Отключение служб. Установите флажок напротив служб, которые следует остановить, и нажмите Disable.
Удаление служб. Установите флажок напротив остановленных служб, которые следует удалить, и нажмите Delete.
Перенос служб. Щелкните на имени службы, чтобы открыть страницу ее настройки. На этой странице указан узел, на котором в данный момент выполняется эта служба.
Из списка Start on node... выберите узел, на который надо ее перенести, и нажмите Start. В верхней части экрана появится сообщение о запуске службы. Чтобы обновить статус вручную, обновите страницу.
Примечание
При выборе службы vm список будет содержать операцию migrate вместо relocate.

Примечание

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

4.6. Создание резервной копии и восстановление конфигурации luci

Ниже рассматривается порядок создания резервной копии базы данных luci — /var/lib/luci/data/luci.db. База данных содержит список пользователей, кластеров и их характеристрик, в то время как конфигурация кластера хранится в файле cluster.conf. По умолчанию резервная копия будет создана в том же каталоге, где расположен файл luci.db.

Выполните service luci stop.
Выполните service luci backup-db.
Дополнительно команде backup-db можно передать имя файла, в который будет сохранена копия базы данных. Пример: service luci backup-db /root/luci.db.backup. Стоит отметить, что резервные копии, которые размещены за пределами /var/lib/luci/data/, не будут показаны в выводе команды list-backups.
Выполните service luci start.

Далее приведена последовательность восстановления базы данных luci.

Выполните service luci stop.
Выполните service luci list-backups, чтобы получить список резервных копий.
Выполните service luci restore-db /var/lib/luci/data/файл, заменив файл именем файла, из которого будет восстановлена база данных.
Так, следующая команда восстановит данные из файла luci-backup20110923062526.db:
```
service luci restore-db /var/lib/luci/data/luci-backup20110923062526.db
```
Выполните service luci start.

Если файл host.pem не найден на компьютере, где была создана резервная копия, для успешной авторизации на узлах кластера потребуется добавить его вручную в окне luci.

Далее рассматривается порядок восстановления базы данных luci на другом компьютере. Для этого помимо копии базы данных понадобится предоставить SSL-сертификат для аутентификации luci на узлах ricci. В приведенном примере резервная копия была изначально создана на компьютере luci1, после чего она будет восстановлена на компьютере luci2.

Следующий набор команд создаст резервную копию luci на luci1, затем скопирует ее и SSL-сертификат на luci2.

[root@luci1 ~]# service luci stop
[root@luci1 ~]# service luci backup-db
[root@luci1 ~]# service luci list-backups
/var/lib/luci/data/luci-backup20120504134051.db
[root@luci1 ~]# scp /var/lib/luci/certs/host.pem /var/lib/luci/data/luci-backup20120504134051.db root@luci2:

На компьютере luci2 должно быть установлено и запущено приложение luci.

Выполните следующие команды для аутентификации и восстановления базы данных на luci2.

[root@luci2 ~]# cp host.pem /var/lib/luci/certs/
[root@luci2 ~]# chown luci: /var/lib/luci/certs/host.pem
[root@luci2 ~]# /etc/init.d/luci restore-db ~/luci-backup20120504134051.db
[root@luci2 ~]# shred -u ~/host.pem ~/luci-backup20120504134051.db
[root@luci2 ~]# service luci start

Глава 5. Настройка кластера с помощью ccs

Начиная с Red Hat Enterprise Linux 6.1 управление комплектом Red Hat High Availability может осуществляться с помощью утилиты ccs. Доступные операции включают создание, просмотр и изменение файла cluster.conf локально или удаленно, а также управление работой кластерных служб на одном или одновременно на всех узлах.

В этой главе рассматриваются основные аспекты настройки комплекта Red Hat High Availability с помощью ccs. Глава 6, Управление кластером с помощью ccs содержит информацию об управлении работающим кластером.

Содержание главы:

Раздел 5.1, «Обзор»
Раздел 5.2, «Задачи конфигурации»
Раздел 5.3, «Запуск ricci»
Раздел 5.4, «Создание кластера»
Раздел 5.5, «Настройка устройств изоляции»
Раздел 5.7, «Настройка изоляции узлов»
Раздел 5.8, «Настройка резервного домена»
Раздел 5.9, «Так, следующая команда покажет список служб на узле node1.»
Раздел 5.10, «Добавление кластерной службы»
Раздел 5.13, «Настройка кворумного диска»
Раздел 5.14, «Прочие характеристики кластера»
Раздел 5.14, «Прочие характеристики кластера»
Раздел 5.15, «Синхронизация файла конфигурации»

Примечание

До ввода Red Hat High Availability в эксплуатацию рекомендуется проконсультироваться с представителем Red Hat на предмет соответствия конфигурации системы требованиям.

Примечание

В этой главе упоминаются параметры из файла cluster.conf, полный список которых можно найти в /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html).

5.1. Обзор

В этой секции рассматриваются основные функции ccs.

Раздел 5.1.1, «Создание файла конфигурации локально»
Раздел 5.1.2, «Просмотр файла конфигурации»
Раздел 5.1.3, «Определение паролей ricci»
Раздел 5.1.4, «Изменение характеристик кластера»

5.1.1. Создание файла конфигурации локально

Файл конфигурации кластера может быть создан удаленно на узле в кластере или в локальной файловой системе с последующей передачей в кластер. Команда ccs не требует наличия разрешений root.

Если файл создается удаленно, необходимо указать имя узла с помощью параметра -h.

ccs -h узел [параметры]

Если файл создается локально, ему может быть присвоено любое имя. Параметр -f позволяет его передать команде ccs.

ccs -f файл [параметры]

Параметр --setconf отвечает за передачу файла кластеру. Он будет размещен в /etc/cluster/cluster.conf.

ccs -h узел -f файл --setconf

Раздел 5.15, «Синхронизация файла конфигурации» содержит подробную информацию о --setconf.

5.1.2. Просмотр файла конфигурации

Для вывода файла конфигурации на любой стадии его создания выполните:

ccs -h узел --getconf

Если файл был создан локально, вместо -h можно указать -f (см. Раздел 5.1.1, «Создание файла конфигурации локально»).

5.1.3. Определение паролей ricci

Для успешной передачи cluster.conf узлам кластера необходимо, чтобы на всех узлах была установлена программа ricci (см. Раздел 2.13, «ricci»).

Пароль ricci можно передать с помощью параметра -p. Если пароль не предоставить, появится запрос его ввода в ходе выполнения ccs.

ccs -h узел -p пароль --sync --activate

Если файл конфигурации передается всем узлам в кластере (параметр --sync), для доступа будет использоваться указанный пароль. Если пароли отличаются, параметр --setconf в комбинации -p позволяет осуществлять передачу файла последовательно.

5.1.4. Изменение характеристик кластера

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

Исключение составляет cman: чтобы изменить его атрибуты, выполните ccs с параметром --setcman. Значения перечисленных в строке атрибутов будут изменены, а остальным атрибутам будут присвоены стандартные значения (см. Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки»).

5.1.5. Команды, переопределяющие предыдущие настройки

Некоторые аргументы ccs переопределяют существующие настройки при изменении отдельных значений. То есть при выполнении команды ccs с одним из перечисленных ниже аргументов всем параметрам будут присвоены значения, используемые по умолчанию.

--settotem
--setdlm
--setrm
--setcman
--setmulticast
--setaltmulticast
--setfencedaemon
--setlogging
--setquorumd

Так, например, чтобы сбросить параметры службы изоляции, выполните команду

# ccs -h hostname --setfencedaemon

Следующая команда присвоит post_fail_delay значение 5 и сбросит все остальные параметры:

# ccs -h hostname --setfencedaemon post_fail_delay=5

Если после этого выполнить следующую команду, параметру post_join_delay будет присвоено значение 10, а post_fail_delay будет снова сброшен.

# ccs -h hostname --setfencedaemon post_join_delay=10

Чтобы одновременно изменить значения post_fail_delay и post_join_delay, выполните:

# ccs -h hostname --setfencedaemon post_fail_delay=5 post_join_delay=10

Раздел 5.5, «Настройка устройств изоляции» содержит подробную информацию о настройке устройств изоляции.

5.1.6. Проверка формата

При создании файла конфигурации с помощью ccs его формат будет проверяться автоматически. В Red Hat Enterprise Linux 6.3 проверка осуществляется согласно схеме в /usr/share/cluster/cluster.rng на узле, который задан параметром -h, в то время как раньше использовалась встроенная схема ccs из /usr/share/ccs/cluster.rng . Если же команда содержит параметр -f, по-прежнему будет использоваться /usr/share/ccs/cluster.rng.

5.2. Задачи конфигурации

Ниже перечислены основные шаги по настройке Red Hat High Availability с помощью ccs.

ricci должен работать на всех узлах (см. Раздел 5.3, «Запуск ricci»).
Раздел 5.4, «Создание кластера».
Раздел 5.5, «Настройка устройств изоляции».
Раздел 5.7, «Настройка изоляции узлов».
Раздел 5.8, «Настройка резервного домена».
Раздел 5.9, «Так, следующая команда покажет список служб на узле node1.».
Раздел 5.10, «Добавление кластерной службы».
Раздел 5.13, «Настройка кворумного диска».
Раздел 5.14, «Прочие характеристики кластера».
Раздел 5.15, «Синхронизация файла конфигурации».

5.3. Запуск ricci

Запуск ricci на каждом узле в кластере является обязательным условием для создания и распределения файлов конфигурации. До запуска ricci необходимо подготовить систему:

Открыть IP-порты для работы ricci (см. Раздел 2.3.1, «Доступ к портам IP на узлах кластера»).
На всех узлах в кластере необходимо установить ricci и определить соотвествующий пароль доступа (см. Раздел 2.13, «ricci»).

После этого можно запустить ricci на каждом узле:

# service ricci start
Starting ricci:                                            [  OK  ]

5.4. Создание кластера

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

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

Создать файл конфигурации кластера на одном из узлов при помощи ccs с параметром -h (определяет узел, где будет создан файл) и createcluster (имя кластера):
```
ccs -h узел --createcluster имя
```
Так, следующая команда создаст файл конфигурации на node-01.example.com в кластере mycluster:
```
ccs -h node-01.example.com --createcluster mycluster
```
Имя кластера не может содержать более 15 знаков.
Если cluster.conf уже существует, он будет перезаписан.
Чтобы создать файл в локальной файловой системе, вместо -h следует указать -f (см. Раздел 5.1.1, «Создание файла конфигурации локально»).
Чтобы добавить узлы в файл конфигурации, следует выполнить:
```
ccs -h хост --addnode узел
```
В следующем примере в файл конфигурации на node-01.example.com будут добавлены узлы node-01.example.com, node-02.example.com и node-03.example.com.
```
ccs -h node-01.example.com --addnode node-01.example.com
ccs -h node-01.example.com --addnode node-02.example.com
ccs -h node-01.example.com --addnode node-03.example.com
```
Команда просмотра узлов в кластере:
```
ccs -h хост --lsnodes
```
Пример 5.1, «cluster.conf с тремя узлами» демонстрирует структуру кластера mycluster, в состав которого входят узлы node-01.example.com, node-02.example.com и node-03.example.com.
Пример 5.1. cluster.conf с тремя узлами
```
<cluster name="mycluster" config_version="2">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>
```
Для добавляемого узла можно определить количество голосов, учитываемых при определении кворума:
```
ccs -h хост --addnode узел --votes число
```
ccs автоматически присвоит узлу уникальный целый идентификатор. Параметр --nodeide позволяет определить идентификатор вручную.
```
ccs -h хост --addnode хост --nodeid ID_узла
```
Удаление узла из кластера осуществляется следующим образом:
```
ccs -h хост --rmnode узел
```

После завершения изменения структуры кластера надо выполнить синхронизацию файла конфигурации на всех узлах (см. Раздел 5.15, «Синхронизация файла конфигурации»).

5.5. Настройка устройств изоляции

Настройка устройств изоляции охватывает их создание, удаление и изменение конфигурации. Раздел 5.7, «Настройка изоляции узлов» содержит информацию о настройке изоляции на отдельных узлах.

Прежде чем приступить к настройке устройств изоляции, возможно, потребуется откорректировать параметры fenced. Основные параметры перечислены ниже.

post_fail_delay — время ожидания с момента сбоя до отключения узла (в секундах). По умолчанию равно 0. Это значение можно изменить в соответствии с производительностью кластера и сети.
post-join_delay — время ожидания (в секундах), которое должно истечь, прежде чем fenced отключит узел после его перехода в резервный домен. Обычно равен 20-30 секундам (по умолчанию — 6).

ccs --setfencedaemon восстановит исходные значения post_fail_delay и post_join_delay. Однако стоит помнить, что значения остальных параметров также будут восстановлены.

Так, например, следующая команда изменит значение post_fail_delay, но при этом восстановит исходные значения других параметров.

ccs -h хост --setfencedaemon post_fail_delay=число

Команда изменения post_join_delay:

ccs -h хост --setfencedaemon post_join_delay=число

Чтобы изменить оба значения одновременно, выполните:

ccs -h хост --setfencedaemon post_fail_delay=значение post_join_delay=значение

Примечание

Дополнительная информация о post_join_delay, post_fail_delay и других параметрах приведена на справочной странице fenced(8), в /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html.

Добавление устройства изоляции:

ccs -h хост --addfencedev имя_устройства [параметры]

Так, следующая команда настроит устройство myfence с адресом apc_ip_example, именем входа login_example и паролем password_example на узле node1.

ccs -h node1 --addfencedev myfence agent=fence_apc ipaddr=apc_ip_example login=login_example passwd=password_example

После этого секция fencedevices в cluster.conf будет выглядеть так:


<fencedevices>
      <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="myfence" passwd="password_example"/>
</fencedevices>

ccs позволяет получить полный список доступных и уже настроенных устройств (см. Раздел 5.6, «Список устройств и их параметров»).

Удаление устройства из конфигурации кластера осуществляется следующим образом:

ccs -h хост --rmfencedev имя_устройства

Так, следующая команда удалит устройство myfence из конфигурации кластера на узле node1.

ccs -h node1 --rmfencedev myfence

Чтобы изменить параметры устройства изоляции, потребуется его удалить и заново добавить со новыми параметрами.

После завершения настройки структуры кластера надо выполнить синхронизацию файла конфигурации на всех узлах (см. Раздел 5.15, «Синхронизация файла конфигурации»).

5.6. Список устройств и их параметров

С помощью ccs можно вывести список доступных и уже настроенных устройств изоляции и их параметров.

Команда вывода доступных устройств:

ccs -h хост --lsfenceopts

Так, следующая команда покажет список исключающих устройств для узла node1.

[root@ask-03 ~]# ccs -h node1 --lsfenceopts
fence_rps10 - RPS10 Serial Switch
fence_vixel - No description available
fence_egenera - No description available
fence_xcat - No description available
fence_na - Node Assassin
fence_apc - Fence agent for APC over telnet/ssh
fence_apc_snmp - Fence agent for APC over SNMP
fence_bladecenter - Fence agent for IBM BladeCenter
fence_bladecenter_snmp - Fence agent for IBM BladeCenter over SNMP
fence_cisco_mds - Fence agent for Cisco MDS
fence_cisco_ucs - Fence agent for Cisco UCS
fence_drac5 - Fence agent for Dell DRAC CMC/5
fence_eps - Fence agent for ePowerSwitch
fence_ibmblade - Fence agent for IBM BladeCenter over SNMP
fence_ifmib - Fence agent for IF MIB
fence_ilo - Fence agent for HP iLO
fence_ilo_mp - Fence agent for HP iLO MP
fence_intelmodular - Fence agent for Intel Modular
fence_ipmilan - Fence agent for IPMI over LAN
fence_kdump - Fence agent for use with kdump
fence_rhevm - Fence agent for RHEV-M REST API
fence_rsa - Fence agent for IBM RSA
fence_sanbox2 - Fence agent for QLogic SANBox2 FC switches
fence_scsi - fence agent for SCSI-3 persistent reservations
fence_virsh - Fence agent for virsh
fence_virt - Fence agent for virtual machines
fence_vmware - Fence agent for VMware
fence_vmware_soap - Fence agent for VMware over SOAP API
fence_wti - Fence agent for WTI
fence_xvm - Fence agent for virtual machines

Получение списка параметров для конкретного типа изоляции:

ccs -h хост --lsfenceopts тип_исключения

Cледующая команда покажет список параметров для агента fence_wti.

[root@ask-03 ~]# ccs -h node1 --lsfenceopts fence_wti
fence_wti - Fence agent for WTI
  Required Options:
  Optional Options:
    option: No description available
    action: Fencing Action
    ipaddr: IP Address or Hostname
    login: Login Name
    passwd: Login password or passphrase
    passwd_script: Script to retrieve password
    cmd_prompt: Force command prompt
    secure: SSH connection
    identity_file: Identity file for ssh
    port: Physical plug number or name of virtual machine
    inet4_only: Forces agent to use IPv4 addresses only
    inet6_only: Forces agent to use IPv6 addresses only
    ipport: TCP port to use for connection with device
    verbose: Verbose mode
    debug: Write debug information to given file
    version: Display version information and exit
    help: Display help and exit
    separator: Separator for CSV created by operation list
    power_timeout: Test X seconds for status change after ON/OFF
    shell_timeout: Wait X seconds for cmd prompt after issuing command
    login_timeout: Wait X seconds for cmd prompt after login
    power_wait: Wait X seconds after issuing ON/OFF
    delay: Wait X seconds before fencing is started
    retry_on: Count of attempts to retry power on

Команда вывода настроенных устройств:

ccs -h хост --lsfencedev

5.7. Настройка изоляции узлов

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

Содержание:

Раздел 5.7.1, «Настройка изоляции с отключением питания»
Раздел 5.7.2, «Настройка изолирующего устройства SAN»
Раздел 5.7.3, «Настройка резервного устройства изоляции»
Раздел 5.7.4, «Изоляция при наличии нескольких источников питания»
Раздел 5.7.5, «Удаление экземпляров и методов изоляции»

5.7.1. Настройка изоляции с отключением питания

Ниже приведен пример настройки исключающего устройства питания apc, которое будет использовать агент fence_apc.

Сначала следует выбрать метод изоляции узла:
```
ccs -h хост --addmethod метод узел
```
Следующая команда настроит метод APC для узла node-01.example.com в файле конфигурации на node-01.example.com.
```
ccs -h node01.example.com --addmethod APC node01.example.com
```
Определить экземпляр устройства. В строке команды необходимо определить устройство изоляции, узел и название метода:
```
ccs -h хост --addfenceinst устройство узел метод [параметры]
```
Ниже приведен пример добавления экземпляра в файл конфигурации на node-01.example.com, который будет использовать порт 1 коммутатора APC на устройстве apc для изоляции узла node-01.example.com.
```
ccs -h node01.example.com --addfenceinst apc node01.example.com APC port=1
```

Для каждого узла в кластере необходимо определить метод изоляции. В приведенном ниже примере для всех узлов будет выбран метод APC. Соответствующее устройство с именем apc должно быть предварительно настроено при помощи --addfencedev (см. Раздел 5.5, «Настройка устройств изоляции»). Номера портов будут отличаться: для node-01.example.com будет выбран порт 1, для node-02.example.com — 2, для node-03.example.com — 3.

ccs -h node01.example.com --addmethod APC node01.example.com
ccs -h node01.example.com --addmethod APC node02.example.com
ccs -h node01.example.com --addmethod APC node03.example.com
ccs -h node01.example.com --addfenceinst apc node01.example.com APC port=1
ccs -h node01.example.com --addfenceinst apc node02.example.com APC port=2
ccs -h node01.example.com --addfenceinst apc node03.example.com APC port=3

Пример 5.2, «cluster.conf после добавления методов APC» демонстрирует пример настройки перечисленных методов и устройств в cluster.conf.

Пример 5.2. cluster.conf после добавления методов APC


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

5.7.2. Настройка изолирующего устройства SAN

Если изоляция узлов осуществляется без отключения питания, необходимо настроить условия ее отмены, что предотвратит активацию изолированного узла до тех пор, пока он не будет перезагружен. Дополнительно следует определить зеркальное устройство для настроенного устройства изоляции в режиме on или enable.

Подробную информацию можно найти на справочной странице fence_node(8).

Ниже приведен пример настройки устройства sanswitch1, которое будет использовать агент fence_sanbox2.

Сначала следует выбрать метод изоляции узла:
```
ccs -h хост --addmethod метод узел
```
Следующая команда настроит метод SAN для узла node-01.example.com в файле конфигурации на node-01.example.com.
```
ccs -h node01.example.com --addmethod SAN  node01.example.com
```
Определить экземпляр устройства. В строке команды необходимо определить устройство изоляции, узел и название метода:
```
ccs -h хост --addfenceinst устройство узел метод [параметры]
```
Ниже приведен пример добавления экземпляра в файл конфигурации на node-01.example.com, который будет использовать порт 11 коммутатора SAN на устройстве sanswitch1 для изоляции узла node-01.example.com.
```
ccs -h node01.example.com --addfenceinst sanswitch1 node01.example.com SAN port=11
```
Следующая команда определит порядок отмены изоляции узла:
```
ccs -h хост --addunfence имя_устройства узел action=on|off
```

Для каждого узла в кластере необходимо определить метод изоляции. В приведенном ниже примере для всех узлов будет выбран метод SAN. Соответствующее устройство с именем sanswitch должно быть предварительно настроено при помощи --addfencedev (см. Раздел 5.5, «Настройка устройств изоляции»). Номера портов будут отличаться: для node-01.example.com будет выбран порт 11, для node-02.example.com — 12, для node-03.example.com — 13.

ccs -h node01.example.com --addmethod SAN node01.example.com
ccs -h node01.example.com --addmethod SAN node02.example.com
ccs -h node01.example.com --addmethod SAN node03.example.com
ccs -h node01.example.com --addfenceinst sanswitch1 node01.example.com SAN port=11
ccs -h node01.example.com --addfenceinst sanswitch1 node02.example.com SAN port=12
ccs -h node01.example.com --addfenceinst sanswitch1 node03.example.com SAN port=13
ccs -h node01.example.com --addunfence sanswitch1 node01.example.com port=11 action=on
ccs -h node01.example.com --addunfence sanswitch1 node02.example.com port=12 action=on
ccs -h node01.example.com --addunfence sanswitch1 node03.example.com port=13 action=on

Пример 5.3, «cluster.conf после добавления методов SAN» демонстрирует пример настройки перечисленных методов и экземпляров в cluster.conf.

Пример 5.3. cluster.conf после добавления методов SAN


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="SAN">
	      <device name="sanswitch1" port="11"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="11" action="on"/> 
         </unfence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="SAN">
	      <device name="sanswitch1" port="12"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="12" action="on"/> 
         </unfence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="SAN">
	      <device name="sanswitch1" port="13"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="13" action="on"/> 
         </unfence>
     </clusternode>
   </clusternodes>
   <fencedevices>
        <fencedevice agent="fence_sanbox2" ipaddr="san_ip_example"
login="login_example" name="sanswitch1" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

5.7.3. Настройка резервного устройства изоляции

Для каждого узла можно определить несколько методов изоляции. Если один метод не работает, будет выбран следующий и т.п. Дополнительно можно настроить запасной метод для узла: для этого надо настроить два метода и один экземпляр для каждого метода.

Примечание

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

Ниже приведена команда просмотра текущих методов и экземпляров для выбранного узла. Если узел не указан, будет получена информация для всех узлов.

ccs -h хост --lsfenceinst [узел]

Ниже рассматривается порядок настройки основного метода, использующего устройство apc с агентом fence_apc, и запасного метода, использующего устройство sanswitch1 с агентом fence_sanbox2. Для sanswitch1 также потребуется настроить отмену изоляции.

Сначала следует выбрать основной метод изоляции.
```
ccs -h хост --addmethod метод узел
```
Следующая команда настроит метод APC для узла node-01.example.com в файле конфигурации на node-01.example.com.
```
ccs -h node01.example.com --addmethod APC node01.example.com
```
Определить экземпляр изоляции для основного метода. В строке команды необходимо определить устройство, узел и название метода изоляции:
```
ccs -h хост --addfenceinst устройство узел метод [параметры]
```
Ниже приведен пример добавления экземпляра в файл конфигурации на node-01.example.com, который будет использовать порт 1 коммутатора APC на устройстве apc для изоляции узла node-01.example.com.
```
ccs -h node01.example.com --addfenceinst apc node01.example.com APC port=1
```
После этого можно добавить запасной метод изоляции.
```
ccs -h хост --addmethod метод узел
```
Следующая команда настроит метод SAN для узла node-01.example.com в файле конфигурации на node-01.example.com.
```
ccs -h node01.example.com --addmethod SAN  node01.example.com
```
Определить экземпляр для резервного метода. В строке команды необходимо определить устройство, узел и название метода:
```
ccs -h хост --addfenceinst устройство узел метод [параметры]
```
Ниже приведен пример добавления экземпляра в файл конфигурации на node-01.example.com, который будет использовать порт 11 коммутатора SAN на устройстве sanswitch1 для изоляции узла node-01.example.com.
```
ccs -h node01.example.com --addfenceinst sanswitch1 node01.example.com SAN port=11
```
Для устройства sanswitch1 также потребуется настроить отмену изоляции.
```
ccs -h node01.example.com --addunfence sanswitch1 node01.example.com port=11 action=on
```

После этого можно будет добавить другие методы изоляции.

Таков порядок действий при настройке основного и запасного устройства для одного узла. Изоляция других узлов настраивается отдельно.

Пример 5.4, «cluster.conf после настройки запасного метода» демонстрирует пример настройки основного и запасного метода изоляции в cluster.conf.

Пример 5.4. cluster.conf после настройки запасного метода


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
            <method name="SAN">
	      <device name="sanswitch1" port="11"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="11" action="on"/> 
         </unfence
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
            <method name="SAN">
	      <device name="sanswitch1" port="12"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="12" action="on"/> 
         </unfence
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
            <method name="SAN">
	      <device name="sanswitch1" port="13"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="13" action="on"/> 
         </unfence
     </clusternode>
   </clusternodes>
   <fencedevices>
        <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
        <fencedevice agent="fence_sanbox2" ipaddr="san_ip_example" login="login_example" name="sanswitch1" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Примечание

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

5.7.4. Изоляция при наличии нескольких источников питания

Если в кластере настроено несколько источников питания, процесс исключения узла должен быть организован таким образом, чтобы проблемный узел мог быть полностью отключен. Если для каждого источника питания определен отдельный алгоритм, узел не будет отключен, так как вместо одного источника начнет использоваться другой. В такой ситуации надо отключить оба источника. Чтобы этого достичь, в один алгоритм следует включить два экземпляра для каждого устройства, в одном из которых атрибут определен как action=off, а во втором — action=off.

Ниже рассматривается порядок изоляции узла с двумя источниками питания.

Сначала надо определить оба источника питания как изолирующие устройства (см. Раздел 3.6, «Настройка устройств изоляции»).
Команда вывода настроенных устройств:
```
ccs -h хост --lsfencedev
```
Сначала следует выбрать метод изоляции узла:
```
ccs -h хост --addmethod метод узел
```
Следующая команда определит метод APC-dual для узла node-01.example.com в файле конфигурации на node-01.example.com.
```
ccs -h node01.example.com --addmethod APC-dual node01.example.com
```
После этого следует добавить экземпляр для первого источника питания. В строке команды необходимо определить устройство изоляции, узел, название метода и присвоить action значение off.
```
ccs -h хост --addfenceinst устройство узел метод [параметры] action=off
```
Ниже приведен пример добавления экземпляра в файл конфигурации на node-01.example.com, который будет использовать порт 1 коммутатора APC на устройстве apc1 для изоляции узла node-01.example.com при помощи метода APC-dual.
```
ccs -h node01.example.com --addfenceinst apc1 node01.example.com APC-dual port=1 action=off
```
После этого следует добавить экземпляр для второго источника питания. В строке команды необходимо определить устройство изоляции, узел, название метода и присвоить action значение off.
```
ccs -h хост --addfenceinst устройство узел метод [параметры] action=off
```
Ниже приведен пример добавления второго экземпляра в файл конфигурации на node-01.example.com, который использует порт 1 коммутатора APC на устройстве apc2 для изоляции узла node-01.example.com при помощи метода APC-dual.
```
ccs -h node01.example.com --addfenceinst apc2 node01.example.com APC-dual port=1 action=off
```
Теперь можно добавить другой экземпляр для первого источника питания, присвоив action значение on. В строке команды необходимо определить устройство изоляции, узел и название метода.
```
ccs -h хост --addfenceinst устройство узел метод [параметры] action=on
```
Ниже приведен пример добавления экземпляра в файл конфигурации на node-01.example.com, который будет использовать порт 1 коммутатора APC на устройстве apc1 для изоляции узла node-01.example.com при помощи метода APC-dual. Но в этом случае атрибуту action будет присвоено значение on.
```
ccs -h node01.example.com --addfenceinst apc1 node01.example.com APC-dual port=1 action=on
```
Теперь можно добавить другой экземпляр для второго источника питания, присвоив action значение on. В строке команды необходимо определить устройство изоляции, узел и название метода.
```
ccs -h хост --addfenceinst устройство узел метод [параметры] action=on
```
Ниже приведен пример добавления второго экземпляра в файл конфигурации на node-01.example.com, который использует порт 1 коммутатора APC на устройстве apc2 для изоляции узла node-01.example.com при помощи метода APC-dual. В этом случае атрибуту action будет присвоено значение on.
```
ccs -h node01.example.com --addfenceinst apc2 node01.example.com APC-dual port=1 action=on
```

Пример 5.5, «cluster.conf после добавления методов изоляции двух источников питания» демонстрирует пример настройки изоляции обоих источников питания в cluster.conf.

Пример 5.5. cluster.conf после добавления методов изоляции двух источников питания


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC-dual">
              <device name="apc1" port="1"action="off"/>
              <device name="apc2" port="1"action="off"/>
              <device name="apc1" port="1"action="on"/>
              <device name="apc2" port="1"action="on"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC-dual">
              <device name="apc1" port="2"action="off"/>
              <device name="apc2" port="2"action="off"/>
              <device name="apc1" port="2"action="on"/>
              <device name="apc2" port="2"action="on"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC-dual">
              <device name="apc1" port="3"action="off"/>
              <device name="apc2" port="3"action="off"/>
              <device name="apc1" port="3"action="on"/>
              <device name="apc2" port="3"action="on"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
       <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc1" passwd="password_example"/>
       <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc2" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

5.7.5. Удаление экземпляров и методов изоляции

Удаление метода изоляции из конфигурации кластера осуществляется следующим образом:

ccs -h хост --rmmethod метод узел

Следующая команда удалит метод APC для узла node-01.example.com в файле конфигурации на node-01.example.com.

ccs -h node01.example.com  --rmmethod APC node01.example.com

Удаление всех экземпляров выбранного устройства:

ccs -h хост --rmfenceinst устройство узел метод

Следующая команда удалит экземпляры устройства apc1 из алгоритма APC-dual для узла node-01.example.com в файле конфигурации на node-01.example.com.

ccs -h node01.example.com --rmfenceinst apc1 node01.example.com APC-dual

5.8. Настройка резервного домена

Неограниченный — позволяет выбрать предпочитаемую группу узлов. При этом служба, закрепленная за этим доменом, может работать на любом доступном узле.
Ограниченный — кластерная служба может выполняться только на заранее определенных узлах. Если в домене не осталось доступных узлов, служба не сможет быть запущена.
Неупорядоченный — восстановление службы может происходить на любом узле в составе домена без каких-либо предпочтений.
Упорядоченный — позволяет определить порядок выбора узлов для восстановления службы. Узел в начале списка является наиболее предпочтительным, в конце — наименее предпочтительным.
С возвратом — разрешает возврат службы на исходный узел после возобновления его работы. Настройка этой характеристики помогает при периодических сбоях узла, входящего в состав упорядоченного домена, так как если узел является предпочтительным, может оказаться так, что служба будет бесконечно переноситься с него на другой узел и обратно, что значительно снизит производительность.
Примечание
Функция возврата доступна только для упорядоченного типа.

Примечание

Изменение конфигурации резервного домена не окажет влияния на уже запущенные службы.

Примечание

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

По умолчанию используются два типа — неограниченный и неупорядоченный.

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

Примечание

Ниже рассматривается порядок настройки резервного домена.

Добавление резервного домена:
```
ccs -h хост --addfailoverdomain имя [restricted] [ordered] [nofailback]
```
Примечание
Рекомендуется указать информативное имя для облегчения идентификации домена.
Так, следующая команда настроит резервный домен example_pri (неограниченный, упорядоченный, с возвратом) на node-01.example.com:
```
ccs -h node-01.example.com --addfailoverdomain example_pri ordered
```
Добавление узлов в резервный домен:
```
ccs -h хост --addfailoverdomainnode домен узел приоритет
```
В следующем примере в файл конфигурации на node-01.example.com будет добавлен домен example_pri, в состав которого войдут узлы node-01.example.com (приоритет 1), node-02.example.com (приоритет 2) и node-03.example.com (приоритет 3).
```
ccs -h node-01.example.com --addfailoverdomainnode example_pri node-01.example.com 1
ccs -h node-01.example.com --addfailoverdomainnode example_pri node-02.example.com 2
ccs -h node-01.example.com --addfailoverdomainnode example_pri node-03.example.com 3
```

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

ccs -h хост --lsfailoverdomain

Удаление резервного домена:

ccs -h хост --rmfailoverdomain имя

Удаление узлов из резервного домена:

ccs -h хост --rmfailoverdomainnode домен узел

5.9. Так, следующая команда покажет список служб на узле `node1`.

В целом, можно настроить два типа ресурсов:

глобальные ресурсы — доступны в пределах кластера;
служебные ресурсы — доступны определенной службе.

Полный список ресурсов и служб кластера можно получить при помощи команды:

ccs -h узел --lsservices

Ниже приведена команда добавления глобального ресурса. Раздел 5.10, «Добавление кластерной службы» подробно рассматривает порядок добавления локальных ресурсов для службы во время ее настройки.

ccs -h хост --addresource тип [параметры]

Так, следующая команда добавит ресурс файловой системы под именем web_fs в файл конфигурации на node01.example.com. Файловая система ext3 расположена на /dev/sdd2 и смонтирована в /var/www.

ccs -h node01.example.com --addresource fs name=web_fs device=/dev/sdd2 mountpoint=/var/www fstype=ext3

Приложение B, Параметры ресурсов содержит информацию о типах ресурсов и их параметрах.

Удаление глобального ресурса:

ccs -h хост --rmresource тип [параметры]

Если необходимо изменить параметры ресурса, следует его удалить и настроить заново.

5.10. Добавление кластерной службы

Ниже рассматривается порядок настройки кластерной службы.

Добавление службы:
```
ccs -h хост --addservice служба [параметры]
```
Примечание
Рекомендуется указать информативное имя для облегчения идентификации службы.
При добавлении службы в конфигурацию кластера потребуется настроить несколько атрибутов:
- autostart — значение 1 разрешает автоматический запуск службы при запуске кластера, а 0 отключает эту возможность. По умолчанию равен 1.
- domain — резервный домен (дополнительно).
- exclusive — запрещает запуск службы, если на узле уже работают другие службы.
- recovery — определяет политику восстановления работы службы. Возможные варианты включают перенос, перезапуск, отключение или повторный запуск с отключением в случае неудачи. При выборе Restart система попытается перезапустить сбойную службу до ее переноса на другой узел. Relocate подразумевает перезапуск службы на другом узле, Disable отключит группу ресурсов при сбое ее компонентов, а Restart-Disable попытается заново запустить службу, но в случае неудачи она будет отключена.
  При выборе Restart или Restart-Disable дополнительно можно указать максимальное число попыток перезапуска и время ожидания, по истечении которого попытки будут прекращены.
Ниже приведен пример добавления службы example_apache в файл конфигурации на node-01.example.com с использованием политики relocate и резервного домена example_pri.
```
ccs -h node-01.example.com --addservice example_apache domain=example_pri recovery=relocate
```
Дополнительно ccs позволяет получить полный список доступных в кластере служб и их параметров (см. Раздел 5.11, «Получение списка доступных служб» ).
Добавление ресурсов для службы:
```
ccs -h хост --addsubservice служба ресурс [параметры]
```
Допускается добавление глобальных или специализированных ресурсов. Параметр --addsubservice отвечает за добавление глобальных ресурсов. Так, ниже приведен пример добавления ресурса web_fs в файл конфигурации на узле node-01.example.com.
```
ccs -h node01.example.com --addsubservice example_apache fs ref=web_fs
```
При добавлении специализированного ресурса потребуется определить все параметры. Например, если web_fs предварительно не была объявлена как глобальная служба, для ее добавления в качестве специализированного ресурса необходимо выполнить:
```
ccs -h node01.example.com --addsubservice example_apache fs name=web_fs device=/dev/sdd2 mountpoint=/var/www fstype=ext3
```
Параметр --addsubservice также позволяет определить подчиненные службы.
Этот параметр может содержать целую иерархию служб. При этом службы в списке разделяются двоеточием, а службы одного типа идентифицируются номером в квадратных скобках следом за их именем. Так, ниже приведен пример добавления третьей подчиненной службы nfsclient для nfsclient, которая является подчиненной по отношению к service_a.
```
ccs -h node01.example.com --addsubservice service_a nfsclient[1]:nfsclient[2]:nfsclient
```
Примечание
Ресурсы Samba не могут быть подчиненными — они должны добавляться напрямую.

Примечание

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1356 qdisc pfifo_fast qlen 1000
    link/ether 00:05:5d:9a:d8:91 brd ff:ff:ff:ff:ff:ff
    inet 10.11.4.31/22 brd 10.11.7.255 scope global eth0
    inet6 fe80::205:5dff:fe9a:d891/64 scope link
    inet 10.11.4.240/22 scope global secondary eth0
       valid_lft forever preferred_lft forever

Удаление службы, включая подчиненные:

ccs -h хост --rmservice служба

Удаление подчиненной службы:

ccs -h хост --rmsubservice служба подчиненная [параметры]

5.11. Получение списка доступных служб

С помощью ccs можно вывести список доступных служб и их параметров.

Команда вывода доступных в кластере служб:

ccs -h хост --lsserviceopts

Так, следующая команда покажет список служб на узле node1.

[root@ask-03 ~]# ccs -h node1 --lsserviceopts
service - Defines a service (resource group).
ASEHAagent - Sybase ASE Failover Instance
SAPDatabase - SAP database resource agent
SAPInstance - SAP instance resource agent
apache - Defines an Apache web server
clusterfs - Defines a cluster file system mount.
fs - Defines a file system mount.
ip - This is an IP address.
lvm - LVM Failover script
mysql - Defines a MySQL database server
named - Defines an instance of named server
netfs - Defines an NFS/CIFS file system mount.
nfsclient - Defines an NFS client.
nfsexport - This defines an NFS export.
nfsserver - This defines an NFS server resource.
openldap - Defines an Open LDAP server
oracledb - Oracle 10g Failover Instance
orainstance - Oracle 10g Failover Instance
oralistener - Oracle 10g Listener Instance
postgres-8 - Defines a PostgreSQL server
samba - Dynamic smbd/nmbd resource agent
script - LSB-compliant init script as a clustered resource.
tomcat-6 - Defines a Tomcat server
vm - Defines a Virtual Machine
action - Overrides resource action timings for a resource instance.

Получение списка параметров для определенного типа служб:

ccs -h хост --lsserviceopts тип_службы

Cледующая команда покажет список параметров vm:

[root@ask-03 ~]# ccs -f node1 --lsserviceopts vm
vm - Defines a Virtual Machine
  Required Options:
    name: Name
  Optional Options:
    domain: Cluster failover Domain
    autostart: Automatic start after quorum formation
    exclusive: Exclusive resource group
    recovery: Failure recovery policy
    migration_mapping: memberhost:targethost,memberhost:targethost ..
    use_virsh: If set to 1, vm.sh will use the virsh command to manage virtual machines instead of xm. This is required when using non-Xen virtual machines (e.g. qemu / KVM).
    xmlfile: Full path to libvirt XML file describing the domain.
    migrate: Migration type (live or pause, default = live).
    path: Path to virtual machine configuration files.
    snapshot: Path to the snapshot directory where the virtual machine image will be stored.
    depend: Top-level service this depends on, in service:name format.
    depend_mode: Service dependency mode (soft or hard).
    max_restarts: Maximum restarts for this service.
    restart_expire_time: Restart expiration time; amount of time before a restart is forgotten.
    status_program: Additional status check program
    hypervisor: Hypervisor
    hypervisor_uri: Hypervisor URI (normally automatic).
    migration_uri: Migration URI (normally automatic).
    __independent_subtree: Treat this and all children as an independent subtree.
    __enforce_timeouts: Consider a timeout for operations as fatal.
    __max_failures: Maximum number of failures before returning a failure to a status check.
    __failure_expire_time: Amount of time before a failure is forgotten.
    __max_restarts: Maximum number restarts for an independent subtree before giving up.
    __restart_expire_time: Amount of time before a failure is forgotten for an independent subtree.

5.12. Ресурсы виртуальных машин

Порядок настройки ресурсов виртуальных машин отличается от настройки других кластерных ресурсов. В частности, ресурсы виртуальных машин не объединяются в группы служб и вместо addservice используется параметр --addvm. Это позволяет поместить определение vm сразу под rm в файле конфигурации.

При добавлении виртуальной машины надо как минимум определить параметры name и path. Значение name должно совпадать с именем домена libvirt, а путь должен содержать каталог с общими определениями виртуальной машины.

Примечание

path должен содержать путь к каталогу, а не к отдельному файлу.

Например, если определения хранятся в /mnt/vm_defs, следующая команда добавит виртуальную машину guest1:

# ccs -h node1.example.com --addvm guest1 path=/mnt/vm_defs

В секцию cluster.conf файла cluster.conf будет добавлено:

<vm name="guest1" path="/mnt/vm_defs"/>

5.13. Настройка кворумного диска

Примечание

Поведение и эвристические правила кворумного диска определяются в соответствии с требованиями окружения. Подробную информацию можно найти на справочной странице qdisk(5). За дополнительной помощью рекомендуется обратиться к официальному представителю службы технической поддержки Red Hat.

Команда настройки кворумного диска:

ccs -h хост --setquorumd [параметры]

Эта команда восстановит исходные значения всех остальных параметров (см. Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки»).

Таблица 5.1, «Параметры диска кворума» содержит список основных параметров. Полный список можно найти в /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html.

Таблица 5.1. Параметры диска кворума

Параметр	Описание
interval	Частота циклов чтения и записи (в секундах).
votes	Число голосов, которое будет объявлено службе `cman` при наличии достаточно высокого приоритета.
tko	Число пропущенных циклов, после чего узел будет признан нерабочим.
min_score	Минимальный приоритет, необходимый для подтверждения рабочего состояния узла. Если не задан или равен нулю, расчет будет осуществляться в соответствии с формулой `floor((n+1)/2)` (где n — сумма приоритетов эвристических правил). Значение Minimum Score не должно превышать n, так как в этом случае кворумный диск будет недоступен.
device	Используемый процессом qdiskd накопитель. На всех узлах должно быть выбрано одно и то же устройство.
label	Метка, присвоенная кворумному диску утилитой `mkqdisk`. Переопределяет значение поля Device. Если указана, qdiskd обращается к `/proc/partitions`, проверяет наличие подписей qdisk на перечисленных в файле устройствах и сравнивает метки. Обычно используется, если имя кворумного диска на разных узлах отличается.

Команда настройки эвристического правила для кворумного диска:

ccs -h хост --addheuristic [параметры]

Таблица 5.2, «Эвристические правила кворума» содержит список основных правил.

Таблица 5.2. Эвристические правила кворума

Параметр	Описание
program	Путь к программе проверки наличия эвристического метода. Можно выбрать любую программу, которую можно запустить с помощью `/bin/sh -c`. Нулевой результат обозначает успех. Этот параметр является обязательным.
interval	Частота опроса эвристического правила в секундах. По умолчанию проверка осуществляется каждые 2 секунды.
score	Вес правила (по умолчанию — 1).
tko	Число неудачных попыток, после чего эвристический метод будет признан недоступным.

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

ccs -h хост --lsquorum

Удаление эвристического правила:

ccs -h host rmheuristic [правило параметры]

Примечание

Чтобы обеспечить нормальную работу кворумного диска, потребуется перезапустить кластер, тем самым перезапустив qdiskd на всех узлах (см. Раздел 6.2, «Запуск и остановка кластера»).

5.14. Прочие характеристики кластера

Содержание главы:

Раздел 5.14.1, «Версия конфигурации кластера»
Раздел 5.14.2, «Конфигурация многоадресной передачи»
Раздел 5.14.3, «Кластер с двумя узлами»
Раздел 5.14.4, «Ведение журналов»
Раздел 5.14.5, «Настройка протокола избыточного кольца»

ccs позволяет определить и более сложные характеристики кластера, включая параметры totem, dlm, rm и cman. Подробную информацию можно найти на справочной странице ccs(8) и в схеме /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html.

Команда просмотра настроенных атрибутов кластера:

ccs -h хост --lsmisc

5.14.1. Версия конфигурации кластера

Файл конфигурации содержит номер версии конфигурации кластера. Изначально это значение равно 1 и автоматически увеличивается на единицу каждый раз при изменении конфигурации. По желанию можно установить другое значение:

ccs -h хост --setversion n

Получение текущей версии:

ccs -h хост --getversion

Следующая команда увеличит номер версии на всех узлах на единицу:

ccs -h хост --incversion

5.14.2. Конфигурация многоадресной передачи

Если в файле конфигурации не определен адрес многоадресной рассылки, Red Hat High Availability создаст широковещательный адрес исходя из идентификатора кластера. Так, будут сгенерированы последние 16 бит и добавлены к первой части адреса, которая определяется протоколом (IPv4 или IPv6). Адрес формируется следующим образом:

Для IPv4 — 239.192. плюс 16 бит, сформированных комплектом Red Hat High Availability.
Для IPv6 — FF15:: плюс 16 бит, сгенерированных комплектом Red Hat High Availability.

Примечание

cman генерирует уникальный идентификатор кластера. Для его просмотра используется cman_tool status.

Адрес может быть задан явно:

ccs -h хост --setmulticast адрес

Эта команда восстановит исходные значения остальных параметров, которые может изменить аргумент --setmulticast (см. Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки»).

Адрес должен быть определен в формате 239.192.x.x (или FF15:: для IPv6), совместимом с cman. Неверный адрес может привести к непредсказуемым результатам, например может оказаться так, что адрес 224.0.0.x, охватывающий все узлы в сети, неверно маршрутизируется оборудованием.

Чтобы изменения вступили в силу, потребуется перезагрузить кластер (см. Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера»).

Примечание

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

Удаление группового адреса из файла конфигурации осуществляется с помощью --setmulticast:

ccs -h хост --setmulticast

5.14.3. Кластер с двумя узлами

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

ccs -h хост --setcman two_node=1 expected_votes=1

Эта команда восстановит исходные значения остальных параметров, которые может изменить аргумент --setcman (см. Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки»).

5.14.4. Ведение журналов

Ведение журнала может быть настроено выборочно или для всех процессов в кластере.

Следущая команда включит регистрацию событий для всех процесов. По умолчанию журналы хранятся в /var/log/cluster/процесс.log.

ccs -h хост --setlogging [параметры]

Пример:

# ccs -h node1.example.com --setlogging debug=on

Эта команда восстановит исходные значения остальных параметров, которые может изменить аргумент --setlogging (см. Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки»).

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

ccs -h хост --addlogging [параметры_журналирования]

Так, следующие команды включат регистрацию отладочных сообщений corosync и fenced.

# ccs -h node1.example.com --addlogging name=corosync debug=on
# ccs -h node1.example.com --addlogging name=fenced debug=on

Команда отключения журналирования индивидуальных процессов:

ccs -h хост --rmlogging name=процесс

Следующая команда отключит ведение журнала для fenced:

ccs -h хост --rmlogging name=fenced

Список процессов, для которых можно настроить ведение журналов, можно найти на справочной странице cluster.conf(5).

5.14.5. Настройка протокола избыточного кольца

Чтобы определить второй сетевой интерфейс для избыточного кольца, надо определить дополнительное имя с помощью аргумента --addalt:

ccs -h хост --addalt узел доп.имя

Ниже приведен пример определения дополнительного имени clusternet-node1-eth2 для узла clusternet-node1-eth1.

# ccs -h clusternet-node1-eth1 --addalt clusternet-node1-eth1 clusternet-node1-eth2

Дополнительные адрес многоадресной рассылки, порт и TTL второго кольца можно определить с помощью аргумента --setaltmulticast команды ccs:

ccs -h host --setaltmulticast [доп.адрес] [доп.параметры].

Следующая команда определяет дополнительный адрес 239.192.99.88, порт 888 и TTL со значением 3 в файле cluster.conf на узле clusternet-node1-eth1:

ccs -h clusternet-node1-eth1 --setaltmulticast 239.192.99.88 port=888 ttl=3

Чтобы удалить дополнительный адрес, выполните ccs с аргументом --setaltmulticast, но не указывайте адрес. При этом стоит помнить, что эта команда также восстановит исходные значения остальных параметров, которые может изменить аргумент --setmulticast (см. Раздел 5.1.5, «Команды, переопределяющие предыдущие настройки»).

5.15. Синхронизация файла конфигурации

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

Команда синхронизации и активации файла конфигурации:

ccs -h хост --sync --activate

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

ccs -h хост --checkconf

Если файл конфигурации был создан или изменен локально, следующая команда скопирует его на указанный узел:

ccs -f файл -h узел --setconf

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

ccs -f файл --checkconf

Глава 6. Управление кластером с помощью ccs

В данной главе описываются различные процедуры управления кластером при помощи утилиты ccs, которая была впервые представлена в Red Hat Enterprise Linux 6.1. Содержание главы:

Раздел 6.1, «Управление узлами кластера»
Раздел 6.2, «Запуск и остановка кластера»
Раздел 6.3, «Диагностика конфликтов в кластере»

6.1. Управление узлами кластера

В этой секции рассматриваются основные функции управления узлами.

Раздел 6.1.1, «Добавление и удаление узлов»
Раздел 6.1.2, «Добавление узла в работающий кластер»

6.1.1. Добавление и удаление узлов

Ниже приведен порядок удаления узла из кластера посредством остановки кластерных служб. Удаленный узел не будет включен в состав кластера после перезагрузки.

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

ccs -h узел --stop

Остановка кластерных служб на узле автоматически вызовет процесс переноса его процессов на другой узел.

Добавление параметра --rmnode окончательно удалит узел из конфигурации кластера (см. Раздел 5.4, «Создание кластера»).

Чтобы заново добавить узел в кластер, выполните следующую команду для запуска кластерных служб:

ccs -h узел --start

6.1.2. Добавление узла в работающий кластер

Раздел 5.4, «Создание кластера» содержит информацию о добавлении узла в работающий кластер. После обновления файла конфигурации следует его скопировать на все узлы и активировать новую конфигурацию (см. Раздел 5.15, «Синхронизация файла конфигурации»).

6.2. Запуск и остановка кластера

Чтобы остановить работу кластера, необходимо остановить работу кластерных служб на всех его узлах:

ccs -h узел --stopall

Чтобы запустить кластер, необходимо запустить кластерные службы на всех его узлах:

ccs -h узел --startall

6.3. Диагностика конфликтов в кластере

Глава 9, Диагностика и решение конфликтов в кластере содержит подробную информацию о диагностике конфликтов в кластере, но вы можете выполнить проверку самостоятельно с помощью ccs.

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

ccs -h узел --checkconf

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

ccs -f файл --checkconf

Глава 7. Настройка кластера в командной строке

В этой главе рассматриваются задачи настройки кластера посредством прямого редактирования файла конфигурации /etc/cluster/cluster.conf и с помощью инструментов командной строки. Так, будет приведен порядок создания файла конфигурации на основе существующего шаблона. В качестве шаблона можно использовать пример со справочной страницы cluster.conf. Существуют разные способы создания файла конфигурации кластера, но эта глава концентрируется на последовательном создании файла по секциям.

Содержание главы:

Раздел 7.1, «Задачи настройки»
Раздел 7.2, «Создание базового файла конфигурации»
Раздел 7.3, «Исключение узлов из кластера»
Раздел 7.4, «Настройка резервных доменов»
Раздел 7.5, «Настройка служб высокой готовности»
Раздел 7.7, «Ведение журналов»
Раздел 7.6, «Настройка протокола избыточного кольца»
Раздел 7.8, «Проверка конфигурации»

Важно

Прежде чем ввести Red Hat High Availability в эксплуатацию, рекомендуется проконсультироваться с представителем Red Hat на предмет соответствия конфигурации системы требованиям.

Важно

В этой главе упоминаются параметры из файла cluster.conf, полный список и описание которых можно найти в /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html).

Важно

Некоторые действия в этой главе предлагают выполнить cman_tool version -r для передачи конфигурации кластера узлам. Эта команда требует, чтобы в системе выполнялся процесс ricci. В свою очередь, при обращении к ricci необходимо ввести пароль (см. Раздел 2.13, «ricci»).

Примечание

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

7.1. Задачи настройки

Ниже перечислены основные этапы настройки Red Hat High Availability с помощью команд.

Раздел 7.2, «Создание базового файла конфигурации».
Раздел 7.3, «Исключение узлов из кластера».
Раздел 7.4, «Настройка резервных доменов».
Раздел 7.5, «Настройка служб высокой готовности».
Раздел 7.8, «Проверка конфигурации».

7.2. Создание базового файла конфигурации

Если Red Hat Enterprise Linux и Red Hat High Availability уже установлены, для создания кластера останется только создать файл конфигурации /etc/cluster/cluster.conf и запустить кластерные службы. Эта секция ориентирована на создание базового файла конфигурации. Более сложные операции — изоляция узлов, настройка резервных доменов и служб высокой готовности — будут рассмотрены позднее.

Важно

В результате будет создан простой файл конфигурации. Такая версия не считается завершенной.

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

Создайте файл /etc/cluster/cluster.conf на любом узле (см. Пример 7.1, «cluster.conf. Базовая конфигурация»).
Дополнительно: при настройке кластера с двумя узлами можно позволить одному узлу поддерживать кворум:
<cman two_node="1" expected_votes="1"/>
Операции добавления или удаления two_node из cluster.conf требуют перезапуска кластера (см. Раздел 8.4, «Обновление конфигурации»). Пример 7.2, «cluster.conf. Базовая конфигурация для двух узлов» содержит пример настройки two_node.
После этого можно выбрать имя кластера и номер версии конфигурации с помощью атрибутов name и config_version в строке cluster (см. Пример 7.1, «cluster.conf. Базовая конфигурация» и Пример 7.2, «cluster.conf. Базовая конфигурация для двух узлов»).
В секции clusternodes для каждого узла можно определить имя и идентификатор с помощью атрибутов name и nodeid в строке clusternode.
Сохраните /etc/cluster/cluster.conf.
Проверьте соответствие его формата схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Скопируйте изменения в /etc/cluster/ на каждом узле. Это можно сделать с помощью scp.
Примечание
Копирование конфигурации работающего кластера рекомендуется выполнять с помощью cman_tool version -r. По желанию можно использовать scp, но при этом потребуется остановить кластерные программы на всех узлах и выполнить проверку ccs_config_validate.
Примечание
Базовый шаблон содержит и другие элементы, но они будут рассмотрены позднее.

Запустите кластер на всех узлах:

service cman start

Пример:

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]

Выполните cman_tool nodes на любом узле, чтобы убедиться, что все узлы успешно вошли в состав кластера, о чем сообщает значение «M» в столбце статуса:

[root@example-01 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M    548   2010-09-28 10:52:21  node-01.example.com
   2   M    548   2010-09-28 10:52:21  node-02.example.com
   3   M    544   2010-09-28 10:52:21  node-03.example.com

После успешного создания кластера можно приступить к настройке изоляции узлов (см. Раздел 7.3, «Исключение узлов из кластера»).

7.2.1. Примеры cluster.conf

Пример 7.1, «cluster.conf. Базовая конфигурация» и Пример 7.2, «cluster.conf. Базовая конфигурация для двух узлов» демонстрируют две схемы, на основе которых будут позднее настроены возможности изоляции узлов и службы высокой готовности.

Пример 7.1. cluster.conf. Базовая конфигурация


<cluster name="mycluster" config_version="2">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Пример 7.2. cluster.conf. Базовая конфигурация для двух узлов


<cluster name="mycluster" config_version="2">
   <cman two_node="1" expected_votes="1"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

7.2.2. Значение `consensus` элемента `totem` в кластере с двумя узлами

Если кластер содержит два узла, и в будущем добавление других узлов не планируется, можно опустить значение consensus в строке totem. В таком случае оно будет рассчитываться автоматически по принципу:

Если число узлов не превышает двух, то (token * 0.2) с допустимым диапазоном 200 - 2000 мс.
Если число узлов больше или равно трем, то (token + 2000 мс).

При увеличении числа узлов с 2 до 3 (и более) потребуется перезапустить кластер, так как формула расчета изменится.

Если в кластер с двумя узлами планируется добавить дополнительные узлы, необходимость перезапуска кластера можно предотвратить, переопределив consensus в строке totem:


<totem token="X" consensus="X + 2000" />

Вместо (X + 2000) необходимо указать полученное целое значение.

Главным достоинством этого подхода является сокращение времени восстановления в кластере с двумя узлами, так как значение consensus не является динамическим.

Следует помнить, что функции автоматического обнаружения узлов cman учитывают только наличие физических узлов в кластере с двумя элементами, а не наличие two_node=1 в cluster.conf.

7.3. Исключение узлов из кластера

Настройка функций изоляции в кластере включает выбор устройств и методов изоляции.

Ниже перечислены особенности настройки изоляции в cluster.conf.

Секция fencedevices содержит список исключающих устройств, каждое из которых определено в элементе fencedevice (см. Пример 7.3, «Добавление устройства APC в cluster.conf»).
Метод изоляции определяется при помощи элемента fence для каждого clusternode в секции clusternodes. Атрибут name в строке method содержит название метода, а элемент device содержит характеристики устройства изоляции (см. Пример 7.4, «Добавление методов изоляции в cluster.conf»).
Для методов, контролирующих доступ к хранилищу и SAN, в clusternodes надо будет добавить секцию unfence. Этот параметр предотвращает подключение изолированного узла к хранилищу до тех пор, пока он не будет перезагружен. Подробную информацию можно найти на справочной странице fence_node(8).
unfence включает элемент device, идентичный одноименному элементу в секции fence, но с параметром action= "on" (или "enable"). То есть обе секции ссылаются на одно устройство из fencedevice.
Присвоение параметру action значения "on" или "enable" отвечает за активацию узла после перезагрузки (см. Пример 7.4, «Добавление методов изоляции в cluster.conf» и Пример 7.5, «Несколько методов изоляции для одного узла»).
Подробную информацию о unfence можно найти на справочной странице fence_node.
Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Дополнительно можно выполнить проверку соответствия формата схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере. При этом еще раз будет проверен формат файла. Предварительно убедитесь, что на всех узлах выполняется процесс ricci.
Убедитесь, что конфигурация была скопирована.
Раздел 7.4, «Настройка резервных доменов» содержит дальнейшую информацию.

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

Иногда для изоляции узла может потребоваться отключить два пути ввода-вывода или два порта питания. Для этого надо определить как минимум два устройства для одного метода. Процесс fenced запустит агент изоляции один раз для каждой строки fencedevice. Изоляция успешна при условии успешной изоляции всех устройств.

«Примеры настройки изоляции» содержит примеры сложной конфигурации.

Инструкции по настройке конкретных типов устройств можно найти на их справочных страницах (например, fence_apc). Приложение A, Параметры устройств изоляции, справочные файлы агентов изоляции в /usr/sbin/, схемы /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html) содержат дополнительную информацию.

7.3.1. Примеры настройки изоляции

Примеры простой конфигурации с одним методом изоляции для каждого узла и одним устройством для каждого метода:

Пример 7.3, «Добавление устройства APC в cluster.conf»
Пример 7.4, «Добавление методов изоляции в cluster.conf»

Примеры более сложных схем:

Пример 7.5, «Несколько методов изоляции для одного узла»
Пример 7.6, «Изоляция с многопутевыми устройствами»
Пример 7.7, «Изоляция узлов с двумя источниками питания»

Примечание

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

Пример 7.3. Добавление устройства APC в cluster.conf


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Здесь в секцию fencedevices добавлен элемент fencedevice с параметрами agent, ipaddr, login, name и passwd.

Пример 7.4. Добавление методов изоляции в cluster.conf


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

В этом примере для каждого из трех узлов будет добавлен метод APC для устройства с именем apc с уникальным номером порта. Например, для node-01.example.com будет выделен порт 1 (port="1"). Выражение (device name="apc") ссылается на одноименное устройство в секции fencedevices: fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example".

Пример 7.5. Несколько методов изоляции для одного узла


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
            <method name="SAN">
	      <device name="sanswitch1" port="11"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="11" action="on"/> 
         </unfence
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
            <method name="SAN">
	      <device name="sanswitch1" port="12"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="12" action="on"/> 
         </unfence
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
            <method name="SAN">
	      <device name="sanswitch1" port="13"/>
             </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="13" action="on"/> 
         </unfence
     </clusternode>
   </clusternodes>
   <fencedevices>
        <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
        <fencedevice agent="fence_sanbox2" ipaddr="san_ip_example"
login="login_example" name="sanswitch1" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Пример 7.6. Изоляция с многопутевыми устройствами


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="SAN-multi">
	      <device name="sanswitch1" port="11"/>
	      <device name="sanswitch2" port="11"/>
	    </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="11" action="on"/>
             <device name="sanswitch2" port="11" action="on"/>
         </unfence
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="SAN-multi">
	      <device name="sanswitch1" port="12"/>
	      <device name="sanswitch2" port="12"/>
            </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="12" action="on"/>
             <device name="sanswitch2" port="12" action="on"/>
         </unfence
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="SAN-multi">
	      <device name="sanswitch1" port="13"/>
	      <device name="sanswitch2" port="13"/>
            </method>
         </fence>
         <unfence>
             <device name="sanswitch1" port="13" action="on"/>
             <device name="sanswitch2" port="13" action="on"/>
         </unfence
     </clusternode>
   </clusternodes>
   <fencedevices>
        <fencedevice agent="fence_sanbox2" ipaddr="san_ip_example"
login="login_example" name="sanswitch1" passwd="password_example"/> 
        <fencedevice agent="fence_sanbox2" ipaddr="san_ip_example"
login="login_example" name="sanswitch2" passwd="password_example"/> 
   </fencedevices>
   <rm>
   </rm>
</cluster>

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


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC-dual">
              <device name="apc1" port="1"action="off"/>
              <device name="apc2" port="1"action="off"/>
              <device name="apc1" port="1"action="on"/>
              <device name="apc2" port="1"action="on"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC-dual">
              <device name="apc1" port="2"action="off"/>
              <device name="apc2" port="2"action="off"/>
              <device name="apc1" port="2"action="on"/>
              <device name="apc2" port="2"action="on"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC-dual">
              <device name="apc1" port="3"action="off"/>
              <device name="apc2" port="3"action="off"/>
              <device name="apc1" port="3"action="on"/>
              <device name="apc2" port="3"action="on"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
       <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc1" passwd="password_example"/>
       <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc2" passwd="password_example"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

При настройке изоляции узла с двумя источниками питания необходимо настроить одновременное отключение их портов.

7.4. Настройка резервных доменов

Неограниченный — позволяет выбрать предпочитаемую группу узлов. При этом служба, закрепленная за этим доменом, может работать на любом доступном узле.
Ограниченный — кластерная служба может выполняться только на заранее определенных узлах. Если в домене не осталось доступных узлов, служба не сможет быть запущена.
Неупорядоченный — восстановление службы может происходить на любом узле в составе домена без каких-либо предпочтений.
Упорядоченный — позволяет определить порядок выбора узлов для восстановления службы. Значение 1 обозначает наивысший приоритет, то есть чем меньше число, тем больше вероятность выбора узла.
С возвратом — разрешает возврат службы на исходный узел после его восстановления. Настройка этой характеристики помогает при периодических сбоях узла, входящего в состав упорядоченного домена, так как если узел является предпочтительным, может оказаться так, что служба будет бесконечно переноситься с него на другой узел и обратно, что значительно снизит производительность.
Примечание
Функция возврата доступна только для упорядоченного типа.

Примечание

Изменение конфигурации резервного домена не окажет влияния на уже запущенные службы.

Примечание

Для нормальной работы кластера резервные домены необязательны.

По умолчанию используется неограниченный и неупорядоченный типы.

Примечание

Ниже рассматривается порядок настройки резервного домена.

Откройте /etc/cluster/cluster.conf на любом узле.
Для каждого домена в секцию rm следует добавить следующий шаблон:
```
        <failoverdomains>
            <failoverdomain name="" nofailback="" ordered="" restricted="">
                <failoverdomainnode name="" priority=""/>
                <failoverdomainnode name="" priority=""/>
                <failoverdomainnode name="" priority=""/>
            </failoverdomain>
        </failoverdomains>
```
Примечание
Число элементов failoverdomainnode зависит от числа узлов в составе домена. В приведенном примере показано три элемента failoverdomainnode с незаполненными значениями имен.
Описание элементов секции failoverdomain можно найти в файле схемы /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html). Пример 7.8, «Добавление резервного домена в cluster.conf» содержит пример секции failoverdomains.
Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Дополнительно можно проверить соответствие формата схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
Раздел 7.5, «Настройка служб высокой готовности» содержит дальнейшую информацию.

Пример 7.8, «Добавление резервного домена в cluster.conf» содержит пример конфигурации упорядоченного, неограниченного домена.

Пример 7.8. Добавление резервного домена в cluster.conf


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
       <failoverdomains>
           <failoverdomain name="example_pri" nofailback="0" ordered="1" restricted="0">
               <failoverdomainnode name="node-01.example.com" priority="1"/>
               <failoverdomainnode name="node-02.example.com" priority="2"/>
               <failoverdomainnode name="node-03.example.com" priority="3"/>
           </failoverdomain>
       </failoverdomains>
   </rm>
</cluster>

failoverdomains содержит секции failoverdomain для всех резервных доменов. В приведенном примере определен один домен с именем example_pri, который не использует функцию возврата (failback="0"), является упорядоченным (ordered="1") и неограниченным (restricted="0").

7.5. Настройка служб высокой готовности

Настройка служб высокой готовности включает два этапа: настройку ресурсов и их выделение службам.

В этой главе приведена информация о добавлении ресурсов и служб в /etc/cluster/cluster.conf.

Раздел 7.5.1, «Добавление кластерных ресурсов»
Раздел 7.5.2, «Добавление кластерных служб»

Важно

Приложение B, Параметры ресурсов и Приложение C, Поведение ресурсов высокой готовности помогут ближе познакомиться с характеристиками ресурсов.

7.5.1. Добавление кластерных ресурсов

В целом, можно настроить два типа ресурсов:

глобальные ресурсы — доступны в пределах кластера и настраиваются в секции resources элемента rm;
служебные ресурсы — доступны определенной службе и настраиваются в секции service элемента rm.

В этой секции рассказывается о добавлении глобальных ресурсов. Раздел 7.5.2, «Добавление кластерных служб» содержит информацию для служебных ресурсов.

Ниже приведен порядок добавления глобального ресурса.

Откройте /etc/cluster/cluster.conf на любом узле.

В элемент rm надо добавить секцию resources:


    <rm>
        <resources>

        </resources>
    </rm>

Например, Apache использует следующие ресурсы: файловую систему (fs), IP-адрес (ip) и ресурс apache.


    <rm>
        <resources>
           <fs name="web_fs" device="/dev/sdd2" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.100" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server" server_root="/etc/httpd" shutdown_wait="0"/>
        </resources>
    </rm>

Пример 7.9, «Добавление ресурсов в cluster.conf» содержит пример секции resources.

Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Дополнительно можно проверить соответствие формата схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
Убедитесь, что конфигурация была скопирована.
Раздел 7.5.2, «Добавление кластерных служб» содержит дальнейшую информацию.

Пример 7.9. Добавление ресурсов в cluster.conf


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
       <failoverdomains>
           <failoverdomain name="example_pri" nofailback="0" ordered="1" restricted="0">
               <failoverdomainnode name="node-01.example.com" priority="1"/>
               <failoverdomainnode name="node-02.example.com" priority="2"/>
               <failoverdomainnode name="node-03.example.com" priority="3"/>
           </failoverdomain>
       </failoverdomains>
       <resources>
           <fs name="web_fs" device="/dev/sdd2" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.100" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server" server_root="/etc/httpd" shutdown_wait="0"/>
        </resources>

   </rm>
</cluster>

7.5.2. Добавление кластерных служб

Ниже рассматривается порядок добавления кластерной службы.

Откройте /etc/cluster/cluster.conf на любом узле.

В элемент rm надо добавить секцию service:


    <rm>
        <service autostart="1" domain="" exclusive="0" name="" recovery="restart">

        </service>
    </rm>

Далее следует настроить параметры service:
- autostart — 1 разрешает автоматический запуск службы при запуске кластера, а 0 отключает эту возможность. По умолчанию равен 1.
- domain — резервный домен (дополнительно).
- exclusive — запрещает запуск службы, если на узле уже работают другие службы.
- recovery — определяет правила восстановления службы. Возможные значения: relocate, restart, disable, restart-disable.

Теперь можно добавить глобальные или специализированные ресурсы.

Пример добавления Apache, который будет использовать глобальные ресурсы:


    <rm>
        <resources>
                <fs name="web_fs" device="/dev/sdd2" mountpoint="/var/www" fstype="ext3"/>
                <ip address="127.143.131.100" monitor_link="yes" sleeptime="10"/>
                <apache config_file="conf/httpd.conf" name="example_server" server_root="/etc/httpd" shutdown_wait="0"/>
        </resources>
        <service autostart="1" domain="example_pri" exclusive="0" name="example_apache" recovery="relocate">
                <fs ref="web_fs"/>
                <ip ref="127.143.131.100"/>
                <apache ref="example_server"/>
        </service>
    </rm>

Пример добавления Apache, который будет использовать специализированные ресурсы:


    <rm>
        <service autostart="0" domain="example_pri" exclusive="0" name="example_apache2" recovery="relocate">
                <fs name="web_fs2" device="/dev/sdd3" mountpoint="/var/www2" fstype="ext3"/>
                <ip address="127.143.131.101" monitor_link="yes" sleeptime="10"/>
                <apache config_file="conf/httpd.conf" name="example_server2" server_root="/etc/httpd" shutdown_wait="0"/>
        </service>
    </rm>

Пример 7.10, «Добавление двух служб с разными типами ресурсов» содержит пример cluster.conf с двумя службами.

example_apache использует глобальные ресурсы web_fs, 127.143.131.100 и example_server.
example_apache2 использует специализированные ресурсы web_fs2, 127.143.131.101 и example_server2.

Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Дополнительно можно выполнить проверку соответствия формата схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
Убедитесь, что конфигурация была скопирована.
Раздел 7.8, «Проверка конфигурации» содержит дальнейшую информацию.

Пример 7.10. Добавление двух служб с разными типами ресурсов


<cluster name="mycluster" config_version="3">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
       <failoverdomains>
           <failoverdomain name="example_pri" nofailback="0" ordered="1" restricted="0">
               <failoverdomainnode name="node-01.example.com" priority="1"/>
               <failoverdomainnode name="node-02.example.com" priority="2"/>
               <failoverdomainnode name="node-03.example.com" priority="3"/>
           </failoverdomain>
       </failoverdomains>
       <resources>
           <fs name="web_fs" device="/dev/sdd2" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.100" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server" server_root="/etc/httpd" shutdown_wait="0"/>
       </resources>
       <service autostart="1" domain="example_pri" exclusive="0" name="example_apache" recovery="relocate">
           <fs ref="web_fs"/>
           <ip ref="127.143.131.100"/>
           <apache ref="example_server"/>
       </service>
       <service autostart="0" domain="example_pri" exclusive="0" name="example_apache2" recovery="relocate">
           <fs name="web_fs2" device="/dev/sdd3" mountpoint="/var/www2" fstype="ext3"/>
           <ip address="127.143.131.101" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server2" server_root="/etc/httpd" shutdown_wait="0"/>
       </service>
   </rm>
</cluster>

7.6. Настройка протокола избыточного кольца

Начиная с Red Hat Enterprise Linux 6.4 комплект Red Hat High Availability стал поддерживать возможности настройки протокола избыточного кольца.

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

Должно быть определено только одно кольцо.
Каждое кольцо может использовать только один протокол — не следует смешивать IPv4 и IPv6.
При необходимости можно вручную определить адрес многоадресной рассылки для второго кольца. Этот адрес и порт должен отличаться от адреса первого кольца. Если дополнительный адрес не задан, для второго кольца будет автоматически выбран другой адрес.
Если вы определили дополнительный порт, номера портов первого и второго кольца должны отличаться как минимум на два, так как сама система использует основной порт и порт с номером на единицу меньше.
Не используйте два разных интерфейса в одной подсети.
Обычно рекомендуется настроить избыточное кольцо для двух сетевых карт и двух переключателей.
Не используйте команды ifdown и service network stop для эмуляции сбоя сети, так как это приведет к сбою работы кластера и необходимости перезагрузки всех узлов.
Не используйте NetworkManager, так как он выполнит команду ifdown при отсоединении кабеля.
При сбое одного узла будет зарегистрирован сбой для его кольца.
Для восстановления функциональности кольца потребуется исправить причину проблемы (восстановить работу переключателя или сетевой карты).

Чтобы определить второй сетевой интерфейс для избыточного кольца, в файле cluster.conf добавьте элемент altname в секцию clusternode. Атрибут name определяет имя второе имя узла или IP-адрес.

Ниже приведен пример определения дополнительного имени clusternet-node1-eth2 для узла clusternet-node1-eth1.


<cluster name="mycluster" config_version="3" >
  <logging debug="on"/>
  <clusternodes>
    <clusternode name="clusternet-node1-eth1" votes="1" nodeid="1">
      <fence>
        <method name="single">
          <device name="xvm" domain="clusternet-node1"/>
        </method>
      </fence>
      <altname name="clusternet-node1-eth2"/>
    </clusternode>

Строка altname может располагаться до или после определения fence в секции clusternode, но она должна быть уникальна — наличие нескольких определений altname помешает запуску системы.

Адрес многоадресной рассылки, порт и TTL второго кольца можно определить вручную в секции cman. Строка altmulticast принимает параметры addr, port и ttl

Ниже приведен пример секции cman в файле конфигурации, где определен адрес, порт и TTL для второго кольца.


<cman>
   <multicast addr="239.192.99.73" port="666" ttl="2"/>
   <altmulticast addr="239.192.99.88" port="888" ttl="3"/>
</cman>

7.7. Ведение журналов

Ведение журнала может быть настроено выборочно или для всех процессов в кластере.

Следущая секция включит сохранение отладочной информации для всех процесов. По умолчанию журнал расположен в /var/log/cluster/процесс.log.


<cluster config_version="7" name="rh6cluster">    
  <logging debug="on"/>
   ...  
</cluster>

Чтобы включить ведение журнала для отдельных процессов, переопределив глобальные настройки, в /etc/cluster/cluster.conf добавьте следующее:


<cluster config_version="7" name="rh6cluster">
   ...
  <logging>
       <!-- turning on per-subsystem debug logging --> 
       <logging_daemon name="corosync" debug="on" />  
       <logging_daemon name="fenced" debug="on" /> 
       <logging_daemon name="qdiskd" debug="on" /> 
       <logging_daemon name="rgmanager" debug="on" />   
       <logging_daemon name="dlm_controld" debug="on" /> 
       <logging_daemon name="gfs_controld" debug="on" />
  </logging> 
   ...
</cluster>

7.8. Проверка конфигурации

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

Сначала следует перезапустить кластерные программы, чтобы применить изменения конфигурации:

[root@example-01 ~]# service cman restart
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]

При наличии кластерных томов, созданных с помощью CLVM, выполните:
```
[root@example-01 ~]# service clvmd start
Activating VGs:                                            [  OK  ]
```

Для запуска Red Hat GFS2 выполните:

[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]

При наличии служб высокой готовности выполните:

[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]

[root@example-01 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M    548   2010-09-28 10:52:21  node-01.example.com
   2   M    548   2010-09-28 10:52:21  node-02.example.com
   3   M    544   2010-09-28 10:52:21  node-03.example.com

Выполните clustat на любом узле, чтобы проверить статус кластерных служб и узлов:

[root@example-01 ~]#clustat
Cluster Status for mycluster @ Wed Nov 17 05:40:00 2010
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node-03.example.com                         3 Online, rgmanager
 node-02.example.com                         2 Online, rgmanager
 node-01.example.com                         1 Online, Local, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----           
 service:example_apache         node-01.example.com            started       
 service:example_apache2        (none)                         disabled

На этом конфигурация кластера завершена. Глава 8, Управление кластером в командной строке содержит информацию о типичных операциях управления кластером из командной строки.

Глава 8. Управление кластером в командной строке

В этой главе рассматриваются задачи управления комплектом Red Hat High Availability. Содержание:

Раздел 8.1, «Запуск и остановка кластера»
Раздел 8.2, «Добавление и удаление узлов»
Раздел 8.3, «Управление службами высокой готовности»
Раздел 8.4, «Обновление конфигурации»

Важно

Примечание

Описываемые здесь процедуры подразумевают использование инструментов командной строки (см. Приложение E, Обзор команд). Подробную информацию можно найти на соответствующих справочных страницах.

8.1. Запуск и остановка кластера

Раздел 8.1.1, «Запуск кластерных программ» и Раздел 8.1.2, «Остановка кластерных программ» рассматривают порядок запуска и остановки кластерных программ на узле. При запуске кластерных служб узел будет добавлен в состав кластера, а при остановке — исключен.

8.1.1. Запуск кластерных программ

Для запуска кластерного программного обеспечения на узле необходимо выполнить следующее:

service cman start
service clvmd start, если для создания кластерных томов использовался CLVM
service gfs2 start, если используется Red Hat GFS2
service rgmanager start, если используются службы высокой готовности (rgmanager).

Пример:

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
[root@example-01 ~]# service clvmd start
Starting clvmd:                                            [  OK  ]
Activating VG(s):   2 logical volume(s) in volume group "vg_example" now active
                                                           [  OK  ]
[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]
[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]#

8.1.2. Остановка кластерных программ

Для остановки кластерного программного обеспечения на узле необходимо выполнить следующее:

service rgmanager stop, если используются службы высокой готовности (rgmanager)
service gfs2 stop, если используется Red Hat GFS2
umount -at gfs2, если Red Hat GFS2 используется в комбинации с rgmanager с целью монтирования файлов GFS2 во время запуска rgmanager
service clvmd stop, если для создания кластерных томов использовался CLVM
service cman stop

Пример:

[root@example-01 ~]# service rgmanager stop
Stopping Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]# service gfs2 stop
Unmounting GFS2 filesystem (/mnt/gfsA):                    [  OK  ]
Unmounting GFS2 filesystem (/mnt/gfsB):                    [  OK  ]
[root@example-01 ~]# umount -at gfs2
[root@example-01 ~]# service clvmd stop
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
[root@example-01 ~]# service cman stop
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@example-01 ~]#

Примечание

Остановка кластерных программ на узле приведет к прекращению работы служб и восстановлению их функционирования на другом узле. Другой возможный вариант подразумевает перенос служб высокой готовности на другой узел с последующей остановкой кластерных программ (см. Раздел 8.3, «Управление службами высокой готовности»).

8.2. Добавление и удаление узлов

Далее рассматривается порядок добавления (см. Раздел 8.2.2, «Добавление узла в кластер») и удаления узлов (см. Раздел 8.2.1, «Удаление узла из кластера»).

8.2.1. Удаление узла из кластера

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

Важно

Если после удаления число узлов в кластере уменьшится до двух, потребуется перезапустить кластерные программы на обоих узлах.

Порядок удаления узла из кластера:

Сначала перенесите или удалите кластерные службы на удаляемом узле. Это можно сделать с помощью утилиты clusvcadm, которая может быть запущена на любом узле (см. Раздел 8.3, «Управление службами высокой готовности»).

Остановите кластерные программы на подлежащем удалению узле:

[root@example-01 ~]# service rgmanager stop
Stopping Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]# service gfs2 stop
Unmounting GFS2 filesystem (/mnt/gfsA):                    [  OK  ]
Unmounting GFS2 filesystem (/mnt/gfsB):                    [  OK  ]
[root@example-01 ~]# service clvmd stop
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
[root@example-01 ~]# service cman stop
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@example-01 ~]#

Откройте файл /etc/cluster/cluster.conf на любом узле и удалите секцию clusternode для удаляемого узла. Например, при удалении node-03.example.com надо будет удалить соответствующую секцию clusternode (см. Пример 8.1, «Конфигурация с тремя узлами»). Если после удаления в кластере останется всего два узла, для поддержки кворума одним из узлов в /etc/cluster/cluster.conf можно добавить:
<cman two_node="1" expected_votes="1"/>
Раздел 8.2.3, «Примеры конфигураций с двумя и тремя узлами» выполняет сравнение структур с двумя и тремя узлами.
Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Дополнительно можно выполнить проверку соответствия формата файла схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
Убедитесь, что конфигурация была скопирована.

Если число узлов в кластере уменьшилось до двух, потребуется перезапустить кластерные программы:

Остановите кластерные программы на всех узлах (см. Раздел 8.1.2, «Остановка кластерных программ»):

[root@example-01 ~]# service rgmanager stop
Stopping Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]# service gfs2 stop
Unmounting GFS2 filesystem (/mnt/gfsA):                    [  OK  ]
Unmounting GFS2 filesystem (/mnt/gfsB):                    [  OK  ]
[root@example-01 ~]# service clvmd stop
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
[root@example-01 ~]# service cman stop
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@example-01 ~]#

Запустите кластерные программы на всех узлах (см. Раздел 8.1.1, «Запуск кластерных программ»):

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
[root@example-01 ~]# service clvmd start
Starting clvmd:                                            [  OK  ]
Activating VG(s):   2 logical volume(s) in volume group "vg_example" now active
                                                           [  OK  ]
[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]
[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]#

На любом узле выполните cman_tool nodes, чтобы убедиться, что все узлы входят в состав кластера, о чем сообщает значение "M" в столбце статуса:
```
[root@example-01 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M    548   2010-09-28 10:52:21  node-01.example.com
   2   M    548   2010-09-28 10:52:21  node-02.example.com
```

На любом узле выполните clustat, чтобы проверить статус работы кластерных служб и узлов:

[root@example-01 ~]#clustat
Cluster Status for mycluster @ Wed Nov 17 05:40:00 2010
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node-02.example.com                         2 Online, rgmanager
 node-01.example.com                         1 Online, Local, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----           
 service:example_apache         node-01.example.com            started       
 service:example_apache2        (none)                         disabled

8.2.2. Добавление узла в кластер

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

Откройте файл /etc/cluster/cluster.conf на любом узле и добавьте секцию clusternode для добавляемого узла. Например, при добавлении node-03.example.com надо будет добавить соответствующую секцию clusternode (см. Пример 8.2, «Конфигурация с двумя узлами»). Если после добавления число узлов в кластере выросло с двух до трех и более, в /etc/cluster/cluster.conf удалите атрибуты cman:
- cman two_node="1"
- expected_votes="1"
Раздел 8.2.3, «Примеры конфигураций с двумя и тремя узлами» выполняет сравнение структур с двумя и тремя узлами.
Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Дополнительно можно выполнить проверку соответствия формата файла схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
Убедитесь, что конфигурация была скопирована.
Скопируйте изменения в каталог /etc/cluster/ на всех добавляемых узлах. Это можно сделать с помощью scp:

Если число узлов в кластере выросло с двух до трех и более, потребуется перезапустить кластерные программы:

Остановите кластерные программы на всех узлах (см. Раздел 8.1.2, «Остановка кластерных программ»):

[root@example-01 ~]# service rgmanager stop
Stopping Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]# service gfs2 stop
Unmounting GFS2 filesystem (/mnt/gfsA):                    [  OK  ]
Unmounting GFS2 filesystem (/mnt/gfsB):                    [  OK  ]
[root@example-01 ~]# service clvmd stop
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
[root@example-01 ~]# service cman stop
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@example-01 ~]#

Запустите кластерные программы на всех узлах (см. Раздел 8.1.1, «Запуск кластерных программ»):

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
[root@example-01 ~]# service clvmd start
Starting clvmd:                                            [  OK  ]
Activating VG(s):   2 logical volume(s) in volume group "vg_example" now active
                                                           [  OK  ]
[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]
[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]#

Запустите кластерные программы на добавляемых узлах:

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
[root@example-01 ~]# service clvmd start
Starting clvmd:                                            [  OK  ]
Activating VG(s):   2 logical volume(s) in volume group "vg_example" now active
                                                           [  OK  ]
[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]

[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]#

Выполните clustat на любом узле, чтобы проверить результат добавления:

[root@example-01 ~]#clustat
Cluster Status for mycluster @ Wed Nov 17 05:40:00 2010
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node-03.example.com                         3 Online, rgmanager
 node-02.example.com                         2 Online, rgmanager
 node-01.example.com                         1 Online, Local, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----           
 service:example_apache         node-01.example.com            started       
 service:example_apache2        (none)                         disabled

Раздел 8.3, «Управление службами высокой готовности» содержит информацию о clustat.

Дополнительно можно выполнить cman_tool status для проверки приоритета узлов, кворума и числа узлов:

[root@example-01 ~]#cman_tool status
Version: 6.2.0
Config Version: 19
Cluster Name: mycluster 
Cluster Id: 3794
Cluster Member: Yes
Cluster Generation: 548
Membership state: Cluster-Member
Nodes: 3
Expected votes: 3
Total votes: 3
Node votes: 1
Quorum: 2  
Active subsystems: 9
Flags: 
Ports Bound: 0 11 177  
Node name: node-01.example.com
Node ID: 3
Multicast addresses: 239.192.14.224 
Node addresses: 10.15.90.58

С помощью утилиты clusvcadm, которая может быть запущена на любом узле, можно осуществить перенос служб на добавленный узел, включить их и отключить (см. Раздел 8.3, «Управление службами высокой готовности»).

8.2.3. Примеры конфигураций с двумя и тремя узлами

Ниже приведены примеры конфигураций с двумя и тремя узлами.

Пример 8.1. Конфигурация с тремя узлами


<cluster name="mycluster" config_version="3">
   <cman/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
            <method name="APC">
              <device name="apc" port="3"/>
            </method>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
       <failoverdomains>
           <failoverdomain name="example_pri" nofailback="0" ordered="1" restricted="0">
               <failoverdomainnode name="node-01.example.com" priority="1"/>
               <failoverdomainnode name="node-02.example.com" priority="2"/>
               <failoverdomainnode name="node-03.example.com" priority="3"/>
           </failoverdomain>
       </failoverdomains>
       <resources>
           <fs name="web_fs" device="/dev/sdd2" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.100" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server" server_root="/etc/httpd" shutdown_wait="0"/>
       </resources>
       <service autostart="0" domain="example_pri" exclusive="0" name="example_apache" recovery="relocate">
           <fs ref="web_fs"/>
           <ip ref="127.143.131.100"/>
           <apache ref="example_server"/>
       </service>
       <service autostart="0" domain="example_pri" exclusive="0" name="example_apache2" recovery="relocate">
           <fs name="web_fs2" device="/dev/sdd3" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.101" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server2" server_root="/etc/httpd" shutdown_wait="0"/>
       </service>
   </rm>
</cluster>

Пример 8.2. Конфигурация с двумя узлами


<cluster name="mycluster" config_version="3">
   <cman two_node="1" expected_votes="1"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
            <method name="APC">
              <device name="apc" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
            <method name="APC">
              <device name="apc" port="2"/>
            </method>
         </fence>
   </clusternodes>
   <fencedevices>
         <fencedevice agent="fence_apc" ipaddr="apc_ip_example" login="login_example" name="apc" passwd="password_example"/>
   </fencedevices>
   <rm>
       <failoverdomains>
           <failoverdomain name="example_pri" nofailback="0" ordered="1" restricted="0">
               <failoverdomainnode name="node-01.example.com" priority="1"/>
               <failoverdomainnode name="node-02.example.com" priority="2"/>
           </failoverdomain>
       </failoverdomains>
       <resources>
           <fs name="web_fs" device="/dev/sdd2" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.100" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server" server_root="/etc/httpd" shutdown_wait="0"/>
       </resources>
       <service autostart="0" domain="example_pri" exclusive="0" name="example_apache" recovery="relocate">
           <fs ref="web_fs"/>
           <ip ref="127.143.131.100"/>
           <apache ref="example_server"/>
       </service>
       <service autostart="0" domain="example_pri" exclusive="0" name="example_apache2" recovery="relocate">
           <fs name="web_fs2" device="/dev/sdd3" mountpoint="/var/www" fstype="ext3"/>
           <ip address="127.143.131.101" monitor_link="yes" sleeptime="10"/>
           <apache config_file="conf/httpd.conf" name="example_server2" server_root="/etc/httpd" shutdown_wait="0"/>
       </service>
   </rm>
</cluster>

8.3. Управление службами высокой готовности

Управление кластерными службами может осуществляться с помощью clustat и clusvcadm. Так, clustat возвращает информацию о состоянии кластера, а clusvcadm непосредственно отвечает за управление службами.

Содержание:

Раздел 8.3.1, «Просмотр статуса кластерных служб с помощью clustat»
Раздел 8.3.2, «Управление кластерными службами с помощью clusvcadm»

8.3.1. Просмотр статуса кластерных служб с помощью `clustat`

clustat возвращает список узлов, кворум, статус кластерных служб (см. Таблица 8.1, «Статус служб») и узел, на котором эта служба была запущена. Пример 8.3, «Вывод clustat» демонстрирует пример вывода команды. За подробной информацией обратитесь к справочной странице clustat.

Таблица 8.1. Статус служб

Статус служб	Описание
Started	Ресурсы службы настроены и доступны.
Recovering	Ожидает запуск на другом узле.
Disabled	У службы нет владельца, и она отключена. Отключенные службы не могут быть запущены автоматически.
Stopped	Это временное состояние служб, в котором они могут быть проверены, прежде чем они будут включены, выключены или запущены на другом узле.
Failed	Служба переходит в это состояние при сбое операции stop. Прежде чем отключить службу окончательно, следует убедиться, что она не использует ресурсы (файловые системы и пр.). Из этого состояния служба может выведена только при помощи команды `disable`.
Uninitialized	Службы иногда переходят в это состояние при запуске и выполнении `clustat -f`.

Пример 8.3. Вывод clustat

[root@example-01 ~]#clustat
Cluster Status for mycluster @ Wed Nov 17 05:40:15 2010
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node-03.example.com                         3 Online, rgmanager
 node-02.example.com                         2 Online, rgmanager
 node-01.example.com                         1 Online, Local, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----           
 service:example_apache         node-01.example.com            started       
 service:example_apache2        (none)                         disabled

8.3.2. Управление кластерными службами с помощью `clusvcadm`

clusvcadm позволяет выполнять задачи управления кластерными службами:

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

Таблица 8.2, «Операции управления службами» содержит описание перечисленных операций. Более подробную информацию можно найти на справочной странице clusvcadm.

Таблица 8.2. Операции управления службами

Операция	Описание	Синтаксис команд
Включить	Запуск службы с дополнительным выбором узла и правил переноса в случае сбоя. Если дополнительные параметры не определены, выбранная служба будет запущена на том же узле, где выполняется `clusvcadm`. Если службу запустить не удалось, будет инициирована операция переноса (см. ниже).	`clusvcadm -e <служба>` или `clusvcadm -e <служба> -m <узел>` (-m определяет узел, на котором следует запустить службу)
Отключить	Остановка службы. Это единственное доступное действие для служб в состоянии failed.	`clusvcadm -d <служба>`
Переместить	Перенос службы на другой узел. Дополнительно можно определить узел для переноса службы. Если запустить службу на этом узле не удалось в силу того, что узел отключен, или по другим причинам, — будет выбран другой узел. `rgmanager` попытается запустить службу на каждом доступном узле в кластере. Если ни одна попытка не завершилась успешно, операция перемещения считается неудачной, и служба будет перезапущена на исходном узле. Если и эта попытка завершилась неудачей, служба перейдет в остановленное состояние.	`clusvcadm -r <служба>` или `clusvcadm -r <служба> -m <узел>` (параметр -m определяет узел, на котором следует запустить службу)
Остановить	Остановка службы и ее перевод в состояние stopped.	`clusvcadm -s <служба>`
Зафиксировать	Приостановка службы, что предотвратит проверку ее состояния и перенос в случае сбоя узла и остановки rgmanager. Обычно используется при необходимости обслуживания ресурсов, на которых выполняется служба. «Особенности операции фиксирования» содержит подробную информацию.	`clusvcadm -Z <служба>`
Освободить	Работа службы будет возобновлена, что снова разрешит проверку ее состояния. «Особенности операции фиксирования» содержит подробную информацию.	`clusvcadm -U <служба>`
Миграция	Миграция виртуальной машины на другой узел. Если миграция завершилась неудачей, виртуальная машина перейдет в состояние failed или started на исходном узле.	`clusvcadm -M <служба> -m <узел>` Важно В этом случае параметр `-m <узел>` является обязательным.
Перезапустить	Перезапуск службы на том же узле.	`clusvcadm -R <служба>`

8.3.2.1. Особенности операции фиксирования

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

Основные характеристики фиксирования служб:

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

Важно

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

Если служба зафиксирована, не следует останавливать все экземпляры rgmanager. Исключение составляют случаи, если вы планируете перезагрузить узел, прежде чем перезапустить rgmanager.
Не следует возобновлять работу службы до тех пор, пока узел, которому она принадлежит, не войдет в состав кластера и не перезапустит rgmanager.

8.4. Обновление конфигурации

Обновление конфигурации кластера подразумевает редактирование файла /etc/cluster/cluster.conf и его копирование на все узлы.

Раздел 8.4.1, «Обновление конфигурации с помощью cman_tool version -r»
Раздел 8.4.2, «Обновление конфигурации с помощью scp»

8.4.1. Обновление конфигурации с помощью `cman_tool version -r`

Ниже приведен порядок обновления конфигурации с помощью cman_tool version -r.

На любом узле откройте файл /etc/cluster/cluster.conf и внесите изменения.
Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере. Предварительно убедитесь, что на всех узлах выполняется процесс ricci.
Убедитесь, что конфигурация была скопирована.

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

Удаление узла из кластера за исключением случаев, когда общее число узлов уменьшилось до двух (см. Раздел 8.2, «Добавление и удаление узлов»).
Добавление узла в кластер за исключением случаев, когда число узлов стало больше двух (см. Раздел 8.2.2, «Добавление узла в кластер»).
Изменение параметров журналирования.
Операции управления службами высокой готовности и виртуальными машинами (добавление, изменение, удаление).
Операции управления ресурсами (добавление, изменение, удаление).
Операции домена восстановления (добавление, изменение, удаление).

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

Остановите кластерные программы на всех узлах (см. Раздел 8.1.2, «Остановка кластерных программ»):

[root@example-01 ~]# service rgmanager stop
Stopping Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]# service gfs2 stop
Unmounting GFS2 filesystem (/mnt/gfsA):                    [  OK  ]
Unmounting GFS2 filesystem (/mnt/gfsB):                    [  OK  ]
[root@example-01 ~]# service clvmd stop
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
[root@example-01 ~]# service cman stop
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@example-01 ~]#

Запустите кластерные программы на всех узлах (см. Раздел 8.1.1, «Запуск кластерных программ»):

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
[root@example-01 ~]# service clvmd start
Starting clvmd:                                            [  OK  ]
Activating VG(s):   2 logical volume(s) in volume group "vg_example" now active
                                                           [  OK  ]
[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]
[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]#

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

На любом узле выполните cman_tool nodes, чтобы убедиться, что все узлы входят в состав кластера, о чем сообщает значение "M" в столбце статуса:

[root@example-01 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M    548   2010-09-28 10:52:21  node-01.example.com
   2   M    548   2010-09-28 10:52:21  node-02.example.com
   3   M    544   2010-09-28 10:52:21  node-03.example.com

На любом узле выполните clustat, чтобы проверить статус работы кластерных служб и узлов:

[root@example-01 ~]#clustat
Cluster Status for mycluster @ Wed Nov 17 05:40:00 2010
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node-03.example.com                         3 Online, rgmanager
 node-02.example.com                         2 Online, rgmanager
 node-01.example.com                         1 Online, Local, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----           
 service:example_apache         node-01.example.com            started       
 service:example_apache2        (none)                         disabled

Если функциональность кластера не нарушилась, значит обновление конфигурации завершено успешно.

8.4.2. Обновление конфигурации с помощью `scp`

Ниже приведен порядок обновления конфигурации с помощью команды scp.

Остановите кластерные программы на всех узлах (см. Раздел 8.1.2, «Остановка кластерных программ»):

[root@example-01 ~]# service rgmanager stop
Stopping Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]# service gfs2 stop
Unmounting GFS2 filesystem (/mnt/gfsA):                    [  OK  ]
Unmounting GFS2 filesystem (/mnt/gfsB):                    [  OK  ]
[root@example-01 ~]# service clvmd stop
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
[root@example-01 ~]# service cman stop
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
[root@example-01 ~]#

На любом узле откройте файл /etc/cluster/cluster.conf и внесите изменения.
Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
Сохраните /etc/cluster/cluster.conf.
Проверьте соответствие формата файла схеме в cluster.rng:
```
[root@example-01 ~]# ccs_config_validate 
Configuration validates
```
Если проверка прошла успешно, скопируйте файл в каталог /etc/cluster/ на всех узлах.
Убедитесь, что конфигурация была скопирована.

Запустите кластерные программы на всех узлах (см. Раздел 8.1.1, «Запуск кластерных программ»):

[root@example-01 ~]# service cman start
Starting cluster: 
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
[root@example-01 ~]# service clvmd start
Starting clvmd:                                            [  OK  ]
Activating VG(s):   2 logical volume(s) in volume group "vg_example" now active
                                                           [  OK  ]
[root@example-01 ~]# service gfs2 start
Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]
[root@example-01 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]
[root@example-01 ~]#

[root@example-01 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M    548   2010-09-28 10:52:21  node-01.example.com
   2   M    548   2010-09-28 10:52:21  node-02.example.com
   3   M    544   2010-09-28 10:52:21  node-03.example.com

На любом узле выполните clustat, чтобы проверить статус работы кластерных служб и узлов:

[root@example-01 ~]#clustat
Cluster Status for mycluster @ Wed Nov 17 05:40:00 2010
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node-03.example.com                         3 Online, rgmanager
 node-02.example.com                         2 Online, rgmanager
 node-01.example.com                         1 Online, Local, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----           
 service:example_apache         node-01.example.com            started       
 service:example_apache2        (none)                         disabled

Если функциональность кластера не нарушилась, значит обновление конфигурации завершено успешно.

Глава 9. Диагностика и решение конфликтов в кластере

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

В этой главе рассматриваются наиболее распространенные причины конфликтов и методы их решения. За дополнительной информацией обратитесь к базе знаний или к официальному представителю службы поддержки Red Hat. Если проблемы связаны с GFS2, обратитесь к руководству GFS2.

9.1. Изменения конфигурации не вступают в силу

При изменении конфигурации кластера необходимо передать изменения всем узлам.

Если кластер был настроен с помощью Conga, изменения будут переданы остальным узлам автоматически.
Раздел 5.15, «Синхронизация файла конфигурации» содержит информацию о применении изменений с помощью ccs.
Раздел 8.4, «Обновление конфигурации» содержит информацию о применении изменений с помощью команд.

Ниже приведен список изменений, не требующих перезапуска кластера после передачи изменений его узлам.

Удаление узла из кластера за исключением случаев, когда общее число узлов уменьшилось до двух.
Добавление узла в кластер за исключением случаев, когда число узлов стало больше двух.
Изменение параметров журналирования.
Добавление, изменение и удаление служб высокой готовности и компонентов виртуальных машин.
Добавление, изменение и удаление кластерных ресурсов.
Добавление, изменение и удаление запасных доменов.

Остальные операции требуют перезагрузки кластера. Примеры:

Добавление и удаление параметра two_node из файла конфигурации.
Переименование кластера.
Изменение таймеров corosync и openais.
Добавление, изменение и удаление эвристических методов определения кворума диска, изменение таймеров кворума, изменение кворумного диска. Для применения изменений потребуется перезапустить qdiskd.
Изменение режима central_processing для rgmanager. Для применения изменений потребуется перезапустить rgmanager.
Изменение адреса многоадресной рассылки.
Изменение режима передачи с многоадресной рассылки UDP на одноадресную и наоборот.

Кластер можно перезапустить с помощью Conga, ccs и инструментов командной строки.

Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера» содержит информацию о перезапуске кластера при помощи Conga.
Раздел 6.2, «Запуск и остановка кластера» содержит информацию о перезапуске кластера с помощью ccs.
Раздел 8.1, «Запуск и остановка кластера» содержит информацию о перезапуске кластера при помощи команд.

9.2. Не удается сформировать кластер

Ниже перечислены основные причины, которые могут препятствовать формированию кластера.

Убедитесь, что имена разрешаются корректно. В cluster.conf должно быть указано имя узла, которое используется для разрешения его адреса. Например, при наличии узлов nodea и nodeb каждому из них должна соответствовать запись в файлах /etc/cluster/cluster.conf и /etc/hosts.
Так как для взаимодействия узлов кластер использует многоадресную рассылку, необходимо убедиться, что трафик такого рода не блокируется и задерживается. Так, например, некоторые коммутаторы Cisco могут вызывать задержки многоадресных передач, что следует учесть при создании кластера.
Для взаимодействия с удаленными узлами рекомендуется использовать telnet или SSH.
Чтобы проверить состояние Ethernet, выполните ethtool eth1 | grep link.
Проверку сетевого трафика на узле можно выполнить с помощью tcpdump.
Убедитесь, что правила межсетевого экрана разрешают обращение к узлам кластера.
Убедитесь, что интерфейсы, используемые при взаимодействии узлов, работают в режиме агрегации 0, 1 и 2. Поддержка режимов 0 и 2 была добавлена в Red Hat Enterprise Linux 6.4.

9.3. Узлы не могут подключиться к кластеру после перезагрузки или изоляции

Если узлы не могут вернуться в состав кластера после изоляции или перезагрузки, следует учесть следующее:

Если трафик кластера проходит через коммутатор Cisco Catalyst, это может препятствовать вхождению узла в кластер.
Файлы cluster.conf должны быть идентичны на всех узлах. Если файл на одном узле отличается от других, этот узел не сможет подключиться к кластеру.
Начиная с Red Hat Enterprise Linux 6.1 для проверки наличия идентичных копий файла конфигурации на всех узлах в кластере можно выполнить:
```
ccs -h узел --checkconf
```
Глава 5, Настройка кластера с помощью ccs и Глава 6, Управление кластером с помощью ccs содержат дополнительную информацию о ccs.
Убедитесь, что на узле настроены службы кластера (с помощью chkconfig on).
Убедитесь, что правила межсетевого экрана разрешают взаимодействие этого узла с другими узлами в кластере.

9.4. Сбой `rgmanager`

RGManager включает специальный процесс, осуществляющий перезагрузку узла в случае сбоя rgmanager. Это, в свою очередь, начнет процедуру изоляции узла и возобновит работу службы на новом узле. Остальные узлы в кластере воспримут перезагрузку узла как его выход из состава кластера.

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

Для этого надо предварительно установить необходимые пакеты и убедиться, что версии rgmanager и rgmanager-debuginfo совпадают.

$ yum -y --enablerepo=rhel-debuginfo install gdb rgmanager-debuginfo

9.4.1. Сохранение состояния памяти `rgmanager`

При запуске rgmanager автоматически запускается два процесса — следует сохранить состояние процесса с более высоким PID.

Пример вывода ps с двумя процессами rgmanager:


$ ps aux | grep rgmanager | grep -v grep 

root    22482  0.0  0.5  23544  5136 ?        S<Ls Dec01   0:00 rgmanager 
root    22483  0.0  0.2  78372  2060 ?        S<l  Dec01   0:47 rgmanager

В следующем примере pidof определит более высокий PID. В результате выполнения приведенной команды будет сохранено состояние памяти процесса с PID 22483.

$ gcore -o /tmp/rgmanager-$(date '+%F_%s').core $(pidof -s rgmanager)

9.4.2. Сохранение состояния памяти при сбое `rgmanager`

По умолчанию сценарий /etc/init.d/functions запрещает доступ процессов, вызванных из /etc/init.d/rgmanager, к файлам состояния памяти. Эту возможность потребуется настроить отдельно на всех узлах, где будут создаваться файлы состояния памяти.

Для этого необходимо изменить значение параметра DAEMONCOREFILELIMIT в файле /etc/sysconfig/cluster, который разрешает создание файлов состояния памяти при сбое процесса. Опция -w предотвращает выполнение процесса наблюдения, отвечающего за перезагрузку узла при сбое rgmanager. В некоторых случаях процесс наблюдения препятствует созданию файла состояния памяти, поэтому его потребуется остановить.

DAEMONCOREFILELIMIT="unlimited"
RGMGR_OPTS="-w"

Чтобы изменения вступили в силу, следует перезапутстить rgmanager:

service rgmanager restart

Примечание

Если на перезагружаемом узле выполняются кластерные службы, это может нарушить их работу.

Файл будет создан на основе журнала сбоя процесса rgmanager.

ls /core*

Пример вывода:

/core.11926

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

9.4.3. Сохранение сеанса отладки `gdb`

Содержимое файла состояния памяти можно просмотреть с помощью gdb. Чтобы записать сеанс сценария gdb для файла состояния, выполните следующее:

$ script /tmp/gdb-rgmanager.txt
$ gdb /usr/sbin/rgmanager /tmp/rgmanager-.core.

В результате будет создан сеанс gdb, и script сохранит его в указаннный файл. В сеансе gdb выполните:

(gdb) thread apply all bt full
(gdb) quit

Нажмите ctrl-D, чтобы остановить сеанс и сохранить результаты в текстовый файл.

9.5. Сбой кластерных служб

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

Возможно, произошел сбой операции в процессе изоляции узла.
Проверьте наличие ошибок операций изоляции в файлах /var/log/messages на всех узлах. Если файлы содержат ошибки, перезагрузите узлы и откорректируйте параметры изоляции.
Проверьте, не возникла ли ситуация, описанная в главе 9.8 (см.Раздел 9.8, «Элементы кластера с двумя узлами не могут связаться друг с другом»), и убедитесь, что узлы могут взаимодействовать друг с другом.
При исключении узлов может оказаться так, что оставшиеся узлы потеряли кворум. Наличие кворума является необходимым условием для нормального функционирования кластера. В этом случае потребуется откорректировать приоритет узлов или вернуть узлы в состав кластера.

Примечание

Узел может быть исключен вручную с помощью fence_node или Conga (см. Раздел 4.3.2, «Добавление и удаление узлов»).

9.6. Кластерные службы не запускаются

Если не удается запустить кластерные службы, следует проверить следующие условия:

Убедитесь в отсутствии ошибок в файле cluster.conf. Команда rg_test поможет проверить его формат.
```
$ rg_test test /etc/cluster/cluster.conf start service служба 
```
Раздел C.5, «Отладка и тестирование служб и порядка следования ресурсов» содержит информацию о rg_test.
Дополнительно можно увеличить уровень журналирования, что поможет идентифицировать причину проблемы. Для этого в файле cluster.conf добавьте параметр loglevel="7" в тег rm.

9.7. Сбой переноса кластерных служб

Если не удается перенести кластерную службу с одного узла на другой, следует проверить следующие условия:

Убедитесь, что для запуска службы на новом узле есть все необходимое. Так, если служба обращается к сценарию, он должен быть доступен в том же месте на новом узле.
Убедитесь, что конфигурация запасных доменов, зависимости и права доступа на новом узле не нарушат нормальную работу перенесенных служб.
При переносе служб виртуальных машин следует ознакомиться с особенностями конфигурации в соответствующей документации.
Увеличение уровня журналирования (см. Раздел 9.6, «Кластерные службы не запускаются») может облегчить поиск причин сбоя.

9.8. Элементы кластера с двумя узлами не могут связаться друг с другом

Если кластер включает всего два узла, и каждый узел сообщает, что другой узел недоступен, значит, узлы не могут связаться друг с другом. Раздел 9.2, «Не удается сформировать кластер» содержит инструкции, которые помогут решить эту проблему.

9.9. Изоляция узлов при сбое пути LUN

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

9.10. Диски кворума не регистрируются в составе кластера

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

Убедитесь, что служба qdisk настроена (с помощью chkconfig on).
Убедитесь, что служба qdisk запущена.
Регистрация диска кворума в кластере может занять несколько минут. Это нормальное явление.

9.11. Нестандартное поведение при изоляции

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

9.12. Незапланированная изоляция

Ниже перечислены условия, которые следует проверить в случае незапланированной изоляции узлов.

Наиболее распространненной причиной является потеря узлом ключа доступа. Это приводит к тому, что узел перестает отвечать на запросы подтверждения соединения и не может взаимодействовать с другими элементами кластера.
Если узел не отвечает на запросы подтверждения соединения на протяжении предопределенного интервала, он будет изолирован. По умолчанию интервал равен 10 секундам. Другое значение можно определить в поле totem token в файле cluster.conf (в миллисекундах). Например, totem token="30000" увеличит интервал до 30 секунд.
Проверьте функциональность сети.
Убедитесь, что интерфейсы, используемые при взаимодействии узлов, работают в режиме агрегации 0, 1 и 2. Поддержка режимов 0 и 2 была добавлена в Red Hat Enterprise Linux 6.4.
Попытайтесь определить, что именно просходит: зависание системы или паника ядра? Если возможно, с помощью kdump сохраните состояние памяти на момент изоляции.
Убедитесь, что конфликт действительно имеет прямое отношение к изоляции узла, будь то исключение узла из кластера диском кворума или вызов перезагрузки узла продуктом стороннего производителя, таким как Oracle RAC. Диагностику следует начинать с проверки сообщений в журналах на всех узлах.
Проверьте оборудование: аппаратные сбои могут привести к тому, что система перестанет отвечать на запросы проверки связи.

9.13. Журналирование для DLM

Дополнительно можно включить две опции журналирования для распределенного менеджера блокировок (DLM, Distributed Lock Manager): отладку ядра DLM и отладку блокировки POSIX.

Отладку DLM можно включить в секции dlm файла /etc/cluster/cluster.conf. Так, параметр log_debug разрешит получение отладочных сообщений ядра, а plock_debug — сообщений блокировки POSIX.

Пример:


<cluster config_version="42" name="cluster1">
  ...
  <dlm log_debug="1" plock_debug="1"/>
  ...
</cluster>

Сохраните файл и выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.

Глава 10. Настройка SNMP

В Red Hat Enterprise Linux 6.1 функциональность ловушек SNMP поддерживается на уровне комплекта Red Hat High Availability. В этой главе рассматриваются принципы настройки SNMP и доступные ловушки.

10.1. SNMP и Red Hat High Availability

Red Hat High Availability предоставляет агент foghorn, который отвечает за генерацию ловушек SNMP (но не поддерживает другие операции SNMP, такие как get и set). Взаимодействие foghorn с snmpd осуществляется по протоколу AgentX.

В настоящее время foghorn не поддерживает параметры config, то есть сокет изменить нельзя, и по умолчанию используется стандартный сокет AgentX.

10.2. Настройка SNMP в кластере

Ниже перечислены основные шаги по настройке SNMP в кластере.

Сначала необходимо необходимо настроить службу snmpd, которая будет выступать в качестве мастер-агента для foghorn, и включить поддержку AgentX. Для этого в файл /etc/snmp/snmpd.conf следует добавить:
```
master agentx
```
Следующая строка определяет узел, которому будут отправляться уведомления ловушек SNMP:
```
trap2sink узел
```
Подробную информацию можно найти на справочной странице snmpd.conf.
После этого следует включить и запустить snmpd:
```
# chkconfig snmpd on
# service snmpd start
```

Запустить messagebus:

# chkconfig messagebus on
# service messagebus start

Запустить foghorn:

# chkconfig foghorn on
# service foghorn start

Разрешить COROSYNC-MIB генерировать ловушки SNMP и запустить corosync-notifyd:

# echo "OPTIONS=\"-d\" " > /etc/sysconfig/corosync-notifyd
# chkconfig corosync-notifyd on
# service corosync-notifyd start

После успешной настройки foghorn сможет получить сигналы D-bus, преобразовывать их в ловушки SNMPv2 и передавать узлу, заданному с помощью параметра trapsink.

10.3. Перенаправление ловушек SNMP

Ловушки SNMP могут быть перенаправлены внешнему компьютеру, не входящему в состав кластера, где с помощью snmptrapd можно настроить реакцию на получение уведомлений.

Ниже рассматривается порядок перенаправления ловушек SNMP.

В /etc/snmp/snmpd.conf в строке trap2sink узел определите узел для перенаправления уведомлений (см. Раздел 10.2, «Настройка SNMP в кластере»).
В файле /etc/snmp/snmptrapd.conf на внешнем компьютере необходимо определить строку сообщества.
```
authCommunity log,execute,net public
```
После этого следует включить и запустить snmptrapd:
```
# chkconfig snmptrapd on
# service snmptrapd start
```

Подробную информацию можно найти на справочной странице snmptrapd.conf.

10.4. Ловушки SNMP комплекта Red Hat High Availability

foghorn генерирует следующие ловушки:

fenceNotifyFenceNode
Эта ловушка генерируется, если изолируемый узел пытается изолировать другой узел. Создается на узле, который пытается осуществить изоляцию.
- fenceNodeName - имя изолируемого узла
- fenceNodeID - идентификатор изолируемого узла
- fenceResult - код результата изоляции. Допустимые значения: 0 (успешно), 1 (ошибка), 2 (не определены методы изоляции).
rgmanagerServiceStateChange
Сообщает об изменении статуса кластерной службы. Поля уведомления:
- rgmanagerServiceName - название службы, которое содержит тип службы, например: service:foo, vm:foo.
- rgmanagerServiceState - статус службы за исключением переходных состояний (например, starting или stopping.
- rgmanagerServiceFlags - служебные флаги. Допустимые значения: frozen (служба заморожена при помощи clusvcadm -Z) и partial (проблемный ресурс отмечен как non-critical, то есть при сбое ресурса его компоненты будут перезапущены без необходимости остановки службы).
- rgmanagerServiceCurrentOwner - владелец службы. Если служба в данный момент не работает, значение будет равно (none).
- rgmanagerServicePreviousOwner - последний владелец. Если неизвестен, равно (none).

corosync-nodifyd генерирует следующие ловушки:

corosyncNoticesNodeStatus
Сообщает о входе узла в кластер и выходе из его состава. Поля уведомления:
- corosyncObjectsNodeName - имя узла
- corosyncObjectsNodeID - идентификатор узла
- corosyncObjectsNodeAddress - IP-адрес узла
- corosyncObjectsNodeStatus - статус узла (joined или left)
corosyncNoticesQuorumStatus
Сообщает об изменении статуса кворума. Поля уведомления:
- corosyncObjectsNodeName - имя узла
- corosyncObjectsNodeID - идентификатор узла
- corosyncObjectsQuorumStatus - новое состояние кворума (quorate или NOT quorate)
corosyncNoticesAppStatus
Генерируется при подключении и отключении клиента от Corosync.
- corosyncObjectsNodeName - имя узла
- corosyncObjectsNodeID - идентификатор узла
- corosyncObjectsAppName - приложение
- corosyncObjectsAppStatus - новый статус приложения (connected или disconnected)

Глава 11. Кластерная конфигурация Samba

Поддержка работы кластерных схем Samba была впервые добавлена в Red Hat Enterprise Linux 6.2. Для реализации этих возможностей на всех узлах в кластере надо установить и настроить базу данных CTDB в комбинации кластерной файловой системой GFS2.

Примечание

Red Hat Enterprise Linux 6 разрешает выполнение кластерной схемы Samba максимум на четырех узлах.

В этой главе рассматривается порядок настройки CTDB. Информацию о настройке файловых систем GFS2 можно найти в руководстве по GFS2, а логических томов — в руководстве LVM.

11.1. Обзор CTDB

CTDB представляет собой кластерный вариант базы данных TDB. Для ее работы необходимо открыть совместный доступ к кластерной файловой системе для всех узлов. Начиная с Red Hat Enterprise Linux 6.2 база данных CTDB поддерживает работу кластерного стека параллельно стандартному стеку кластеризации Red Hat Enterprise Linux. CTDB несет ответственность за управление составом кластера, восстановлением в случае сбоя узлов, работой служб Samba и переносом IP.

11.2. Обязательные пакеты

Ниже перечислены пакеты, которые требуются для нормальной работы Samba в кластерных схемах Red Hat Enterprise Linux помимо стандартных пакетов, необходимых для Red Hat High Availability и Red Hat Resilient Storage.

ctdb
samba
samba-common
samba-winbind-clients

11.3. Конфигурация GFS2

Настройка Samba в кластере Red Hat Enterprise Linux требует наличия двух файловых систем GFS2 — одной для CTDB, второй для общего ресурса Samba.

Прежде чем приступить к созданию GFS2, для каждой будущей файловой системы необходимо создать логический том LVM (см. руководство по LVM). В этой главе в качестве примера будут созданы:

/dev/csmb_vg/csmb_lv (100 гигабайт) для хранения данных пользователя, экспортируемых через общий ресурс Samba.
/dev/csmb_vg/ctdb_lv (1 гигабайт) для хранения общей информации о состоянии CTDB.

Логические тома и их группы создаются только на одном узле.

После этого можно создать файловую систему, выполнив mkfs.gfs2 лишь на одном узле.

Следущая команда создаст файловую систему на /dev/csmb_vg/csmb_lv для размещения общего ресурса Samba:

[root@clusmb-01 ~]# mkfs.gfs2 -j3 -p lock_dlm -t csmb:gfs2 /dev/csmb_vg/csmb_lv

Параметры:

-j: Определяет число создаваемых журналов. В этом примере будет создано три журнала — по одному на узел.
-p: Определяет имя блокирующего протокола. GFS2 использует lock_dlm.
-t: Имя таблицы блокирования в формате кластер:ФС. В этом примере в cluster.conf имя кластера определено как csmb, а имя файловой системы — gfs2.

Пример вывода:

This will destroy any data on /dev/csmb_vg/csmb_lv.
  It appears to contain a gfs2 filesystem.

Are you sure you want to proceed? [y/n] y

Device:
/dev/csmb_vg/csmb_lv
Blocksize:		4096
Device Size		100.00 GB (26214400 blocks)
Filesystem Size:	100.00 GB (26214398 blocks)
Journals:		3
Resource Groups: 	400
Locking Protocol:  	"lock_dlm"
Lock Table: 		"csmb:gfs2"
UUID:
  94297529-ABG3-7285-4B19-182F4F2DF2D7

Таким образом, файловая система /dev/csmb_vg/csmb_lv будет смонтирована в /mnt/gfs2 на всех узлах кластера. Точка монтирования должна соответствовать значению path = для общего ресурса в файле конфигурации /etc/samba/smb.conf (см. Раздел 11.5, «Конфигурация Samba»).

После этого можно создать файловую систему для хранения информации о состоянии CTDB:

[root@clusmb-01 ~]# mkfs.gfs2 -j3 -p lock_dlm -t csmb:ctdb_state /dev/csmb_vg/ctdb_lv

Обратите внимание, что таблица блокирования отличается от указанной в первой команде.

Пример вывода:

This will destroy any data on /dev/csmb_vg/ctdb_lv.
  It appears to contain a gfs2 filesystem.

Are you sure you want to proceed? [y/n] y

Device:
/dev/csmb_vg/ctdb_lv
Blocksize:  		4096
Device Size 		1.00 GB (262144 blocks)
Filesystem Size: 	1.00 GB (262142 blocks)
Journals:		3
Resource Groups: 	4
Locking Protocol: 	"lock_dlm"
Lock Table: 		"csmb:ctdb_state"
UUID:
  BCDA8025-CAF3-85BB-B062-CC0AB8849A03

В этом примере файловая система /dev/csmb_vg/ctdb_lv на всех узлах будет смонтирована в /mnt/ctdb. Точка монтирования должна соответствовать расположению файла .ctdb.lock, которое определяется параметром CTDB_RECOVERY_LOCK в файле конфигурации /etc/sysconfig/ctdb (см. Раздел 11.4, «Конфигурация CTDB»).

11.4. Конфигурация CTDB

Файл конфигурации CTDB расположен в /etc/sysconfig/ctdb. Для нормального функционирования CTDB потребуется настроить обязательные значения:

CTDB_NODES
CTDB_PUBLIC_ADDRESSES
CTDB_RECOVERY_LOCK
CTDB_MANAGES_SAMBA (должно быть активно)
CTDB_MANAGES_WINBIND (должно быть активно при выполнении на сервере)

Пример файла:

CTDB_NODES=/etc/ctdb/nodes
CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
CTDB_RECOVERY_LOCK="/mnt/ctdb/.ctdb.lock"
CTDB_MANAGES_SAMBA=yes
CTDB_MANAGES_WINBIND=yes

Далее эти параметры рассмотрены более подробно.

CTDB_NODES

Определяет путь к файлу со списком узлов.

Файл /etc/ctdb/nodes содержит перечень IP-адресов узлов. Пример:

192.168.1.151
192.168.1.152
192.168.1.153

В этом примере для каждого узла настроен один IP-адрес, используемый для обслуживания клиентов и взаимодействия между кластером и базой данных CTDB. Однако на каждом узле настоятельно рекомендуется настроить отдельные интерфейсы для обслуживания клиентов и вазимодействия кластера с базой данных. Указанные адреса должны совпадать с перечисленными в файле cluster.conf, а определения интерфейсов должны соответстветствовать интерфейсам в файле public_addresses.

Файл /etc/ctdb/nodes должен быть идентичен на всех узлах кластера.

CTDB_PUBLIC_ADDRESSES

Определяет расположение файла со списком IP-адресов, используемых для доступа клиентов CIFS к экспортируемым каталогам Samba. Эти адреса должны быть сопоставлены DNS-имени сервера Samba. Имя сервера должно быть определено в виде DNS-записи типа A с несколькими IP-адресами узлов, которые будут выбираться циклически.

В этом примере запись csmb-server будет включать все адреса из файла /etc/ctdb/public_addresses. Выбор узлов для обработки запросов клиентов будет осуществляться циклически.

/etc/ctdb/public_addresses на каждом узле будет выглядеть так:

192.168.1.201/0 eth0
192.168.1.202/0 eth0
192.168.1.203/0 eth0

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

Далее приведен пример файла /etc/ctdb/public_addresses в кластере с тремя узлами, но четырьмя адресами. Адрес 198.162.2.1 может предоставляться узлом 0 или 1 и будет доступен клиентам при условии, что хотя бы один из двух узлов доступен. Остальные адреса предоставляются отдельными узлами.

Так, /etc/ctdb/public_addresses на узле 0 будет включать:

198.162.1.1/24 eth0
198.162.2.1/24 eth1

/etc/ctdb/public_addresses на узле 1 будет включать:

198.162.2.1/24 eth1
198.162.3.1/24 eth2

/etc/ctdb/public_addresses на узле 2 будет включать:

198.162.3.2/24 eth2

CTDB_RECOVERY_LOCK

Определяет файл блокирования, используемый базой данных CTDB для восстановления. Должен быть доступен всем узлам. В приведенном примере файловая система GFS2 будет смонтирована в /mnt/ctdb на всех узлах. Эта GFS2 отличается от файловой системы, где будет размещаться экспортируемый ресурс Samba. Файл блокирования предназначен для предотвращения разделения мощностей в кластере. В последних версиях CTDB (начиная с 1.0.112) этот файл не является обязательным, если определен другой механизм предотвращения подобных сценариев.

CTDB_MANAGES_SAMBA

Значение yes разрешает базе данных CTDB осуществлять запуск и остановку службы Samba при ее переносе на другой узел.

При активации CTDB_MANAGES_SAMBA следует отключить автоматический запуск smb и nmb в init:

[root@clusmb-01 ~]# chkconfig snb off
[root@clusmb-01 ~]# chkconfig nmb off

CTDB_MANAGES_WINBIND

Значение yes разрешает базе данных CTDB осуществлять запуск и остановку winbind. Рекомендуется установить, если CTDB используется в домене Windows или работает в защищенном режиме Active Directory.

При активации CTDB_MANAGES_SAMBA следует отключить автоматический запуск winbind в init:

[root@clusmb-01 ~]# chkconfig windinbd off

11.5. Конфигурация Samba

Файл конфигурации Samba расположен в /etc/samba/smb.conf и содержит следующее:

[global]
	guest ok = yes
	clustering = yes
	netbios name = csmb-server
[csmb]
	comment = Clustered Samba
 	public = yes
	path = /mnt/gfs2/share
	writeable = yes
	ea support = yes

Этот файл экспортирует общую папку csmb из /mnt/gfs2/share. В этом случае файловая система отличается от той, где будет размещаться файл /mnt/ctdb/.ctdb.lock из параметра CTDB_RECOVERY_LOCK.

В этом примере будет создан каталог share в /mnt/gfs2 сразу после ее монтирования. Выражение clustering = yes разрешает Samba использовать базу данных CTDB, netbios name = csmb-server гарантирует, что все узлы будут иметь одно и то же имя NetBIOS. Если необходимо определить дополнительные атрибуты, следует добавить параметр ea support.

Файл smb.conf должен быть быть идентичен на всех узлах кластера.

Samba также предоставляет возможности автоматической синхронизации конфигурации на всех узлах с помощью net conf. Подробную информацию можно найти на справочной странице net(8).

11.6. Запуск CTDB и Samba

После запуска кластера потребуется смонтировать созданные файловые системы GFS2 (см. Раздел 11.3, «Конфигурация GFS2»). При этом необходимо разрешить доступ клиентов к общему каталогу Samba.

Для запуска ctdbd надо выполнить приведенную ниже команду на всех узлах. Так как файл конфигурации содержит CTDB_MANAGES_SAMBA=yes, CTDB сможет запустить Samba на всех узлах и экспортировать настроенные общие каталоги Samba.

[root@clusmb-01 ~]# service ctdb start

Процесс запуска Samba, экспортирования каталогов и подготовки к работе может занять несколько минут. ctdb status позволяет проверить состояние выполнения.

[root@clusmb-01 ~]# ctdb status
Number of nodes:3
pnn:0 192.168.1.151     OK (THIS NODE)
pnn:1 192.168.1.152     OK
pnn:2 192.168.1.153     OK
Generation:1410259202
Size:3
hash:0 lmaster:0
hash:1 lmaster:1
hash:2 lmaster:2
Recovery mode:NORMAL (0)
Recovery master:0

Если статус всех узлов равен «OK», это значит, что кластерный сервер Samba готов к работе (см. Раздел 11.7, «Обращение к серверу Samba»).

11.7. Обращение к серверу Samba

Клиенты могут обращаться к каталогам Samba посредством подключения к одному из IP-адресов, заданных в файле /etc/ctdb/public_addresses, или при помощи DNS-записи csmb-server.

[root@clusmb-01 ~]# mount -t cifs //csmb-server/csmb /mnt/sambashare -o user=testmonkey

или

[user@clusmb-01 ~]$ smbclient //csmb-server/csmb

Приложение A. Параметры устройств изоляции

В этом приложении рассматриваются параметры устройств изоляции. Их значения могут быть изменены при помощи luci, команды ccs или посредством прямого редактирования файла etc/cluster/cluster.conf. Подробную информацию о параметрах отдельных агентов можно найти на их соответствующих справочных страницах.

Примечание

Параметр Name содержит произвольное имя устройства (не DNS-имя).

Примечание

Дополнительный параметр Password Script позволяет получить пароль устройства из сценария. Password Script имеет преимущество над Password, так как при использовании сценария нет необходимости в хранении пароля в /etc/cluster/cluster.conf.

Таблица A.1, «Обзор устройств изоляции» содержит список устройств и их агентов изоляции.

Таблица A.1. Обзор устройств изоляции

Устройство	Агент изоляции	Описание
Управление питанием APC (telnet/SSH)	fence_apc	Таблица A.2, «Управление питанием APC (telnet/SSH)»
Brocade Fabric Switch	fence_brocade	Таблица A.4, «Brocade Fabric Switch»
Cisco MDS	fence_cisco_mds	Таблица A.5, «Cisco MDS»
Cisco UCS	fence_cisco_ucs	Таблица A.6, «Cisco UCS»
Dell DRAC 5	fence_drac5	Таблица A.7, «Dell DRAC 5»
Источник питания Eaton (интерфейс SNMP)	fence_eaton_snmp	Таблица A.8, «Сетевой источник питания Eaton (начиная с Red Hat Enterprise Linux 6.4)»
SAN-контроллер Egenera	fence_egenera	Таблица A.9, «SAN-контроллер Egenera»
ePowerSwitch	fence_eps	Таблица A.10, «ePowerSwitch»
Fence virt	fence_virt	Таблица A.11, «Fence virt»
Fujitsu Siemens Remoteview Service Board (RSB)	fence_rsb	Таблица A.12, «Fujitsu Siemens Remoteview Service Board (RSB)»
HP BladeSystem	fence_hpblade	Таблица A.13, «HP BladeSystem (начиная с Red Hat Enterprise Linux 6.4)»
HP iLO/iLO2 (Integrated Lights Out)	fence_ilo	Таблица A.14, «HP iLO/iLO2 (Integrated Lights Out)»
HP iLO (Integrated Lights Out) MP	fence_ilo_mp	Таблица A.15, «HP iLO (Integrated Lights Out) MP»
IBM BladeCenter	fence_bladecenter	Таблица A.16, «IBM BladeCenter»
IBM BladeCenter SNMP	fence_ibmblade	Таблица A.17, «IBM BladeCenter SNMP»
IBM iPDU	fence_ipdu	Таблица A.18, «IBM iPDU (начиная с Red Hat Enterprise Linux 6.4)»
IF MIB	fence_ifmib	Таблица A.19, «IF MIB»
Intel Modular	fence_intelmodular	Таблица A.20, «Intel Modular»
IPMI (Intelligent Platform Management Interface) LAN	fence_ipmilan	Таблица A.21, «IPMI (Intelligent Platform Management Interface) LAN»
RHEV-M REST API	fence_rhevm	Таблица A.22, «RHEV-M REST API (RHEL 6.2+ с RHEV 3.0+)»
Изолирование SCSI	fence_scsi	Таблица A.23, «Изолирование SCSI»
Изоляция VMware (SOAP)	fence_vmware_soap	Таблица A.24, «VMware (интерфейс SOAP) (начиная с Red Hat Enterprise Linux 6.2)»
WTI Power Switch	fence_wti	Таблица A.25, «WTI Power Switch»

Таблица A.2, «Управление питанием APC (telnet/SSH)» cодержит список параметров агента fence_apc.

Таблица A.2. Управление питанием APC (telnet/SSH)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства APC, подключенного к кластеру, к которому обращается fenced.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Power wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port	`port`	Порт.
Switch (необязательный)	`switch`	Номер коммутатора для устройства APC, подключенного к узлу, при использовании нескольких последовательно соединенных коммутаторов.
Use SSH	`secure`	Использование SSH для доступа к устройству.
Path to SSH Identity File	`identity_file`	Файл удостоверения SSH.

Таблица A.3, «Управление питанием APC через SNMP» cодержит список параметров агента fence_apc_snmp.

Таблица A.3. Управление питанием APC через SNMP

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства APC, подключенного к кластеру, к которому агент изоляции обращается через SNMP.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
UDP/TCP port	`udpport`	Порт UDP/TCP, используемый для подключения к устройству (по умолчанию порт 161).
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3). Значение по умолчанию: 1.
SNMP Community	`community`	Строка сообщества SNMP. Значение по умолчанию: `private`.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP Privacy Protocol Password	`snmp_priv_passwd`	Пароль протокола шифрования SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port (Outlet) Number	`port`	Порт.

Таблица A.4, «Brocade Fabric Switch» cодержит список параметров агента fence_brocade.

Таблица A.4. Brocade Fabric Switch

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства Brocade, подключенного к кластеру.
IP Address или Hostname	`ipaddr`	IP-адрес устройства.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Port	`port`	Номер розетки коммутатора.

Таблица A.5, «Cisco MDS» cодержит список параметров агента fence_cisco_mds.

Таблица A.5. Cisco MDS

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства Cisco MDS 9000 с включенным SNMP.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
UDP/TCP port	`udpport`	Порт UDP/TCP, используемый для подключения к устройству (по умолчанию порт 161).
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Port (Outlet) Number	`port`	Порт.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3).
SNMP Community	`community`	Строка сообщества SNMP.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP Privacy Protocol Password	`snmp_priv_passwd`	Пароль протокола шифрования SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.

Таблица A.6, «Cisco UCS» cодержит список параметров агента fence_cisco_ucs.

Таблица A.6. Cisco UCS

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства Cisco UCS.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
Порт IP (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Use SSL	`ssl`	Взаимодействие с устройство через SSL.
Sub-Organization	`suborg`	Дополнительный путь доступа к подчиненной организации.
Port (Outlet) Number	`port`	Имя виртуальной машины.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.

Таблица A.7, «Dell DRAC 5» cодержит список параметров агента fence_drac5.

Таблица A.7. Dell DRAC 5

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя DRAC.
IP Address или Hostname	`ipaddr`	IP-адрес или имя DRAC.
IP Port (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя, используемое для доступа к DRAC.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Use SSH	`secure`	Использование SSH для доступа к устройству.
Path to SSH Identity File	`identity_file`	Файл удостоверения SSH.
Module Name	`module_name`	Дополнительное имя модуля при наличии нескольких модулей DRAC.
Force Command Prompt	`cmd_prompt`	Командная строка (по умолчанию — ’\$’).
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.

Таблица A.8, «Сетевой источник питания Eaton (начиная с Red Hat Enterprise Linux 6.4)» содержит список параметров, используемых агентом fence_eaton_snmp.

Таблица A.8. Сетевой источник питания Eaton (начиная с Red Hat Enterprise Linux 6.4)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя источника питания Eaton, подключенного к кластеру.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
UDP/TCP Port (необязательный)	`udpport`	Порт UDP/TCP, используемый для подключения к устройству (по умолчанию порт 161).
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3). Значение по умолчанию: 1.
SNMP Community	`community`	Строка сообщества SNMP. Значение по умолчанию: `private`.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP Privacy Protocol Password	`snmp_priv_passwd`	Пароль протокола шифрования SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power wait (seconds)	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port (Outlet) Number	`port`	Номер физического подключения или имя виртуальной машины. Этот параметр является обязательным.

Таблица A.9, «SAN-контроллер Egenera» содержит список параметров агента fence_egenera.

Таблица A.9. SAN-контроллер Egenera

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя Egenera BladeFrame, подключенного к кластеру.
CServer	`cserver`	Имя компьютера (и дополнительно имя пользователя в формате `username@hostname`). Подробную информацию можно найти на справочной странице fence_egenera(8).
ESH Path (необязательный)	`esh`	Путь к команде esh command на cserver (по умолчанию — /opt/panmgr/bin/esh).
Username	`user`	Имя пользователя (по умолчанию — `root`).
lpan	`lpan`	LPAN (Logical Process Area Network).
pserver	`pserver`	Имя устройства на blade-сервере pserver.

Таблица A.10, «ePowerSwitch» cодержит список параметров агента fence_eps.

Таблица A.10. ePowerSwitch

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства ePowerSwitch, подключенного к кластеру.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Name of Hidden Page	`hidden_page`	Имя спрятанной страницы.
Port (Outlet) Number	`port`	Номер розетки или имя виртуальной машины.

Таблица A.11, «Fence virt» cодержит список параметров агента fence_virt.

Таблица A.11. Fence virt

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства.
Serial Device	`serial_device`	Такому устройству на хосте должна соответствовать запись в файле конфигурации домена. За подробной информацией обратитесь к справочной странице `fence_virt.conf`. Если это поле содержит значение, агент `fence_virt` будет функционировать в последовательном режиме. Если поле не содержит значение, `fence_virt` будет работать в режиме канала виртуальной машины.
Serial Parameters	`serial_params`	Параметры устройства с последовательным интерфейсом (по умолчанию — 115200, 8N1).
VM Channel IP Address	`channel_address`	IP-адрес канала (по умолчанию — 10.0.2.179).
Port or Domain (устарел)	`port`	UUID домена или имя изолируемой виртуальной машины.
	`ipport`	Порт канала. По умолчанию используется номер 1229, так как именно этот порт используется при настройке устройства изоляции в luci.

Таблица A.12, «Fujitsu Siemens Remoteview Service Board (RSB)» cодержит список параметров агента fence_rsb.

Таблица A.12. Fujitsu Siemens Remoteview Service Board (RSB)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства изоляции RSB.
IP Address или Hostname	`ipaddr`	Имя хоста, присвоенное устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
TCP Port	`ipport`	Номер порта, который прослушивает telnet. По умолчанию прослушивается порт 3172.

Таблица A.13, «HP BladeSystem (начиная с Red Hat Enterprise Linux 6.4)» содержит список параметров fence_hpblade.

Таблица A.13. HP BladeSystem (начиная с Red Hat Enterprise Linux 6.4)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства HP Bladesystem, подключенного к кластеру.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя для доступа к устройству. Этот параметр является обязательным.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Force Command Prompt	`cmd_prompt`	Командная строка (по умолчанию — ’\$’).
Отсутствие порта возвращает OFF вместо ошибки.	`missing_as_off`	Отсутствие порта возвращает OFF вместо ошибки.
Power Wait (seconds)	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Use SSH	`secure`	Использование SSH для доступа к устройству.
Path to SSH Identity File	`identity_file`	Файл удостоверения SSH.

Таблица A.14, «HP iLO/iLO2 (Integrated Lights Out)» cодержит список параметров агента fence_ilo.

Таблица A.14. HP iLO/iLO2 (Integrated Lights Out)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя сервера с поддержкой HP iLO.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP, используемый для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.

Таблица A.15, «HP iLO (Integrated Lights Out) MP» cодержит список параметров агента fence_ilo_mp.

Таблица A.15. HP iLO (Integrated Lights Out) MP

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя сервера с поддержкой HP iLO.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP, используемый для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Use SSH	`secure`	Использование SSH для доступа к устройству.
Path to SSH Identity File	`identity_file`	Файл удостоверения SSH.
Force Command Prompt	`cmd_prompt`	Командная строка (по умолчанию — ’MP>’, ’hpiLO->’).
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.

Таблица A.16, «IBM BladeCenter» cодержит список параметров агента fence_bladecenter для IBM BladeCenter.

Таблица A.16. IBM BladeCenter

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства IBM BladeCenter.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
Порт IP (необязательный)	`ipport`	Порт TCP, используемый для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Use SSH	`secure`	Использование SSH для доступа к устройству.
Path to SSH Identity File	`identity_file`	Файл удостоверения SSH.

Таблица A.17, «IBM BladeCenter SNMP» cодержит список параметров агента fence_ibmblade.

Таблица A.17. IBM BladeCenter SNMP

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя IBM BladeCenter SNMP.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
UDP/TCP Port (необязательный)	`udpport`	Порт UDP/TCP, используемый для подключения к устройству (по умолчанию порт 161).
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3). Значение по умолчанию: 1.
SNMP Community	`community`	Строка сообщества SNMP.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP privacy protocol password	`snmp_priv_passwd`	Пароль протокола SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port	`port`	Номер розетки или имя виртуальной машины.

Таблица A.18, «IBM iPDU (начиная с Red Hat Enterprise Linux 6.4)» содержит список параметров агента fence_ipdu.

Таблица A.18. IBM iPDU (начиная с Red Hat Enterprise Linux 6.4)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства IBM iPDU, подключенного к кластеру, к которому агент изоляции обращается через SNMP.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
UDP/TCP Port	`udpport`	Порт UDP/TCP, используемый для подключения к устройству (по умолчанию порт 161).
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3). Значение по умолчанию: 1.
SNMP Community	`community`	Строка сообщества SNMP. Значение по умолчанию: `private`.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP Privacy Protocol Password	`snmp_priv_passwd`	Пароль протокола шифрования SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port	`port`	Порт.

Таблица A.19, «IF MIB» cодержит список параметров агента fence_ifmib.

Таблица A.19. IF MIB

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства IF MIB.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
UDP/TCP Port (необязательный)	`udpport`	Порт UDP/TCP, используемый для подключения к устройству (по умолчанию порт 161).
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3). Значение по умолчанию: 1.
SNMP Community	`community`	Строка сообщества SNMP.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP Privacy Protocol Password	`snmp_priv_passwd`	Пароль протокола шифрования SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port	`port`	Номер розетки или имя виртуальной машины.

Таблица A.20, «Intel Modular» cодержит список параметров агента fence_intelmodular.

Таблица A.20. Intel Modular

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства Intel Modular.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
SNMP Version	`snmp_version`	Версия SNMP (1, 2c, 3). Значение по умолчанию: 1.
SNMP Community	`community`	Строка сообщества SNMP. Значение по умолчанию: `private`.
SNMP Security Level	`snmp_sec_level`	Уровень защиты SNMP (noAuthNoPriv, authNoPriv, authPriv).
SNMP Authentication Protocol	`snmp_auth_prot`	Протокол аутентификации SNMP (MD5, SHA).
SNMP Privacy Protocol	`snmp_priv_prot`	Протокол шифрования SNMP (DES, AES).
SNMP Privacy Protocol Password	`snmp_priv_passwd`	Пароль протокола шифрования SNMP.
SNMP Privacy Protocol Script	`snmp_priv_passwd_script`	Сценарий, предоставляющий пароль для шифрования SNMP. Этот параметр имеет преимущество над значением SNMP privacy protocol password.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port	`port`	Номер розетки или имя виртуальной машины.

Таблица A.21, «IPMI (Intelligent Platform Management Interface) LAN» cодержит список параметров агента fence_ipmilan.

Таблица A.21. IPMI (Intelligent Platform Management Interface) LAN

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства LAN IPMI.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
Login	`login`	Имя пользователя, обладающего разрешениями на выдачу команд управления питанием порту IPMI.
Пароль	`passwd`	Пароль аутентификации подключения к порту IPMI.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Authentication Type	`auth`	Возможные типы аутентификации: `none`, `password`, `md5`.
Use Lanplus	`lanplus`	`True` или `1`. Если поле остается пустым, используется значение `False`.
Ciphersuite to use	`cipher`	Алгоритмы шифрования и аутентификации на удаленном сервере для подключений Lanplus IPMIv2.
Privilege level	`privlvl`	Уровень привилегий устройства IPMI.

Таблица A.22, «RHEV-M REST API (RHEL 6.2+ с RHEV 3.0+)» cодержит список параметров агента fence_rhevm для RHEV-M REST API.

Таблица A.22. RHEV-M REST API (RHEL 6.2+ с RHEV 3.0+)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства RHEV-M REST API.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Use SSL	`ssl`	Взаимодействие с устройство через SSL.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Port	`port`	Номер розетки или имя виртуальной машины.

Таблица A.23, «Изолирование SCSI» cодержит список параметров агента fence_scsi.

Примечание

Использование постоянного резервирования SCSI в качестве метода изоляции поддерживается со следующими ограничениями:

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

Таблица A.23. Изолирование SCSI

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя изолирующего устройства SCSI.
Node name
Key for current action		(переопределяет имя узла)

Таблица A.24, «VMware (интерфейс SOAP) (начиная с Red Hat Enterprise Linux 6.2)» cодержит список параметров агента fence_vmware_soap.

Таблица A.24. VMware (интерфейс SOAP) (начиная с Red Hat Enterprise Linux 6.2)

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя устройства изоляции виртуальной машины.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Separator	`separator`	Разделитель для созданного CSV. По умолчанию используется запятая.
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
VM name	`port`	Имя и путь к виртуальной машине (например /datacenter/vm/Discovered_virtual_machine/myMachine).\n\n\t
VM UUID	`uuid`	UUID изолируемой виртуальной машины.
Use SSL	`ssl`	Взаимодействие с устройство через SSL.

Таблица A.25, «WTI Power Switch» cодержит список параметров агента fence_wti.

Таблица A.25. WTI Power Switch

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя коммутатора WTI.
IP Address или Hostname	`ipaddr`	IP-адрес или имя устройства.
IP Port (необязательный)	`ipport`	Порт TCP для подключения к устройству.
Login	`login`	Имя для доступа к устройству.
Пароль	`passwd`	Пароль доступа к устройству.
Password Script (необязательный)	`passwd_script`	Сценарий, возвращающий пароль доступа к устройству. Этот параметр является более предпочтительным по сравнению с Password.
Port	`port`	Номер розетки или имя виртуальной машины.
Force command prompt	`cmd_prompt`	Командная строка (по умолчанию — [’RSM>’, ’>MPC’, ’IPS>’, ’TPS>’, ’NBB>’, ’NPS>’, ’VMR>’]).
Power Wait	`power_wait`	Время ожидания (в секундах) после запуска команд включения и отключения питания.
Use SSH	`secure`	Использование SSH для доступа к устройству.
Path to SSH Identity File	`identity_file`	Файл удостоверения SSH.

Приложение B. Параметры ресурсов

В данном приложении представлено описание параметров ресурсов высокой готовности. Эти параметры можно настроить при помощи luci, утилиты ccs или отредактировав файл etc/cluster/cluster.conf. Таблица B.1, «Обзор ресурсов» содержит список ресурсов, их агентов, а также ссылки на другие таблицы с описанием параметров. Ознакомиться с принципами работы агентов можно, просмотрев сценарии в каталоге /usr/share/cluster любого узла кластера.

Дополнительно можно ознакомиться с примером сценария service.sh в каталоге /usr/share/cluster.

Подробное описание элементов и атрибутов cluster.conf можно найти в /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html).

Таблица B.1. Обзор ресурсов

Ресурс	Агент	Описание параметров
Apache	apache.sh	Таблица B.2, «Сервер Apache»
Экземпляр Condor	condor.sh	Таблица B.3, «Экземпляр Condor»
Файловая система	fs.sh	Таблица B.4, «Filesystem»
GFS2	clusterfs.sh	Таблица B.5, «GFS2»
IP-адрес	ip.sh	Таблица B.6, «IP-адрес»
LVM	lvm.sh	Таблица B.7, «LVM»
MySQL	mysql.sh	Таблица B.8, «MySQL»
Клиент NFS	nfsclient.sh	Таблица B.9, «Клиент NFS»
Экспорт NFS	nfsexport.sh	Таблица B.10, «Экспорт NFS»
NFS-сервер	nfsserver.sh	Таблица B.11, «NFS-сервер»
ФС NFS/CIFS	netfs.sh	Таблица B.12, «ФС NFS/CIFS»
Open LDAP	openldap.sh	Таблица B.13, «Open LDAP»
Экземпляр восстановления Oracle 10g/11g	oracledb.sh	Таблица B.14, «Экземпляр Oracle 10g/11G»
Экземпляр восстановления Oracle 10g	orainstance.sh	Таблица B.15, «Экземпляр восстановления Oracle 10g»
Прослушивание Oracle 10g	oralistener.sh	Таблица B.16, «Прослушивание Oracle 10g»
PostgreSQL 8	postgres-8.sh	Таблица B.17, «PostgreSQL 8»
База данных SAP	SAPDatabase	Таблица B.18, «База данных SAP»
Экземпляр SAP	SAPInstance	Таблица B.19, «Экземпляр SAP»
Samba	samba.sh	Таблица B.20, «Сервер Samba»
Сценарий	script.sh	Таблица B.21, «Сценарий»
Sybase ASE	ASEHAagent.sh	Таблица B.22, «Экземпляр Sybase ASE»
Tomcat 6	tomcat-6.sh	Таблица B.23, «Tomcat 6»
Виртуальная машина	vm.sh	Таблица B.24, «Виртуальная машина» Примечание. Если кластер поддерживает виртуальные машины, в luci этот ресурс будет представлен как виртуальная служба.

Таблица B.2. Сервер Apache

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя службы.
Server Root	`server_root`	По умолчанию: `/etc/httpd`.
Config File	`config_file`	Файл конфигурации Apache. По умолчанию: `/etc/httpd/conf`.
httpd Options	`httpd_options`	Прочие параметры командной строки для `httpd`.
Shutdown Wait (seconds)	`shutdown_wait`	Время ожидания корректного завершения остановки службы (в секундах).

Таблица B.3. Экземпляр Condor

Поле	Поле luci	Атрибут в `cluster.conf`
Instance Name	`name`	Уникальное имя экземпляра Condor.
Condor Subsystem Type	`type`	Допустимые значения: `schedd`, `job_server`, `query_server`.

Таблица B.4. Filesystem

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя ресурса файловой системы.
Filesystem Type	`fstype`	Если не определен, `mount` попытается определить тип файловой системы.
Mount Point	`mountpoint`	Каталог, в который будет смонтирован данный ресурс.
Device, FS Label, or UUID	`device`	Устройство, ассоциированное с ресурсом (блочное устройство, метка файловой системы или UUID файловой системы).
Mount Options	`options`	Параметры монтирования файловой системы. Список поддерживаемых параметров можно найти на справочной странице `mount`(8).
File System ID (необязательный)	`fsid`	Примечание Идентификатор файловой системы используется только службами NFS. При создании нового ресурса это поле можно оставить пустым, что присвоит ID файловой системы автоматически.
Force Unmount	`force_unmount`	Этот параметр отвечает за принудительное отключение файловой системы. По умолчанию отключен (`disabled`). Если включен, процессы, использующие точку монтирования, будут завершены принудительно.
Force fsck	`force_fsck`	Если включен, перед монтированием файловой системы будет выполнена проверка `fsck`. По умолчанию отключен (`disabled`).
Enable NFS daemon and lockd workaround (начиная с Red Hat Enterprise Linux 6.4)	`nfsrestart`	Этот параметр помогает очистить ссылки на экспортированную файловую систему NFS до ее отключения, если иначе ее не удается отключить. Он не должен использоваться с ресурсом `NFS Server` и требует наличия параметра Force unmount. К его помощи следует прибегать лишь в крайних случаях, так как он принудительно отключает файловую систему.
Use Quick Status Checks	`quick_status`	Быстрая проверка статуса.
Reboot Host Node if Unmount Fails	`self_fence`	Если включен, но монтирование файловой системы завершилось неудачно, узел будет перезагружен. Агент ресурсов `filesystem` принимает значение 1, `yes`, `on`, `true` и 0, `no`, `off`, `false`. По умолчанию используется значение `disabled`.

Таблица B.5. GFS2

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя ресурса файловой системы.
Mount Point	`mountpoint`	Определяет каталог, в который монтируется файловая система.
Device, FS Label, or UUID	`device`	Файл устройства для ресурса файловой системы.
Filesystem Type	`fstype`	В luci определен как GFS2.
Mount Options	`options`	Параметры монтирования.
File System ID (необязательный)	`fsid`	Примечание Идентификатор файловой системы используется только службами NFS. При создании нового ресурса это поле можно оставить пустым, что присвоит ID файловой системы автоматически.
Force Unmount	`force_unmount`	Этот параметр отвечает за принудительное отключение файловой системы. По умолчанию отключен (`disabled`). Если включен, процессы, использующие точку монтирования, будут завершены принудительно. В случае падения службы операция отключения не будет выполнена, пока не будет активирована эта опция.
Enable NFS daemon and lockd workaround (начиная с Red Hat Enterprise Linux 6.4)	`nfsrestart`	Этот параметр помогает очистить ссылки на экспортированную файловую систему NFS до ее отключения, если иначе ее не удается отключить. Он не должен использоваться с ресурсом `NFS Server` и требует наличия параметра Force unmount. К его помощи следует прибегать лишь в крайних случаях, так как он принудительно отключает файловую систему.
Reboot Host Node if Unmount Fails	`self_fence`	Если включен, но монтирование файловой системы завершилось неудачно, узел будет перезагружен. Обычно используется в комбинации с Force Unmount. Агент ресурсов `GFS2` принимает значение 1, `yes`, `on`, `true` и 0, `no`, `off`, `false`.

Таблица B.6. IP-адрес

Поле luci	Атрибут в `cluster.conf`	Описание
IP Address, Netmask Bits	`address`	Виртуальный IP-адрес и, дополнительно, разряды маска сети ресурса. Биты маски сети могут быть указаны после адреса и отделяются наклонной чертой (например, 10.1.1.1/8).\nПоддерживаются адреса IPv4 и IPv6, а также мониторинг соединений NIC для каждого адреса.
Monitor Link	`monitor_link`	Если включен, то при отсутствии соединения NIC для этого IP-адреса проверка статуса завершается.
Disable Updates to Static Routes	`disable_rdisc`	Отключение обновления маршрутизации с помощью протокола RDISC.
Number of Seconds to Sleep After Removing an IP Address	`sleeptime`	Продолжительность бездействия (в секундах).

Таблица B.7. LVM

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Уникальное имя ресурса LVM.
Volume Group Name	`vg_name`	Имя группы томов.
Logical Volume Name (необязательный)	`lv_name`	Имя логического тома. Этот параметр используется только при управлении несколькими томами в группе томов.
Fence the Node if It is Unable to Clean UP LVM Tags	`self_fence`	Изоляция узла, если он не смог очистить метки LVM. Агент ресурсов LVM принимает значения 1, `yes`, 0, `no`.

Таблица B.8. MySQL

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя ресурса сервера MySQL.
Config File	`config_file`	Файл конфигурации. По умолчанию: `/etc/my.cnf`.
Listen Address	`listen_address`	Адрес прослушивания запросов для сервера MySQL. Если не определен, будет выбра первый IP-адрес службы.
mysqld Options	`mysqld_options`	Прочие параметры командной строки для `httpd`.
Startup Wait	`startup_wait`	Время ожидания корректного завершения запуска службы (в секундах).
Shutdown Wait (seconds)	`shutdown_wait`	Время ожидания корректного завершения остановки службы (в секундах).

Таблица B.9. Клиент NFS

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя клиента в дереве ресурсов. Это имя отличается от значения в поле `Target`.
Target Hostname, Wildcard, or Netgroup	`target`	Сервер, с которого осуществляется монтирование. Можно использовать имя машины, шаблоны (в строке IP-адреса или имени) и сетевые группы, содержащие узлы для экспорта.
Allow Recovery of This NFS Client	`allow_recover`	Разрешить восстановление.
Options	`options`	Список параметров для клиента. Описание параметров можно найти в секции General Options на справочной странице `exports` (5).

Таблица B.10. Экспорт NFS

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя ресурса. Этот ресурс отвечает за поддержку работы процессов NFS. Допускается многократное использование, но обычно используется только один ресурс такого типа. Примечание Рекомендуется использовать уникальное имя ресурса.

Таблица B.11. NFS-сервер

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Описательное имя NFS-ресурса, используемого для экспорта файловых систем NFSv4. На сервере может размещаться только один ресурс NFSv4. Дополнительно, NFS-ресурс не может использоваться одновременно локальными экземплярами NFS на узлах кластера.

Таблица B.12. ФС NFS/CIFS

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя ресурса. Примечание Ресурс такого типа необходим в случаях, когда кластерная служба настроена в качестве NFS-клиента.
Mount Point	`mountpoint`	Каталог, в который монтируется файловая система.
Host	`host`	IP-адрес или имя сервера NFS/CIFS.
NFS Export Directory Name or CIFS share	`export`	Имя экспортируемого каталога NFS/CIFS.
Filesystem type	`fstype`	Тип файловой системы: `NFS` — используется по умолчанию. `NFS v4` — использует протокол NFSv4. `CIFS` — использовать протокол CIFS.
Force Unmount	`force_unmount`	Если включен, кластер принудительно завершит все процессы, использующие файловую систему, в момент остановки службы. Принудительное завершение процессов освободит файловую систему. В противном случае unmount завершится ошибкой, и служба будет перезапущена.
Do Not Unmount the Filesystem During a Stop of Relocation Operation.	`no_unmount`	Предотвращает отключение файловой системы в ответ на остановку или перенос службы.
Options	`options`	Параметры монтирования. По умолчанию используется `-o sync`.

Таблица B.13. Open LDAP

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя службы ведения журнала.
Config File	`config_file`	Абсолютный путь к файлу конфигурации. По умолчанию: `/etc/openldap/slapd.conf`.
URL List	`url_list`	По умолчанию: `ldap:///`.
`slapd` Options	`slapd_options`	Другие параметры `slapd`.
Shutdown Wait (seconds)	`shutdown_wait`	Время ожидания корректного завершения остановки службы (в секундах).

Таблица B.14. Экземпляр Oracle 10g/11G

Поле luci	Атрибут в `cluster.conf`	Описание
Instance name (SID) of Oracle instance	`name`	Имя экземпляра.
Oracle User Name	`user`	Пользователь Oracle, от имени которого запускается экземпляр Oracle AS.
Oracle Application Home Directory	`home`	Домашний каталог Oracle (приложения, не пользователя). Настраивается при установке Oracle.
Oracle Installation Type	`type`	Тип установки Oracle. По умолчанию: `10g`; экземпляр базы данных и прослушивание: `base`; база данных, прослушивание, Enterprise Manager и ISQL*Plus: `base-em` или `10g`; Internet Application Server (инфраструктура): `ias` или `10g-ias`.
Virtual Hostname (дополнительно)	`vhost`	Это имя совпадает с именем узла, где установлена Oracle 10g. При запуске и остановке ресурса oracledb имя узла временно изменяется на указанное в этом поле. Поэтому ресурс oracledb следует настраивать как эксклюзивную службу.

Таблица B.15. Экземпляр восстановления Oracle 10g

Поле luci	Атрибут в `cluster.conf`	Описание
Instance name (SID) of Oracle instance	`name`	Имя экземпляра.
Oracle User Name	`user`	Пользователь Oracle, от имени которого запускается экземпляр Oracle.
Oracle Application Home Directory	`home`	Домашний каталог Oracle (приложения, не пользователя). Настраивается при установке Oracle.
List of Oracle Listeners (необязательно, разделяется пробелами)	`listeners`	Список модулей прослушивания, запускаемых при запуске экземпляра базы данных. По умолчанию список пуст.
Path to Lock File (необязательно)	`lockfile`	Путь к файлу блокирования работы Oracle. По умолчанию расположен в `/tmp`.

Таблица B.16. Прослушивание Oracle 10g

Поле luci	Атрибут в `cluster.conf`	Описание
Listener Name	`name`	Имя прослушивателя.
Oracle User Name	`user`	Пользователь Oracle, от имени которого запускается экземпляр Oracle.
Oracle Application Home Directory	`home`	Домашний каталог Oracle (приложения, не пользователя). Настраивается при установке Oracle.

Таблица B.17. PostgreSQL 8

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя службы ведения журнала.
Config File	`config_file`	Абсолютный путь к файлу конфигурации. По умолчанию: `/var/lib/pgsql/data/postgresql.conf`.
Postmaster User	`postmaster_user`	Администратор сервера базы данных. По умолчанию: postgres.
Postmaster Options	`postmaster_options`	Другие параметры командной строки.
Shutdown Wait (seconds)	`shutdown_wait`	Время ожидания корректного завершения остановки службы (в секундах).

Таблица B.18. База данных SAP

Поле luci	Атрибут в `cluster.conf`	Описание
SAP Database Name	`SID`	Уникальный системный идентификатор SAP, например P01.
SAP Executable Directory	`DIR_EXECUTABLE`	Путь к каталогу с `sapstartsrv` и `sapcontrol`.
Database Type	`DBTYPE`	Тип базы данных: Oracle, DB6, ADA.
Oracle Listener Name	`NETSERVICENAME`	Имя службы прослушивания Oracle TNS.
ABAP Stack is Not Installed, Only Java Stack is Installed	`DBJ2EE_ONLY`	Должен быть включен, если в базе данных SAP не установлен стек ABAP.
Application Level Monitoring	`STRICT_MONITORING`	Разрешает мониторинг на уровне приложений.
Automatic Startup Recovery	`AUTOMATIC_RECOVER`	Разрешает восстановление автоматического запуска.
Path to Java SDK	`JAVE_HOME`	Путь к Java SDK.
File Name of the JDBC Driver	`DB_JARS`	Имя файла драйвера JDBC.
Path to a Pre-Start Script	`PRE_START_USEREXIT`	Путь к сценарию, который будет выполняться перед запуском.
Path to a Post-Start Script	`POST_START_USEREXIT`	Путь к сценарию, который будет выполняться после запуска.
Path to a Pre-Stop Script	`PRE_STOP_USEREXIT`	Путь к сценарию, который будет выполняться перед остановкой.
Path to a Post-Stop Script	`POST_STOP_USEREXIT`	Путь к сценарию, который будет выполняться после остановки.
J2EE Instance Bootstrap Directory	`DIR_BOOTSTRAP`	Путь к каталогу сценариев запуска J2EE. Например: `/usr/sap/P01/J00/j2ee/cluster/bootstrap`.
J2EE Security Store Path	`DIR_SECSTORE`	Путь к каталогу хранения J2EE. Например: `/usr/sap/P01/SYS/global/security/lib/tools`.

Таблица B.19. Экземпляр SAP

Поле luci	Атрибут в `cluster.conf`	Описание
SAP Instance Name	`InstanceName`	Полное имя экземпляра SAP, например P01_DVEBMGS00_sapp01ci.
SAP Executable Directory	`DIR_EXECUTABLE`	Путь к каталогу с `sapstartsrv` и `sapcontrol`.
Directory Containing the SAP START Profile	`DIR_PROFILE`	Путь к профилю SAP START.
Name of the SAP START Profile	`START_PROFILE`	Имя профиля SAP START.
Number of Seconds to Wait Before Checking Startup Status	`START_WAITTIME`	Время задержки проверки статуса запуска без ожидания J2EE-Addin (в секундах).
Enable Automatic Startup Recovery	`AUTOMATIC_RECOVER`	Разрешает восстановление автоматического запуска.
Path to a Pre-Start Script	`PRE_START_USEREXIT`	Путь к сценарию, который будет выполняться перед запуском.
Path to a Post-Start Script	`POST_START_USEREXIT`	Путь к сценарию, который будет выполняться после запуска.
Path to a Pre-Stop Script	`PRE_STOP_USEREXIT`	Путь к сценарию, который будет выполняться перед остановкой.
Path to a Post-Stop Script	`POST_STOP_USEREXIT`	Путь к сценарию, который будет выполняться после остановки.

Примечание

Ресурсы Samba не могут быть подчиненными — они должны добавляться напрямую (см. Таблица B.20, «Сервер Samba»).

Таблица B.20. Сервер Samba

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя сервера Samba.
Config File	`config_file`	Файл конфигурации Samba.
Other Command-Line Options for smbd	`smbd_options`	Другие параметры командной строки smbd.
Other Command-Line Options for nmbd	`nmbd_options`	Другие параметры командной строки nmbd.
Shutdown Wait (seconds)	`shutdown_wait`	Время ожидания корректного завершения остановки службы (в секундах).

Таблица B.21. Сценарий

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя пользовательского сценария. Ресурс script позволяет использовать стандартный LSB-совместимый сценарий инициализации для запуска кластерной службы.
Full Path to Script File	`file`	Путь к сценарию, например `/etc/init.d/сценарий`.

Таблица B.22. Экземпляр Sybase ASE

Поле luci	Атрибут в `cluster.conf`	Описание
Instance Name	`name`	Имя экземпляра ресурса Sybase ASE.
ASE Server Name	`server_name`	Имя сервера ASE.
SYBASE Home directory	`sybase_home`	Домашний каталог продуктов Sybase.
Login File	`login_file`	Полный путь к файлу, содержащему пару имя входа-пароль.
Interfaces File	`interfaces_file`	Путь к файлу интерфейсов, используемых для запуска и доступа к серверу ASE.
SYBASE_ASE Directory Name	`sybase_ase`	Каталог внутри sybase_home, где установлены продукты ASE.
SYBASE_OCS Directory Name	`sybase_ocs`	Каталог внутри sybase_home, где установлены продукты OCS (например, ASE-15_0).
Sybase User	`sybase_user`	Имя пользователя, обладающего правами запуска сервера ASE.
Start Timeout	`start_timeout`	Время ожидания запуска (в секундах).
Shutdown Timeout	`shutdown_timeout`	Время ожидания остановки (в секундах).
Deep Probe Timeout	`deep_probe_timeout`	Максимальный период ожидания, по истечении которого принимается решение об отсутствии ответа от сервера ASE.

Таблица B.23. Tomcat 6

Поле luci	Атрибут в `cluster.conf`	Описание
Name	`name`	Имя службы ведения журнала.
Config File	`config_file`	Абсолютный путь к файлу конфигурации. По умолчанию: `/etc/tomcat6/tomcat6.conf`.
Shutdown Wait (seconds)	`shutdown_wait`	Время ожидания корректного завершения остановки службы (по умолчанию 30 секунд).

Важно

Запуск и остановку виртуальных машин в кластере (см. Таблица B.24, «Виртуальная машина») рекомендуется осуществлять с помощью инструментов rgmanager, так как virsh может привести к запуску нескольких копий, что может повредить данные. Раздел 2.14, «Виртуальные машины в кластере» содержит подробную информацию.

Примечание

Настройка ресурсов виртуальных машин несколько отличается от других ресурсов. Так, для настройки виртуальной машины в luci сначала потребуется добавить группу служб, в службу добавить ресурс, присвоив ему тип Virtual Machine, и определить параметры. Раздел 5.12, «Ресурсы виртуальных машин» содержит информацию о настройке виртуальной машины при помощи ccs.

Таблица B.24. Виртуальная машина

Поле luci	Атрибут в `cluster.conf`	Описание
Service Name	`name`	Имя виртуальной машины. В окне luci это значение содержит имя службы.
Automatically Start This Service	`autostart`	Если включен, виртуальная машина запускается автоматически после формирования кворума кластера. Если отключен, виртуальная машина не будет запускаться и останется в состоянии `disabled`.
Run Exclusive	`exclusive`	Если включен, виртуальную машину можно будет перенести только для эксклюзивной работы на одном узле кластера. Если на момент перемещения свободных узлов в кластере нет, то работа виртуальной машины не будет восстановлена. На узле, где работает виртуальная машина с активным параметром `Run exclusive`, нельзя запустить другие службы. Значение этого параметра можно переопределить, выполнив операции запуска и перемещения вручную.
Failover Domain	`domain`	Список узлов, на которых возможно восстановление работы после сбоя виртуальной машины.
Recovery Policy	`recovery`	Параметры: `Disable` — отключение виртуальной машины при сбое. `Relocate` — перезапуск виртуальной машины на другом узле без попытки перезапуска на текущем узле. `Restart` — попытка перезапуска виртуальной машины на текущем узле до ее переноса на другой узел. `Restart-Disable` — попытка перезапуска службы, но в случае неудачи она будет отключена.
Restart Options	`max_restarts`, `restart_expire_time`	Если выбран вариант Restart или Restart-Disable, эти значения позволяют задать максимальное число попыток перезапуска службы и время ожидания, по истечении которого перезапуск будет отменен.
Migration Type	`migrate`	Допустимые значения типа миграции: `live`, `pause`. По умолчанию используется `live`.
Migration Mapping	`migration_mapping`	Дополнительный интерфейс для миграции. Задается, если сетевой адрес, используемый для миграции виртуальной машины, отличается от адреса узла, взаимодействующего с кластером. Так, в следующем примере при миграции виртуальной машины с узла `member` на `member2` на самом деле она будет перенесена на узел `target2`. Аналогично при миграции с `member2` на `member` в действительности перенос осуществляется на узел `target`. `member:target,member2:target2`
Status Program	`status_program`	Программа проверки состояния виртуальной машины. Если определена, выполняется каждую минуту, что позволяет проверить работоспособность критических служб. Если проверка завершилась неудачей, будет инициирован процесс восстановления этой машины. После запуска агент ресурса виртуальной машины будет периодически вызывать программу проверки и ожидать код успешного завершения (ноль). Максимальное время ожидания ответа: 5 минут.
Path to xmlfile Used to Create the VM	`xmlfile`	Полный путь к XML-файлу `libvirt`, содержащему определение домена `libvirt`.
VM Configuration File Path	`path`	Список каталогов, разделенных двоеточием, где `vm.sh` будет выполнять поиск конфигурации виртуальной машины. Пример: `/mnt/guests/config:/etc/libvirt/qemu`. Важно Путь не должен напрямую ссылаться на файл конфигурации виртуальной машины.
Path to the VM Snapshot Directory	`snapshot`	Путь к каталогу, где расположен образ виртуальной машины.
Hypervisor URI	`hypervisor_uri`	URI гипервизора (обычно определяется автоматически).
Migration URI	`migration_uri`	URI миграции (обычно определяется автоматически).
Tunnel data over ssh during migration	`tunnelled`	Миграция данных по туннелю ssh.

Приложение C. Поведение ресурсов высокой готовности

В данном приложении рассматривается типичное поведение ресурсов высокой готовности с целью облегчения настройки соответствующих служб. Настройка параметров может осуществляться при помощи luci или напрямую в файле /etc/cluster/cluster.conf. Приложение B, Параметры ресурсов содержит перечень параметров. Ознакомиться с принципами работы агентов ресурсов можно, просмотрев сценарии в каталоге /usr/share/cluster любого узла кластера.

Примечание

Для того чтобы усвоить приведенную здесь информацию в полном объеме, требуется понимание принципов функционирования агентов ресурсов и знание структуры файла /etc/cluster/cluster.conf.

Служба высокой доступности представляет собой группу кластерных ресурсов, объединенных в единое целое. В файле конфигурации /etc/cluster/cluster.conf эта структура представлена в виде дерева ресурсов в формате XML.

Примечание

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

Содержание приложения:

Раздел C.1, «Отношения между ресурсами — родительские, дочерние, параллельные.»
Раздел C.2, «Порядок запуска параллельных и дочерних ресурсов»
Раздел C.3, «Наследование, секция <resources> и повторное использование ресурсов»
Раздел C.4, «Восстановление и независимые деревья»
Раздел C.5, «Отладка и тестирование служб и порядка следования ресурсов»

Примечание

Фрагменты файла /etc/cluster/cluster.conf в следующем разделе приведены только в целях демонстрации.

C.1. Отношения между ресурсами — родительские, дочерние, параллельные.

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

Пример C.1, «Иерархия ресурсов службы foo» демонстрирует пример простого дерева ресурсов службы foo. Отношения между ресурсами:

fs:myfs (<fs name="myfs" ...>) и ip:10.1.1.2 (<ip address="10.1.1.2 .../>) являются родственными.
fs:myfs (<fs name="myfs" ...>) является родителем script:script_child (<script name="script_child"/>).
script:script_child (<script name="script_child"/>) является дочерним для fs:myfs (<fs name="myfs" ...>).

Пример C.1. Иерархия ресурсов службы foo

<service name="foo" ...>
    <fs name="myfs" ...>
        <script name="script_child"/>
    </fs>
    <ip address="10.1.1.2" .../>
</service>

Для родительских и дочерних отношений в дереве ресурсов определяются следующие правила:

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

C.2. Порядок запуска параллельных и дочерних ресурсов

Ресурс «service» определяет порядок запуска и остановки дочерних ресурсов в соответствии с атрибутом «child type»:

Атрибут дочернего типа указан (типовой ресурс). Если в ресурсе типа «service» явно задан тип дочернего ресурса, такой дочерний ресурс называется типовым. Тип позволяет явно определить порядок запуска и остановки дочернего ресурса.
Атрибут типа не указан (нетиповой ресурс). Если в ресурсе типа «service» тип дочернего ресурса не задан, такой ресурс называется нетиповым. Ресурс службы не контролирует порядок запуска и остановки нетиповых ресурсов. Они запускаются и останавливаются в соответствии с порядком следования в файле /etc/cluster/cluster.conf. К тому же, запуск нетиповых ресурсов начинается только после запуска ресурсов с определенным значением типа, а их остановка происходит до остановки типовых ресурсов.

Примечание

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

Раздел C.2.1, «Запуск и остановка типовых дочерних ресуров» содержит дополнительную информацию о порядке запуска и остановки типовых дочерних ресуров, а Раздел C.2.2, «Запуск и остановка нетиповых дочерних ресуров» — о нетиповых ресурсах.

C.2.1. Запуск и остановка типовых дочерних ресуров

Атрибут «type» содержит значения от 1 до 100, определяющие порядок запуска и остановки ресурсов. Чем меньше значение, тем раньше ресурс запускается или останавливается. Таблица C.1, «Запуск и остановка разных типов ресурсов» содержит список значений для разных типов ресурсов, а Пример C.2, «Фрагмент service.sh с определениями значений запуска и остановки ресурсов» демонстрирует пример значений в service.sh. Сначала происходит запуск ресурсов типа LVM, затем ресурсов файловых систем, сценариев и т.д.

Таблица C.1. Запуск и остановка разных типов ресурсов

Ресурс	Тип	Порядок запуска	Порядок остановки
LVM	lvm	1	9
Файловая система	fs	2	8
GFS2	clusterfs	3	7
ФС NFS	netfs	4	6
Экспорт NFS	nfsexport	5	5
Клиент NFS	nfsclient	6	4
IP-адрес	ip	7	2
Samba	smb	8	3
Сценарий	script	9	1

Пример C.2. Фрагмент service.sh с определениями значений запуска и остановки ресурсов

<special tag="rgmanager">
    <attributes root="1" maxinstances="1"/>
    <child type="lvm" start="1" stop="9"/>
    <child type="fs" start="2" stop="8"/>
    <child type="clusterfs" start="3" stop="7"/>
    <child type="netfs" start="4" stop="6"/>
    <child type="nfsexport" start="5" stop="5"/>
    <child type="nfsclient" start="6" stop="4"/>
    <child type="ip" start="7" stop="2"/>
    <child type="smb" start="8" stop="3"/>
    <child type="script" start="9" stop="1"/>
</special>

Порядок запуска и остановки ресурсов одного типа определяется положением соответствующей записи в файле /etc/cluster/cluster.conf (см. Пример C.3, «Запуск и остановка ресурсов одного типа»).

Пример C.3. Запуск и остановка ресурсов одного типа

<service name="foo">
  <script name="1" .../>
  <lvm name="1" .../>
  <ip address="10.1.1.1" .../>
  <fs name="1" .../>
  <lvm name="2" .../>
</service>

C.2.1.1. Порядок запуска типовых ресурсов

В приведенном выше примере (см. Пример C.3, «Запуск и остановка ресурсов одного типа») запуск ресурсов производится в следующем порядке:

lvm:1 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:1 (<lvm name="1" .../>) запускается первым среди прочих ресурсов LVM, так как он является первым в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
lvm:2 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:2 (<lvm name="2" .../>) запускается после lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
fs:1 — ресурс файловой системы. Если бы в состав foo входили другие ресурсы этого типа, их запуск происходил бы в порядке следования в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.
script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.

C.2.1.2. Порядок остановки ресурсов согласно типу

В приведенном выше примере (см. Пример C.3, «Запуск и остановка ресурсов одного типа») остановка ресурсов производится в следующем порядке:

script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их остановка происходила бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
fs:1 — ресурс файловой системы. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
lvm:2 — ресурс LVM. Ресурсы LVM останавливаются последними. lvm:2 (<lvm name="2" .../>) останавливается до lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
lvm:1 — ресурс LVM. Ресурсы LVM останавливаются последними. lvm:1 (<lvm name="1" .../>) останавливается после lvm:2 , так как в списке ресурсов службы foo он определен перед lvm:1.

C.2.2. Запуск и остановка нетиповых дочерних ресуров

Если тип дочерних ресурсов не определен, порядок их запуска и остановки будет выбираться в соответствии с их расположением в /etc/cluster/cluster.conf. Запуск этих ресурсов начнется только после завершения запуска всех ресурсов с определенным значением типа, а остановка будет выполнена до остановки типовых ресурсов.

Пример C.4, «Нетиповые и типовые дочерние ресурсы» рассматривает порядок запуска и остановки ресурсов, для которых тип не определен.

Пример C.4. Нетиповые и типовые дочерние ресурсы

<service name="foo">
  <script name="1" .../>
  <nontypedresource name="foo"/>
  <lvm name="1" .../>
  <nontypedresourcetwo name="bar"/>
  <ip address="10.1.1.1" .../>
  <fs name="1" .../>
  <lvm name="2" .../>
</service>

C.2.2.1. Порядок запуска нетиповых ресурсов

В приведенном выше примере (см. Пример C.4, «Нетиповые и типовые дочерние ресурсы») запуск ресурсов производится в следующем порядке:

lvm:1 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:1 (<lvm name="1" .../>) запускается первым среди прочих ресурсов LVM, так как он является первым в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
lvm:2 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:2 (<lvm name="2" .../>) запускается после lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
fs:1 — ресурс файловой системы. Если бы в состав foo входили другие ресурсы этого типа, их запуск происходил бы в порядке следования в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.
script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.
nontypedresource:foo — ресурс без типа. Запуск таких ресурсов происходит после завершения запуска типовых ресурсов. Поскольку строка описания этого ресурса расположена выше строки второго нетипового ресурса (nontypedresourcetwo:bar), этот ресурс запускается перед nontypedresourcetwo:bar. Ресурсы запускаются в порядке следования.
nontypedresourcetwo:bar — ресурс без типа. Запуск таких ресурсов происходит после завершения запуска типовых ресурсов. Поскольку строка описания этого ресурса расположена ниже строки nontypedresource:foo, этот ресурс запускается после nontypedresource:foo.

C.2.2.2. Порядок остановки нетиповых ресурсов

В приведенном выше примере (см. Пример C.4, «Нетиповые и типовые дочерние ресурсы») остановка ресурсов производится в следующем порядке:

nontypedresourcetwo:bar — ресурс без типа. Остановка таких ресурсов происходит до остановки типовых ресурсов. Поскольку строка описания этого ресурса расположена ниже строки nontypedresource:foo, он будет остановлен до nontypedresource:foo. Ресурсы без типа останавливаются в порядке, обратном тому, в котором они перечислены в файле.
nontypedresource:foo — ресурс без типа. Остановка таких ресурсов происходит до остановки типовых ресурсов. Поскольку строка описания этого ресурса расположена выше строки nontypedresourcetwo:bar, он будет остановлен после nontypedresourcetwo:bar. Ресурсы без типа останавливаются в порядке, обратном тому, в котором они перечислены в файле.
script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их остановка происходила бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
fs:1 — ресурс файловой системы. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
lvm:2 — ресурс LVM. Ресурсы LVM останавливаются последними. lvm:2 (<lvm name="2" .../>) останавливается до lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
lvm:1 — ресурс LVM. Ресурсы LVM останавливаются последними. lvm:1 (<lvm name="1" .../>) останавливается после lvm:2 , так как в списке ресурсов службы foo он определен перед lvm:1.

C.3. Наследование, секция <resources> и повторное использование ресурсов

Для некоторых ресурсов наследование значений родительского ресурса может оказаться довольно эффективным; примером может служить NFS. Пример C.5, «Наследование и повторное использование ресурсов для NFS» демонстрирует типичную конфигурацию службы NFS, организации наследования и повторного использования ресурсов.

Пример C.5. Наследование и повторное использование ресурсов для NFS


    <resources>
        <nfsclient name="bob" target="bob.example.com" options="rw,no_root_squash"/>
        <nfsclient name="jim" target="jim.example.com" options="rw,no_root_squash"/>
        <nfsexport name="exports"/>
    </resources>
    <service name="foo">
        <fs name="1" mountpoint="/mnt/foo" device="/dev/sdb1" fsid="12344">
            <nfsexport ref="exports">  <!-- nfsexport's path and fsid attributes
                                            are inherited from the mountpoint &
                                            fsid attribute of the parent fs 
                                            resource -->
                <nfsclient ref="bob"/> <!-- nfsclient's path is inherited from the
                                            mountpoint and the fsid is added to the
                                            options string during export -->
                <nfsclient ref="jim"/>
            </nfsexport>
        </fs>
        <fs name="2" mountpoint="/mnt/bar" device="/dev/sdb2" fsid="12345">
            <nfsexport ref="exports">
                <nfsclient ref="bob"/> <!-- Because all of the critical data for this
                                            resource is either defined in the 
                                            resources block or inherited, we can
                                            reference it again! -->
                <nfsclient ref="jim"/>
            </nfsexport>
        </fs>
        <ip address="10.2.13.20"/>
    </service>

Если у службы нет родительских и дочерних связей, необходимо учесть следующее:

Для такой службы надо будет создать четыре ресурса «nfsclient» — по одному на каждую файловую систему (всего два на файловые системы), а также по одному на target-машину (всего два на target-машины).
Для каждого nfsclient надо будет путь экспорта и идентификатор файловой системы, что усиливает риск возникновения ошибок в файле конфигурации.

Пример C.5, «Наследование и повторное использование ресурсов для NFS» демонстрирует определения ресурсов nfsclient:bob, nfsclient:jim и nfsexport:exports. Их атрибуты наследуются от родительских ресурсов и являются динамическими, поэтому допускается их повторное использование и определение в секции «resources». На практике не всегда допускается настривать ресурсы в нескольких местах. Например, настройка ресурса файловой системы в разных местах может привести к монтированию одной файловой системы на разных узлах, что может привести к конфликтам.

C.4. Восстановление и независимые деревья

В большей части промышленных окружений стандартный подход к восстановлению работоспособности службы при сбое одного из компонентов заключается в ее полном перезапуске. Пример C.6, «Восстановление foo после сбоя» демонстрирует ситуацию, когда при сбое одного сценария служба будет перезапущена, перенесена или отключена (в зависимости от политики восстановления). Однако некоторые компоненты могут расмматриваться как некритические, то есть не требуют перезапуска всей службы. Для этой цели предназначен атрибут __independent_subtree. Так Пример C.7, «Восстановление foo с определенным атрибутом __independent_subtree» иллюстрирует реализацию следующей логики с помощью __independent_subtree:

Если script:script_one завершается с ошибкой, перезапустить script:script_two и script:script_one.
Если script:script_two завершается с ошибкой, перезапустить just script:script_two.
Если script:script_three завершается с ошибкой, перезапустить script:script_one, script:script_two и script:script_three.
Если script:script_four завершается с ошибкой, полностью перезапустить службу.

Пример C.6. Восстановление foo после сбоя

<service name="foo">
      <script name="script_one" ...>
          <script name="script_two" .../>
      </script>
      <script name="script_three" .../>
</service>

Пример C.7. Восстановление foo с определенным атрибутом __independent_subtree

<service name="foo">
      <script name="script_one" __independent_subtree="1" ...>
          <script name="script_two" __independent_subtree="1" .../>
          <script name="script_three" .../>
      </script>
      <script name="script_four" .../>
</service>

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

Примечание

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

Начиная с Red Hat Enterprise Linux 6.1 в дереве ресурсов каждого узла можно определить дополнительные значения:

__max_restarts определяет максимальное число попыток перезапуска;
__restart_expire_time определяет время ожидания, по истечении которого попытки перезапуска будут прекращены.

C.5. Отладка и тестирование служб и порядка следования ресурсов

Утилита rg_test отвечает за отладку и тестирование служб и порядка следования ресурсов. rg_test входит в состав пакета rgmanager, запускается из оболочки или терминала и недоступна в Conga. Таблица C.2, «Обзор rg_test» содержит список основных функций rg_test.

Таблица C.2. Обзор rg_test

Действие	Синтаксис
Просмотр правил ресурсов, которые распознает `rg_test`	`rg_test rules`
Проверка конфигурации и /usr/share/cluster на наличие ошибок и избыточных агентов ресурсов	`rg_test test /etc/cluster/cluster.conf`
Просмотр порядка запуска и остановки	Получение порядка запуска: `rg_test noop /etc/cluster/cluster.conf start service служба` Получение порядка остановки: `rg_test noop /etc/cluster/cluster.conf stop service служба`
Запуск и остановка службы	Важно Эту операцию следует выполнять только на одном узле, предварительно отключив службу в rgmanager. Запуск: `rg_test test /etc/cluster/cluster.conf start service служба` Остановка: `rg_test test /etc/cluster/cluster.conf stop service служба`
Определение и вывод отличий деревьев ресурсов в двух разных файлах cluster.conf	`rg_test delta cluster.conf file 1 cluster.conf file 2` Например: `rg_test delta /etc/cluster/cluster.conf.bak /etc/cluster/cluster.conf`

Приложение D. Проверка ресурсов кластерных служб и ожидание восстановления

В этом приложении рассказывается о мониторинге кластерных ресурсов и изменении интервала проверки их статуса. Дополнительно рассматривается параметр __enforce_timeouts, определяющий время ожидания ответа службы.

Примечание

Здесь упоминаются параметры из файла /etc/cluster/cluster.conf, полный список которых можно найти в /usr/share/cluster/cluster.rng и /usr/share/doc/cman-X.Y.ZZ/cluster_conf.html (например, /usr/share/doc/cman-3.0.12/cluster_conf.html).

D.1. Интервал проверки статуса ресурса

rgmanager проверяет состояние отдельных ресурсов, а не служб. Дерево ресурсов будет проверяться каждые 10 секунд.

Интервал настраивается отдельно для разных агентов ресурсов. Его значение может быть явно переопределено при помощи элемента <action> в файле cluster.conf:

<action name="status" depth="*" interval="10" />

В cluster.conf эта строка определяется в секции ресурса. Так, чтобы переопределить интервал для файловой системы, можно добавить ресурс файловой системы в cluster.conf:


  <fs name="test" device="/dev/sdb3">
    <action name="status" depth="*" interval="10" />
    <nfsexport...>
    </nfsexport>
  </fs>

Некоторые агенты предоставляют несколько уровней проверки. Например, стандартный тест файловой системы (уровень 0) заключается в проверке монтирования в нужный каталог. С другой стороны, на уровне 10 будет проверена возможность чтения файлов в файловой системе, на уровне 20 — возможность записи. В приведенном выше примере используется шаблон depth="*", то есть указанные значения будут применяться ко всем уровням проверки файловой системы test.

D.2. Ограничение времени ожидания

По умолчанию время ожидания запуска, остановки и восстановления ресурсов не ограничивается. Если остановка не удалась, будет зарегистрирован сбой службы. Время ожидания можно определить при помощи параметра __enforce_timeouts="1" в cluster.conf.

В приведенном ниже примере для ресурса netfs будет настроен параметр __enforce_timeouts. Если параметр установлен, время ожидания ограничивается 30 секундами, после чего статус службы будет определен как сбойный.


</screen>
<rm>
  <failoverdomains/>
  <resources>
    <netfs export="/nfstest" force_unmount="1" fstype="nfs" host="10.65.48.65" 
           mountpoint="/data/nfstest" name="nfstest_data" options="rw,sync,soft"/>
  </resources>
  <service autostart="1" exclusive="0" name="nfs_client_test" recovery="relocate">
    <netfs ref="nfstest_data" __enforce_timeouts="1"/>
  </service>
</rm>

Приложение E. Обзор команд

Таблица E.1, «Обзор инструментов командной строки» содержит перечень команд настройки и управления комплектом высокой степени готовности. Подробную информацию можно найти на соответствующих справочных страницах.

Таблица E.1. Обзор инструментов командной строки

Утилита	Используется в комплекте	Описание
`ccs_config_dump`: дамп конфигурации кластера	Инфраструктура кластера	`ccs_config_dump` создает XML активной конфигурации, которая может отличаться от содержимого файла конфигурации, так как некоторые подсистемы могут подставлять стандартные значения. Эти значения обычно не хранятся на диске и запрашиваются во время работы. За дальнейшей информацией обратитесь к справочной странице ccs_config_dump(8).
`ccs_config_validate`: проверка конфигурации кластера	Инфраструктура кластера	`ccs_config_validate` проверяет формат файлов `cluster.conf` и `cluster.rng` (в `/usr/share/cluster/cluster.rng`) на каждом узле. За дальнейшей информацией обратитесь к справочной странице ccs_config_validate(8).
`clustat`: проверка статуса кластера	Компоненты управления службами высокой степени готовности	`clustat` возвращает информацию о состоянии кластера: список элементов, кворум, статус пользовательских служб. За дальнейшей информацией обратитесь к справочной странице clustat(8).
`clusvcadm`: администрирование служб кластера	Компоненты управления службами высокой степени готовности	`clusvcadm` отвечает за активацию, отключение, перенос и перезапуск служб высокой степени готовности. За информацией обратитесь к справочной странице clusvcadm(8).
`cman_tool`: управление кластером	Инфраструктура кластера	`cman_tool` отвечает за управление менеджером кластера. С ее помощью можно добавить и исключить узел из кластера, отключить его или изменить кворум. За дальнейшей информацией обратитесь к справочной странице cman_tool(8).
`fence_tool`: программа разграничения	Инфраструктура кластера	`fence_tool` позволяет войти в состав домена изоляции или покинуть его. За информацией обратитесь к справочной странице fence_tool(8).

Приложение F. HA-LVM

Red Hat High Availability обеспечивает поддержку томов HA-LVM (High Availability LVM), что существенно отличается от активных структур CLVM (Clustered Logical Volume Manager). CLVM предоставляет расширения к системе управления томами совместного хранилища.

Решение в пользу CLVM или HA-LVM принимается исходя из потребностей приложений и служб.

Если приложения поддерживают кластер и могут одновременно выполняться на нескольких узлах в кластере, следует выбрать CLVM. Если узлы кластера обращаются к совместному хранилищу, которое доступно активным узлам, необходимо использовать CLVM. CLVM позволяет создавать логические тома в общем хранилище, блокируя доступ к физическому хранилищу на время настройки томов. Подробную информацию о CLVM можно найти в руководстве по администрированию LVM.
Если работоспособность приложений оптимальна в активно-пассивных схемах, где активен только узел, обращающийся к хранилищу, рекомендуется выбрать агенты HA-LVM (High Availability Logical Volume Management).

Большинство приложений будет лучше работать в активно-пассивной схеме, так как они изначально не предназначены для параллельной работы. При выполнении приложений, не поддерживающих кластер, на кластерных логических томах их производительность значительно снизится, особенно при создании зеркального отображения логических томов. И наоборот, производительность приложений с поддержкой кластера в целом возрастет. Индивидуальные требования кластера и необходимость дополнительной оптимизации помогут сделать выбор в пользу HA-LVM или CLVM. Обычно HA-LVM позволяет добиться лучших результатов.

Сходство HA-LVM и CLVM состоит в том, что они позволяют предотвратить повреждение метаданных и логических томов при изменении одних и тех же данных разными компьютерами. Так, в любой момент времени HA-LVM разрешает активацию тома только на одной машине, что, в свою очередь, гарантирует использование только локальных (не кластерных) драйверов хранилища. Так как операции выполняются локально, производительность такой организации довольно высокая. В свою очередь, CLVM не накладывает таких ограничений, то есть разрешается активации логических томов на любых машинах. Это требует использования драйверов с поддержкой кластерной функциональности.

Существует два основных метода конфигурации HA-LVM:

Первый и более предпочтительный подход заключается в использовании CLVM для эксклюзивной активации логических томов. Достоинством этого метода является простота настройки и снижение риска ошибок администратора (например, при удалении находящегося в работе тома). Для нормальной работы CLVM необходимо, чтобы в системе работали комплекты High Availability, Resilient Storage и процесс clvmd.
Раздел F.1, «Восстановление HA-LVM в CLVM» содержит информацию об этом методе конфигурации.
Второй подход подразумевает использование тегов LVM и блокирование локальной машины. Преимущество этого метода состоит в отсутствии необходимости установки пакетов кластера LVM, но при этом процедура конфигурации не исключает риск удаления неактивного логического тома. Раздел F.2, «Теги восстановления HA-LVM» содержит подробную информацию.

F.1. Восстановление HA-LVM в CLVM

Ниже рассматривается порядок настройки восстановления HA-LVM при помощи предпочитаемого варианта CLVM.

Убедитесь, что система поддерживает CLVM, то есть должны удовлетворяться следующие условия:
- Установлены комплекты High Availability и Resilient Storage, а также пакет cmirror (для зеркальной организации логических томов CLVM)/
- В файле /etc/lvm/lvm.conf значение параметра locking_type должно быть равно 3.
- Должны быть запущены программы High Availability и Resilient Storage, включая clvmd и дополнительно cmirrord (для зеркальной организации).
Создайте логический том и файловую систему:
```
# pvcreate /dev/sd[cde]1

# vgcreate -cy shared_vg /dev/sd[cde]1

# lvcreate -L 10G -n ha_lv shared_vg

# mkfs.ext4 /dev/shared_vg/ha_lv

# lvchange -an shared_vg/ha_lv
```
Подробную информацию о создании томов LVM можно найти в руководстве по администрированию LVM.

В /etc/cluster/cluster.conf добавьте определение нового тома в виде ресурса (ресурсы также могут быть настроены с помощью Conga и ccs). Пример:


<rm>  
   <failoverdomains>
       <failoverdomain name="FD" ordered="1" restricted="0">
          <failoverdomainnode name="neo-01" priority="1"/>
          <failoverdomainnode name="neo-02" priority="2"/>
       </failoverdomain>
   </failoverdomains>
   <resources>
       <lvm name="lvm" vg_name="shared_vg" lv_name="ha-lv"/>
       <fs name="FS" device="/dev/shared_vg/ha-lv" force_fsck="0" force_unmount="1" fsid="64050" fstype="ext4" mountpoint="/mnt" options="" self_fence="0"/>
   </resources>
   <service autostart="1" domain="FD" name="serv" recovery="relocate">
       <lvm ref="lvm"/>
       <fs ref="FS"/>
   </service>
</rm>

F.2. Теги восстановления HA-LVM

Ниже рассматривается порядок настройки восстановления HA-LVM при помощи тегов в /etc/lvm/lvm.conf.

Параметр locking_type в /etc/lvm/lvm.conf должен быть равен единице:
Создайте логический том и файловую систему:
```
# pvcreate /dev/sd[cde]1

# vgcreate shared_vg /dev/sd[cde]1

# lvcreate -L 10G -n ha_lv shared_vg

# mkfs.ext4 /dev/shared_vg/ha_lv
```
Подробную информацию о создании томов LVM можно найти в руководстве по администрированию LVM.
В /etc/cluster/cluster.conf добавьте определение нового тома в виде ресурса (ресурсы также могут быть настроены с помощью Conga и ccs). Пример:
```
<rm>  
   <failoverdomains>
       <failoverdomain name="FD" ordered="1" restricted="0">
          <failoverdomainnode name="neo-01" priority="1"/>
          <failoverdomainnode name="neo-02" priority="2"/>
       </failoverdomain>
   </failoverdomains>
   <resources>
       <lvm name="lvm" vg_name="shared_vg" lv_name="ha_lv"/>
       <fs name="FS" device="/dev/shared_vg/ha_lv" force_fsck="0" force_unmount="1" fsid="64050" fstype="ext4" mountpoint="/mnt" options="" self_fence="0"/>
   </resources>
   <service autostart="1" domain="FD" name="serv" recovery="relocate">
       <lvm ref="lvm"/>
       <fs ref="FS"/>
   </service>
</rm>
```
Примечание
Если группа содержит несколько логических томов, имя тома (lv_name) для ресурса lvm следует оставить пустым или вообще опустить. Также следует помнить, что в конфигурации HA-LVM группа томов может использоваться только одной службой.
В поле volume_list определите имя корневой группы томов и имя узла, в качестве которого надо указать имя локальной системы, где происходит редактирование файла lvm.conf. Эта строка должна соответствовать имени узла в /etc/cluster/cluster.conf. Перед именем узла надо добавить @. Пример:
```
volume_list = [ "VolGroup00", "@neo-01" ]
```
Этот тег сможет использоваться для активации общих логических томов и их групп. Строка не должна содержать имена групп, к которым не был открыт совместный доступ HA-LVM.
Обновите initrd на всех узлах кластера:
```
# dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
```
Перезагрузите все узлы для активации этого устройства initrd.

Приложение G. История переиздания

История переиздания

Издание 5.0-25.2.31.400 2013-10-31 Rüdiger Landmann

Rebuild with publican 4.0.0

Издание 5.0-25.2.31 Thu Oct 3 2013 Zac Dover

BZ#1007864 - s/Red Had/Red Hat/g

Издание 5.0-25.2 Wed May 1 2013 Yuliya Poyarkova

Перевод на русский язык.

Издание 5.0-25.1 Thu Apr 18 2013 Chester Cheng

Синхронизация с кодом XML 5.0-25

Издание 5.0-25 Mon Feb 18 2013 Steven Levine

Версия для Red Hat Enterprise Linux 6.4

Издание 5.0-23 Wed Jan 30 2013 Steven Levine

BZ#901641

Исправления правил iptables

Издание 5.0-22 Tue Jan 29 2013 Steven Levine

BZ#788636

Описание конфигурации RRP при помощи ccs.

BZ#789010

Описание конфигурации RRP в файле cluster.conf.

Издание 5.0-20 Fri Jan 18 2013 Steven Levine

BZ#894097

Удаление предупреждения о тегах VLAN.

BZ#845365

Добавлена информация о поддержке режимов агрегации 0 и 2.

Издание 5.0-19 Thu Jan 17 2013 Steven Levine

BZ#896234

Уточнения терминологии узлов кластера.

Издание 5.0-16 Mon Nov 26 2012 Steven Levine

Версия для выпуска Beta.

Издание 5.0-15 Wed Nov 20 2012 Steven Levine

BZ#838988

Описание атрибута nfsrestart.

BZ#843169

Информация об агенте iPDU IBM.

BZ#846121

Информация об агенте Eaton.

BZ#856834

Информация об агенте HP Bladesystem.

BZ#865313

Информация об агенте ресурсов NFS-сервера.

BZ#862281

Уточнение о переопределении значений с помощью ccs.

BZ#846205

Информация о фильтрации компонента igmp при помощи правил iptables.

BZ#857172

Информация о возможности удаления пользователей в luci.

BZ#857165

Описание параметра для уровня привилегий агента IPMI.

BZ#840912

Откорректирован формат таблицы параметров ресурсов.

BZ#849240, 870292

Уточнена последовательность установки.

BZ#871165

Уточнено описание параметра IP-адреса.

BZ#845333, 869039, 856681

Исправления опечаток.

Издание 5.0-12 Thu Nov 1 2012 Steven Levine

Добавлена информация о новых агентах изоляции.

Издание 5.0-7 Thu Oct 25 2012 Steven Levine

Добавлена секция о переопределении семантики.

Издание 5.0-6 Tue Oct 23 2012 Steven Levine

Исправлено стандартное значение задержки.

Издание 5.0-4 Tue Oct 16 2012 Steven Levine

Добавлено описание ресурса NFS-сервера.

Издание 5.0-2 Thu Oct 11 2012 Steven Levine

Обновлена информация о Conga.

Издание 5.0-1 Mon Oct 8 2012 Steven Levine

Уточнения семантики ccs.

Издание 4.0-5 Fri Jun 15 2012 Steven Levine

Версия для Red Hat Enterprise Linux 6.3.

Издание 4.0-4 Tue Jun 12 2012 Steven Levine

BZ#830148

Откорректированы номера портов в примерах luci.

Издание 4.0-3 Tue May 21 2012 Steven Levine

BZ#696897

Добавлено описание параметров cluster.conf.

BZ#811643

Описание восстановления базы данных luci на отдельном компьютере.

Издание 4.0-2 Wed Apr 25 2012 Steven Levine

BZ#815619

Удалено предупреждение об одноадресной рассылке UDP в GFS2.

Издание 4.0-1 Fri Mar 30 2012 Steven Levine

BZ#771447, BZ#800069, BZ#800061

Коррекции в соответствии с версией luci в Red Hat Enterprise Linux 6.3.

BZ#712393

Добавлена информация о создании снимка памяти приложений для RGManager.

BZ#800074

Добавлена информация об агенте condor.

BZ#757904

Добавлена информация о создании резервной копии и восстановлении конфигурации luci.

BZ#772374

Добавлена секция об управлении виртуальными машинами в кластере.

BZ#712378

Документация по настройке HA-LVM.

BZ#712400

Добавлено описание параметров отладки.

BZ #751156

Описание параметра fence_ipmilan.

BZ #721373

Добавлена информация о параметрах, требующих перезапуска кластера.

Издание 3.0-5 Thu Dec 1 2011 Steven Levine

Редакция для Red Hat Enterprise Linux 6.2.

BZ# 755849

Откорректирован пример monitor_link.

Издание 3.0-4 Mon Nov 7 2011 Steven Levine

BZ# 749857

Добавлена информация о REST API RHEV-M.

Издание 3.0-3 Fri Oct 21 2011 Steven Levine

BZ#747181, BZ#747182, BZ#747184, BZ#747185, BZ#747186, BZ#747187, BZ#747188, BZ#747189, BZ#747190, BZ#747192

Исправлены опечатки и неточности, обнаруженные в ходе редакции документа на этапе подготовки к выпуску Red Hat Enterprise Linux 6.2.

Издание 3.0-2 Fri Oct 7 2011 Steven Levine

BZ#743757

Исправления в секции о поддержке режима агрегации.

Издание 3.0-1 Wed Sep 28 2011 Steven Levine

Исходная версия для Red Hat Enterprise Linux 6.2 Beta.

BZ#739613

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

BZ#707740

Добавлена информация об изменениях в интерфейсе Conga и настройке разрешений для администрирования Conga.

BZ#731856

Добавлена информация о настройке luci в файле /etc/sysconfig/luci.

BZ#736134

Информация о поддержке передач UDPU.

BZ#736143

Информация о поддержке кластерных схем Samba.

BZ#617634

Информация о выделении отдельного IP-адреса для обслуживания luci.

BZ#713259

Описание поддержки fence_vmware_soap.

BZ#721009

Добавлена ссылка на статью "Support Essentials".

BZ#717006

Информация о разрешении многоадресной рассылки через межсетевой экран iptables.

BZ#717008

Добавлена информация о проверке состояния кластерных служб и о периоде ожидания обработки отказа.

BZ#711868

Уточнено описание autostart.

BZ#728337

Описание последовательности добавления ресурсов vm с помощью ccs.

BZ#725315, BZ#733011, BZ#733074, BZ#733689

Исправления опечаток.

Издание 2.0-1 Thu May 19 2011 Steven Levine

Language and Page Formatting Options

Red Hat Training

Администрирование кластера

Red Hat High Availability

Введение

1. Отзывы и предложения

Глава 1. Обзор

1.1. Основные изменения

1.1.1. Red Hat Enterprise Linux 6.1

1.1.2. Red Hat Enterprise Linux 6.2

1.1.3. Red Hat Enterprise Linux 6.3

1.1.4. Red Hat Enterprise Linux 6.4

1.2. Обзор конфигурации

1.3. Подготовка оборудования

1.4. Установка программ Red Hat High Availability

1.4.1. Обновление программ

1.5. Настройка программ Red Hat High Availability

Глава 2. Подготовка системы

2.1. Общие требования

2.2. Совместимость оборудования

2.3. Доступ к портам IP

2.3.1. Доступ к портам IP на узлах кластера

2.3.2. Порт для luci

2.3.3. Настройка правил iptables

2.4. /etc/sysconfig/luci

2.5. ACPI и интегрированные устройства изоляции

2.5.1. Отключение ACPI Soft-Off с помощью chkconfig

2.5.2. Отключение ACPI Soft-Off в BIOS

2.5.3. Отключение ACPI в grub.conf

2.6. Особенности настройки служб высокой готовности

2.7. Валидация cluster.conf

2.8. NetworkManager

2.9. Диск кворума

2.10. SELinux

2.11. Многоадресная рассылка

2.12. Одноадресная передача UDP

2.13. ricci

2.14. Виртуальные машины в кластере

Глава 3. Настройка кластера в Conga

3.1. Задачи настройки

3.2. Запуск luci

3.3. Управление доступом к luci

3.4. Создание кластера

3.5. Глобальные параметры кластера

3.5.1. Настройка глобальных параметров

3.5.2. Настройка fenced

3.5.3. Настройка сети

3.5.4. Настройка протокола избыточного кольца

3.5.5. Настройка диска кворума

3.5.6. Настройка журналирования

3.6. Настройка устройств изоляции

3.6.1. Создание устройства изоляции

3.6.2. Изменение параметров устройств изоляции

3.6.3. Удаление устройства изоляции

3.7. Исключение узлов из кластера

3.7.1. Настройка устройства изоляции

3.7.2. Настройка запасного устройства изоляции

3.7.3. Настройка запасных источников питания

3.8. Настройка резервного домена

3.8.1. Добавление резервного домена

3.8.2. Изменение резервного домена

3.8.3. Удаление резервного домена

3.9. Настройка глобальных ресурсов кластера

3.10. Добавление службы в кластер

Глава 4. Управление кластером с помощью Conga

4.1. Добавление кластера в luci

4.2. Удаление кластера из luci

4.3. Управление узлами кластера

4.3.1. Перезагрузка узла

4.3.2. Добавление и удаление узлов

4.3.3. Добавление узла в работающий кластер

4.3.4. Удаление узла из кластера

4.4. Запуск, остановка, перезапуск и удаление кластера

4.5. Управление службами высокой готовности

4.6. Создание резервной копии и восстановление конфигурации luci

Глава 5. Настройка кластера с помощью ccs

5.1. Обзор

5.1.1. Создание файла конфигурации локально

5.1.2. Просмотр файла конфигурации

5.1.3. Определение паролей ricci

2.4. `/etc/sysconfig/luci`

2.5.1. Отключение ACPI Soft-Off с помощью `chkconfig`

2.5.3. Отключение ACPI в `grub.conf`

2.13. `ricci`

5.9. Так, следующая команда покажет список служб на узле `node1`.

7.2.2. Значение `consensus` элемента `totem` в кластере с двумя узлами