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

Logo

Аннотация

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

1.1.2. Red Hat Enterprise Linux 6.2

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.2.
Кроме того, внесены другие незначительные изменения и дополнения.

1.1.3. Red Hat Enterprise Linux 6.3

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.3.
Кроме того, внесены другие незначительные изменения и дополнения.

1.1.4. Red Hat Enterprise Linux 6.4

Ниже перечислены основные изменения в Red Hat Enterprise Linux 6.4.
Кроме того, внесены другие незначительные изменения и дополнения.

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 программы кластера можно обновить без необходимости остановки кластера. Для этого требуется лишь остановить, обновить и перезапустить программы поочередно на каждом узле.
  1. Остановите работу служб кластера (см. Раздел 8.1.2, «Остановка кластерных программ»). В некоторых случаях может быть рекомендовано перенести кластерные службы и виртуальные машины на другой узел и уже после этого остановить rgmanager.
  2. Обновите пакеты с помощью yum update.
  3. Перезапустите службы или перезагрузите узел (см. Раздел 8.1.1, «Запуск кластерных программ»).

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

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

Примечание

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

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

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

Важно

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

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):
Следующий раздел содержит информацию о правилах iptables для активации портов, необходимых для нормальной работы Red Hat High Availability:

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.
  1. Снимите комментарий со строки:
    #port = 4443
    
  2. Измените номер порта (должен быть больше 1024), например:
    port = 8084
    
  3. Перезапустите 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

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

Примечание

Этот метод является предпочтительным.
Порядок отключения ACPI Soft-Off на каждом узле:
  1. Выполните:
    • chkconfig --del acpid (удаляет acpid из списка служб под управлением chkconfig)
      ИЛИ
    • chkconfig --level 2345 acpid off (отключает acpid).
  2. Перезагрузите узел.
  3. После настройки и запуска кластера убедитесь, что в результате процедуры изоляции узел немедленно отключается.

    Примечание

    Процесс изоляции узла можно инициировать из интерфейса 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 на каждом узле:
  1. Перезагрузите компьютер и войдите в BIOS.
  2. Перейдите в меню настройки питания.
  3. Измените значение 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 таким образом, чтобы компьютер выключался сразу же после нажатия кнопки питания.
  4. Сохраните изменения и выйдите из BIOS.
  5. После настройки и запуска кластера убедитесь, что в результате процедуры изоляции узел немедленно отключается.

    Примечание

    Процесс изоляции узла можно инициировать из интерфейса 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-BTTNInstant-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 на всех узлах кластера:
  1. Откройте /boot/grub/grub.conf в текстовом редакторе.
  2. Добавьте acpi=off в команду загрузки ядра (см. Пример 2.2, «Команда загрузки ядра с параметром acpi=off»).
  3. Перезагрузите узел.
  4. После настройки и запуска кластера убедитесь, что в результате процедуры изоляции узел немедленно отключается.

    Примечание

    Процесс изоляции узла можно инициировать из интерфейса 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.

Примечание

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

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


<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.2. Запуск luci

Примечание

На каждом узле кластера под управлением luci необходимо установить ricci (см. Раздел 2.13, «ricci»). Как уже упоминалось, при добавлении нового узла в кластер потребуется ввести пароль ricci (см. Раздел 3.4, «Создание кластера»).
Предварительно на узлах кластера надо открыть порт 11111 для разрешения подключений с сервера luci (см. Раздел 2.3.1, «Доступ к портам IP на узлах кластера»).
Далее рассматривается порядок установки luci.
  1. Выберите компьютер для установки luci и выполните:
    # yum install luci

    Примечание

    Обычно для luci выделяется отдельный компьютер в центре обработки данных; тем не менее, luci можно установить и на узле в составе кластера.
  2. Запустите 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 строка адреса будет содержать новый номер порта.
  3. В адресной строке веб-браузера введите адрес сервера luci в формате https://узел:порт. По умолчанию используется порт 8084.
    При первом обращении к luci появится окно подтверждения сертификата SSL. После этого откроется форма авторизации в luci.
  4. Для авторизации можно использовать данные любого пользователя системы, где установлено приложение luci, но начиная с Red Hat Enterprise Linux 6.2 только пользователь root изначально обладает правами доступа к компонентам luci (см. Раздел 3.3, «Управление доступом к luci»).
    После успешной авторизации будет показана домашняя страница (см. Рисунок 3.1, «Домашняя страница luci»).
    Домашняя страница 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 установит необходимые программы на узлах и запустит кластер.
  1. В левой панели навигации выберите пункт Manage Clusters. Появится окно управления (см. Рисунок 3.2, «Окно управления кластером»).
    Окно управления кластером

    Рисунок 3.2. Окно управления кластером

  2. Выберите пункт создания кластера (см. Рисунок 3.3, «Диалог создания кластера luci»).
    Диалог создания кластера luci

    Рисунок 3.3. Диалог создания кластера luci

  3. Ниже перечислены поля, которые следует заполнить.
    • В поле 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. Не следует выбирать этот пункт при отсутствии комплектов отказоустойчивого хранилища и масштабируемой файловой системы.
  4. Нажмите кнопку создания кластера. Будут выполнены следующие действия:
    1. Если был выбран пункт Download Packages, на добавляемые компьютеры будут загружены необходимые программы.
    2. Загруженные программы кластера будут установлены на всех компьютерах.
    3. Файл конфигурации кластера будет обновлен и передан всем узлам кластера.
    4. Перечисленные компьютеры будут добавлены в состав кластера.
    Наконец, появится окно состояния полученного кластера (см. Рисунок 3.4, «Список компонентов кластера»). Стоит отметить, что если процесс ricci выполняется не на всех узлах, создание кластера завершится неудачей.
    Список компонентов кластера

    Рисунок 3.4. Список компонентов кластера

  5. С помощью кнопок добавления и удаления узлов в верхней строке меню можно изменить состав кластера. Удаляемые узлы сначала надо остановить (см. Раздел 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-адреса, имени пользователя, пароля). Настройки выбранного устройства могут быть изменены. Процесс удаления включает в себя выбор устройства и, собственно, его удаление.
Содержание этой секции:
Чтобы настроить устройства изоляции, выберите Fence Devices в верхней части страницы кластера. Появится список устройств и кнопки изменения, удаления и добавления новых устройств.

Примечание

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

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

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

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

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

Порядок изменения параметров:
  1. Выберите устройство в окне Fence Devices для перехода к его настройкам.
  2. Нажмите Apply.

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

Примечание

Устройства, к которым осуществляется обращение, нельзя удалить — сначала следует обновить конфигурацию узла и уже после этого удалить устройство.
Порядок удаления:
  1. Выберите устройства в окне Fence Devices.
  2. Нажмите Delete и дождитесь подтверждения.
Устройство будет удалено из списка.

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

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

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

Ниже рассматривается порядок настройки единственного устройства изоляции для узла.
  1. В главном меню кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
  2. Щелкните на имени узла для перехода к его настройкам.
    На этой странице будут показаны активные службы и резервные домены, в состав которых входит данный компьютер (см. Раздел 3.8, «Настройка резервного домена»).
  3. В секции Fence Devices выберите Add Fence Method — появится окно Add Fence Method to Node.
  4. В поле Method Name введите произвольное имя.
  5. Нажмите Submit.
  6. Чтобы добавить устройство для этого метода, нажмите Add Fence Instance и выберите настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
  7. Если устройство требует отдельно определить параметры для узла, будет предложено их настроить (см. Приложение A, Параметры устройств изоляции).

    Примечание

    Для методов управления доступом к хранилищу/SAN пункт Unfencing в списке параметров будет выбран по умолчанию. Этот параметр предотвращает подключение исключенного узла к хранилищу до тех пор, пока он не будет перезагружен. Подробную информацию можно найти на справочной странице fence_node(8).
  8. Нажмите Submit.

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

