Введение

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

Собственно ПО

Поясню выбор ПО и, собственно, для чего это все делается.

1. Чтобы поднять кластер из соединенных между собой каналами связи серверов,
необходимо установить некоторые службы для централизованного управления
ресурсами, а также использовать кластерную ФС для организации общего хранилища.
В случае, если используется ОС от RedHat, сюда входят:

- CMAN - или cluster manager - служба управления кластером. демон, который
соединяет и отсоединяет узлы от кластера. Выполняется на каждой ноде;

- CCSD - это демон, который обеспечивает доступ к файлу
конфигурации(cluster.conf) другим кластерным приложениям. Выполняется на каждом узле;

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

- GFS2 в качестве кластерной ФС.

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

- DRBD. По сути, сетевой RAID1. Используется для репликации данных. Таким
образом данные всегда доступны при отказе одного из узлов. Начиная с версии 8,
DRBD позволяет организовать работу всех устройств в режиме "primary", в отличае
от предыдущих версий, где primary устройство было единственное.

- HeartBeat. Механизизм "сердцебиения". Эта служба "наблюдает" за узлами, и, в
случае, отказа одного из них, передает задачу другому, рабочему узлу. Таким
образом, достигается доступность сервисов.

3. Чтобы поднять файловый сервер на данном кластере и использовать его для
Windows-клиентов, необходимо использовать Samba'у. Текущая версия Samba не
поддерживает развертывание её на кластере из-за свеобразного механизма работы.

Поясню: Samba использует легковесную базу данных (TDB) для приведения
соответствия Windows SID к Unix UID/GID (таблицы ID-мэппинга), хранения данных
об открытых сессиях (session.tdb), таблицу блокировок файловой системы
(locking.tdb), а также ряд других параметров.

Если использовать классическую конфигурацию на кластере "как есть", получим
следующее: На каждом узле работает свой демон smbd и каждый узел имеет свою
копию TDB, причем эти TDB никак не связаны между собой и не имеют механизма
взаимодействия. Это и является проблемой. Необходимо, чтобы все узлы кластера
"знали" в каждый момент времени некоторые значения из всех TDB. Ключевым здесь
является - locking.tdb и session.tdb. Для этих целей и используется CTDB.

CTDB преобразует стандартный механизм работы Samba с TDB: все локальные
locking.tdb и session.tdb - преобразуются в распределенную базу данных, таблицы
ID-мэппинга остаются под управлением локальных демонов smbd. CTDB также
осуществляет управление демонами smbd и производит передачу управления демоном
smbd в случае отказа узла.

Подведем некоторые итоги

Имеем следующее:

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

- за её работу отвечает CTDB. Данные хранятся на локальных дисках,
реплицируются с помощью DRBD, доступ к ним может осуществляться одновременно
обоими узлами кластера(для этого и нужна кластерная ФС - GFS2).

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

Служба HeartBeat в данном случае не используется, так как CTDB выполняет эти
функции для Samba-сервера.

В результате, получим: высокопроизводительный файловый сервер, обеспечивающий
100%-ю целостность данных и непрырывность предоставляемых сервисов.

Установка, настройка и запуск

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

Для начала собираем CTDB из исходных текстов

       cd ctdb
       ./autogen.sh
       ./configure
       make
       make install


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

1. Создать файл /etc/sysconfig/ctdb.sysconfig:

       CTDB_RECOVERY_LOCK="/synchronized/lock"
       CTDB_PUBLIC_INTERFACE=eth0
       CTDB_PUBLIC_ADDRESSES=/usr/local/etc/ctdb/public_addresses
       CTDB_MANAGES_SAMBA=yes
       CTDB_INIT_STYLE=redhat
       CTDB_NODES=/usr/local/etc/ctdb/nodes
       CTDB_LOGFILE=/var/log/log.ctdb

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

CTDB_RECOVERY_LOCK="/synchronized/lock" - этот параметр описывает
месторасположение файла, в котором хранится записи о том, какой из узлов
является мастером восстановления. Файл lock должен располагаться на общем
хранилище и быть доступным всем нодам,использующим CTDB.

CTDB_PUBLIC_INTERFACE=eth0 - этот параметр описывает сетевой интерфейс, на
котором в данный момент времени поднято сетевое соединение.

CTDB_PUBLIC_ADDRESSES=/usr/local/etc/ctdb/public_addresses - этот параметр
определяет файл, содержащий список IP-адресов, по которым клиенты, использующие
Samba для доступа к файловым ресурсам, посылают запросы на соединение.
Распределением этих адресов по нодам занимается CTDB.

CTDB_MANAGES_SAMBA=yes - этот параметр определяет, будет ли CTDB управлять
запуском  Samba-сервера вместо стандартных сценариев управления, которые
реализует операционная система.

CTDB_INIT_STYLE=redhat - этот параметр описывает сценарии запуска служб для
различных операционных систем.

CTDB_NODES=/usr/local/etc/ctdb/nodes - этот параметр определяет файл, в котором
хранится информация об узлах кластера.

CTDB_LOGFILE=/var/log/log.ctdb - этот параметр определяет лог-    файл,
использующийся службой CTDB.

2.  Создать файл /usr/local/etc/ctdb/nodes:

       192.168.1.1
       192.168.1.2

Здесь IP-адрес 192.168.1.1 принадлежит первой ноде, IP-адрес 192.168.1.2 - второй.

3. Создать файл /usr/local/etc/ctdb/public_addresses:

       192.168.0.200/24 eth0

Это IP-адрес, за которым в DNS сервере закреплено доменное имя Samba-сервера.


Далее собираем самбу

       cd samba-3.3.8/source
       ./autogen.sh
       ./configure --with-ctdb=/usr/src/ctdb --with-cluster-support \
          --enable-pie=no --with-shared-modules=idmap_tdb2
       make
       make install

/usr/src/ctdb - каталог с исходными текстами CTDB, установленными ранее.

Правим smb.conf

Эти два параметра обязательно надо добавить в global. Остальное, по Вашим запросам.

       clustering = Yes
       idmap backend = tdb

Запуск Samba

Сначала запускаем CTDB на всех узлах кластера.

       /usr/local/sbin/ctdbd

Проверяем, запустилось ли.

       ctdb status

Если все конфигурационные файлы корректны,будет такое:

       Number of nodes:2
       pnn:0 192.168.1.1      OK (THIS NODE)
       pnn:1 192.168.1.2      OK
       Generation:1087563258
       Size:2
       hash:0 lmaster:0
       hash:1 lmaster:1
       Recovery mode:NORMAL (0)
       Recovery master:0

Проверяем для начала параметры smb.conf

       /usr/local/samba/bin/testparm

       Load smb config files from /usr/local/samba/etc/smb.conf
       Processing section "[public]"
       Loaded services file OK.
       Server role: ROLE_STANDALONE

Запускаем самбу:

       /usr/local/samba/sbin/smbd -D
       /usr/local/samba/sbin/smbd -D

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

Тестирование

Для сравнения производительности Samba-сервера с использованием CTDB и без
использования CTDB, а также возможностей файловой системы (общего хранилища)
используется ряд тестовых модулей.

Скорость чтения данных

Чтение(MB/sec)
Клиент
1
2
3
4
Samba без CTDB
2,15
2,16
2,13
2,09
Samba + CTDB
24,73
23,42
23,26
23,15

Сервер был доступен по кналу 1 Гб/с, поэтому суммарно использовано около 75%
пропускной способности.

Скорость записи идентична, не намного уступает, определяется скорее возможностями файловой системы.
Замечу, что с ростом узлов (до 8) скорость доступа к данным (скорость
чтения/записи) стремительно растет.


Заключение

Предложенный вариант кластеризации Samba позволяет достичь некоторых результатов:
1. Высокая надежность и отказоустойчивость (читайте про CTDB). Потеря данных исключена.
2. Показатели производительности по сравнению с 1-серверными системами отличные.

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

Список источников

* http://ctdb.samba.org
* http://wiki.samba.org/index.php/Clustered_Samba