Создание отказоустойчивого кластера для биллинговой системы на базе Gentoo Linux

Все права защищены (c) 2001-2011 NetUP (www.netup.ru)
Перепечатка материалов разрешается только с предварительного разрешения
компании NetUP (info@netup.ru)

 

Обращаем ваше внимание на то, что информация в данной статье может быть не актуальной.

В настоящей документации рассматриваются вопросы создания отказоустойчивого кластера для работы с биллинговой системой NetUP UTM на базе двух физических серверов. В качестве операционной системы используется GentooLinux. База данных mysql.

Рисунок 1. Общая схема кластера

Каждый сервер укомплектован двумя сетевыми картами стандарта GigabitEthernetи двумя жесткими дисками одинакового размера.

Внутренние коммуникации между серверами осуществляются на внутренних сетевых картах, на скорости 1 Гбит/сек. При этом для большей надежности можно использовать «перевернутый» кабель (crossover) без промежуточного коммутатора. Внешние сетевые карты подключены в коммутатор и через них осуществляется связь кластера с остальной сетью. При этом для внешних устройств данный кластер доступен под одним общим адресом – 192.168.0.200. Этот адрес используется только одним сервером в один момент времени. Если на этом сервере произошел сбой, то адрес автоматически присваивается второму, резервному серверу и кластер доступен в прежнем режиме. Работу по определению сбоев осуществляет пакет heartbeat [2].

Сетевые настройки сервера 1:

Имя хоста: netup1
IP-адрес на внутренней сетевой карте. Интерфейс eth1: 172.16.0.1
IP-адрес на внешнем интерфейсе 192.168.0.200 (eth0:1). Настраивается автоматически пакетом heartbeat

Сетевые настройки сервера 2:

Имя хоста: netup2
IP-адрес на внутренней сетевой карте. Интерфейс eth1: 172.16.0.2
IP-адрес на внешнем интерфейсе 192.168.0.200 (eth0:1). Настраивается автоматически пакетом heartbeat.

Установка операционной системы GentooLinuxпроизводится на первый жесткий диск - /dev/sda. Второй жесткий диск - /dev/sdbбудет полностью использоваться для синхронизации данных между серверами средствами пакета drbd [1]. Установка этого пакета осуществляется командой:

emergedrbd

После успешной установки создайте конфигурационный файл /etc/drbd.conf следующего содержания:


resource r0 {
protocol C;
incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";

startup {
degr-wfc-timeout 120; # 2 minutes.
}

disk {
on-io-error detach;
}

net {
}

syncer {
rate 200M;
group 1;
al-extents 257;
}



on netup2 {
device /dev/drbd0;
disk /dev/sdb1;
address 172.16.0.2:7788;
meta-disk internal;
}

on netup1 {
device /dev/drbd0;
disk /dev/sdb1;
address 172.16.0.1:7788;
meta-disk internal;
}}

Пример конфигурационного файла с комментариями приведен в файле /usr/share/doc/drbd-0.7.11/drbd.conf.gz.

Согласно приведенным настройкам синхронизация данных будет осуществляться на разделе /dev/sdb1. При этом для доступа к этому разделу необходимо использовать устройство /dev/drbd0 в противном случае синхронизация данных осуществляться не будет.

Для запуска пакета drbdвыполните команду на обоих серверах:

/etc/init.d/drbdstart

На сервере 1 выполните команду:

drbdadm -- --do-what-I-say primary all

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

/etc/init.d/drbd status

Пример вывода данной команды:


drbd driver OK; device status:
version: 0.7.11 (api:77/proto:74)
SVN Revision: 1807 build by netup@netup1, 2006-01-17 00:52:49
0: cs:Connected st:Primary/Secondary ld:Consistent

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

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

mkreiserfs /dev/drbd0

mkdir /mnt/sync

на сервере 2 команду:

mkdir /mnt/sync

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

echo "sys-cluster/heartbeat ~x86" >> /etc/portage/package.keywords

emergesys-cluster/heartbeat

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

На сервере 1 файл /etc/ha.d/ha.cf следующего содержания:

logfacility     local0
ucast eth1 172.16.0.2
auto_failback on
node netup1 netup2

На сервере 2 файл /etc/ha.d/ha.cf следующего содержания:

logfacility     local0
ucast eth1 172.16.0.1
auto_failback on
node netup1 netup2

В этих файлах мы указали имена и IP-адреса серверов используемых в кластере. Далее необходимо создать конфигурационный файл /etc/ha.d/haresources следующего содержания:

netup1 192.168.0.200/24/eth0:1 drbddisk Filesystem::/dev/drbd0::/mnt/sync::reiserfs apache2 mysql utm5_core utm5_radius