Для одного узла можно определить несколько алгоритмов изоляции. Если один метод не работает, будет выбран следующий и т.п.
Ниже рассматривается порядок настройки запасного устройства для узла.
  1. Настройте основной алгоритм (см. Раздел 3.7.1, «Настройка устройства изоляции»).
  2. В нижней части окна алгоритма нажмите Add Fence Method.
  3. Введите имя алгоритма и нажмите Submit. Новый алгоритм появится в списке следом за основным методом.
  4. Чтобы добавить устройство для этого метода, нажмите Add Fence Instance под его именем и выберите предварительно настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
  5. Если устройство требует отдельно определить параметры для узла, будет предложено их настроить (см. Приложение A, Параметры устройств изоляции).
  6. Нажмите Submit.
При необходимости можно добавить другие алгоритмы. Их порядок можно изменить с помощью кнопок Move Up и Move Down.

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

Если в кластере настроено несколько источников питания, для изоляции узла потребуется отключить все его источники. Если каждый источник контролируется отдельным алгоритмом, он будет отключаться отдельно и вместо него просто начнет использоваться другой источник, тем самым предотвращая изоляцию узла. Так, если узел использует два источника питания, для их одновременного отключения надо будет настроить два устройства для одного метода изоляции.
Ниже рассматривается порядок отключения узла с двумя источниками питания.и
  1. Сначала надо определить оба источника питания как устройства изоляции (см. Раздел 3.6, «Настройка устройств изоляции»).
  2. В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
  3. Щелкните на имени узла для перехода к его настройкам.
  4. На странице узла нажмите Add Fence Method.
  5. Введите имя метода изоляции.
  6. Нажмите Submit.
  7. Добавьте первый источник питания, нажав Add Fence Instance под названием алгоритма. В открывшемся меню выберите предварительно настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
  8. Выберите источник питания и заполните его параметры.
  9. Нажмите Submit.
  10. Добавьте второй источник питания, нажав Add Fence Instance. В открывшемся меню выберите предварительно настроенное устройство (см. Раздел 3.6.1, «Создание устройства изоляции»).
  11. Выберите второй источник питания и заполните его параметры.
  12. Нажмите Submit. Появится окно узла со списком настроенных алгоритмов и устройств (см. Рисунок 3.6, «Конфигурация с двумя источниками питания»).
    Конфигурация с двумя источниками питания

    Рисунок 3.6. Конфигурация с двумя источниками питания

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

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

    Примечание

    Функция возврата доступна только для упорядоченного типа.

Примечание

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

Примечание

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

Примечание

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

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

Ниже рассматривается порядок добавления резервного домена.
  1. В главном меню кластера выберите Failover Domains для перехода к списку его резервных доменов.
  2. Нажмите Add для перехода к диалогу добавления домена (см. Рисунок 3.7, «Окно настройки резервного домена»).
    Окно настройки резервного домена

    Рисунок 3.7. Окно настройки резервного домена

  3. В поле Name введите имя домена.

    Примечание

    Рекомендуется указать информативное имя, которое поможет легко идентифицировать домен.
  4. Если при выборе запасного узла должен учитываться приоритет, установите флажок Prioritized и укажите приоритет в поле Priority.
  5. Пункт Restricted отвечает за восстановление работы сбойной службы только на узлах, входящих в состав резервного домена.
  6. Если установлен флажок No Failback, то при возобновлении работы исходного узла выполняемая на запасном узле служба не будет переноситься обратно.
  7. Чтобы добавить узел в домен, установите флажок Member напротив его имени. Если выше был выбран пункт Prioritized, укажите значение в поле Priority.
  8. Нажмите Create. Появится подтверждение создания домена.

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

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

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

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

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

В кластер можно добавить глобальные ресурсы (будут доступны всем службам) и частные (будут доступны выборочным службам).
Ниже рассматривается порядок добавления глобальных кластерных ресурсов. Информацию о добавлении локальных ресурсов для отдельных служб можно найти в следующем разделе (см. Раздел 3.10, «Добавление службы в кластер»).
  1. В главном меню страницы кластера выберите Resources для перехода к списку настроенных ресурсов.
  2. Нажмите Add для перехода к диалогу добавления ресурсов.
  3. Из выпадающего списка выберите тип ресурса.
  4. Введите параметры (см. Приложение B, Параметры ресурсов).
  5. Нажмите Submit. Новый ресурс будет добавлен в список ресурсов кластера.
Порядок изменения ресурса:
  1. Выберите ресурс на странице Resources.
  2. Измените параметры.
  3. Нажмите Apply.
Порядок удаления ресурса:
  1. Выберите ресурс на странице Resources.
  2. Нажмите Delete.

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

Ниже рассматривается порядок добавления кластерных служб в кластер.
  1. В главном меню страницы кластера выберите Service Groups для перехода к списку служб (см. Раздел 4.5, «Управление службами высокой готовности»).
  2. Чтобы добавить службу, нажмите Add.
  3. В поле Service name введите имя службы.

    Примечание

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

    Примечание

    Ресурсы Samba не могут быть подчиненными и должны быть добавлены напрямую.
  10. Завершив добавление, нажмите 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
Порядок изменения существующей службы:
  1. Выберите службу на странице Service Groups для перехода к странице ее настроек.
  2. Измените параметры.
  3. Нажмите Submit.
Порядок удаления служб:
  1. Выберите службы на странице Service Groups.
  2. Нажмите Delete.
  3. В Red Hat Enterprise Linux 6.3 сначала появится запрос подтверждения удаления. Cancel закроет диалог без удаления, а Proceed удалит службы.

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

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

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

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

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

Кластер может быть удален из интерфейса luci. Это не скажется на его составе и работе служб. Удаленный кластер можно будет впоследствии снова добавить (см. Раздел 4.1, «Добавление кластера в luci»).
Чтобы удалить кластер из интерфейса luci, выполните следующее:
  1. В левой панели навигации выберите пункт Manage Clusters. Появится окно управления кластерами.
  2. Выберите кластеры для удаления.
  3. Нажмите Remove.
Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера» содержит информацию об остановке служб кластера, удалении конфигурации с узлов и удалении кластера полностью.

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

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

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

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

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

С помощью Conga можно добавить или исключить узел из кластера, предварительно остановив работающие кластерные службы.
При исключении узла настройки кластера не будут удалены, а сам узел будет доступен в списке узлов со статусом Not a cluster member (см Раздел 4.3.4, «Удаление узла из кластера»).
Ниже приведен порядок удаления узла из кластера. Удаленный узел не будет включен в состав кластера даже после перезагрузки.
  1. В главном меню страницы кластера выберите Nodes для перехода к списку узлов. Этот список также можно открыть, выбрав имя кластера в секции Manage Clusters на домашней странице luci.
  2. Выберите узел.
  3. В верхнем меню выберите Leave Cluster. Появится сообщение об остановке узла.
  4. Чтобы получить текущий статус, обновите страницу.
Чтобы удалить несколько узлов, отметьте их и нажмите Leave Cluster.
Чтобы вернуть узлы в состав кластера, выберите их и нажмите Join Cluster.

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

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

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

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

    Примечание

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

Важно

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

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

На вкладке Nodes страницы кластера можно запустить, остановить и перезапустить его узлы.
Запуск и перезапуск узлов позволяет искуственно создать ситуацию переноса служб на другой узел, так как они не смогут продолжать работу на остановленном узле.
Ниже рассматривается порядок остановки кластера, что подразумевает завершение работы всех программ на узлах без удаления конфигурации кластера. Узлы по-прежнему будут доступны в окне содержимого кластера со статусом Not a cluster member.
  1. Отметьте все узлы в списке.
  2. В верхнем меню выберите Leave Cluster. Появится сообщение об остановке узла.
  3. Чтобы получить текущий статус, обновите страницу.
Порядок запуска кластера:
  1. Отметьте все узлы в списке.
  2. В верхнем меню выберите Join Cluster.
  3. Чтобы получить текущий статус, обновите страницу.
