Lustre FS. Настраиваем и используем кластерную систему в промышленных масштабах. Часть II

 ВИТАЛИЙ БАНКОВСКИЙ

Lustre FS. Настраиваем и используем кластерную систему
в промышленных масштабах
Часть II

Продолжая цикл статей про кластерные системы, представляю следующую тему – повышение отказоустойчивости кластерной файловой системы Lustre.

В первой части статьи (см. №11 за 2008 г.) я описал процедуру установки и настройки кластерной файловой системы Lustre. На данный момент текущая версия ФС Lustre не поддерживает технологий избыточности информации (RAID, replication), поэтому при отключении какого-либо сервера с данными они будут недоступны клиентам.

В этой статье я расскажу, как можно повысить отказоустойчивость системы путем дублирования информации на серверах с данными. Для этого мы воспользуемся двумя известными проектами High-Availability Linux Project (Linux HA) и Distributed Replicated Block Device (DRBD).

Топология системы

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

Топология системы

Установка и настройка DRBD

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

Установка программы DRBD

В своей работе я использую CentOS, поэтому описание процедуры установки и настройки будет ориентировано на этот дистрибутив. Получаем последнюю версию программы DRBD (на момент написания была доступна версия 8.2.7 с сайта производителя http://www.drbd.org, раскрываем архив и устанавливаем программу:

tar -xzvf drbd-8.2.7.tgz

make KDIR=/usr/src/linux

make tools

make install

make install-tools

где переменная KDIR указывает на каталог с исходными текстами используемого ядра Linux.

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

Настройка DRBD

На этом этапе необходимо настроить репликацию данных между серверами oss1-a и oss1-b. Для этого в файл /etc/drbd.conf вносим следующие конфигурационные строки:

# Название нашего ресурса (диска)

resource r0 {

 

# Синхронный протокол репликации

protocol      C;

 

# Временные настройки

 startup { wfc-timeout 0; degr-wfc-timeout     120; }

 

# Отключать ресурс в случае сбоя диска

disk { on-io-error detach; }

 

# Ограничение скорости передачи данных между серверами Slave и Master

syncer { rate 10M; }

 

# Описание подсистемы на oss1-a

on oss1-a1.domain.com {

    # Путь к устройству хранилища DRBD

    device      /dev/drbd1;

    # Путь к физическому диску, где будут храниться

    # метаданные и сами данные сервиса DRBD

    disk        /dev/hda7;

    # IP-адрес первого сервера

    address     10.40.10.10:7791;

    # Указание, где будут храниться метаданные сервиса DRBD.

    # В данном случае я использовал внутренний объем

    # раздела, где хранятся данные.

    meta-disk   internal;

}


}

По аналогии создаем описание устройства DRBD в этом же файле для второго сервера oss1-b:

on oss1-b.domain.com

{

device /dev/drbd1;

disk /dev/sda7;

address 10.40.10.11:7791;

meta-disk /internal;

}

Копируем этот файл на сервер oss1-b.domain.com в каталог /etc.

Запуск сервиса DRBD и инициализация хранилищ

Перед инициализацией хранилищ DRBD необходимо запустить сервис drbd на обоих серверах:

/etc/init.d/drbd start

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

drbdadm create-md r0

Подключение раздела для данных к ресурсу:

drbdadm attach r0

Подключение сервисной части DRBD к ресурсу:

drbdadm connect r0

Затем запускаем синхронизацию с сервера oss1-a:

drbdadm -- --overwrite-data-of-peer primary r0

По умолчанию синхронизация может занять несколько дней, если данные не поступают в хранилище. У меня это заняло несколько дней, поэтому для ускорения я применил следующую команду на сервере oss1-a:

drbdadm adjust r0

Далее проверяем содержимое /proc/drbd, в котором должен быть виден прогресс синхронизации. По завершении репликация сервера oss1-a на oss1-b должна быть в состоянии Primary/Secondary:

cat /proc/drbd

Форматируем раздел /dev/drbd1 под файловую систему Lustre:

mkfs.lustre --reformat --ost --fsname=webstorage --mgsnode= mds.domain.com@tcp0 /dev/drbd1

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

Установка и настройка Linux HA

Перед установкой Linux HA необходимо проверить наличие пакетов разработчика: библиотека Perl LibNet, libgcrypt, gnutls, libgpg-error. Описание процесса установки этих пакетов выходит за рамки данной статьи, и я рекомендую обратиться к сопроводительной документации этих пакетов за подробными инструкциями. Также необходимо убедиться, что в ядре включены следующие опции: CONFIG_CONNECTOR (раздел Device Drivers) и CONFIG_CRYPTO_HMAC (раздел Cryptographic options).

Установка Linux HA

Домашняя страница проекта находится по адресу http://linux-ha.org. Загружаем архив последней версии программы Linux HA, раскрываем, проводим конфигурацию, компилируем и устанавливаем:

tar -xvf STABLE-2.1.4.tar

cd Heartbeat-STABLE-2-1-STABLE-2.1.4

./ConfigureMe configure

make

make install

При этом все настройки будут установлены в каталог /usr/local/etc/ha.d. Добавляем учетную запись пользователя hacluster и группу haclient согласно документации:

adduser hacluster

groupadd haclient

cp /usr/src/drbd-8.2.7/scripts/drbddisk /usr/local/etc/ha.d/resource.d/

Настройка Linux HA

Система настроек Linux HA состоит из трех файлов:

•  ha.cf – общие настройки;
•  haresources – настройка ресурсов;
•  authkeys – файл аутентификации.

Общие настройки

Находятся в файле /usr/local/etc/ha.d/ha.cf. Минимальный набор состоит из следующих строк:

# Порт, на котором будут приниматься сообщения от других серверов

udpport 694

# Способ оповещения других серверов. В данном случае — broadcast через интерфейс etho

bcast eth0

# Не использовать формат XML для настройки ресурсов.

# Использовать текстовый формат настроек

crm no

# Список серверов

node oss1-a.domain.com

node oss1-b.domain.com

# Временные настройки

keepalive 1

deadtime 3

hopfudge 1

# Включение режима failover

auto_failback on

# Включить использование системного syslog для лог-файлов

use_logd on

Настройка ресурсов

Файл /usr/local/etc/ha.d/haresources содержит список ресурсов, которые должны активизироваться на slave-сервере в случае отключения master-сервера. Описание каждого ресурса для типичного случая содержит компоненты:

•   имя master-сервера;
•  отказоустойчивый адрес-IP;
•  описание общей файловой системы;
•  список сервисов, которые должны быть запущены на активном сервере (не используются на серверах OSS, так как сервисы обычно запускаются на клиентах ФС Lustre).

В нашем случае строка ресурсов выглядит так:

oss1-a.domain.com 10.40.10.12/25/eth0 drbddisk::r0 Filesystem::/dev/drbd1::/mnt/ost1::lustre

Настройка файла аутентификации authkeys

Этот файл authkeys расположен в /usr/local/etc/had.d/ и содержит описание методов, которые используются для аутентификации сервера Slave на сервере Master и наоборот.

Формат записей следующий:

auth 1

1 sha1 your_password_here

где:

•   1 – номер ключа, ассоциированный с этой строкой;
•  sha1 – метод шифрования;
•  your_password_here – сам пароль в открытом виде.

Поддерживаются следующие алгоритмы шифрования:

• sha1 – SHA1-шифрование (используется ключ);
• md5 – проверка данных по MD5 (используется ключ);
• crc – простая проверка целостности через подсчет контрольной суммы.

Пример такого файла:

auth 1

1 md5 my_god_password_nobody_will_know

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

chmod 600 /etc/ha.d/authkeys

Запуск и тестирование подсистемы Linux HA

После того как все настроено, можно перейти к запуску и тестированию всей системы. Последовательно запускаем Linux HA на сервере oss1-a и oss1-b:

/etc/init.d/heartbeat start

По истечении нескольких секунд на сервере можно будет увидеть, что сервис Linux HA смонтировал раздел /dev/drbd1 на точку монтирования /mnt/ost1:

mount | grep drbd

Соответственно на сервере MDS в лог-файлах можно увидеть следующую строку:

где 10.40.10.12 – наш отказоустойчивый адрес IP (смотрите таблицу).

Описание ресурсов

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

Выключаем сервер oss1-a, ждем несколько минут и проверяем сервер oss1-b. Если все правильно настроено, то можем обнаружить, что наш «плавающий» IP появился на этом сервере. Также сервис DRBD находится в состоянии Master, и что файловая система Lustre смонтирована:

mount | grep drbd

Проверяем лог-файл на сервере MDS и обнаруживаем следующую строку:

Что означает, что сервер MDS удачно смог восстановить соединения с сервером OSS.

Примечание. В Linux HA есть механизм под названием STONITH, который может быть использован для принудительного выключения сбойного сервера. Этот механизм обычно используется в системах с совместным доступом к общему ресурсу, например Serial Attached Network (SAN). Но в данном случае каждый сервер имеет собственное хранилище, поэтому механизм не используется.

Финальные шаги

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

chkconfig drbd on

chkconfig heartbeat on

Теперь все.

1. http://wiki.lustre.org.
2. http://gazette.linux.ru.net/rus/articles/clusters.html.
3. http://xgu.ru/wiki/DRBD.

Комментарии могут оставлять только зарегистрированные пользователи