Red Hat Training

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

Обзор Cluster Suite

Red Hat Enterprise Linux 5

Red Hat Cluster Suite для Red Hat Enterprise Linux 5

Редакция 3

Logo

Аннотация

Обзор Red Hat Cluster Suite включает информацию для Red Hat Enterprise Linux 5.

Введение

Данный документ содержит общий обзор Red Hat Cluster Suite для Red Hat Enterprise Linux 5 и организован следующим образом:
Поскольку приведенная здесь информация является лишь обзорной, она предназначена для специалистов Red Hat Enterprise Linux, уже знакомыми с концепциями работы сервера.
За информацией о Red Hat Enterprise Linux обратитесь к следующим ресурсам:
  • Руководство по установке Red Hat Enterprise Linux предоставляет информацию о процессе установки Red Hat Enterprise Linux 5.
  • Руководство по развертыванию Red Hat Enterprise Linux предоставляет информацию по развертыванию, конфигурации и администрированию Red Hat Enterprise Linux 5.
За информацией о Red Hat Cluster Suite для Red Hat Enterprise Linux 5 обратитесь к следующим ресурсам:
  • Конфигурация и администрирование Red Hat Cluster предоставляет информацию об установке, конфигурации и управлению компонентами Red Hat Cluster.
  • LVM Administrator's Guide: Configuration and Administration — Provides a description of the Logical Volume Manager (LVM), including information on running LVM in a clustered environment.
  • Глобальная файловая система: Конфигурация и администрирование предоставляет информацию по установке, настройке и обеспечении поддержки GFS Red Hat.
  • Глобальная файловая система 2: Конфигурация и администрирование предоставляет информацию по установке, конфигурации и обеспечении поддержки GFS2 Red Hat.
  • Использование Device-Mapper Multipath содержит описание возможности Device-Mapper Multipath в Red Hat Enterprise Linux 5.
  • Использование GNBD с GFS содержит обзорную информацию о работе GNBD (Global Network Block Device) с GFS Red Hat.
  • Администрирование виртуального сервера Linux содержит информацию о конфигурации высокопроизводительных систем и служб с помощью виртуального сервера Linux (LVS, Linux Virtual Server).
  • Замечания к выпуску Red Hat Cluster Suite содержат краткие сведения о выпуске.
Документацию Red Hat Cluster Suite и другие документы Red Hat можно найти на диске документации Red Hat Enterprise Linux в форматах HTML, PDF и RPM или на сайте http://www.redhat.com/docs/.

1. Обратная связь