Чтобы перезапустить работающий кластер, надо остановить и перезапустить узлы в его составе (см. выше).
Ниже приведен порядок удаления кластера. При этом его службы будут остановлены, конфигурация кластера удалена со всех узлов, а узлы будут удалены из списка элементов кластера. Повторные попытки добавления этих узлов приведут к генерации сообщения о том, что узел не принадлежит какому-либо кластеру.

Важно

Удаление является необратимой операцией. Чтобы восстановить кластер, потребуется создать его заново.
  1. Отметьте все узлы в списке.
  2. В верхнем меню выберите 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.
  1. Выполните service luci stop.
  2. Выполните service luci backup-db.
    Дополнительно команде backup-db можно передать имя файла, в который будет сохранена копия базы данных. Пример: service luci backup-db /root/luci.db.backup. Стоит отметить, что резервные копии, которые размещены за пределами /var/lib/luci/data/, не будут показаны в выводе команды list-backups.
  3. Выполните service luci start.
Далее приведена последовательность восстановления базы данных luci.
  1. Выполните service luci stop.
  2. Выполните service luci list-backups, чтобы получить список резервных копий.
  3. Выполните service luci restore-db /var/lib/luci/data/файл, заменив файл именем файла, из которого будет восстановлена база данных.
    Так, следующая команда восстановит данные из файла luci-backup20110923062526.db:
    service luci restore-db /var/lib/luci/data/luci-backup20110923062526.db
    
  4. Выполните service luci start.
Если файл host.pem не найден на компьютере, где была создана резервная копия, для успешной авторизации на узлах кластера потребуется добавить его вручную в окне luci.
Далее рассматривается порядок восстановления базы данных luci на другом компьютере. Для этого помимо копии базы данных понадобится предоставить SSL-сертификат для аутентификации luci на узлах ricci. В приведенном примере резервная копия была изначально создана на компьютере luci1, после чего она будет восстановлена на компьютере luci2.
  1. Следующий набор команд создаст резервную копию 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:
  2. На компьютере luci2 должно быть установлено и запущено приложение luci.
  3. Выполните следующие команды для аутентификации и восстановления базы данных на 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 содержит информацию об управлении работающим кластером.
Содержание главы:

Примечание

До ввода 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. Создание файла конфигурации локально

Файл конфигурации кластера может быть создан удаленно на узле в кластере или в локальной файловой системе с последующей передачей в кластер. Команда 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.3. Запуск ricci

Запуск ricci на каждом узле в кластере является обязательным условием для создания и распределения файлов конфигурации. До запуска ricci необходимо подготовить систему:
  1. Открыть IP-порты для работы ricci (см. Раздел 2.3.1, «Доступ к портам IP на узлах кластера»).
  2. На всех узлах в кластере необходимо установить ricci и определить соотвествующий пароль доступа (см. Раздел 2.13, «ricci»).
После этого можно запустить ricci на каждом узле:
# service ricci start
Starting ricci:                                            [  OK  ]

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

Далее рассматривается порядок создания, изменения и удаления базовой конфигурации кластера с помощью ccs. Описание изоляции узлов и служб высокой готовности приведено в последующих секциях.
Сначала необходимо создать кластер, присвоить ему имя и добавить в его состав узлы. Ниже приведен порядок действий.
  1. Создать файл конфигурации кластера на одном из узлов при помощи 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, «Создание файла конфигурации локально»).
  2. Чтобы добавить узлы в файл конфигурации, следует выполнить:
    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. Настройка изоляции с отключением питания

Ниже приведен пример настройки исключающего устройства питания apc, которое будет использовать агент fence_apc.
  1. Сначала следует выбрать метод изоляции узла:
    ccs -h хост --addmethod метод узел
    Следующая команда настроит метод APC для узла node-01.example.com в файле конфигурации на node-01.example.com.
    ccs -h node01.example.com --addmethod APC node01.example.com
    
  2. Определить экземпляр устройства. В строке команды необходимо определить устройство изоляции, узел и название метода:
    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.com2, для node-03.example.com3.
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.15, «Синхронизация файла конфигурации»).

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

Если изоляция узлов осуществляется без отключения питания, необходимо настроить условия ее отмены, что предотвратит активацию изолированного узла до тех пор, пока он не будет перезагружен. Дополнительно следует определить зеркальное устройство для настроенного устройства изоляции в режиме on или enable.
Подробную информацию можно найти на справочной странице fence_node(8).
Ниже приведен пример настройки устройства sanswitch1, которое будет использовать агент fence_sanbox2.
  1. Сначала следует выбрать метод изоляции узла:
    ccs -h хост --addmethod метод узел
    Следующая команда настроит метод SAN для узла node-01.example.com в файле конфигурации на node-01.example.com.
    ccs -h node01.example.com --addmethod SAN  node01.example.com
    
  2. Определить экземпляр устройства. В строке команды необходимо определить устройство изоляции, узел и название метода:
    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
    
  3. Следующая команда определит порядок отмены изоляции узла:
    ccs -h хост --addunfence имя_устройства узел action=on|off
    
Для каждого узла в кластере необходимо определить метод изоляции. В приведенном ниже примере для всех узлов будет выбран метод SAN. Соответствующее устройство с именем sanswitch должно быть предварительно настроено при помощи --addfencedev (см. Раздел 5.5, «Настройка устройств изоляции»). Номера портов будут отличаться: для node-01.example.com будет выбран порт 11, для node-02.example.com12, для node-03.example.com13.
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.15, «Синхронизация файла конфигурации»).

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

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

Примечание

Порядок выбора метода изоляции зависит от порядка в файле конфигурации кластера. Первый метод является основным, второй — запасным. Порядок методов в файле может быть изменен.
Ниже приведена команда просмотра текущих методов и экземпляров для выбранного узла. Если узел не указан, будет получена информация для всех узлов.
ccs -h хост --lsfenceinst [узел]
Ниже рассматривается порядок настройки основного метода, использующего устройство apc с агентом fence_apc, и запасного метода, использующего устройство sanswitch1 с агентом fence_sanbox2. Для sanswitch1 также потребуется настроить отмену изоляции.
  1. Сначала следует выбрать основной метод изоляции.
    ccs -h хост --addmethod метод узел
    Следующая команда настроит метод APC для узла node-01.example.com в файле конфигурации на node-01.example.com.
    ccs -h node01.example.com --addmethod APC node01.example.com
    
  2. Определить экземпляр изоляции для основного метода. В строке команды необходимо определить устройство, узел и название метода изоляции:
    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
    
  3. После этого можно добавить запасной метод изоляции.
    ccs -h хост --addmethod метод узел
    Следующая команда настроит метод SAN для узла node-01.example.com в файле конфигурации на node-01.example.com.
    ccs -h node01.example.com --addmethod SAN  node01.example.com
    
  4. Определить экземпляр для резервного метода. В строке команды необходимо определить устройство, узел и название метода:
    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
    
  5. Для устройства 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.15, «Синхронизация файла конфигурации»).

Примечание

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

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

Если в кластере настроено несколько источников питания, процесс исключения узла должен быть организован таким образом, чтобы проблемный узел мог быть полностью отключен. Если для каждого источника питания определен отдельный алгоритм, узел не будет отключен, так как вместо одного источника начнет использоваться другой. В такой ситуации надо отключить оба источника. Чтобы этого достичь, в один алгоритм следует включить два экземпляра для каждого устройства, в одном из которых атрибут определен как action=off, а во втором — action=off.
Ниже рассматривается порядок изоляции узла с двумя источниками питания.
  1. Сначала надо определить оба источника питания как изолирующие устройства (см. Раздел 3.6, «Настройка устройств изоляции»).
    Команда вывода настроенных устройств:
    ccs -h хост --lsfencedev
    
  2. Сначала следует выбрать метод изоляции узла:
    ccs -h хост --addmethod метод узел
    Следующая команда определит метод APC-dual для узла node-01.example.com в файле конфигурации на node-01.example.com.
    ccs -h node01.example.com --addmethod APC-dual node01.example.com
    
  3. После этого следует добавить экземпляр для первого источника питания. В строке команды необходимо определить устройство изоляции, узел, название метода и присвоить 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
    
  4. После этого следует добавить экземпляр для второго источника питания. В строке команды необходимо определить устройство изоляции, узел, название метода и присвоить 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
    
  5. Теперь можно добавить другой экземпляр для первого источника питания, присвоив 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
    
  6. Теперь можно добавить другой экземпляр для второго источника питания, присвоив 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.15, «Синхронизация файла конфигурации»).

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) на всех узлах. Вместо этого надо будет настроить лишь узлы из резервного домена.

