Масштабируемый Отказоустойчивый Файловый Сервис На Базе Ctdb, Glusterfs

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

написано хабрасообщество.

Поскольку GlusterFS является частью Хранилище Красной Шляпы , туториал написан для RH-подобных систем.



Масштабируемый отказоустойчивый файловый сервис на базе CTDB, GlusterFS



Как эти сервисы взаимодействуют?
ГлюстерФС Я использую версию 3.3.1, обороты скачал с официального сайта.

После создания тома клиент может получить к нему доступ несколькими способами:



  • # mount.glusterfs



  • # mount -o mountproto=tcp,async -t nfs



  • # mount.cifs

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

Масштабируемый отказоустойчивый файловый сервис на базе CTDB, GlusterFS

ЦТБД Механика работы прекрасно описана в этот почта.

Хочу добавить, что распределение нагрузки на кластер с использованием LVS указано в документации только для сети NAT, поэтому мы будем использовать Round Robbin DNS. Доступен в стандартных репозиториях, а также SMB, NFS:

# yum install ctdb samba nfs-utils cifs-utils



Давайте начнем
Допустим, у нас есть 2 узла:

gluster1, 192.168.122.100



gluster2, 192.168.122.101

Еще нам нужна пара IP, которые будут реализовывать отказоустойчивость — мигрировать между серверами.



192.168.122.200



192.168.122.201

RR DNS для домена данных выглядит следующим образом:

; zone file fragment



data. 86400 IN A 192.168.122.200



data. 86400 IN A 192.168.122.201

Я не буду вдаваться в подробности создания тома для GlusterFS. Я скажу, что нам нужен распределенный — раздел репликации (распределенный+реплицируемый том).

Давай позвоним ему кто-то .

Сначала мы монтируем его локально для каждый узлы:

# mount.glusterfs gluster1:smb /mnt/glustersmb

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

Не забудьте сделать запись в /etc/fstab. Теперь давайте отредактируем конфигурацию Samba. (на каждом сервере) .



# vim /etc/samba/smb.conf



[global]

# Основной параметр отвечает за кластеризацию.



clustering = yes

# Соединение с базой данных, в которой хранятся запросы пользователей (о механике работы см.

ссылку)

idmap backend = tdb2

# Папка с файлами конфигурации

private dir = /mnt/glustersmb/lock

И туда добавим участок самого шара:

[pub]



path = /mnt/glustersmb/lock



browseable = YES



force user = smbcli



force group = smbcli



writable = yes



guest ok = yes



guest account = smbcli



guest only = yes

Папка будет общедоступной, к ней сможет получить доступ пользователь smbcli без авторизации.

Давайте создадим его позже и назначим права.

Сейчас на одной на серверах создаем папку, в которую поместим некоторые файлы конфигурации CTDB

# mkdir /mnt/glustersmb/lock

И добавьте файл:

# touch /mnt/glustersmb/lock/lockfile

Конфигурационный файл CTDB на каждом server приводим к виду:

# vim /etc/sysconfig/ctdb



CTDB_RECOVERY_LOCK=/mnt/glustersmb/lock/lockfile



CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses



CTDB_MANAGES_SAMBA=yes



CTDB_NODES=/etc/ctdb/nodes



CTDB_MANAGES_NFS=yes

# Файл, который выполняется каждый раз, когда узел кластера CTDB меняет свой статус (например, отправляет письмо)

CTDB_NOTIFY_SCRIPT=/etc/ctdb/notify.sh

Указываем наши публичные адреса (на каждом сервере) :

# vim /etc/ctdb/public_addesses



192.168.122.200/24 eth0



192.168.122.201/24 eth0

Указание узлов кластера CTDB (на каждом сервере) :

# vim /etc/ctdb/nodes



192.168.122.100



192.168.122.101

Я отключаю SElinux, IPtables выглядит так (естественно для каждого сервер):

# vim /etc/sysconfig/iptables



-A INPUT -p tcp --dport 4379 -j ctdb



-A INPUT -p udp --dport 4379 -j ctdb



-A INPUT -p tcp -m multiport --ports 137:139,445 -m comment --comment "SAMBA" -j SMB



-A INPUT -p udp -m multiport --ports 137:139,445 -m comment --comment "SAMBA" -j SMB



-A INPUT -p tcp -m multiport --ports 111,2049,595:599 -j NFS



-A INPUT -p udp -m multiport --ports 111,2049,595:599 -j NFS



-A INPUT -p tcp -m tcp --dport 24007:24220 -m comment --comment "Gluster daemon" -j ACCEPT



-A INPUT -p tcp -m tcp --dport 38465:38667 -m comment --comment "Gluster daemon(nfs ports)" -j ACCEPT

# Вместо названий цепочек можно просто указать ACCEPT. Вернемся к Samba и пользователю smbcli. (на каждом сервере) :

# useradd smbcli



# chown -R smbcli.smbcli /mnt/glustersmb/pub

Предпоследние штрихи:

# chkconfig smbd off



# chkconfig ctdb on



# service ctdb start

Теперь вы можете посмотреть

# ctdb status



Number of nodes:2



pnn:0 192.168.122.100 OK (THIS NODE)



pnn:1 192.168.122.101 OK



Generation:1112747960



Size:2



hash:0 lmaster:0



hash:1 lmaster:1



Recovery mode:NORMAL (0)



Recovery master:0

Список публичных мигрирующих IP-адресов и их принадлежность к серверам получается командой

# ctdb ip



Public IPs on node 0



192.168.122.200 node[1] active[] available[eth0] configured[eth0]



192.168.122.201 node[0] active[eth0] available[eth0] configured[eth0]

Монтируем клиент по протоколу SMB или NFS командами:

# mount.cifs data:smb /mnt



# mount -o mountproto=tcp,async -t nfs data:smb /mnt

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

Обрыв соединения практически незаметен.

Объясняет все АндрейКиров Образовательная программа

Узел, перенявший IP-адрес другого, знает о старых TCP-соединениях только то, что они существовали, и не знает «номер последовательности TCP» этих соединений.

Соответственно, он не может их продолжать.

Так же, как и клиент, он ничего не знает о том, что сейчас устанавливаются соединения с другим узлом.

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

Чтобы понять эту технику, вам необходимо понять основные принципы протокола TCP. Новый узел, получив IP-адрес, отправляет клиенту пакет с флагом ACK и заведомо неверным «номером последовательности», равным нулю.

В ответ клиент в соответствии с правилами протокола TCP отправляет обратно пакет ACK Reply с правильным «порядковым номером».

Получив правильный «номер последовательности», узел формирует пакет с флагом RST и этим «номером последовательности».

Получив его, клиент немедленно перезапускает соединение.

Приятного кодирования! Теги: #Системное администрирование #Настройка Linux #руководство #высокая доступность #Samba #nfs #nfs
Вместе с данным постом часто просматривают: