NAS-сервис веб-кластера на базе NFS, SMB/CIFS

Если веб-кластер создается на двух нодах, на одной ноде запустите сервер NFS/CIFS и обращайтесь к хранимым на нем файлам с других нод веб-кластера.

Для увеличения производительности организуйте выделенный NFS/CIFS сервер, оптимизированный исключительно под файловые операции, используемый всеми нодами веб-кластера. Для достижения большей производительности и надежности общего файлового хранилища веб-кластера рекомендуется обратить внимание на технологии: OCFS, GFS, Lustre, DRBD, SAN, GFS (GlusterFS).

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

  Синхронизация данных между серверами

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

Существует множество инструментов, позволяющих решить эту задачу, начиная с простых утилит копирования файлов (ftp, scp) и заканчивая специализированным ПО для синхронизации данных между серверами (rsync, unison). Рассмотрим два варианта.

lsyncd

Если вы используете виртуальную машину BitrixVM, то в ней используется утилита lsyncd. Описание настроек этой утилиты приводится в курсе "Виртуальная машина".

Пример этих настроек можно взять за основу настройки lsyncd и на других окружениях.

csync2

Также в других окружениях можно использовать утилиту csync2, которая ранее использовалась в штатной BitrixVM до версии 7.0. csync2 предоставляет хорошие возможности:

• Высокая скорость работы.
• Низкое потребление ресурсов (CPU, дисковые операции). Два этих фактора позволяют запускать процесс синхронизации максимально часто, поэтому данные на серверах становятся идентичными практически в "реальном времени".
• Простота настройки для обмена данными между любым количеством серверов.
• Возможность синхронизации удаления файлов.
• Защищенный обмен данными между хостами (SSL).

Подробная документация по использованию и конфигурированию csync2 доступна на официальном сайте разработчика: http://oss.linbit.com/csync2/. Мы же рассмотрим пример конкретной конфигурации для двух веб-серверов в кластере.

В некоторых дистрибутивах Linux (например, в Ubuntu) csync2 уже присутствует в репозиториях и доступен для установки из пакетов. Для CentOS это, к сожалению, не так, поэтому необходимо рассмотреть иные варианты установки (сборка из исходников, установка из доступных rpm).

Один из возможных вариантов установки:

1. Устанавливаем необходимые доступные пакеты (библиотеки rsync используются в csync2, из xinetd будет запускаться серверная часть csync2):

   # yum install rsync librsync-devel xinetd
   

2. Устанавливаем libtasn1 - библиотеку для работы с X.509 (требуется для csync2):

   # wget http://ftp.freshrpms.net/redhat/testing/EL5/cluster/x86_64/libtasn1-1.1-1.el5/libtasn1-1.1-1.el5.x86_64.rpm 
   # wget http://ftp.freshrpms.net/redhat/testing/EL5/cluster/x86_64/libtasn1-1.1-1.el5/libtasn1-devel-1.1-1.el5.x86_64.rpm 
   # wget http://ftp.freshrpms.net/redhat/testing/EL5/cluster/x86_64/libtasn1-1.1-1.el5/libtasn1-tools-1.1-1.el5.x86_64.rpm 
   # rpm -ihv libtasn1-1.1-1.el5.x86_64.rpm libtasn1-devel-1.1-1.el5.x86_64.rpm libtasn1-tools-1.1-1.el5.x86_64.rpm
   
   

3. Устанавливаем sqlite (2-ой версии) - именно эта версия используется в csync2:

   # wget http://ftp.freshrpms.net/redhat/testing/EL5/cluster/x86_64/sqlite2-2.8.17-1.el5/sqlite2-2.8.17-1.el5.x86_64.rpm 
   # wget http://ftp.freshrpms.net/redhat/testing/EL5/cluster/x86_64/sqlite2-2.8.17-1.el5/sqlite2-devel-2.8.17-1.el5.x86_64.rpm 
   # rpm -ihv sqlite2-2.8.17-1.el5.x86_64.rpm sqlite2-devel-2.8.17-1.el5.x86_64.rpm
   

4. Устанавливаем непосредственно csync2:

   # wget http://ftp.freshrpms.net/redhat/testing/EL5/cluster/x86_64/csync2-1.34-4.el5/csync2-1.34-4.el5.x86_64.rpm 
   # rpm -ihv csync2-1.34-4.el5.x86_64.rpm
   

5. После установки уже доступны сгенерированные SSL-сертификаты, однако, если их нужно сгенерировать заново, сделать это можно так:

   # openssl genrsa -out /etc/csync2/csync2_ssl_key.pem 1024 
   # openssl req -new -key /etc/csync2/csync2_ssl_key.pem -out /etc/csync2/csync2_ssl_cert.csr 
   # openssl x509 -req -days 600 -in /etc/csync2/csync2_ssl_cert.csr -signkey /etc/csync2/csync2_ssl_key.pem -out /etc/csync2/csync2_ssl_cert.pem
   

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

   # csync2 -k /etc/csync2/csync2.cluster.key
   

   Файл csync2.cluster.key на всех машинах должен быть одинаковым и должен быть размещен в /etc/csync2/.

   Пример конфигурационного файла /etc/csync2/csync2.cfg

   group cluster { host node1.demo-cluster.ru node2.demo-cluster.ru; key /etc/csync2/csync2.cluster.key; include /home/bitrix/www; exclude /home/bitrix/www/bitrix/php_interface/dbconn.php; auto younger; } где: host - адреса серверов, для которых синхронизируются данные; key - файл ключей; include - директория, файлы которой синхронизируются; exclude - исключения (не синхронизировать эти данные); auto - способ разрешения конфликтов в ситуациях, когда один и тот же файл был изменен на нескольких серверах одновременно; younger - приоритет имеет сервер, где были сделаны последние изменения.

7. Обратим особое внимание на директиву host.

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

   Поэтому имена машин, данные которых синхронизируются, не должны изменяться. Используйте файл /etc/hosts для указания постоянных IP для конкретных имен. Чтобы задать фиксированное имя для каждого сервера укажите его в каком-либо файле:

   # echo "node1.demo-cluster.ru" > /etc/hostname
   

   И в стартап-скрипте /etc/init.d/network предпоследней строкой (до exit) впишите:

   /bin/hostname -F /etc/hostname
   

8. Если изначально каждый новый сервер создается уже с копией данных с других серверов (например, в случае использования Amazon EC2 удобно сделать snapshot имеющегося instance, а затем подключить его для нового instance), то первая инициализация базы файлов для синхронизации выполняется с помощью команды:

   # csync2 -cIr
   

   Делается это на каждом хосте.

9. Работа csync2 на каждом хосте состоит из двух частей - серверной и клиентской. Для запуска серверной части закомментируйте (символом #) в файле /etc/xinetd.d/csync2 строку "disable = yes", перезапустите сервис xinetd и разрешите его запуск при загрузке системы:

   # service xinetd restart 
   # chkconfig xinetd on
   

10. Клиентская часть - запуск csync2 с ключом "-x".

    Определите (в зависимости от объема данных) необходимую частоту обновлений и пропишите запуск csync2, например, через cron. Строка в /etc/crontab:

    */5 * * * * root /usr/sbin/csync2 -x >/dev/null 2>&1
    

    ...означает запуск csync2 каждые 5 минут.