Примечание

Для настройки приоритетного узла можно создать неограниченный домен, включающий всего один узел. Это гарантирует, что служба будет выполняться именно на этом узле, а в случае сбоя будет перенесена на любой другой узел кластера.
Ниже рассматривается порядок настройки резервного домена.
  1. Добавление резервного домена:
    ccs -h хост --addfailoverdomain имя [restricted] [ordered] [nofailback]
    

    Примечание

    Рекомендуется указать информативное имя для облегчения идентификации домена.
    Так, следующая команда настроит резервный домен example_pri (неограниченный, упорядоченный, с возвратом) на node-01.example.com:
    ccs -h node-01.example.com --addfailoverdomain example_pri ordered
    
  2. Добавление узлов в резервный домен:
    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.15, «Синхронизация файла конфигурации»).

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.15, «Синхронизация файла конфигурации»).

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

Ниже рассматривается порядок настройки кластерной службы.
  1. Добавление службы:
    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, «Получение списка доступных служб» ).
  2. Добавление ресурсов для службы:
    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
    
  3. Параметр --addsubservice также позволяет определить подчиненные службы.
    Этот параметр может содержать целую иерархию служб. При этом службы в списке разделяются двоеточием, а службы одного типа идентифицируются номером в квадратных скобках следом за их именем. Так, ниже приведен пример добавления третьей подчиненной службы nfsclient для nfsclient, которая является подчиненной по отношению к service_a.
    ccs -h node01.example.com --addsubservice service_a nfsclient[1]:nfsclient[2]:nfsclient
    

    Примечание

    Ресурсы Samba не могут быть подчиненными — они должны добавляться напрямую.

Примечание

Чтобы проверить наличие ресурса 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
Удаление службы, включая подчиненные:
ccs -h хост --rmservice служба
Удаление подчиненной службы:
ccs -h хост --rmsubservice служба подчиненная [параметры]
После завершения настройки структуры кластера надо выполнить синхронизацию файла конфигурации на всех узлах (см. Раздел 5.15, «Синхронизация файла конфигурации»).

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 [правило параметры]
После завершения настройки структуры кластера надо выполнить синхронизацию файла конфигурации на всех узлах (см. Раздел 5.15, «Синхронизация файла конфигурации»).

Примечание

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

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

Содержание главы:
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, «Команды, переопределяющие предыдущие настройки»).
Чтобы изменения вступили в силу, потребуется перезагрузить кластер (см. Раздел 4.4, «Запуск, остановка, перезапуск и удаление кластера»).

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.15, «Синхронизация файла конфигурации»).

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

Начиная с Red Hat Enterprise Linux 6.4 комплект Red Hat High Availability поддерживает возможности настройки протокола избыточного кольца (см. Раздел 7.6, «Настройка протокола избыточного кольца»).
Чтобы определить второй сетевой интерфейс для избыточного кольца, надо определить дополнительное имя с помощью аргумента --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, «Синхронизация файла конфигурации»).

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.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. Существуют разные способы создания файла конфигурации кластера, но эта глава концентрируется на последовательном создании файла по секциям.
Содержание главы:

Важно

Прежде чем ввести 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.2. Создание базового файла конфигурации

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