При этом необходимо проконтролировать, что бы данный файл был одинакового содержания на обоих серверах. В данном файле мы указали внешний IP-адрес кластера – 192.168.0.200, маску подсети – 24 и интерфейс eth0:1, на котором использовать данный IP-адрес. Так же мы указали пакеты, которые необходимо запускать, когда данный сервер берет на себя роль ведущего сервера в кластере. Запуск сервисов осуществляется в том порядке, в котором они указаны в файле. Согласно приведенному файлу первым будет запущен пакет drbddisk, который переведет данный сервер в режим «ведущего» (Primary) для пакета drbd. После этого можно производить монтирование раздела /dev/drbd0. Данную операцию производит второй пакет – Filesystem. В параметрах данный пакет принимает указание на раздел - /dev/drbd0, директорию для монтирования - /mnt/sync и тип используемой файловой системы – reiserfs. Таким образом после старта этих двух пакетов директория /mnt/syncбудет содержать синхронизированные между двумя серверами данные. Записанные в эту директорию данные будут автоматически дублироваться на втором резервном сервере. В случае если на основном сервере произойдет сбой, то резервный сервер будет содержать абсолютно те же данные, что и основной сервер до сбоя.

Далее по списку будут запущены прикладные сервисы – веб-сервер apache2, сервер базы данных mysql, ядро биллинговой системы utm5_core, RADIUSсервер utm5_radius. Биллинговая система NetUPUTMво время работы делает запись биллинговой информации в базу данных mysql, поэтому для синхронизации этих данных необходимо переместить директорию /var/lib/mysqlна синхронизируемый раздел /mnt/sync. Данную операцию необходимо производить при остановленном сервисе mysql. Так же необходимо в конфигурационном файле /etc/mysql/my.cnf в разделе [mysqld] указать новый путь:

datadir = /mnt/sync/mysql

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

Для корректной работы пакета heartbeatтак же необходимо создать файл /etc/ha.d/authkeys с ключами для безопасной работы между серверами. В этом файле указывается тип ключа и сам ключ:

auth 1

1 sha1 somethinglong

Этот файл так же должен быть идентичен на обоих серверах в кластере.

На этом настройка пакета heartbeatзавершена и можно произвести его запуск на обоих серверах командой:

/etc/init.d/heartbeat start

Для проверки работоспособности кластера можно использовать утилиты ifconfig, df, ps. Сервер, который в настоящий момент является ведущим, должен иметь:

  1. настроенный интерфейс eth0:1 с IP-адресом 192.168.0.200
  2. смонтированную директорию /mnt/sync
  3. запущенные сервисы apache2, mysql, utm5_core, utm5_radius

Резервный сервер при этом не должен иметь вышеуказанные настройки. Для того, что бы резервный сервер стал основным необходимо остановить сервис heartbeatна основном сервере либо эмулировать аппаратный сбой физическим выключением основного сервера. При этом резервный сервер присваивает себе общий IP-адрес 192.168.0.1, монтирует директорию /mnt/syncи запускает сервисы apache2, mysql, utm5_core и utm5_radius. На тестовом стенде компании НетАП восстановление работы кластера после сбоя основного сервера не превышало 30 секунд. Таким образом, работа отказоустойчивого кластера позволяет минимизировать перебои в работе биллинговой системы и тем самым повысить сервис, предоставляемый абонентам.

Для автоматического запуска сервисов после перезагрузки сервера необходимо на обоих серверах выполнить команды:

rc-update add drbd default

rc-update add heartbeat default

Проблема синхронизации данных и ситуация "split-brain"

В случае если по какой-то причине произошел сбой связи между серверами и в один момент времени оба сервера перешли в режим «ведущего», может произойти ситуация когда данные на синхронизируемом разделе будут отличаться между серверами. Данная ситуация называется «расщепление разума» («split-brain»). В этом случае администратор в ручном режиме должен произвести действия по разрешению этого конфликта.

Идентифицировать данную проблему можно по статусу пакета drbd. Получить статус можно командой:

/etc/init.d/drbd status

Вывод при конфликтной ситуации на основном сервере будет содержать строку следующего содержания:

0: cs:StandAlone st:Primary/Unknown ld:Consistent

Вывод при конфликтной ситуации на резервном сервере будет содержать строку следующего содержания:

0: cs:StandAlone st:Secondary/Unknown ld:Consistent

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

На обоих серверах выполняем команды:

drbdadm disconnect all

/etc/init.d/heartbeat stop

Затем на сервере с неактуальными данными выполняем команду:

drbdadm secondary all

и после этого на сервере с актуальными данными команду:

drbdadm secondary all

Далее на сервере с актуальными данными выполняем команду:

drbdadm -- --human primary all

После этих действий необходимо подключить устройства на обоих серверах командой:

drbdadmconnectall

При этом автоматически неактуальные данные будут удалены, и оба сервера будут иметь актуальные и полностью идентичные данные. Проверить результат можно командой просмотра статуса:

/etc/init.d/drbd status

Вывод на основном сервере должен выглядеть следующим образом:


drbd driver OK; device status:
version: 0.7.11 (api:77/proto:74)
SVN Revision: 1807 build by netup@netup1, 2006-01-17 00:52:49
0: cs:Connected st:Secondary/Primary ld:Consistent

Строка «st:Secondary/Primary ld:Consistent» свидетельствует о том, что данные полностью синхронизированы между серверами и конфликт был успешно разрешен.

 

[1] Страница пакета drbdв Интернете - http://www.drbd.org/

[2] Страница пакета heartbeatв Интернете - http://linux-ha.org/HeartbeatProgram