Если вы обнаружите ошибку или у вас есть предложения по усовершенствованию этого документа, мы бы хотели услышать об этом. Отправьте сообщение в систему регистрации ошибок Bugzilla (http://bugzilla.redhat.com/bugzilla/), указав компонент Documentation-cluster.
Be sure to mention the document's identifier: 
Cluster_Suite_Overview(EN)-5 (2008-12-11T15:49)
By mentioning this document's identifier, we know exactly which version of the guide you have.
Если у вас есть предложения по улучшению документации, попытайтесь описать их как можно более детально. Если вы нашли ошибку, пожалуйста, укажите номер раздела и часть окружающего текста, чтобы облегчить ее поиск.

Глава 1. Обзор Red Hat Cluster Suite

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

1.1. Основы кластера

Кластер включает один или несколько компьютеров (называемые узлами или участниками), которые функционируют вместе с целью выполнения одной задачи. Существует четыре основных типа кластеров:
  • Хранилище
  • Высокая доступность
  • Распределение нагрузки
  • Высокая производительность
Кластеры хранилищ обеспечивают доступ к образу файловой системы (ФС) для серверов, входящих в состав кластера, тем самым разрешая одновременную запись и чтение разделяемой файловой системы. Такой кластер облегчает администрирование хранилища, ограничивая установку приложений и исправлений пределами одной ФС. Если файловая система занимает все пространство кластера хранилища, отпадает необходимость в создании избыточных копий данных приложений, а процессы создания резервных копий и восстановления существенно упрощаются. Red Hat Cluster Suite реализует кластеризацию хранилищ с помощью Red Hat GFS.
Кластеры высокой доступности, как следует из определения, обеспечивают постоянный доступ к службам за счет исключения критических точек сбоя, а также за счет переноса служб с одного узла на другой в случае его неисправности. Обычно службы кластера высокой доступности осуществляют чтение и запись данных (файловые системы смонтированы в режиме чтения и записи), поэтому кластер должен обеспечить целостность данных при передаче службой управления от одного узла другому. Сбои узлов кластеров высокой доступности (их иногда называют кластерами восстановления) не будут видимы клиентам за пределами кластера. Компонент управления службами Red Hat Cluster Suite позволяет обеспечить высокую доступность кластеров.
Кластеры распределения загрузки направляют запросы сетевых служб различным узлам. Такая балансировка является экономичным решением для достижения масштабируемости, поскольку в зависимости от загрузки вы можете использовать необходимое число узлов. В случае сбоя одного узла специальное программное обеспечение его определит и перенаправит запросы другим узлам. Сбои узлов кластеров распределения загрузки не будут видимы клиентам за пределами кластера. Виртуальный сервер LVS (Linux Virtual Server) Red Hat Cluster Suite обеспечивает распределение загрузки.
Кластеры высокой производительности используют узлы для выполнения одновременных расчетов. Высокопроизводительный кластер допускает параллельное исполнение программ, тем самым повышая их производительность. Такие кластеры иногда называют вычислительными кластерами или кластерами распределенных вычислений (grid computing).

Примечание

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

1.2. Red Hat Cluster Suite Introduction

Red Hat Cluster Suite (RHCS) представляет собой набор программных компонентов, различные конфигурации которых позволяют удовлетворить большинство потребностей по обеспечению необходимого уровня производительности, высокой доступности, распределению нагрузки, масштабируемости, совместного доступа к файлам и экономичности.
RHCS consists of the following major components (refer to Рисунок 1.1, «Red Hat Cluster Suite Introduction»):
  • Инфраструктура кластера — предоставляет основные функции узлам, которые позволяют их объединять в кластер. Эти функции включают управление файлами конфигурации, участниками, блокировкой, а также функции изолирования узлов.
  • Управление службами высокой доступности — обеспечивает перенос работы служб с проблемного узла на функционирующий.
  • Утилиты администрирования кластера — утилиты конфигурации и управления кластером Red Hat используются вместе с компонентами инфраструктуры кластера, компонентами высокой доступности, управления службами и хранилищами.
  • Виртуальный сервер Linux (LVS, Linux Virtual Server) — программное обеспечение маршрутизации, осуществляющее распределение нагрузки IP. LVS выполняется на двух избыточных серверах, которые равномерно распределяют запросы клиентов между рабочими серверами, на основе которых и созданы виртуальные сервера.
Функциональность Red Hat Cluster Suite можно дополнить следующими компонентами (они являются частью отдельного пакета и НЕ входят в состав Red Hat Cluster Suite):
  • Red Hat GFS (Global File System) — кластерная файловая система для Red Hat Cluster Suite. GFS допускает совместное использование хранилища несколькими узлами на уровне блоков так, как будто оно подключено локально к каждому узлу.
  • Менеджер логических томов кластера (CLVM, Cluster Logical Volume Manager) — обеспечивает управление кластерным хранилищем.

    Примечание

    When you create or modify a CLVM volume for a clustered environment, you must ensure that you are running the clvmd daemon. For further information, refer to Раздел 1.6, «Менеджер логических томов кластера».
  • Устройство GNBD (Global Network Block Device) — дополнительный компонент GFS, экспортирующий блочное хранилище для Ethernet. GNBD представляет собой экономичное решение для обеспечения доступа Red Hat GFS к хранилищу.
For a lower level summary of Red Hat Cluster Suite components and optional software, refer to Глава 2, Обзор компонентов Red Hat Cluster Suite.
Red Hat Cluster Suite Introduction

Рисунок 1.1. Red Hat Cluster Suite Introduction

Примечание

Рисунок 1.1, «Red Hat Cluster Suite Introduction» includes GFS, CLVM, and GNBD, which are components that are part of an optional package and not part of Red Hat Cluster Suite.

1.3. Cluster Infrastructure

Инфраструктура кластера Red Hat Cluster Suite обеспечивает базоывае функции, которые позволяют объединить группу компьютеров (также называемых узлами или участниками) в кластер. Также возможно использовать компоненты Red Hat Cluster Suite для выполнения различных операций кластеризации, например, обеспечения совместного доступа к файлам в файловой системе GFS или настройки переноса служб в случае сбоя. Основные функции такой инфраструктуры:
  • Управление кластерами
  • Управление блокировками
  • Fencing
  • Управление конфигурацией кластера

1.3.1. Управление кластером

Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for cluster manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5. CMAN is a distributed cluster manager and runs in each cluster node; cluster management is distributed across all nodes in the cluster (refer to Рисунок 1.2, «CMAN/DLM Overview»).
CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the nodes are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not have quorum, and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "split-brain" condition — a condition where two instances of the same cluster are running. A split-brain condition would allow each cluster instance to access cluster resources without knowledge of the other cluster instance, resulting in corrupted cluster integrity.
Под определением «кворума» по отношению к кластерам подразумевается обмен сообщениями между узлами кластера через Ethernet и, дополнительно, через «кворум-диск». Ethernet-кворум достигается при активности 50% плюс 1 узел. Дисковый кворум определяется заданными пользователем условиями.

Примечание

По умолчанию каждому узлу соответствует один пункт. Однако можно настроить узел так, чтобы ему соответствовало произвольное число пунктов.
CMAN наблюдает за участниками, отслеживая обмен сообщениями между узлами. Если число участников изменилось, менеджер кластера уведомит другие компоненты. Представим, например, что в кластер добавляется узел A. Он монтирует файловую систему GFS, которая уже смонтирована узлами B и С; в этом случае для A потребуется обеспечить отдельный журнал и управление блокировкой, чтобы он мог использовать GFS. Если узел не передает сообщение в пределах заданного промежутка времени, менеджер кластера удалит узел из кластера и уведомит об этом компоненты инфраструктуры. Наконец, в зависимости от полученной информации, компоненты определят последующие действия. К примеру, изолирование ограничит использование исключенного узла.
CMAN/DLM Overview

Рисунок 1.2. CMAN/DLM Overview

1.3.2. Управление блокировкой

Lock management is a common cluster-infrastructure service that provides a mechanism for other cluster infrastructure components to synchronize their access to shared resources. In a Red Hat cluster, DLM (Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock manager and runs in each cluster node; lock management is distributed across all nodes in the cluster (refer to Рисунок 1.2, «CMAN/DLM Overview»). GFS and CLVM use locks from the lock manager. GFS uses locks from the lock manager to synchronize access to file system metadata (on shared storage). CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups (also on shared storage).

1.3.3. Fencing

Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through the fence daemon, fenced.
Когда CMAN определяет, что произошел сбой узла, эта информация передается другим компонентам инфраструктуры, включая fenced, который тут же изолирует проблемный узел. Другие компоненты будут выполнять действия в соответствии с ситуацией, к примеру, начнут операции восстановления. Получив информацию о сбое узла, DLM и GFS прекращают все действия, до тех пор пока fenced не завершит его изолирование.
Изолирующая программа выбирает способ изоляции на основе полученной из файла конфигурации информации. Его определяют два основных элемента: изолирующий агент и изолирующее устройство. Программа осуществляет вызов агента, заданного в файле конфигурации. Агент, в свою очередь, ограничит узел с помощью изолирующего устройства. Программа уведомит менеджер кластера о завершении.
Возможные методы изоляции Red Hat Cluster Suite:
  • Изолирование с помощью питания: использует контроллер питания для отключения проблемного узла.
  • Изолирование с помощью переключателя Fibre Channel: отключает порт Fibre Channel, соединяющий хранилище с проблемным узлом.
  • GNBD fencing — A fencing method that disables an inoperable node's access to a GNBD server.
  • Прочие виды: отключение ввода/ вывода или питания проблемного узла, включая IBM Bladecenters, PAP, DRAC/MC, HP ILO, IPMI, IBM RSA II и пр.
Рисунок 1.3, «Power Fencing Example» shows an example of power fencing. In the example, the fencing program in node A causes the power controller to power off node D. Рисунок 1.4, «Fibre Channel Switch Fencing Example» shows an example of Fibre Channel switch fencing. In the example, the fencing program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D from storage.
Power Fencing Example

Рисунок 1.3. Power Fencing Example

Fibre Channel Switch Fencing Example

Рисунок 1.4. Fibre Channel Switch Fencing Example

Чтобы указать метод изолирования узла, в файле конфигурации кластера необходимо определить имя метода, агент и изолирующее устройство для каждого узла в составе кластера.
The way in which a fencing method is specified depends on if a node has either dual power supplies or multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must specify at least two fencing devices — one fencing device for each power supply (refer to Рисунок 1.5, «Fencing a Node with Dual Power Supplies»). Similarly, if a node has multiple paths to Fibre Channel storage, then the fencing method for the node must specify one fencing device for each path to Fibre Channel storage. For example, if a node has two paths to Fibre Channel storage, the fencing method should specify two fencing devices — one for each path to Fibre Channel storage (refer to Рисунок 1.6, «Fencing a Node with Dual Fibre Channel Connections»).
Fencing a Node with Dual Power Supplies

Рисунок 1.5. Fencing a Node with Dual Power Supplies

Fencing a Node with Dual Fibre Channel Connections

Рисунок 1.6. Fencing a Node with Dual Fibre Channel Connections

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

1.3.4. Система конфигурации кластера

The Cluster Configuration System (CCS) manages the cluster configuration and provides configuration information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system administrator updates the configuration file in Node A, CCS propagates the update from Node A to the other nodes in the cluster (refer to Рисунок 1.7, «CCS Overview»).
CCS Overview

Рисунок 1.7. CCS Overview

Other cluster components (for example, CMAN) access configuration information from the configuration file through CCS (refer to Рисунок 1.7, «CCS Overview»).
Accessing Configuration Information

Рисунок 1.8. Accessing Configuration Information

Файл конфигурации кластера (/etc/cluster/cluster.conf) представляет собой XML-файл, содержащий определения следующих характеристрик:
  • Имя кластера: Отображает имя кластера, версию его файла конфигурации, основные временные параметры изоляции, назначаемые узлу при его включении в кластер.
  • Кластер: Отображает все узлы кластера с указанием их имен, идентификаторов, число соответствующих пунктов кворума и изолирующий метод.
  • Изолирующее устройство: Отображает соответствующие кластеру устройства. Параметры могут отличаться для разных типов устройств. Например, если в качестве ограничивающего устройства используется контроллер питания, то настройки будут включать его имя, IP-адрес, имя входа и пароль.
  • Управляемые ресурсы: Отображают необходимые для создания кластерных служб ресурсы, что включает определения доменов восстановления, ресурсов (IP-адреса и др.), а также службы. Комбинация управляемых ресурсов позволяет определить кластерные службы и их поведение в случае сбоя.

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

Управление объединяет операции создания и администрирования кластерных служб высокого доступа Red Hat. Ключевым компонентом при этом является rgmanager, обеспечивающий восстановление приложений. В кластере Red Hat для организации службы с высоким доступом осуществляется настройка приложения с другими кластерными ресурсами. Такие службы могут быть перенесены с одного кластерного узла на другой без видимого клиенту прерывания работы. Перенос обычно выполняется при сбое узла или в случае необходимости (например, плановой профилактики).
Чтобы создать высокодоступную службу, сначала надо ее настроить в файле конфигурации кластера. В состав службы входят кластерные ресурсы. Они являются компонентами, которые создаются и управляются с помощью файла конфигурации. Примерами компонентов могут служить IP-адреса, сценарии инициализации приложений, разделяемые разделы Red Hat GFS.
You can associate a cluster service with a failover domain. A failover domain is a subset of cluster nodes that are eligible to run a particular cluster service (refer to Рисунок 1.9, «Домены восстановления»).

Примечание

Домены восстановления НЕ являются обязательными.
Кластерная служба может выполняться одновременно только на одном узле во избежание нарушения целостности данных. В домене восстановления можно задать приоритет для каждого узла домена. Уровень приоритета определяет порядок узлов, на которые будет перенесена служба в случае сбоя исходного узла. Если приоритет не задан, кластерная служба может быть перенесена на любой узел в домене восстановления. Также можно разрешить исполнение кластерной службы только на соответствующих ее домену восстановления узлах. Если же службе соответствует неограничиваемый домен, то она может быть запущена на любом узле, если узлы в ее домене недоступны.
In Рисунок 1.9, «Домены восстановления», Failover Domain 1 is configured to restrict failover within that domain; therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is also configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing over to Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that Cluster Service Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover Domain 3. However, if none of those nodes is available, Cluster Service Z can fail over to any node in the cluster.
Домены восстановления

Рисунок 1.9. Домены восстановления

Рисунок 1.10, «Web Server Cluster Service Example» shows an example of a high-availability cluster service that is a web server named "content-webserver". It is running in cluster node B and is in a failover domain that consists of nodes A, B, and D. In addition, the failover domain is configured with a failover priority to fail over to node D before node A and to restrict failover to nodes only in that failover domain. The cluster service comprises these cluster resources:
  • Ресурс IP-адреса: 10.10.10.201.
  • An application resource named "httpd-content" — a web server application init script /etc/init.d/httpd (specifying httpd).
  • A file system resource — Red Hat GFS named "gfs-content-webserver".
Web Server Cluster Service Example

Рисунок 1.10. Web Server Cluster Service Example

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

1.5. Red Hat GFS

Red Hat GFS -- кластерная файловая система, позволяющая объединенным в кластер узлам выполнять одновременное обращение к разделяемому блочному устройству. GFS напрямую сообщается со слоем VFS интерфейса ядра Linux файловых систем. Для достижения оптимальной функциональности GFS использует распределенные метаданные и множество журналов. Контролирующий ввод и вывод менеджер блокирования позволяет поддерживать целостность данных. Например, если один узел изменил данные в GFS, изменения немедленно станут видимы другим узлам кластера, использующим такую же файловую систему.
С помощью Red Hat GFS можно достичь максимального времени работы приложений. Достоинства:
  • Упрощение инфраструктуры данных
    • Установка приложений и их исправлений один раз для всего кластера.
    • Нет необходимости в избыточных копиях данных приложений (дублировании).
    • Активируется одновременный доступ чтения/ записи данных для клиентов.
    • Упрощение резервного копирования и восстановления после аварийного сбоя (для одной файловой системы).
  • Максимальная утилизация ресурсов хранения, минимизация издержек их администрирования.
    • Управление хранилищем как единым целым, а не на уровне разделов.
    • Снижение потребностей хранилища в ресурсах за счет исключения дублирования данных.
  • Прозрачное масштабирование кластера за счет добавления серверов или хранилища «на лету».
    • Упрощено разбиение хранилища на разделы.
    • Добавление серверов в кластер «на лету» путем их монтирования в общую файловую систему.
Конфигурация и администрирование узлов с Red Hat GFS осуществляется с помощью соответствующих утилит. С помощью CLVM (Cluster Logical Volume Manager) выполняется управление томами. Red Hat GFS обеспечивает совместный доступ к данным для узлов GFS в пределах кластера Red Hat. GFS позволяет использовать одно пространство имен файловой системы для всех GFS-узлов, а также допускает установку и исполнение приложений без необходимости подробного ознакомления с инфраструктурой хранилища. Также доступны функции, обычно использующиеся в корпоративных окружениях, такие как использование квот, многочисленных журналов и поддержка альтернативных маршрутов.
GFS предоставляет гибкий метод организации сетевого хранилища и его оптимизации в соответствии с индивидуальными потребностями производительности, масштабируемости и экономичности. Этот раздел содержит самую основную информацию о GFS.
You can deploy GFS in a variety of configurations to suit your needs for performance, scalability, and economy. For superior performance and scalability, you can deploy GFS in a cluster that is connected directly to a SAN. For more economical needs, you can deploy GFS in a cluster that is connected to a LAN with servers that use GNBD (Global Network Block Device) or to iSCSI (Internet Small Computer System Interface) devices. (For more information about GNBD, refer to Раздел 1.7, «Устройство GNBD».)
Далее будут приведены примеры вариантов развертывания GFS:

Примечание

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

1.5.1. Повышение производительности и масштабируемости

You can obtain the highest shared-file performance when applications access storage directly. The GFS SAN configuration in Рисунок 1.11, «GFS with a SAN» provides superior file performance for shared files and file systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or storage servers to slow data access, performance is similar to individual Linux servers with directly connected storage; yet, each GFS application node has equal access to all data files. GFS supports over 300 GFS nodes.
GFS with a SAN

Рисунок 1.11. GFS with a SAN

1.5.2. Производительность, масштабируемость, экономичность

Multiple Linux client applications on a LAN can share the same SAN-based data as shown in Рисунок 1.12, «GFS and GNBD with a SAN». SAN block storage is presented to network clients as block storage devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were directly attached to the server in which the application is running. Stored data is actually on the SAN. Storage devices and data can be equally shared by network client applications. File locking and sharing functions are handled by GFS for each network client.
GFS and GNBD with a SAN

Рисунок 1.12. GFS and GNBD with a SAN

1.5.3. Экономичность и производительность

Рисунок 1.13, «GFS и GNBD с напрямую подключенным хранилищем» shows how Linux client applications can take advantage of an existing Ethernet topology to gain shared access to all block storage devices. Client data files and file systems can be shared with GFS on each client. Application failover can be fully automated with Red Hat Cluster Suite.
GFS и GNBD с напрямую подключенным хранилищем

Рисунок 1.13. GFS и GNBD с напрямую подключенным хранилищем

1.6. Менеджер логических томов кластера

CLVM (Cluster Logical Volume Manager) представляет собой расширенную версию LVM2 (в пределах кластера) и реализует те же возможности что и LVM2 на индивидуальных узлах, но дополнительно обеспечивает доступ к томам для всех узлов в составе кластера Red Hat. Созданные с помощью CLVM логические тома будут доступны всем узлам кластера.
The key component in CLVM is clvmd. clvmd is a daemon that provides clustering extensions to the standard LVM2 tool set and allows LVM2 commands to manage shared storage. clvmd runs in each cluster node and distributes LVM metadata updates in a cluster, thereby presenting each cluster node with the same view of the logical volumes (refer to Рисунок 1.14, «CLVM Overview»). Logical volumes created with CLVM on shared storage are visible to all nodes that have access to the shared storage. CLVM allows a user to configure logical volumes on shared storage by locking access to physical storage while a logical volume is being configured. CLVM uses the lock-management service provided by the cluster infrastructure (refer to Раздел 1.3, «Cluster Infrastructure»).

Примечание

Для обеспечения работы разделяемого хранилища необходимо, чтобы выполнялся демон clvmd или агенты управления высокодоступными логическими томами HA-LVM (High Availability Logical Volume Management). Если по какой-то причине вы не можете их запустить, например, у вас нет достаточных полномочий, то не используйте LVM на диске с совместным доступом, так как это может повредить данные. Если у вас есть вопросы, обратитесь за помощью к торговому представителю Red Hat.

Примечание

Для разрешения блокирования в пределах кластера при работе с CLVM необходимо немного изменить /etc/lvm/lvm.conf.
CLVM Overview

Рисунок 1.14. CLVM Overview

You can configure CLVM using the same commands as LVM2, using the LVM graphical user interface (refer to Рисунок 1.15, «LVM Graphical User Interface»), or using the storage configuration function of the Conga cluster configuration graphical user interface (refer to Рисунок 1.16, «Conga LVM Graphical User Interface») . Рисунок 1.17, «Creating Logical Volumes» shows the basic concept of creating logical volumes from Linux partitions and shows the commands used to create logical volumes.
LVM Graphical User Interface

Рисунок 1.15. LVM Graphical User Interface

Conga LVM Graphical User Interface

Рисунок 1.16. Conga LVM Graphical User Interface

Creating Logical Volumes

Рисунок 1.17. Creating Logical Volumes

1.7. Устройство GNBD

Глобальное блочное устройство сети (GNBD, Global Network Block Device) обеспечивает доступ блочных устройств к Red Hat GFS по TCP/IP. Концепция GNBD аналогична NBD за тем исключением, что GNBD является более GFS-специализированным, а его настройки подразумевают работу исключительно с GFS. GNBD применяется, когда нет необходимости прибегать к помощи мощных технологий, таких как Fibre Channel или SCSI с одним инициатором.
GNBD consists of two major components: a GNBD client and a GNBD server. A GNBD client runs in a node with GFS and imports a block device exported by a GNBD server. A GNBD server runs in another node and exports block-level storage from its local storage (either directly attached storage or SAN storage). Refer to Рисунок 1.18, «Обзор GNBD». Multiple GNBD clients can access a device exported by a GNBD server, thus making a GNBD suitable for use by a group of nodes running GFS.
Обзор GNBD

Рисунок 1.18. Обзор GNBD

1.8. Виртуальный сервер Linux

Виртуальный сервер Linux (LVS, Linux Virtual Server) представляет собой комплект программных компонентов, целью которых является обеспечение баланса загрузки IP между набором настоящих серверов. LVS выполняется на паре аналогично настроенных компьютеров, один из которых исполняет функции активного маршрутизатора LVS, а второй -- резервного маршрутизатора. Назначение активного маршрутизатора LVS:
  • Обеспечивать баланс загрузки между настоящими серверами.
  • Выполнять проверку целостности служб на каждом реальном сервере.
Резервный маршрутизатор LVS следит за работой активного маршрутизатора, в случае сбоя которого управление будет передано резервному.
Рисунок 1.19, «Components of a Running LVS Cluster» provides an overview of the LVS components and their interrelationship.
Components of a Running LVS Cluster

Рисунок 1.19. Components of a Running LVS Cluster

На обоих компьютерах выполняется демон pulse. На резервном маршрутизаторе LVS pulse отправляет тактовый импульс общему интерфейсу активного маршрутизатора, чтобы проверить корректность его работы. На активном маршрутизаторе pulse запустит демон lvs и ответит на полученные от резервного маршрутизатора LVS запросы тактового импульса.
Сначала демон lvs вызывает утилиту ipvsadm для выполнения конфигурации и обеспечения поддержки работы таблицы маршрутизации сервера IPVS (IP Virtual Server) в ядре, а также на каждом реальном сервере запускает процесс nanny для каждого настроенного виртуального сервера. Процесс nanny проверяет состояние одной службы для каждого настоящего сервера и сообщает демону lvs о неполадках. Если обнаружены проблемы, lvs укажет ipvsadm удалить соответствующий настоящий сервер из таблицы маршрутизации IPVS.
Если резервный маршрутизатор LVS не получил ответ от активного маршрутизатора, активируется send_arp, что позволит переназначить все виртуальные адреса IP аппаратным адресам NIC (MAC) резервного маршрутизатора LVS. Затем активному маршрутизатору будет направлена команда завершения работы демона lvs и через общий, и через частный сетевые интерфейсы, а на резервном маршрутизаторе будет запущен демон lvs, для того чтобы получать запросы от настроенных виртуальных серверов.
Пользователь, пытающийся получить доступ к службе (например, к сайту или приложению) извне, видит LVS как один сервер, хотя на самом деле обращение осуществляется к настоящим серверам, скрытым за маршрутизаторами LVS.
Поскольку LVS не обладает встроенными компонентами для разделения данных между реальными серверами, можно выбрать один из следующих вариантов:
  • Синхронизировать данные между серверами.
  • Добавить третий слой топологии для доступа к разделяемым данным.
Первый вариант предпочтителен для серверов, которые не допускают закачку или изменение данных на реальных серверах большим числом пользователей. Если же сервер разрешает большому числу пользователей изменять данные (актуально для сайтов электронной коммерции, например), то рекомендуется добавить дополнительный слой.
Существует множество методов синхронизации данных между серверами. Например, с помощью сценариев оболочки можно одновременно публиковать обновленные веб-страницы на настоящих серверах. Также можно использовать такие программы как rsync для периодической синхронизации измененных данных на всех серверах. Но в окружениях, где пользователи часто закачивают файлы на сервер или обращаются к базе данных, вместо rsync или сценариев оболочки для синхронизации данных больше подходит применение трехуровневой топологии.

1.8.1. Two-Tier LVS Topology

Рисунок 1.20, «Two-Tier LVS Topology» shows a simple LVS configuration consisting of two tiers: LVS routers and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The real-server tier consists of real servers connected to the private network. Each LVS router has two network interfaces: one connected to a public network (Internet) and one connected to a private network. A network interface connected to each network allows the LVS routers to regulate traffic between clients on the public network and the real servers on the private network. In Рисунок 1.20, «Two-Tier LVS Topology», the active LVS router uses Network Address Translation (NAT) to direct traffic from the public network to real servers on the private network, which in turn provide services as requested. The real servers pass all public traffic through the active LVS router. From the perspective of clients on the public network, the LVS router appears as one entity.
Two-Tier LVS Topology

Рисунок 1.20. Two-Tier LVS Topology

Запросы служб, поступающие на маршрутизатор LVS, предназначаются виртуальному IP-адресу, который представляет собой общедоступный адрес, назначенный администратором полностью квалифицированному имени домена (в формате www.example.com). Этот адрес также соответствует одному или нескольким виртуальным серверам[1] Обратите внимание, что виртуальный адрес IP мигрирует с одного маршрутизатора LVS на другой в случае восстановления после отказа, тем самым обеспечивая доступность этого IP-адреса (его также называют «плавающий IP-адрес»).
Виртуальные IP-адреса могут быть обозначены в соответствии с именем устройства, соединяющего маршрутизатор LVS c общей сетью. Например, если к Интернету подключается eth0, то виртуальные серверы можно обозначить как eth0:1. Или же каждый виртуальный сервер может быть сопоставлен отдельному устройству для каждой службы. К примеру, обработка HTTP-трафика будет осуществляться на eth0:1, а FTP-трафика -- на eth0:2.
В определенный момент времени может быть активен только один маршрутизатор LVS. Роль активного маршрутизатора -- перенаправление запросов службы с виртуальных IP-адресов настоящим серверам, в основу которого положен один из восьми алгоритмов распределения загрузки:
  • Последовательный (RR, Round-Robin): распределяет каждый запрос последовательно между серверами в предопределенном наборе. В этом случае предпочтение не отдается никаким серверам, независимо от их емкости или загрузки.
  • Последовательный с коэффициентом (WRR, Weighted Round-Robin): распределяет каждый запрос последовательно между серверами в предопределенном наборе, но назначает серверам с большей емкостью больше задач. Емкость определяется заданным пользователем коэффициентом, который изменяется в зависимости от информации о загрузке. Такой метод является предпочтительным, если емкости серверов значительно отличаются. Но если загрузка запросов сильно изменяется, сервер с бóльшим коэффициентом может обработать большее число запросов.
  • Минимальное число соединений: распределяет больше запросов между серверами с меньшим числом активных соединений. Такой алгоритм динамического распределения предпочтителен в случаях, когда загрузка запросов значительно изменяется, и лучше всего подходит для набора реальных серверов, в котором все сервера обладают приблизительно одинаковой емкостью. Если же их емкость отличается, можно использовать следующий алгоритм.
  • Минимальное число соединений с коэффициентом (используется по умолчанию): распределяет больше запросов между серверами с меньшим числом активных соединений, которые зависят от емкости, которой соответствует определенный пользователем коэффициент. Коэффициент изменяется в зависимости от информации загрузки. Добавление коэффициента делает этот алгоритм идеальным выбором, если набор настоящих серверов содержит оборудование с различной емкостью.
  • Минимальное число соединений в зависимости от расположения: распределяет больше запросов между серверами с меньшим числом активных соединений, которые зависят от целевого IP-адреса. Такой алгоритм используется для кластеров сервера прокси-кэша. При этом пакеты, предназначенные IP-адресу на сервере, направляются этому серверу, если только емкость сервера не превышена, а загрузка сервера не достигла половины, в случае чего IP-адрес будет присвоен наименее загруженному настоящему серверу.
  • Минимальное число соединений в зависимости от расположения с дублированием: распределяет больше запросов между серверами с меньшим числом активных соединений, которые зависят от целевого IP-адреса. Такой алгоритм используется для кластеров сервера прокси-кэша. Он отличается от предыдущего алгоритма тем, что целевой IP-адрес сопоставляется набору настоящих серверов. Затем запросы направляются тому серверу, которому соответствует наименьшее число соединений. Если же емкость всех узлов для заданного IP-адреса превышена, будет выполнено дублирование нового сервера путем добавления настоящего сервера с минимальным числом подключений из общего набора в подмножество серверов для целевого IP-адреса. Максимально загруженный узел будет исключен из набора, что позволит избежать излишнего дублирования.
  • Хеш источника: распределяет запросы между реальными серверами в наборе, определяя IP-адрес источника из статической таблицы хеша. Этот алгоритм обычно применяется для маршрутизаторов LVS c несколькими межсетевыми экранами.
Активный маршрутизатор LVS динамически наблюдает за общим состоянием определенных устройств настоящих серверов с помощью сценариев send/expect. Также можно использовать внешние исполняемые компоненты для отслеживания состояния служб, работающих с динамическими данными (HTTPS, SSL). Если функциональность службы на сервере нарушена, активный маршрутизатор LVS прекратит отправку заданий до тех пор, пока сервер не начнет функционировать нормально.
Резервный маршрутизатор LVS исполняет роль системы, находящейся в режиме ожидания. Периодически маршрутизаторы обмениваются тактовыми импульсами через общий интерфейс или, в случае сбоя, через частный. Если по какой-то причине резервный маршрутизатор LVS не получил сообщение тактового импульса в течение ожидаемого времени, он начнет исполнять роль активного маршрутизатора. При этом виртуальные адреса будут обслуживаться посредством ARP-спуфинга. В этом случае резервный маршрутизатор LVS объявляет себя целевым назначением для всех IP-пакетов, предназначенных неисправному узлу. При восстановлении нормальной работы проблемного узла резервный маршрутизатор LVS возвращается в исходное состояние.
The simple, two-tier configuration in Рисунок 1.20, «Two-Tier LVS Topology» is suited best for clusters serving data that does not change very frequently — such as static web pages — because the individual real servers do not automatically synchronize data among themselves.

1.8.2. Three-Tier LVS Topology

Рисунок 1.21, «Three-Tier LVS Topology» shows a typical three-tier LVS configuration. In the example, the active LVS router routes the requests from the public network (Internet) to the second tier — real servers. Each real server then accesses a shared data source of a Red Hat cluster in the third tier over the private network.
Three-Tier LVS Topology

Рисунок 1.21. Three-Tier LVS Topology

Трехуровневая топология подходит для FTP-серверов с интенсивной нагрузкой, когда данные централизованно хранятся на высокодоступном сервере. При этом доступ к данным осуществляется с помощью экспортируемого по NFS каталога или разделяемого ресурса Samba. Использование такой топологии рекомендуется для веб-сайтов, которые активно взаимодействуют с базой данных. Также можно настроить один высокодоступный кластер Red Hat с помощью конфигурации «активно - активно», так чтобы кластер исполнял обе перечисленные функции.

1.8.3. Методы маршрутизации

Следующие секции вкратце описывают маршрутизацию NAT (Network Address Translation) и прямую маршрутизацию с LVS.

1.8.3.1. Маршрутизация NAT

Рисунок 1.22, «LVS Implemented with NAT Routing», illustrates LVS using NAT routing to move requests between the Internet and a private network.
LVS Implemented with NAT Routing

Рисунок 1.22. LVS Implemented with NAT Routing

В приведенном примере активному маршрутизатору LVS соответствуют две карты NIC. Карте для выхода в Интернет назначен настоящий IP-адрес на eth0 и «плавающий» адрес на eth0:1. Карте NIC частной сети назначен настоящий IP-адрес на eth1 и «плавающий» адрес на eth1:1. В случае сбоя работа виртуального интерфейса, используемого для выхода в Интернет, и другого виртуального интерфейса для связи с частной сетью будет перенесена на резервный маршрутизатор LVS. Все настоящие серверы в частной сети будут использовать «плавающий» IP-адрес для маршрутизатора NAT в качестве стандартного маршрута для связи с активным маршрутизатором LVS с целью сохранения возможности ответа на поступающие из Интернета запросы.
In the example, the LVS router's public LVS floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its physical device on the LVS router nodes, having more than two NICs is not a requirement.
При использовании такой топологии активный маршрутизатор LVS получает запрос и направляет его соответствующему серверу. Тем временем, настоящий сервер обрабатывает запрос и возвращает пакеты маршрутизатору LVS, который использует преобразование сетевых адресов для замены настоящего адреса сервера общим виртуальным IP-адресом маршрутизатора LVS. Этот процесс носит имя IP-маскарада, поскольку действительные IP-адреса серверов невидимы клиентам, отправляющим запросы.
Так, при использовании маршрутизации NAT сервера могут представлять собой любые компьютеры с различными операционными системами. Основным недостатком маршрутизации NAT является то, что в масштабных инфраструктурах LVS-маршрутизатор может не справиться со всеми исходящими и поступающими запросами.

1.8.3.2. Прямая маршрутизация

Прямая маршрутизация позволяет достичь более высокой производительности по сравнению с маршрутизацией NAT. При этом серверы обрабатывают пакеты и перенаправляют их запрашивающему пользователю напрямую, а не пропускают их через маршрутизатор LVS. Это способствует снижению вероятности проблем производительности сети за счет ограничения работы маршрутизатора лишь обработкой входящих пакетов.
LVS Implemented with Direct Routing

Рисунок 1.23. LVS Implemented with Direct Routing

При типичной конфигурации маршрутизатор LVS получает запросы с сервера через виртуальный IP-адрес и с помощью алгоритма планирования направляет запрос соответствующим серверам. Каждый сервер обрабатывает запросы и направляет их клиентам напрямую, в обход маршрутизаторов LVS. Прямая маршрутизация способствует масштабируемости, так как добавление серверов не приведет к дополнительной нагрузке на маршрутизатор LVS при передаче исходящих пакетов от сервера к клиенту.
Основные ограничения на прямое масштабирование и LVS накладывает протокол ARP (Address Resolution Protocol).
In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.
Проблемой при конфигурации прямой маршрутизации LVS с учетом обработки запросов ARP является то, что виртуальный IP-адрес маршрутизатора LVS должен соответствовать MAC-адресу, так как запрос, предназначенный адресу IP, должен быть сопоставлен адресу MAC. Но поскольку и маршрутизатор LVS, и действительные серверы имеют тот же виртуальный IP-адрес, запрос ARP передается ВСЕМ узлам с этим адресом. Это может привести к проблемам, например, если виртуальный адрес напрямую назначен серверу, в случае чего обработка запросов будет осуществляться напрямую, в обход маршрутизатора LVS, тем самым сводя весь смысл конфигурации LVS к нулю. Использование маршрутизатора с мощным процессором не решит проблему. Если загрузка маршрутизатора LVS существенна, он будет отвечать на запросы все же медленнее по сравнению с незанятым сервером, которому соответствует виртуальный IP-адрес в кэше ARP клиента, отправляющего запрос.
Чтобы решить эту проблему, необходимо, чтобы входящие запросы предназначались только виртуальному IP-адресу маршрутизатора LVS, который будет их обрабатывать и направлять реальным серверам. Для этого понадобится утилита фильтрования пакетов arptables.

1.8.4. Постоянство и метки межсетевого экрана

В некоторых случаях клиенту может понадобиться повторно подключиться к серверу вместо передачи запроса алгоритмом распределения нагрузки LVS первому доступному серверу. Примерами таких ситуаций могут служить многочисленные веб-формы, cookie-файлы, соединения SSL и FTP. При этом клиент не будет функционировать корректно, если все передачи не обрабатываются одним сервером. Эти требования можно удовлетворить с помощью сохранения постоянства и меток межсетевого экрана.

1.8.4.1. Persistence

Когда клиент подключается к службе, LVS сохраняет информацию о последнем подключении на протяжении определенного периода времени. Если же осуществляется повторное подключение с того же IP-адреса, запросы будут направлены тому же серверу (в обход механизмов распределения нагрузки). Если же соединение произошло после истечения установленного периода времени, оно будет обработано в соответствии со стандартными правилами.
Сохранение постоянства позволяет задать маску подсети для IP-адреса клиента, чтобы проверить, какие адреса обладают более высоким уровнем постоянства, на основе чего их можно сгруппировать для заданной подсети.
Группировка соединений, предназначенных разным портам, имеет большое значение для протоколов, использующих несколько портов (например, FTP). Однако сохранение постоянства не является наиболее эффективным методом решения проблемы объединения соединений, направляемых разным портам. Для этого лучше использовать метки межсетевого экрана.

1.8.4.2. Метки межсетевого экрана

Использование меток межсетевого экрана представляет собой эффективный метод объединения портов для использования протоколом или группой протоколов. Представим, что LVS положен в основу сайта электронных продаж. В таком случае метки могут использоваться для привязки соединений HTTP к порту 80, а безопасных соединений HTTPS -- к порту 443. При присвоении одной метки всем протоколам сохраняется информация о состоянии транзакции, тем самым обеспечивая перенаправление всех запросов одному серверу после установки соединения.
Вследствие легкости и эффективности использования рекомендуется использовать метки межсетевого экрана. Сохранение постоянства может использоваться в качестве дополнения, чтобы убедиться в том, что клиенты повторно подключаются к тому же серверу в пределах заданного интервала времени.

1.9. Средства администрирования кластера

Red Hat Cluster Suite предоставляет множество утилит, с помощью которых можно настроить кластер Red Hat. Данный раздел содержит обзор управляющих утилит Red Hat Cluster Suite.

1.9.1. Conga

Conga представляет собой комплект программных компонентов для централизованной конфигурации и управления кластерами и хранилищами Red Hat. Основные возможности Conga:
  • Управление кластером и хранилищем осуществляется с помощью одного интерфейса.
  • Автоматическое развертывание данных кластера и пакетов поддержки.
  • Легкость интеграции с существующими кластерами.
  • Отсутствие необходимости в повторной аутентификации.
  • Объединение информации состояния кластера и журналов.
  • Контроль за разрешениями пользователей.
Основные компоненты Conga, luci и ricci, устанавливаются отдельно. luci представляет собой сервер, который работает на одном компьютере и с помощью ricci связывается с различными кластерами. Агент ricci выполняется на каждом компьютере (отдельном или входящем в состав кластера) под управлением Conga.
Доступ к luci можно получить с помощью веб-браузера. Следующие вкладки предоставляют доступ к основным возможностям luci:
  • homebase: добавление и удаление компьютеров, пользователей и настройка пользовательских привилегий. Доступ к данной вкладке разрешен только системному администратору.
  • cluster: создание и конфигурация кластеров. Каждая версия luci отображает настроенные с ее помощью кластеры. На этой вкладке системный администратор может управлять кластерами; другие пользователи могут управлять только теми кластерами, разрешения на управление которыми им предоставлены администратором.
  • storage: удаленное управление хранилищем на компьютерах независимо от того, входят ли они в состав кластера или нет.
Чтобы обеспечить возможность администрирования кластера или хранилища, сначала администратор добавляет (регистрирует) кластер или компьютер на сервере luci. После регистрации полностью квалифицированное DN-имя или IP-адрес сохраняется в базе данных luci.
Базу данных одного варианта luci можно заполнить, скопировав данные из другого варианта. Такая возможность позволяет дублировать копии серверов luci и выполнять обновления более эффективно. При изначальной установке копии luci ее база данных пуста. Если же планируется развертывание нового сервера luci, можно частично скопировать базу данных luci с уже существующего сервера luci.
Для каждого варианта luci после установки будет создан всего один пользователь -- admin, который может добавлять системы к серверу luci, создавать учетные записи пользователей и управлять их правами доступа к кластерам и компьютерам, зарегистрированным в базе данных luci. Несколько пользователей можно импортировать так же, как можно импортировать кластеры или компьютеры.
При добавлении компьютера к серверу luci аутентификация осуществляется лишь один раз. После этого необходимости в ней нет, если только используемый сертификат не был аннулирован. Затем можно выполнять удаленную конфигурацию, а также управление кластерами и хранилищами с помощью интерфейса luci. Взаимодействие luci с ricci происходит через XML.
Следующие рисунки иллюстрируют описанные вкладки homebase, cluster, storage.
За дальнейшей информацией о Conga обратитесь к странице помощи сервера luci и разделу Конфигурация и администрирование кластера Red Hat.
luci : Вкладка homebase

Рисунок 1.24. luci : Вкладка homebase

luci : Вкладка cluster

Рисунок 1.25. luci : Вкладка cluster

luci : Вкладка storage

Рисунок 1.26. luci : Вкладка storage

1.9.2. Интерфейс утилиты администрирования кластера

This section provides an overview of the system-config-cluster cluster administration graphical user interface (GUI) available with Red Hat Cluster Suite. The GUI is for use with the cluster infrastructure and the high-availability service management components (refer to Раздел 1.3, «Cluster Infrastructure» and Раздел 1.4, «Управление службами высокой доступности»). The GUI consists of two major functions: the Cluster Configuration Tool and the Cluster Status Tool. The Cluster Configuration Tool provides the capability to create, edit, and propagate the cluster configuration file (/etc/cluster/cluster.conf). The Cluster Status Tool provides the capability to manage high-availability services. The following sections summarize those functions.

1.9.2.1. Cluster Configuration Tool

You can access the Cluster Configuration Tool (Рисунок 1.27, «Cluster Configuration Tool») through the Cluster Configuration tab in the Cluster Administration GUI.
Cluster Configuration Tool

Рисунок 1.27. Cluster Configuration Tool

С левой стороны экрана отображена иерархия компонентов файла конфигурации кластера (/etc/cluster/cluster.conf). Треугольник слева от имени компонента обозначает, что данному компоненту соответствует несколько подчиненных компонентов. Нажав на этот значок, можно развернуть или свернуть поддерево. Отображаемые компоненты сгруппированы следующим образом:
  • Cluster Nodes: Узлы кластера, каждый из которых представлен именем. С помощью кнопок настройки, расположенных внизу экрана, можно добавлять, удалять узлы, изменять их свойства и настраивать методы ограничения для каждого узла.
  • Fence Devices: Отображает изолирующие устройства. С помощью кнопок настройки, расположенных внизу экрана, можно добавлять, удалять устройства и изменять их свойства. Изолирующие устройства должны быть определены заранее для каждого узла (нажмите кнопку Manage Fencing For This Node), прежде чем вы сможете настроить ограничения.
  • Managed Resources: Отображает домены восстановления, ресурсы и службы.
    • Failover Domains: Используется для конфигурации доменов, на которые будут переноситься службы высокого доступа в случае сбоя узлов, на которых они выполняются. С помощью кнопок настройки, расположенных внизу экрана, можно создавать домены восстановления (строка Failover Domains при этом должна быть выделена) или изменять их свойства (предварительно выбрав домен для модификации).
    • Resources: Настройка разделяемых ресурсов служб высокой доступности. Разделяемые ресурсы включают файловые системы, IP-адреса, монтируемые и экспортируемые по NFS ресурсы, пользовательские сценарии, доступные всем службам высокой доступности кластера. С помощью кнопок настройки, расположенных внизу экрана, можно создавать ресурсы (строка Resources при этом должна быть выделена) или изменять их свойства (предварительно выбрав ресурс для модификации).

      Примечание

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

1.9.2.2. Cluster Status Tool

You can access the Cluster Status Tool (Рисунок 1.28, «Cluster Status Tool») through the Cluster Management tab in Cluster Administration GUI.
Cluster Status Tool

Рисунок 1.28. Cluster Status Tool

Утилита статуса отобразит те узлы и службы, которые определены файлом конфигурации кластера (/etc/cluster/cluster.conf), и позволяет включить, отключить, перезапустить или переместить службы высокой доступности.

1.9.3. Текстовые утилиты администрирования

In addition to Conga and the system-config-cluster Cluster Administration GUI, command line tools are available for administering the cluster infrastructure and the high-availability service management components. The command line tools are used by the Cluster Administration GUI and init scripts supplied by Red Hat. Таблица 1.1, «Утилиты командной строки» summarizes the command line tools.

Таблица 1.1. Утилиты командной строки

Утилита командной строки Используется в комплекте Назначение
ccs_tool: системная утилита конфигурации кластера Cluster Infrastructure ccs_tool: программа онлайн-обновления файла конфигурации кластера. Обеспечивает возможность создания и изменения компонентов инфраструктуры кластера (к примеру, создание, добавление и удаление узла). Подробная информация может быть найдена на странице помощи ccs_tool(8).
cman_tool: утилита администрирования кластера Cluster Infrastructure cman_tool: программа администрирования менеджера кластера CMAN. Обеспечивает возможность включения в кластер, исключения из него, немедленного удаления узла и пр. Подробная информация может быть найдена на странице помощи ccs_tool(8).
fence_tool: утилита изолирования Cluster Infrastructure fence_tool: программа, отвечающая за включение узла в заданный изолирующий домен и за его исключение. Иначе говоря, эта программа запускает демон fenced (при подключении узла к домену) или останавливает fenced (kill) (при исключении из домена). Более подробная информация может быть найдена на странице помощи fence_tool(8).
clustat: утилита статуса кластера Компоненты управления службами высокой доступности clustat отображает статус кластера, что включает информацию об участниках, кворуме и состоянии настроенных пользовательских служб. Подробная информация может быть найдена на странице помощи clustat(8).
clusvcadm: утилита администрирования пользовательских служб кластера Компоненты управления службами высокой доступности clusvcadm позволяет включить, выключить, переместить и перезапустить службы высокой доступности на кластере. Подробная информация может быть найдена на странице помощи clusvcadm(8).

1.10. Графический интерфейс администрирования виртуального сервера Linux

В данной секции будет рассмотрена утилита Piranha, которая служит для конфигурации LVS. Piranha предоставляет графический интерфейс, обеспечивающий организованный подход к созданию файла конфигурации /etc/sysconfig/ha/lvs.cf.
Piranha доступна, если на активном маршрутизаторе LVS выполняется служба piranha-gui. Эту утилиту можно открыть локально или удаленно в веб-браузере. Для локального доступа используйте адрес http://localhost:3636. Для удаленного доступа используйте действительный IP-адрес с последующим указанием :3636, плюс вам понадобится установить соединение ssh к активному маршрутизатору LVS в качестве пользователя root.
Starting the Piranha Configuration Tool causes the Piranha Configuration Tool welcome page to be displayed (refer to Рисунок 1.29, «The Welcome Panel»). Logging in to the welcome page provides access to the four main screens or panels: CONTROL/MONITORING, GLOBAL SETTINGS, REDUNDANCY, and VIRTUAL SERVERS. In addition, the VIRTUAL SERVERS panel contains four subsections. The CONTROL/MONITORING panel is the first panel displayed after you log in at the welcome screen.
The Welcome Panel

Рисунок 1.29. The Welcome Panel

Далее будут вкратце рассмотрены страницы конфигурации Piranha.

1.10.1. CONTROL/MONITORING

Панель CONTROL/MONITORING отображает состояние демона pulse, таблицы маршрутизации LVS и процессов nanny.
The CONTROL/MONITORING Panel

Рисунок 1.30. The CONTROL/MONITORING Panel

Auto update
Активирует автоматическое обновление экрана состояния каждые 10 секунд (по умолчанию). Интервал времени может быть изменен в поле Update frequency in seconds.
Не рекомендуется задавать интервал менее 10 секунд, так как при этом будет сложнее модифицировать интервал Auto update вследствие частого обновления страницы. Если вы столкнулись с такой проблемой, щелкните на любой другой панели, затем вернитесь на панель CONTROL/MONITORING.
Update information now
Ручное обновление статуса.
CHANGE PASSWORD
При нажатии этой кнопки будет отображен экран помощи с информацией о том, как изменить административный пароль Piranha.

1.10.2. GLOBAL SETTINGS

The GLOBAL SETTINGS panel is where the LVS administrator defines the networking details for the primary LVS router's public and private network interfaces.
The GLOBAL SETTINGS Panel

Рисунок 1.31. The GLOBAL SETTINGS Panel

The top half of this panel sets up the primary LVS router's public and private network interfaces.
Primary server public IP
Действительный IP-адрес основного узла LVS, доступный извне.
Primary server private IP
Действительный IP-адрес альтернативного сетевого интерфейса основного узла LVS. Этот адрес используется лишь как дополнительный канал обмена тактовыми импульсами с резервным маршрутизатором.
Use network type
Тип маршрутизации. По умолчанию используется NAT.
The next three fields are specifically for the NAT router's virtual network interface connected the private network with the real servers.
NAT Router IP
Частный «плавающий» IP-адрес, который используется в качестве шлюза для настоящих серверов.
NAT Router netmask
If the NAT router's floating IP needs a particular netmask, select it from drop-down list.
NAT Router device
Имя устройства сетевого интерфейса для «плавающего» IP-адреса (например, eth1:1).

1.10.3. REDUNDANCY

На панели REDUNDANCY можно настроить резервный узел маршрутизатора LVS и определить параметры наблюдения за обменом тактовыми импульсами.
The REDUNDANCY Panel

Рисунок 1.32. The REDUNDANCY Panel

Redundant server public IP
Открытый, действительный IP-адрес резервного маршрутизатора LVS.
Redundant server private IP
The backup router's private real IP address.
Остальные параметры помогают настроить канал обмена тактовыми импульсами, который используется резервным узлом для слежения за основным узлом на случай его сбоя.
Heartbeat Interval (seconds)
Задает интервал (в секундах) между тактовыми импульсами, целью которых является проверка работы основного узла LVS.
Assume dead after (seconds)
Если главный узел LVS не отвечает в течение заданного интервала (в секундах), то резервный узел LVS инициирует процесс восстановления.
Heartbeat runs on port
Определяет порт, используемый для взаимодействия с главным узлом LVS. Если поле оставлено пустым, используется порт 539.

1.10.4. VIRTUAL SERVERS

На панели VIRTUAL SERVERS отображается информация обо всех определенных в данный момент виртуальных серверах. Каждая запись в таблице содержит данные состояния виртуального сервера, его имя, назначенный ему виртуальный IP-адрес, номер порта, к которому обращается служба, используемый протокол и интерфейс.
The VIRTUAL SERVERS Panel

Рисунок 1.33. The VIRTUAL SERVERS Panel

Все отображаемые на панели VIRTUAL SERVERS серверы могут быть настроены на последующих экранах (подсекциях).
Чтобы добавить службу, нажмите кнопку ADD. Чтобы удалить службу, выберите ее и нажмите кнопку DELETE.
Для активации/ деактивации виртуального сервера выберите его и нажмите (DE)ACTIVATE.
Добавив виртуальный сервер, можно выполнить его настройку: для этого выберите его и нажмите кнопку EDIT для отображения подсекции VIRTUAL SERVER.

1.10.4.1. Подсекция VIRTUAL SERVER

The VIRTUAL SERVER subsection panel shown in Рисунок 1.34, «The VIRTUAL SERVERS Subsection» allows you to configure an individual virtual server. Links to subsections related specifically to this virtual server are located along the top of the page. But before configuring any of the subsections related to this virtual server, complete this page and click on the ACCEPT button.
The VIRTUAL SERVERS Subsection

Рисунок 1.34. The VIRTUAL SERVERS Subsection

Name
Имя, идентифицирующее виртуальный сервер. Это имя НЕ является именем узла машины, поэтому рекомендуется сделать его как можно более наглядным. Даже можно включить имя протокола (например, HTTP), используемого виртуальным сервером.
Application port
Номер прослушиваемого службой порта.
Protocol
Позволяет выбрать протокол (UDP или TCP) из выпадающего списка.
Virtual IP Address
The virtual server's floating IP address.
Virtual IP Network Mask
Выпадающее меню для выбора маски сети виртуального сервера.
Firewall Mark
Целое значение метки межсетевого экрана при объединении протоколов с несколькими портами или при создании виртуального сервера с различными, но связанными каналами.
Device
Имя сетевого устройства, к которому будет привязан «плавающий» IP-адрес, заданный в поле Virtual IP Address.
Следует связать открытый «плавающий» адрес с интерфейсом Ethernet, подключенным к открытой сети.
Re-entry Time
Целое значение, которое определяет интервал времени (в секундах), до того как активный маршрутизатор LVS попытается использовать реальный сервер после сбоя сервера.
Service Timeout
Целое значение, которое определяет интервал времени (в секундах), по истечению которого реальный сервер будет считаться недоступным.
Quiesce server
При выборе опции Quiesce server, если реальный сервер переходит в онлайн, содержимое таблицы least-connections будет сброшено в ноль, при этом активный маршрутизатор LVS обрабатывает запросы, как будто все действительные серверы были заново добавлены в кластер. Эта опция позволяет избежать перегрузки нового сервера большим количеством соединений при его включении в кластер.
Load monitoring tool
Маршрутизатор LVS может наблюдать за нагрузкой на различных серверах с помощью rup или ruptime. При выборе rup каждый реальный сервер будет выполнять службу rstatd. Если же вы выберете ruptime, то будет выполняться служба rwhod.
Scheduling
Выберите предпочитаемый алгоритм из выпадающего меню. По умолчанию используется метод Weighted least-connection.
Persistence
Используется, если необходимо сохранять постоянство подключений к виртуальному серверу при его взаимодействии с клиентом. Введите интервал времени (в секундах), по истечению которого соединение будет остановлено.
Persistence Network Mask
Из выпадающего меню выберите маску сети, чтобы ограничить сохранение постоянства подключений пределами конкретной подсети.

1.10.4.2. Подсекция REAL SERVER

Нажав на ссылку REAL SERVER, вы перейдете к подсекции EDIT REAL SERVER, где отображается статус узлов физического сервера для заданной виртуальной службы.
The REAL SERVER Subsection

Рисунок 1.35. The REAL SERVER Subsection

Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Рисунок 1.36, «The REAL SERVER Configuration Panel».
The REAL SERVER Configuration Panel

Рисунок 1.36. The REAL SERVER Configuration Panel

Панель содержит три поля:
Name
Описательное имя реального сервера.

Примечание

Это имя НЕ является именем узла машины, поэтому рекомендуется сделать его как можно более наглядным.
Address
The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number.
Weight
An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers.

1.10.4.3. EDIT MONITORING SCRIPTS Subsection

Нажмите ссылку MONITORING SCRIPTS в верхней части страницы. Вы перейдете к подсекции EDIT MONITORING SCRIPTS, где администратор может определить последовательность отправки и ожидания строк для проверки функциональности служб виртуального сервера на каждом реальном сервере. Здесь также можно указать отдельные сценарии для тестирования служб, работающих с динамически изменяемыми данными.
The EDIT MONITORING SCRIPTS Subsection

Рисунок 1.37. The EDIT MONITORING SCRIPTS Subsection

Sending Program
Введите путь к сценарию проверки службы, чтобы обеспечить возможность более детальной проверки. Эта функция особенно важна для служб, работающих с динамически изменяемыми данными (например, HTTPS, SSL).
Чтобы иметь возможность использования этой функции, необходимо написать сценарий, который в результате исполнения вернет текст, и ввести путь к нему в поле Sending Program.

Примечание

Если поле содержит указание внешней программы, то поле Send будет проигнорировано.
Send
Строка, которую демон nanny будет отправлять каждому реальному серверу. По умолчанию его содержимое настроено для HTTP. Если вы оставите поле пустым, nanny попытается открыть порт и решит, что служба выполняется, если порт открыт успешно.
Поле может содержать только одну отправляемую последовательность, которая, в свою очередь, может содержать Escape-последовательности и ASCII:
  • \n — новая строка.
  • \r — возврат каретки.
  • \t — символ табуляции.
  • \ — конвертирует последующий символ в Escape-последовательность.
Expect
Текст ответа, которые ожидается получить от сервера. Если вы написали собственную программу для отправки, введите соответствующий вариант ответа, который она отправит в случае успеха.

[1] Виртуальный сервер -- служба, настроенная на прослушивание заданного виртуального IP.

Глава 2. Обзор компонентов Red Hat Cluster Suite

Эта глава содержит обзор компонентов Red Hat Cluster Suite и включает следующие секции:

2.1. Компоненты кластера

Таблица 2.1, «Компоненты программных подсистем Red Hat Cluster Suite» summarizes Red Hat Cluster Suite components.

Таблица 2.1. Компоненты программных подсистем Red Hat Cluster Suite

Назначение Компоненты Описание
Conga luci Удаленное управление системой — Управляющая станция.
ricci Удаленное управление системой — Управляемая станция.
Cluster Configuration Tool system-config-cluster Графическая утилита управления настройками кластера.
Менеджер логических томов кластера (CLVM, Cluster Logical Volume Manager) clvmd Этот демон передает обновления метаданных LVS участникам кластера. Он должен выполняться на всех узлах кластера, в противном случае будет отображена ошибка.
lvm Утилиты командной строки для работы с LVM2.
system-config-lvm Графический интерфейс для LVM2.
lvm.conf Файл конфигурации LVM (/etc/lvm/lvm.conf.).
Система конфигурации кластера (CSS, Cluster Configuration System) ccs_tool ccs_tool является частью системы конфигурации кластера (CCS, Cluster Configuration System). Кроме того, ccs_tool может использоваться для выполнения онлайн-обновлений файлов конфигурации из архивов CCS, созданных в GFS 6.0 (или более ранних версиях) в формат XML, использующийся в данном выпуске Red Hat Cluster Suite.
ccs_test Команда диагностики и тестирования, используемая для получения информации из файлов конфигурации с помощью ccsd.
ccsd Демон CCS исполняется на всех кластерных узлах и предоставляет данные файла конфигурации программному обеспечению кластера.
cluster.conf Файл конфигурации кластера (/etc/cluster/cluster.conf).
Менеджер кластера (CMAN, Cluster Manager) cman.ko Модуль ядра для CMAN.
cman_tool Административный интерфейс CMAN, с помощью которого можно запускать и останавливать CMAN, а также изменять некоторые внутренние параметры.
dlm_controld Демон, запускаемый сценарием инициализации cman. Предназначен для управления dlm и не используется напрямую пользователем.
gfs_controld Демон, запускаемый сценарием инициализации cman. Предназначен для управления gfs и не используется напрямую пользователем.
group_tool Используется для получения списка групп (изолирование, DLM, GFS), а также отладочной информации. Включает функции, которые в RHEL4 исполняли службы cman_tool.
groupd Демон, запускаемый сценарием инициализации cman. Предназначен для взаимодействия openais/cman и dlm_controld/gfs_controld/fenced и не используется напрямую пользователем.
libcman.so.<version number> Библиотека для приложений, взаимодействующих с cman.ko.
Менеджер группы ресурсов (rgmanager) clusvcadm Команда, которая позволяет вручную активировать, деактивировать, переместить и перезапустить пользовательские службы на кластере.
clustat Команда отображения состояния кластера, включая информацию об участвующих узлах и выполняющихся службах.
clurgmgrd Демон, управляющий пользовательскими запросами запуска, остановки, перемещения и перезапуска служб.
clurmtabd Демон для работы с таблицами монтирования кластерной NFS.
Изолирование fence_apc Изолирующий агент для блоков питания APC.
fence_bladecenter Изолирующий агент для IBM Bladecenters с интерфейсом Telnet.
fence_bullpap Изолирующий агент для интерфейса Bull Novascale Platform Administration Processor (PAP).
fence_drac Изолирующий агент для карт удаленного доступа Dell.
fence_ipmilan Изолирующий агент для интерфейса IPMI (Bull Novascale Intelligent Platform Management Interface), подключаемого в LAN.
fence_wti Изолирующий агент для для переключателя питания WTI.
fence_brocade Изолирующий агент для переключателя Brocade Fibre Channel.
fence_mcdata Изолирующий агент для переключателя McData Fibre Channel.
fence_vixel Изолирующий агент для переключателя Vixel Fibre Channel.
fence_sanbox2 Изолирующий агент для переключателя SANBox2 Fibre Channel.
fence_ilo Изолирующий агент для интерфейсов HP ILO (раньше назывался fence_rib).
fence_rsa Агент ограничения ввода/ вывода для IBM RSA II.
fence_gnbd Изолирующий агент, используемый с хранилищем GNBD.
fence_scsi Изолирующий ввод/ вывод агент для SCSI.
fence_egenera Изолирующий агент, используемый с системой Egenera BladeFrame.
fence_manual Изолирующий агент, используемый для ручной настройки. Замечание: Этот компонент не поддерживается в критических окружениях.
fence_ack_manual Интерфейс пользователя для работы с агентом fence_manual.
fence_node Программа, осуществляющая ограничение ввода/ вывода для одного узла.
fence_xvm Агент ограничения ввода/ вывода для виртуальных машин Xen.
fence_xvmd Узел ограничивающего ввод/ вывод агента для виртуальных машин Xen.
fence_tool Программа для входа и выхода из изолируемого домена.
fenced Демон, ограничивающий ввод/ вывод.
DLM libdlm.so.<version number> Библиотека для поддержки менеджера DLM (Distributed Lock Manager).
GFS gfs.ko Модуль ядра для работы с файловой системой GFS. Загружается на GFS-узлы кластера.
gfs_fsck Команда проверки несмонтированной GFS.
gfs_grow Команда, с помощью которой можно увеличивать размер смонтированной файловой системы GFS.
gfs_jadd Команда добавления журналов к смонтированной файловой системе GFS.
gfs_mkfs Команда создания на накопителе файловой системы GFS.
gfs_quota Команда управления квотами в смонтированной файловой системе GFS.
gfs_tool Команда конфигурации файловой системы GFS. С ее помощью также можно осуществлять сбор информации о файловой системе.
mount.gfs Помощник монтирования, вызываемый командой mount(8); не используется пользователем напрямую.
GNBD gnbd.ko Модуль ядра, который позволяет активировать драйвер устройств GNBD на клиентах.
gnbd_export Команда для создания, экспорта и управления GNBD на сервере GNBD.
gnbd_import Команда импортирования и управления GNBD на клиенте GNBD.
gnbd_serv Демон сервера, позволяющий экспорт локального хранилища узла по сети.
LVS pulse This is the controlling process which starts all other daemons related to LVS routers. At boot time, the daemon is started by the /etc/rc.d/init.d/pulse script. It then reads the configuration file /etc/sysconfig/ha/lvs.cf. On the active LVS router, pulse starts the LVS daemon. On the backup router, pulse determines the health of the active router by executing a simple heartbeat at a user-configurable interval. If the active LVS router fails to respond after a user-configurable interval, it initiates failover. During failover, pulse on the backup LVS router instructs the pulse daemon on the active LVS router to shut down all LVS services, starts the send_arp program to reassign the floating IP addresses to the backup LVS router's MAC address, and starts the lvs daemon.
lvsd Демон lvs будет запущен на активном маршрутизаторе LVS процессом pulse. lvs считывает файл конфигурации /etc/sysconfig/ha/lvs.cf, вызывает утилиту ipvsadm для создания и поддержки таблицы маршрутизации IPVS и сопоставляет каждой настроенной службе LVS процесс nanny. Если nanny сообщает, что действительный сервер не работает, то по указанию lvs утилита ipvsadm удалит этот сервер из таблицы маршрутизации IPVS.
ipvsadm Эта служба обновляет в ядре таблицу маршрутизации IPVS. Демон lvs осуществляет настройку и управление LVS посредством вызова ipvsadm для добавления, изменения или удаления записей в таблице маршрутизации IPVS.
nanny Демон мониторинга nanny выполняется на активном маршрутизаторе LVS. С его помощью определяется текущее состояние всех действительных серверов и их нагрузка. Для каждой службы на отдельном сервере исполняется отдельный процесс.
lvs.cf Файл конфигурации LVS (/etc/sysconfig/ha/lvs.cf). Все демоны получают информацию конфигурации из этого файла, напрямую или косвенно.
Piranha Configuration Tool Веб-утилита наблюдения, конфигурации и администрирования LVS, используемая по умолчанию для поддержки файла конфигурации /etc/sysconfig/ha/lvs.cf.
send_arp Эта программа отправляет широковещательные сообщения ARP, если «плавающий» IP-адрес в процессе восстановления переносится с одного узла на другой.
Кворум диска qdisk Демон кворума диска для CMAN/ Linux-Cluster.
mkqdisk Утилита кворума диска.
qdiskd Демон кворума диска.

2.2. Страницы помощи

В данной секции рассмотрены страницы помощи, имеющие отношение к Red Hat Cluster Suite.
  • Инфраструктура кластера
    • ccs_tool (8): Используется для онлайн-обновлений файлов конфигурации CCS
    • ccs_test (8): Утилита диагностики для работающей системы CCS (Cluster Configuration System)
    • ccsd (8): Демон доступа к файлам конфигурации кластера CCS
    • ccs (7): Система конфигурации кластера
    • cman_tool (8): Утилита администрирования кластера
    • cluster.conf [cluster] (5): Файл конфигурации продуктов кластера
    • qdisk (5): Демон кворума (на диске) для CMAN / Linux-Cluster
    • mkqdisk (8): Утилита кворума диска
    • qdiskd (8): Демон кворума диска
    • fence_ack_manual (8): Программа, исполняемая оператором как часть ручного ограничения ввода/ вывода
    • fence_apc (8): Агент ограничения ввода/ вывода для APC MasterSwitch
    • fence_bladecenter (8): Агент ограничения ввода/ вывода для IBM Bladecenter
    • fence_brocade (8): Агент ограничения ввода/ вывода для переключателей Brocade FC
    • fence_bullpap (8): Агент ограничения ввода/ вывода для архитектуры Bull FAME, управляемой с помощью консоли PAP
    • fence_drac (8): Изолирующий агент для карт удаленного доступа Dell
    • fence_egenera (8): Агент ограничения ввода/ вывода для Egenera BladeFrame
    • fence_gnbd (8): Агент ограничения ввода/ вывода для GFS-кластеров на основе GNBD
    • fence_ilo (8): Агент ограничения ввода/ вывода для карт HP Integrated Lights Out
    • fence_ipmilan (8): Агент ограничения ввода/ вывода для машин, которые находятся под управлением IPMI по LAN.
    • fence_manual (8): Программа, которую исполняет демон fenced в процессе ручного ограничения ввода/ вывода
    • fence_mcdata (8): Агент ограничения ввода/ вывода для переключателей McData FC
    • fence_node (8): Программа ограничения ввода/ вывода на одном узле
    • fence_rib (8): Агент ограничения ввода/ вывода для карт Compaq Remote Insight Lights Out
    • fence_rsa (8): Агент ограничения ввода/ вывода для IBM RSA II
    • fence_sanbox2 (8): Агент ограничения ввода/ вывода для переключателей QLogic SANBox2 FC
    • fence_scsi (8): Агент ограничения ввода/ вывода для сохраняемых соответствий SCSI
    • fence_tool (8): Программа подключения и отключения от изолированного домена
    • fence_vixel (8): Агент ограничения ввода/ вывода для переключателей Vixel FC
    • fence_wti (8): Агент ограничения ввода/ вывода для сетевого переключателя питания WTI
    • fence_xvm (8): Агент ограничения ввода/ вывода для виртуальных машин Xen
    • fence_xvmd (8): Агент ограничения ввода/ вывода для виртуальных машин Xen
    • fenced (8): Демон ограничения ввода/ вывода
  • Управление службами высокого доступа
    • clusvcadm (8): Утилита администрирования пользовательских служб кластера
    • clustat (8): Утилита состояния кластера
    • Clurgmgrd [clurgmgrd] (8): Демон менеджера группы ресурсов
    • clurmtabd (8): Демон таблицы удаленного монтирования по NFS
  • GFS
    • gfs_fsck (8): Оффлайн-проверка файловой системы GFS
    • gfs_grow (8): Расширение файловой системы GFS
    • gfs_jadd (8): Добавление журналов в файловую систему GFS
    • gfs_mount (8): Опции монтирования GFS
    • gfs_quota (8): Работа с дисковыми квотами GFS
    • gfs_tool (8): Интерфейс к вызовам gfs ioctl
  • Менеджер логических томов кластера
    • clvmd (8): Демон LVM
    • lvm (8): Утилиты LVM2
    • lvm.conf [lvm] (5): Файл конфигурации LVM2
    • lvmchange (8): Изменение атрибутов менеджера логических томов
    • pvcreate (8): Инициализация диска или раздела для LVM
    • lvs (8): Вывод сведений о логических томах
  • GNBD (Global Network Block Device)
    • gnbd_export (8): Интерфейс для экспорта устройств GNBD
    • gnbd_import (8): Манипулирование блочными устройствами GNBD на клиенте
    • gnbd_serv (8): Демон gnbd для сервера
  • LVS
    • pulse (8): Демон обмена тестовыми сообщениями для контроля состояния кластерных узлов
    • lvs.cf [lvs] (5): Файл конфигурации для LVS
    • lvscan (8): Сканирование всех дисков
    • lvsd (8): Демон контроля кластерных служб Red Hat
    • ipvsadm (8): Администрирование виртуального сервера Linux
    • ipvsadm-restore (8): Восстанавливает таблицу IPVS из stdin
    • ipvsadm-save (8): Сохраняет таблицу IPVS в stdout
    • nanny (8): Утилита для наблюдения за состоянием служб кластера
    • send_arp (8): Утилита для оповещения сети о новом соответствии IP-адреса и MAC-адреса

2.3. Совместимое оборудование

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

Приложение A. Revision History

История переиздания
Издание 3-7.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Издание 3-72012-07-18Anthony Towns
Rebuild for Publican 3.0
Издание 1.0-0Tue Jan 20 2008Paul Kennedy
Consolidation of point releases

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

C

cluster
displaying status, Cluster Status Tool
cluster administration
displaying cluster and service status, Cluster Status Tool
cluster component compatible hardware, Совместимое оборудование
cluster component man pages, Страницы помощи
cluster components table, Компоненты кластера
Cluster Configuration Tool
accessing, Cluster Configuration Tool
cluster service
displaying status, Cluster Status Tool
command line tools table, Текстовые утилиты администрирования
compatible hardware
cluster components, Совместимое оборудование
Conga
overview, Conga
Conga overview, Conga

F

feedback, Обратная связь

I

introduction, Введение
other Red Hat Enterprise Linux documents, Введение

L

LVS
direct routing
requirements, hardware, Прямая маршрутизация
requirements, network, Прямая маршрутизация
requirements, software, Прямая маршрутизация
routing methods
NAT, Методы маршрутизации
three tiered
high-availability cluster, Three-Tier LVS Topology

M

man pages
cluster components, Страницы помощи

N

NAT
routing methods, LVS, Методы маршрутизации
network address translation (см. NAT)

O

overview
economy, Red Hat GFS
performance, Red Hat GFS
scalability, Red Hat GFS

P

Piranha Configuration Tool
CONTROL/MONITORING, CONTROL/MONITORING
EDIT MONITORING SCRIPTS Subsection, EDIT MONITORING SCRIPTS Subsection
GLOBAL SETTINGS, GLOBAL SETTINGS
login panel, Графический интерфейс администрирования виртуального сервера Linux
necessary software, Графический интерфейс администрирования виртуального сервера Linux
REAL SERVER subsection, Подсекция REAL SERVER
REDUNDANCY, REDUNDANCY
VIRTUAL SERVER subsection, VIRTUAL SERVERS
Firewall Mark , Подсекция VIRTUAL SERVER
Persistence , Подсекция VIRTUAL SERVER
Scheduling , Подсекция VIRTUAL SERVER
Virtual IP Address , Подсекция VIRTUAL SERVER
VIRTUAL SERVERS, VIRTUAL SERVERS

R

Red Hat Cluster Suite
components, Компоненты кластера

T

table
cluster components, Компоненты кластера
command line tools, Текстовые утилиты администрирования

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

Copyright © 2009 Red Hat, Inc.
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.