Важно

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

    Примечание

    Копирование конфигурации работающего кластера рекомендуется выполнять с помощью cman_tool version -r. По желанию можно использовать scp, но при этом потребуется остановить кластерные программы на всех узлах и выполнить проверку ccs_config_validate.

    Примечание

    Базовый шаблон содержит и другие элементы, но они будут рассмотрены позднее.
  8. Запустите кластер на всех узлах:
    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  ]
    
  9. Выполните 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
    
  10. После успешного создания кластера можно приступить к настройке изоляции узлов (см. Раздел 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.
  1. Секция fencedevices содержит список исключающих устройств, каждое из которых определено в элементе fencedevice (см. Пример 7.3, «Добавление устройства APC в cluster.conf»).
  2. Метод изоляции определяется при помощи элемента fence для каждого clusternode в секции clusternodes. Атрибут name в строке method содержит название метода, а элемент device содержит характеристики устройства изоляции (см. Пример 7.4, «Добавление методов изоляции в cluster.conf»).
  3. Для методов, контролирующих доступ к хранилищу и 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.
  4. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  5. Сохраните /etc/cluster/cluster.conf.
  6. Дополнительно можно выполнить проверку соответствия формата схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере. При этом еще раз будет проверен формат файла. Предварительно убедитесь, что на всех узлах выполняется процесс ricci.
  8. Убедитесь, что конфигурация была скопирована.
  9. Раздел 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


<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 обозначает наивысший приоритет, то есть чем меньше число, тем больше вероятность выбора узла.
  • С возвратом — разрешает возврат службы на исходный узел после его восстановления. Настройка этой характеристики помогает при периодических сбоях узла, входящего в состав упорядоченного домена, так как если узел является предпочтительным, может оказаться так, что служба будет бесконечно переноситься с него на другой узел и обратно, что значительно снизит производительность.

    Примечание

    Функция возврата доступна только для упорядоченного типа.

Примечание

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

Примечание

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

Примечание

Для настройки приоритетного узла можно создать неограниченный домен, включающий всего один узел. Это гарантирует, что служба будет выполняться именно на этом узле, а в случае сбоя будет перенесена на любой другой узел кластера.
Ниже рассматривается порядок настройки резервного домена.
  1. Откройте /etc/cluster/cluster.conf на любом узле.
  2. Для каждого домена в секцию rm следует добавить следующий шаблон:
    
            <failoverdomains>
                <failoverdomain name="" nofailback="" ordered="" restricted="">
                    <failoverdomainnode name="" priority=""/>
                    <failoverdomainnode name="" priority=""/>
                    <failoverdomainnode name="" priority=""/>
                </failoverdomain>
            </failoverdomains>
    
    

    Примечание

    Число элементов failoverdomainnode зависит от числа узлов в составе домена. В приведенном примере показано три элемента failoverdomainnode с незаполненными значениями имен.
  3. Описание элементов секции 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.
  4. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  5. Сохраните /etc/cluster/cluster.conf.
  6. Дополнительно можно проверить соответствие формата схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
  8. Раздел 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.

Важно

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

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

В целом, можно настроить два типа ресурсов:
  • глобальные ресурсы — доступны в пределах кластера и настраиваются в секции resources элемента rm;
  • служебные ресурсы — доступны определенной службе и настраиваются в секции service элемента rm.
В этой секции рассказывается о добавлении глобальных ресурсов. Раздел 7.5.2, «Добавление кластерных служб» содержит информацию для служебных ресурсов.
Ниже приведен порядок добавления глобального ресурса.
  1. Откройте /etc/cluster/cluster.conf на любом узле.
  2. В элемент rm надо добавить секцию resources:
    
        <rm>
            <resources>
    
            </resources>
        </rm>
    
    
  3. Например, 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.
  4. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  5. Сохраните /etc/cluster/cluster.conf.
  6. Дополнительно можно проверить соответствие формата схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
  8. Убедитесь, что конфигурация была скопирована.
  9. Раздел 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. Добавление кластерных служб

Ниже рассматривается порядок добавления кластерной службы.
  1. Откройте /etc/cluster/cluster.conf на любом узле.
  2. В элемент rm надо добавить секцию service:
    
        <rm>
            <service autostart="1" domain="" exclusive="0" name="" recovery="restart">
    
            </service>
        </rm>
    
    
  3. Далее следует настроить параметры service:
    • autostart — 1 разрешает автоматический запуск службы при запуске кластера, а 0 отключает эту возможность. По умолчанию равен 1.
    • domain — резервный домен (дополнительно).
    • exclusive — запрещает запуск службы, если на узле уже работают другие службы.
    • recovery — определяет правила восстановления службы. Возможные значения: relocate, restart, disable, restart-disable.
  4. Теперь можно добавить глобальные или специализированные ресурсы.
    Пример добавления 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.
  5. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  6. Сохраните /etc/cluster/cluster.conf.
  7. Дополнительно можно выполнить проверку соответствия формата схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  8. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
  9. Убедитесь, что конфигурация была скопирована.
  10. Раздел 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>

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

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

Приведенные ниже действия помогут убедиться в работоспособности созданной конфигурации.
  1. Сначала следует перезапустить кластерные программы, чтобы применить изменения конфигурации:
    [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  ]
    
  2. При наличии кластерных томов, созданных с помощью CLVM, выполните:
    [root@example-01 ~]# service clvmd start
    Activating VGs:                                            [  OK  ]
    
  3. Для запуска Red Hat GFS2 выполните:
    [root@example-01 ~]# service gfs2 start
    Mounting GFS2 filesystem (/mnt/gfsA):                      [  OK  ]
    Mounting GFS2 filesystem (/mnt/gfsB):                      [  OK  ]
    
  4. При наличии служб высокой готовности выполните:
    [root@example-01 ~]# service rgmanager start
    Starting Cluster Service Manager:                          [  OK  ]
    
  5. Выполните 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
    
  6. Выполните 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
    
  7. На этом конфигурация кластера завершена. Глава 8, Управление кластером в командной строке содержит информацию о типичных операциях управления кластером из командной строки.

Глава 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.

Примечание

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

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

Раздел 8.1.1, «Запуск кластерных программ» и Раздел 8.1.2, «Остановка кластерных программ» рассматривают порядок запуска и остановки кластерных программ на узле. При запуске кластерных служб узел будет добавлен в состав кластера, а при остановке — исключен.

8.1.1. Запуск кластерных программ

Для запуска кластерного программного обеспечения на узле необходимо выполнить следующее:
  1. service cman start
  2. service clvmd start, если для создания кластерных томов использовался CLVM
  3. service gfs2 start, если используется Red Hat GFS2
  4. 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. Остановка кластерных программ

Для остановки кластерного программного обеспечения на узле необходимо выполнить следующее:
  1. service rgmanager stop, если используются службы высокой готовности (rgmanager)
  2. service gfs2 stop, если используется Red Hat GFS2
  3. umount -at gfs2, если Red Hat GFS2 используется в комбинации с rgmanager с целью монтирования файлов GFS2 во время запуска rgmanager
  4. service clvmd stop, если для создания кластерных томов использовался CLVM
  5. 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. Удаление узла из кластера

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

Важно

Если после удаления число узлов в кластере уменьшится до двух, потребуется перезапустить кластерные программы на обоих узлах.
Порядок удаления узла из кластера:
  1. Сначала перенесите или удалите кластерные службы на удаляемом узле. Это можно сделать с помощью утилиты clusvcadm, которая может быть запущена на любом узле (см. Раздел 8.3, «Управление службами высокой готовности»).
  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 ~]#
    
  3. Откройте файл /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, «Примеры конфигураций с двумя и тремя узлами» выполняет сравнение структур с двумя и тремя узлами.
  4. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  5. Сохраните /etc/cluster/cluster.conf.
  6. Дополнительно можно выполнить проверку соответствия формата файла схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
  8. Убедитесь, что конфигурация была скопирована.
  9. Если число узлов в кластере уменьшилось до двух, потребуется перезапустить кластерные программы:
    1. Остановите кластерные программы на всех узлах (см. Раздел 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 ~]#
      
    2. Запустите кластерные программы на всех узлах (см. Раздел 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 ~]#
      
    3. На любом узле выполните 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
      
    4. На любом узле выполните 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. Добавление узла в кластер

При добавлении узла в кластер потребуется обновить конфигурацию кластера, скопировать ее на добавляемый узел и запустить кластерные программы. Порядок действий приведен ниже.
  1. Откройте файл /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, «Примеры конфигураций с двумя и тремя узлами» выполняет сравнение структур с двумя и тремя узлами.
  2. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  3. Сохраните /etc/cluster/cluster.conf.
  4. Дополнительно можно выполнить проверку соответствия формата файла схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  5. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере.
  6. Убедитесь, что конфигурация была скопирована.
  7. Скопируйте изменения в каталог /etc/cluster/ на всех добавляемых узлах. Это можно сделать с помощью scp:
  8. Если число узлов в кластере выросло с двух до трех и более, потребуется перезапустить кластерные программы:
    1. Остановите кластерные программы на всех узлах (см. Раздел 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 ~]#
      
    2. Запустите кластерные программы на всех узлах (см. Раздел 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 ~]#
      
  9. Запустите кластерные программы на добавляемых узлах:
    [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 ~]#
    
  10. Выполните 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
    
    Дополнительно можно выполнить 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
    
  11. С помощью утилиты 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

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

Ниже приведен порядок обновления конфигурации с помощью cman_tool version -r.
  1. На любом узле откройте файл /etc/cluster/cluster.conf и внесите изменения.
  2. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  3. Сохраните /etc/cluster/cluster.conf.
  4. Выполните cman_tool version -r, чтобы скопировать изменения на остальные узлы в кластере. Предварительно убедитесь, что на всех узлах выполняется процесс ricci.
  5. Убедитесь, что конфигурация была скопирована.
  6. Перезагрузите кластерные программы. Этот шаг может быть пропущен, если изменения конфигурации ограничиваются следующими операциями:
    • Удаление узла из кластера за исключением случаев, когда общее число узлов уменьшилось до двух (см. Раздел 8.2, «Добавление и удаление узлов»).
    • Добавление узла в кластер за исключением случаев, когда число узлов стало больше двух (см. Раздел 8.2.2, «Добавление узла в кластер»).
    • Изменение параметров журналирования.
    • Операции управления службами высокой готовности и виртуальными машинами (добавление, изменение, удаление).
    • Операции управления ресурсами (добавление, изменение, удаление).
    • Операции домена восстановления (добавление, изменение, удаление).
    В противном случае необходимо перезапустить кластерные программы.
    1. Остановите кластерные программы на всех узлах (см. Раздел 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 ~]#
      
    2. Запустите кластерные программы на всех узлах (см. Раздел 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 ~]#
      
      Остановка и запуск кластерных программ позволяют применить изменения конфигурации, не дожидаясь перезапуска.
  7. На любом узле выполните 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
    
  8. На любом узле выполните 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. Если функциональность кластера не нарушилась, значит обновление конфигурации завершено успешно.

8.4.2. Обновление конфигурации с помощью scp

Ниже приведен порядок обновления конфигурации с помощью команды scp.
  1. Остановите кластерные программы на всех узлах (см. Раздел 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 ~]#
    
  2. На любом узле откройте файл /etc/cluster/cluster.conf и внесите изменения.
  3. Увеличьте значение config_version на единицу. Например, если исходное выражение выглядело как config_version="2", после изменения оно будет выглядеть так: config_version="3".
  4. Сохраните /etc/cluster/cluster.conf.
  5. Проверьте соответствие формата файла схеме в cluster.rng:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  6. Если проверка прошла успешно, скопируйте файл в каталог /etc/cluster/ на всех узлах.
  7. Убедитесь, что конфигурация была скопирована.
  8. Запустите кластерные программы на всех узлах (см. Раздел 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 ~]#
    
  9. На любом узле выполните 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
    
  10. На любом узле выполните 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
    
  11. Если функциональность кластера не нарушилась, значит обновление конфигурации завершено успешно.

Глава 9. Диагностика и решение конфликтов в кластере

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

9.1. Изменения конфигурации не вступают в силу

При изменении конфигурации кластера необходимо передать изменения всем узлам.
Ниже приведен список изменений, не требующих перезапуска кластера после передачи изменений его узлам.
  • Удаление узла из кластера за исключением случаев, когда общее число узлов уменьшилось до двух.
  • Добавление узла в кластер за исключением случаев, когда число узлов стало больше двух.
  • Изменение параметров журналирования.
  • Добавление, изменение и удаление служб высокой готовности и компонентов виртуальных машин.
  • Добавление, изменение и удаление кластерных ресурсов.
  • Добавление, изменение и удаление запасных доменов.
Остальные операции требуют перезагрузки кластера. Примеры:
  • Добавление и удаление параметра two_node из файла конфигурации.
  • Переименование кластера.
  • Изменение таймеров corosync и openais.
  • Добавление, изменение и удаление эвристических методов определения кворума диска, изменение таймеров кворума, изменение кворумного диска. Для применения изменений потребуется перезапустить qdiskd.
  • Изменение режима central_processing для rgmanager. Для применения изменений потребуется перезапустить rgmanager.
  • Изменение адреса многоадресной рассылки.
  • Изменение режима передачи с многоадресной рассылки UDP на одноадресную и наоборот.
Кластер можно перезапустить с помощью Conga, ccs и инструментов командной строки.

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
    
  • Убедитесь, что на узле настроены службы кластера (с помощью 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 служба 
    Дополнительно можно увеличить уровень журналирования, что поможет идентифицировать причину проблемы. Для этого в файле 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 в кластере.
  1. Сначала необходимо необходимо настроить службу snmpd, которая будет выступать в качестве мастер-агента для foghorn, и включить поддержку AgentX. Для этого в файл /etc/snmp/snmpd.conf следует добавить:
    master agentx
    
  2. Следующая строка определяет узел, которому будут отправляться уведомления ловушек SNMP:
    trap2sink узел
    Подробную информацию можно найти на справочной странице snmpd.conf.
  3. После этого следует включить и запустить snmpd:
    # chkconfig snmpd on
    # service snmpd start
  4. Запустить messagebus:
    # chkconfig messagebus on
    # service messagebus start
  5. Запустить foghorn:
    # chkconfig foghorn on
    # service foghorn start
  6. Разрешить 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.
  1. В /etc/snmp/snmpd.conf в строке trap2sink узел определите узел для перенаправления уведомлений (см. Раздел 10.2, «Настройка SNMP в кластере»).
  2. В файле /etc/snmp/snmptrapd.conf на внешнем компьютере необходимо определить строку сообщества.
    authCommunity log,execute,net public
    
  3. После этого следует включить и запустить 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.

Примечание

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

Примечание

Фрагменты файла /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, «Запуск и остановка ресурсов одного типа») запуск ресурсов производится в следующем порядке:
  1. lvm:1 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:1 (<lvm name="1" .../>) запускается первым среди прочих ресурсов LVM, так как он является первым в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
  2. lvm:2 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:2 (<lvm name="2" .../>) запускается после lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
  3. fs:1 — ресурс файловой системы. Если бы в состав foo входили другие ресурсы этого типа, их запуск происходил бы в порядке следования в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
  4. ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.
  5. script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.

C.2.1.2. Порядок остановки ресурсов согласно типу

В приведенном выше примере (см. Пример C.3, «Запуск и остановка ресурсов одного типа») остановка ресурсов производится в следующем порядке:
  1. script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их остановка происходила бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
  2. ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
  3. fs:1 — ресурс файловой системы. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
  4. lvm:2 — ресурс LVM. Ресурсы LVM останавливаются последними. lvm:2 (<lvm name="2" .../>) останавливается до lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
  5. 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, «Нетиповые и типовые дочерние ресурсы») запуск ресурсов производится в следующем порядке:
  1. lvm:1 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:1 (<lvm name="1" .../>) запускается первым среди прочих ресурсов LVM, так как он является первым в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
  2. lvm:2 — ресурс LVM. Ресурсы LVM запускаются в первую очередь. lvm:2 (<lvm name="2" .../>) запускается после lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
  3. fs:1 — ресурс файловой системы. Если бы в состав foo входили другие ресурсы этого типа, их запуск происходил бы в порядке следования в списке ресурсов службы foo в файле /etc/cluster/cluster.conf.
  4. ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.
  5. script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке следования в файле /etc/cluster/cluster.conf.
  6. nontypedresource:foo — ресурс без типа. Запуск таких ресурсов происходит после завершения запуска типовых ресурсов. Поскольку строка описания этого ресурса расположена выше строки второго нетипового ресурса (nontypedresourcetwo:bar), этот ресурс запускается перед nontypedresourcetwo:bar. Ресурсы запускаются в порядке следования.
  7. nontypedresourcetwo:bar — ресурс без типа. Запуск таких ресурсов происходит после завершения запуска типовых ресурсов. Поскольку строка описания этого ресурса расположена ниже строки nontypedresource:foo, этот ресурс запускается после nontypedresource:foo.

C.2.2.2. Порядок остановки нетиповых ресурсов

В приведенном выше примере (см. Пример C.4, «Нетиповые и типовые дочерние ресурсы») остановка ресурсов производится в следующем порядке:
  1. nontypedresourcetwo:bar — ресурс без типа. Остановка таких ресурсов происходит до остановки типовых ресурсов. Поскольку строка описания этого ресурса расположена ниже строки nontypedresource:foo, он будет остановлен до nontypedresource:foo. Ресурсы без типа останавливаются в порядке, обратном тому, в котором они перечислены в файле.
  2. nontypedresource:foo — ресурс без типа. Остановка таких ресурсов происходит до остановки типовых ресурсов. Поскольку строка описания этого ресурса расположена выше строки nontypedresourcetwo:bar, он будет остановлен после nontypedresourcetwo:bar. Ресурсы без типа останавливаются в порядке, обратном тому, в котором они перечислены в файле.
  3. script:1 — ресурс типа «script». Если бы для foo было определено несколько ресурсов этого типа, их остановка происходила бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
  4. ip:10.1.1.1 — IP-адрес. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
  5. fs:1 — ресурс файловой системы. Если бы для foo было определено несколько ресурсов этого типа, их запуск происходил бы в порядке, обратном тому, в котором ресурсы этого типа были бы перечислены в файле /etc/cluster/cluster.conf.
  6. lvm:2 — ресурс LVM. Ресурсы LVM останавливаются последними. lvm:2 (<lvm name="2" .../>) останавливается до lvm:1 , так как в списке ресурсов службы foo он следует за lvm:1.
  7. 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.
  1. Убедитесь, что система поддерживает CLVM, то есть должны удовлетворяться следующие условия:
    • Установлены комплекты High Availability и Resilient Storage, а также пакет cmirror (для зеркальной организации логических томов CLVM)/
    • В файле /etc/lvm/lvm.conf значение параметра locking_type должно быть равно 3.
    • Должны быть запущены программы High Availability и Resilient Storage, включая clvmd и дополнительно cmirrord (для зеркальной организации).
  2. Создайте логический том и файловую систему:
    # 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.
  3. В /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.
  1. Параметр locking_type в /etc/lvm/lvm.conf должен быть равен единице:
  2. Создайте логический том и файловую систему:
    # 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.
  3. В /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 группа томов может использоваться только одной службой.
  4. В поле volume_list определите имя корневой группы томов и имя узла, в качестве которого надо указать имя локальной системы, где происходит редактирование файла lvm.conf. Эта строка должна соответствовать имени узла в /etc/cluster/cluster.conf. Перед именем узла надо добавить @. Пример:
    volume_list = [ "VolGroup00", "@neo-01" ]
    
    Этот тег сможет использоваться для активации общих логических томов и их групп. Строка не должна содержать имена групп, к которым не был открыт совместный доступ HA-LVM.
  5. Обновите initrd на всех узлах кластера:
    # dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
  6. Перезагрузите все узлы для активации этого устройства initrd.

Приложение G. История переиздания

История переиздания
Издание 5.0-25.2.31.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Издание 5.0-25.2.31Thu Oct 3 2013Zac Dover
BZ#1007864 - s/Red Had/Red Hat/g
Издание 5.0-25.2Wed May 1 2013Yuliya Poyarkova
Перевод на русский язык.
Издание 5.0-25.1Thu Apr 18 2013Chester Cheng
Синхронизация с кодом XML 5.0-25
Издание 5.0-25Mon Feb 18 2013Steven Levine
Версия для Red Hat Enterprise Linux 6.4
Издание 5.0-23Wed Jan 30 2013Steven Levine
BZ#901641
Исправления правил iptables
Издание 5.0-22Tue Jan 29 2013Steven Levine
BZ#788636
Описание конфигурации RRP при помощи ccs.
BZ#789010
Описание конфигурации RRP в файле cluster.conf.
Издание 5.0-20Fri Jan 18 2013Steven Levine
BZ#894097
Удаление предупреждения о тегах VLAN.
BZ#845365
Добавлена информация о поддержке режимов агрегации 0 и 2.
Издание 5.0-19Thu Jan 17 2013Steven Levine
BZ#896234
Уточнения терминологии узлов кластера.
Издание 5.0-16Mon Nov 26 2012Steven Levine
Версия для выпуска Beta.
Издание 5.0-15Wed Nov 20 2012Steven 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-12Thu Nov 1 2012Steven Levine
Добавлена информация о новых агентах изоляции.
Издание 5.0-7Thu Oct 25 2012Steven Levine
Добавлена секция о переопределении семантики.
Издание 5.0-6Tue Oct 23 2012Steven Levine
Исправлено стандартное значение задержки.
Издание 5.0-4Tue Oct 16 2012Steven Levine
Добавлено описание ресурса NFS-сервера.
Издание 5.0-2Thu Oct 11 2012Steven Levine
Обновлена информация о Conga.
Издание 5.0-1Mon Oct 8 2012Steven Levine
Уточнения семантики ccs.
Издание 4.0-5Fri Jun 15 2012Steven Levine
Версия для Red Hat Enterprise Linux 6.3.
Издание 4.0-4Tue Jun 12 2012Steven Levine
BZ#830148
Откорректированы номера портов в примерах luci.
Издание 4.0-3Tue May 21 2012Steven Levine
BZ#696897
Добавлено описание параметров cluster.conf.
BZ#811643
Описание восстановления базы данных luci на отдельном компьютере.
Издание 4.0-2Wed Apr 25 2012Steven Levine
BZ#815619
Удалено предупреждение об одноадресной рассылке UDP в GFS2.
Издание 4.0-1Fri Mar 30 2012Steven 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-5Thu Dec 1 2011Steven Levine
Редакция для Red Hat Enterprise Linux 6.2.
BZ# 755849
Откорректирован пример monitor_link.
Издание 3.0-4Mon Nov 7 2011Steven Levine
BZ# 749857
Добавлена информация о REST API RHEV-M.
Издание 3.0-3Fri Oct 21 2011Steven 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-2Fri Oct 7 2011Steven Levine
BZ#743757
Исправления в секции о поддержке режима агрегации.
Издание 3.0-1Wed Sep 28 2011Steven 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-1Thu May 19 2011Steven Levine
Исходная версия для Red Hat Enterprise Linux 6.1
BZ#671250
Информация о поддержке ловушек SNMP.
BZ#659753
Описание команды ccs.
BZ#665055
Обновлена информация о Conga.
BZ#680294
Добавлена информация о пароле для агента ricci.
BZ#687871
Добавлена глава о дигностике.
BZ#673217
Исправления опечаток.
BZ#675805
Добавлено описание параметров схемы cluster.conf.
BZ#672697
Обновлены таблицы параметров ограждающих устройств.
BZ#677994
Откорректировано описание параметров fence_ilo.
BZ#629471
Добавлено примечание о значении таймаута в кластере с двумя узлами.
BZ#579585
Коррекции в секции об обновлении программ комплекта Red Hat High Availability.
BZ#643216
Различные исправления в рамках документа.
BZ#643191
Откорректирована секция luci.
BZ#704539
Обновлена таблица параметров ресурсов виртуальных машин.
Издание 1.0-1Wed Nov 10 2010Paul Kennedy
Исходная версия для Red Hat Enterprise Linux 6

Предметный указатель

Символы

Изоляция SCSI, Параметры устройств изоляции
Управление питанием APC через SNMP, Параметры устройств изоляции
Управление питанием APC через telnet/SSH, Параметры устройств изоляции
Устройство изоляции CISCO MDS , Параметры устройств изоляции
Устройство изоляции Cisco UCS, Параметры устройств изоляции
Устройство изоляции Dell DRAC 5, Параметры устройств изоляции
Устройство изоляции ePowerSwitch, Параметры устройств изоляции
Устройство изоляции Fujitsu Siemens Remoteview Service Board (RSB), Параметры устройств изоляции
Устройство изоляции IBM BladeCenter, Параметры устройств изоляции
Устройство изоляции IBM BladeCenter SNMP, Параметры устройств изоляции
Устройство изоляции IF MIB, Параметры устройств изоляции
Устройство изоляции IPMI LAN, Параметры устройств изоляции
Устройство изоляции виртуальной машины , Параметры устройств изоляции
агент fence_apc, Параметры устройств изоляции
агент fence_apc_snmp, Параметры устройств изоляции
агент fence_bladecenter, Параметры устройств изоляции
агент fence_brocade, Параметры устройств изоляции
агент fence_cisco_mds, Параметры устройств изоляции
агент fence_cisco_ucs, Параметры устройств изоляции
агент fence_drac5, Параметры устройств изоляции
агент fence_egenera, Параметры устройств изоляции
агент fence_eps, Параметры устройств изоляции
агент fence_hpblade, Параметры устройств изоляции
агент fence_ibmblade, Параметры устройств изоляции
агент fence_ifmib, Параметры устройств изоляции
агент fence_ilo, Параметры устройств изоляции
агент fence_ilo_mp, Параметры устройств изоляции
агент fence_intelmodular, Параметры устройств изоляции
агент fence_ipdu, Параметры устройств изоляции
агент fence_ipmilan, Параметры устройств изоляции
агент fence_rhevm, Параметры устройств изоляции
агент fence_rsb, Параметры устройств изоляции
агент fence_scsi, Параметры устройств изоляции
агент fence_virt, Параметры устройств изоляции
агент fence_vmware_soap, Параметры устройств изоляции
агент fence_wti, Параметры устройств изоляции
агент изоляции
Brocade FC, Параметры устройств изоляции
fence_apc, Параметры устройств изоляции
fence_apc_snmp, Параметры устройств изоляции
fence_bladecenter, Параметры устройств изоляции
fence_brocade, Параметры устройств изоляции
fence_cisco_mds, Параметры устройств изоляции
fence_cisco_ucs, Параметры устройств изоляции
fence_drac5, Параметры устройств изоляции
fence_eaton_snmp, Параметры устройств изоляции
fence_egenera, Параметры устройств изоляции
fence_eps, Параметры устройств изоляции
fence_hpblade, Параметры устройств изоляции
fence_ibmblade, Параметры устройств изоляции
fence_ifmib, Параметры устройств изоляции
fence_ilo, Параметры устройств изоляции
fence_ilo_mp, Параметры устройств изоляции
fence_intelmodular, Параметры устройств изоляции
fence_ipdu, Параметры устройств изоляции
fence_ipmilan, Параметры устройств изоляции
fence_rhevm, Параметры устройств изоляции
fence_rsb, Параметры устройств изоляции
fence_scsi, Параметры устройств изоляции
fence_virt, Параметры устройств изоляции
fence_vmware_soap, Параметры устройств изоляции
fence_wti, Параметры устройств изоляции
IBM BladeCenter, Параметры устройств изоляции
IBM BladeCenter SNMP, Параметры устройств изоляции
управление питанием APC через SNMP, Параметры устройств изоляции
управление питанием APC через telnet/SSH, Параметры устройств изоляции
агент изоляции fence_eaton_snmp, Параметры устройств изоляции
администрирование
общие принципы, Общие требования
администрирование кластера, Подготовка системы, Управление кластером с помощью Conga, Управление кластером с помощью ccs, Управление кластером в командной строке
NetworkManager, NetworkManager
SELinux, SELinux
активация портов IP, Доступ к портам IP
виртуальные машины, Виртуальные машины в кластере
выход из кластера, Добавление и удаление узлов, Добавление и удаление узлов
диагностика и решение проблем в кластере, Диагностика конфликтов в кластере, Диагностика и решение конфликтов в кластере
диск кворума, Диск кворума
добавление узла в кластер, Добавление узла в работающий кластер, Добавление узла в работающий кластер
запуск кластера, Запуск, остановка, перезапуск и удаление кластера, Запуск и остановка кластера
запуск, остановка и перезапуск кластера, Запуск и остановка кластера
исключение узла из конфигурации; добавление узла в конфигурацию, Добавление и удаление узлов
использование qdisk, Диск кворума
настройка ACPI, ACPI и интегрированные устройства изоляции
настройка iptables, Доступ к портам IP
обновление конфигурации, Обновление конфигурации
обновление конфигурации с помощью cman_tool version -r, Обновление конфигурации с помощью cman_tool version -r
обновление конфигурации с помощью scp, Обновление конфигурации с помощью scp
особенности ricci, ricci
остановка кластера, Запуск, остановка, перезапуск и удаление кластера, Запуск и остановка кластера
перезагрузка узла, Перезагрузка узла
перезапуск кластера, Запуск, остановка, перезапуск и удаление кластера
присоединение к кластеру, Добавление и удаление узлов, Добавление и удаление узлов
проверка настроек, Валидация cluster.conf
сетевые коммутаторы и многоадресная рассылка, Многоадресная рассылка
совместимое оборудование, Совместимость оборудования
статус служб, Просмотр статуса кластерных служб с помощью clustat
удаление кластера, Запуск, остановка, перезапуск и удаление кластера
удаление узла из кластера, Удаление узла из кластера
управление службами, Управление службами высокой готовности, Управление службами высокой готовности
управление службами, фиксация и возобновление работы, Управление кластерными службами с помощью clusvcadm, Особенности операции фиксирования
управление узлами кластера, Управление узлами кластера, Управление узлами кластера
введение, Введение
другие руководства, Введение
виртуальные машины в кластере, Виртуальные машины в кластере
возможности, новые и измененные, Основные изменения
время ожидания, Проверка ресурсов кластерных служб и ожидание восстановления
время ожидания восстановления, Проверка ресурсов кластерных служб и ожидание восстановления
диагностика
диагностика и решение проблем в кластере, Диагностика конфликтов в кластере, Диагностика и решение конфликтов в кластере
диск кворума
особенности, Диск кворума
значение consensus, Значение consensus элемента totem в кластере с двумя узлами
инструменты, командная строка, Обзор команд
интегрированные устройства изоляции
настройка ACPI, ACPI и интегрированные устройства изоляции
кластер
администрирование, Подготовка системы, Управление кластером с помощью Conga, Управление кластером с помощью ccs, Управление кластером в командной строке
диагностика и решение проблем в кластере, Диагностика конфликтов в кластере, Диагностика и решение конфликтов в кластере
запуск, остановка, перезапуск, Запуск и остановка кластера
кластерные службы, Добавление службы в кластер, Добавление кластерной службы, Добавление кластерных служб
(см. также добавление в кластер)
коммутатор WTI, Параметры устройств изоляции
конфигурация кластера
обновление, Обновление конфигурации
удаление и добавление узла, Добавление и удаление узлов
межсетевой экран iptables, Настройка правил iptables
менеджеры кластерных служб
конфигурация, Добавление службы в кластер, Добавление кластерной службы, Добавление кластерных служб
многоадресная рассылка
особенности многоадресной передачи, Многоадресная рассылка
многоадресная рассылка, активация, Настройка правил iptables
настройка
службы высокой готовности, Особенности настройки служб высокой готовности
настройка LVM высокой готовности, HA-LVM
настройка кластера, Настройка кластера в Conga, Настройка кластера с помощью ccs , Настройка кластера в командной строке
настройка служб высокой готовности
обзор, Особенности настройки служб высокой готовности
обзор
возможности, новые и обновленные, Основные изменения
оборудование
совместимое, Совместимость оборудования
общие
требования для кластера, Общие требования
отзывы, Отзывы и предложения
отношения
кластерные ресурсы, Отношения между ресурсами — родительские, дочерние, параллельные.
отношения между ресурсами, Отношения между ресурсами — родительские, дочерние, параллельные.
параметры, ресурсы высокой готовности, Параметры ресурсов
параметры, устройство изоляции, Параметры устройств изоляции
поведение, ресурсы высокой готовности, Поведение ресурсов высокой готовности
порты IP
активация, Доступ к портам IP
проверка
конфигурация кластера, Валидация cluster.conf
проверка состояния кластерных ресурсов, Проверка ресурсов кластерных служб и ожидание восстановления
проверка состояния, кластерные ресурсы, Проверка ресурсов кластерных служб и ожидание восстановления
программы кластера
настройка, Настройка кластера в Conga, Настройка кластера с помощью ccs , Настройка кластера в командной строке
сетевой источник питания Eaton, Параметры устройств изоляции
таблицы
ресурсы, параметры, Параметры ресурсов
устройства изоляции, параметры, Параметры устройств изоляции
типы
ресурс кластера, Особенности настройки служб высокой готовности
типы ресурсов кластера, Особенности настройки служб высокой готовности
устройство изоляции
Cisco MDS, Параметры устройств изоляции
Cisco UCS, Параметры устройств изоляции
Dell DRAC 5, Параметры устройств изоляции
ePowerSwitch, Параметры устройств изоляции
Fujitsu Siemens Remoteview Service Board (RSB), Параметры устройств изоляции
HP BladeSystem, Параметры устройств изоляции
HP iLO MP, Параметры устройств изоляции
HP iLO/iLO2, Параметры устройств изоляции
IF MIB, Параметры устройств изоляции
Intel Modular, Параметры устройств изоляции
IPMI LAN, Параметры устройств изоляции
RHEV-M REST API, Параметры устройств изоляции
SAN-контроллер Egenera, Параметры устройств изоляции
VMware (интерфейс SOAP), Параметры устройств изоляции
изоляция SCSI, Параметры устройств изоляции
источник питания Eaton, Параметры устройств изоляции
переключатель WTI, Параметры устройств изоляции
устройство изоляции Brocade , Параметры устройств изоляции
устройство изоляции HP Bladesystem, Параметры устройств изоляции
устройство изоляции IBM iPDU, Параметры устройств изоляции

L

LVM, высокая готовность, HA-LVM

N

NetworkManager
отключение, NetworkManager

Q

qdisk
особенности, Диск кворума

R

RHEV-M REST API, Параметры устройств изоляции
ricci
особенности администрирования кластера, ricci

S

SAN-контроллер Egenera, Параметры устройств изоляции
SELinux
настройка, SELinux

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

Copyright © 2013 Red Hat, Inc. and others.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.