Настраиваем файловый сервер Samba в отказоустойчевом кластере
Пятница, 11 мая 2018 14:54

Настраиваем файловый сервер Samba в отказоустойчевом кластере

Автор
Оцените материал
(0 голосов)

В предыдущих статьях рассматривался вариант установки файлового сервера Samba в связке с доменом FreeIPA, разграничение прав доступа на каталоги и установка файлового сервера NFS в кластере высокой доступности. Сервер NFS прекрасно живет и работает в среде Linux (Unix). Но для клиентов Windows как правило возникают проблемы (отсутствие встроеного клиента NFS, проблемы с отработкой групповых политик и.т.д. и т.п.). Поэтому попробуем "скрестить бульдога с носорогом" и установить файловый сервер Samba в уже развернутый и настроенный кластер, который обслуживает доступ к файлам по NFS. Работы как всегда будут проводится в рамках "импортозамещения" на ОС Rosa Enterprise Linux Server 7.3 (RELS 7.3) (он же CentOS 7.3, он же RedHat 7.3)

Исходные данные:

  1. Развернутые и настроенные два виртуальных хоста, объединенные в кластер (настройка кластера здесь).
  2. Сетевое хранилище, на котором выделен кусок пространства для организации файлового сервера.
  3. Имена узлов:
    fs-01.rpn.int - первый хост кластера
    fs-02.rpn.int - второй хост кластера
    smb.rpn.int - имя виртуального сервера, к которому будут подключаться клиенты

Процесс настройки настройки кластера Samba в режиме active/active состоит из нескольких шагов:

  1. Создание кластера высокой доступности.
  2. Создание и конфигурирования кластерной файловой системы GFS2.
  3. Конфигурирование Samba на обоих узлах кластера
  4. Ну тестирование всего того, что у нас получилось.

Создание кластера.

Как таковой кластер мы уже создали (смотрим здесь). Требуется только добавить один ресурс и немного изменить параметры кластера.

Так как хосты кластера будут располагаться в виртуальной среде Vmvare vSphere, то создаем ресурс, который будет отслеживать состояние виртуальной машины и в случае возникновения проблем с этой виртуальной машиной будет отключать ее от кластера:

# pcs stonith create vcenter-fence fence_vmware_soap ipaddr=XXX.XXX.XXX.XXX \
     ipport=9443 ssl=1 ssl_insecure=1 login=vcadmin passwd=XXXX action=reboot \
     pcmk_host_map="pcmk01-cr:FS-01.RPN.INT;pcmk02-cr:FS-02.RPN.INT" \
     pcmk_host_list="fs-01.rpn.int; fs-02.rpn.int" pcmk_host_check=static-list

Где:

vcenter-fence - имя ресурса
ipaddr=XXX.XXX.XXX.XXX - IP адрес сервера управления vCenter Server
ipport=9443 - порт для подключения к vCenter Server
login=vcadmin - логин администратора vSphere
passwd=XXXX - пароль администратора vSphere
Так же указаны имена узлов файлового кластера

Для работы с GFS2 потребуется изменить глобальный параметр:

# pcs property set no-quorum-policy=freeze

Кластерная файловая система GFS2.

Для работы Samba в кластере нам необходимо создать кластерный LVM том для совместной работы узлов кластера.

  1. Подключаем общий диск к узлам кластера как описано здесь.
  2. На всех узлах кластера устанавливаем необходимое ПО:
    # yum install lvm2-cluster gfs2-utils
    

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

Создаем dlm ресурс. Этот ресурс требуется для службы clvmd и файловой системы GFS2.

# pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s on-fail=fence clone interleave=true ordered=true

Настраиваем сервис clvmd в качестве ресурса кластера:

# pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s on-fail=fence clone interleave=true ordered=true

Здесь агент ресурса ocf:heartbeat:clvm является частью процедуры запуска, устанавливает параметр lock_type в файле /etc/lvm/lvm.conf равным 3 и отключает демон lvmetad.

Устанавливаем зависимость clvmd и dlm. Настраиваем порядок запуска ресурсов. Ресурс clvmd должен запускаться после ресурса dlm и должен выполняться на том же узле, что и ресурс dlm.

# pcs constraint order start dlm-clone then clvmd-clone /
    Adding dlm-clone clvmd-clone (kind: Mandatory) /
    (Options: first-action=start then-action=start)
# pcs constraint colocation add clvmd-clone with dlm-clone

Проверяем что ресурсы dlm и clvmd созданы и запущены на всех узлах:

# pcs status
.....
Clone Set: dlm-clone [dlm]
     Started: [ fs-01.rpn.int fs-02.rpn.int ]
Clone Set: clvmd-clone [clvmd]
     Started: [ fs-01.rpn.int fs-02.rpn.int ]
......

Создание кластерного логического раздела.

Ранее мы создали и подключили общий диск ко всем узлам кластера. В устройствах он у нас виден как /dev/sdc. Создаем логический раздел на этом диске (работы производятся только на одном узле кластера):

# pvcreate /dev/sdc
# vgcreate -Ay -cy vg_samba /dev/sdc
# lvcreate -l +100%FREE -n lv_samba vg_samba

Проверяем наличие созданного раздела:

# lvs
  LV       VG         Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ............
  lv_samba vg_samba   -wi-ao----  2,00t  

Форматируем раздел с файловой системой GFS2. Используемые параметры: my_cluster - это имя кластера; -j 2 - указываем два журнала, поскольку количество настраиваемых журналов должно равняться количеству узлов в кластере.

# mkfs.gfs2 -p lock_dlm -j 2 -t my_cluster:samba /dev/vg_samba/lv_samba

Создаем в кластере ресурс файловой системы, который настраивает Pacemaker для монтирования и управления файловой системой. В этом примере создается ресурс файловой системы с именем fs_smb_cluster и создается точка монтирования /opt/smb_fs на обоих узлах кластера. Так же включается параметр, позволяющий использовать на файловой системе расширенные права доступа (ACL).

# pcs resource create fs_smb_cluster ocf:heartbeat:Filesystem device="/dev/vg_samba/lv_samba" directory="/opt/smb_fs" fstype="gfs2" options="acl,noatime" --clone

Настраиваем зависимость и порядок запуска файловой системы GFS2 и службы clvmd. GFS2 должен запускаться после clvmd и должен выполняться на том же узле, что и clvmd.

# pcs constraint order start clvmd-clone then fs_smb_cluster-clone Adding clvmd-clone fs-clone (kind: Mandatory) Options: first-action=start then-action=start)
# pcs constraint colocation add fs_smb_cluster-clone with clvmd-clone

После создания ресурса файловой системы, ранее созданный раздел должен смонтироваться в точке /opt/smb_fs на всех узлах кластера.

Настраиваем Samba.

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

Устанавливаем необходимое ПО:

# yum install samba ctdb cifs-utils

Останавливаем и запрещаем автозапуск следующих служб:

# systemctl disable ctdb
# systemctl disable smb
# systemctl disable nmb
# systemctl disable winbind
# systemctl stop ctdb
# systemctl stop smb
# systemctl stop nmb
# systemctl stop winbind

Приводим файл /etc/samba/smb.conf к виду (здесь публикуется общая папка public):

[global]
netbios name = linuxserver
workgroup = WORKGROUP
server string = Public File Server
security = user
map to guest = bad user
guest account = smbguest
clustering = yes
ctdbd socket = /tmp/ctdb.socket
#unix charset = koi8-r
#dos charset = 866

[public]
path = /opt/smb_fs/public
guest ok = yes
read only = no
#inherit owner = yes           # ACL
#inherit acls = yes            # ACL
#inherit permissions = yes     # ACL
#map acl inherit = yes         # ACL

Здесь приведена конфигурация сервера Samba в режиме Standalone. Работа сервера в домене FreeIPA, а также авторизация пользователей из доверенного домена Windows Active Directory будет рассмотрена ниже.

Создаем файл /etc/ctdb/nodes:

# cat  /etcctdb/nodes
192.168.1.151
192.168.1.152
END

В этот файл записываются IP адреса всех хостов кластера.

Для организации балансировки нагрузки между узлами кластера необходимо добавить два или более (в зависимости от числа узлов) IP-адреса, которые будут использоваться для доступа к файлам Samba, предоставляемым этим кластером, в файл /etc/ctdb/public_addresses. Эти IP-адреса, которые необходимо настроить в DNS для имени сервера Samba, являются адресами, к которым будут подключаться клиенты SMB. Нужно настроить имя сервера Samba как одну запись DNS типа A с несколькими IP-адресами. DNS-сервер распределяет клиентов по узлам кластера с соответствующим IP адресом. В этом примере:

# dig smb.rpn.int
 ...........
 ;; ANSWER SECTION:
smb.rpn.int.	86400	IN	A	192.168.1.153
smb.rpn.int.	86400	IN	A	192.168.1.154
.........

Эти адреса не должны принадлежать никаким физическим адаптерам узлов кластера и являются "виртуальными". Т.е. клиенты, обращаясь к серверу по FQDN файлового сервера (в данном случае smb.rpn.int) будут оращаться именно по этим адресам.

Создаем файл /etc/public_addresses:

# cat  /etcctdb/public_addresses
192.168.1.153/0 eth0
192.168.1.154/0 eth0
END

Где eth0 - имя физического интерфейса узла кластера. Оно может быть другим в зависимости от системы.

Создаем группу smbguest и пользователя smbguest для доступа к папке public:

# groupadd smbguest
# adduser smbguest -g smbguest

Создаем каталог для работы ctdb и, если не отключен SeLinux, настраиваем его для корректной работы:

# mkdir /var/ctdb/
# chcon -Rv -u system_u -r object_r -t ctdbd_var_lib_t /var/ctdb/
changing security context of ‘/var/ctdb/’
# chcon -Rv -u system_u -r object_r -t ctdbd_var_lib_t /var/lib/ctdb/
changing security context of ‘/var/lib/ctdb/’

Далее необходимо проверить идентичность файлов настройки на всех узлах кластера (либо настроить синхронизацию необходимых файлов).

Следующие настройки производятся только на одном из узлов кластера.

Создаем каталоги для работы CTDB (ctdb lock) и общую папку public:

# mkdir -p /opt/smb_fs/ctdb/
# mkdir -p /opt/smb_fs/public/

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

# chown smbguest:smbguest /opt/smb_fs/public/
# chmod 755 /opt/smb_fs/public/
# chcon -Rv -t ctdbd_var_run_t /opt/smb_fs/ctdb/
changing security context of ‘/opt/smb_fs/ctdb/’
# chcon -Rv -u system_u -r object_r -t samba_share_t /opt/smb_fs/public/
changing security context of ‘/opt/smb_fs/public’

Создание ресурсов кластера Samba.

Настраивать кластер будем путем импорта текущих настроек в файл samba.cib, внесения изменений в это файл и окончательного экспорта настроек из этого файла в работающий кластер.

Импорт текущих настроек:

# pcs cluster cib samba.cib

Создаем ресурс CTDB, необходимый для работы Samba. Ресурс создается клонированным, для того, что бы он работал одновременно на всех узлах кластера.:

# pcs -f samba.cib resource create ctdb ocf:heartbeat:CTDB \
ctdb_recovery_lock="/opt/smb_fs/ctdb/ctdb.lock" \
ctdb_dbdir=/var/ctdb ctdb_socket=/tmp/ctdb.socket \
ctdb_logfile=/var/log/ctdb.log \
op monitor interval=10 timeout=30 op start timeout=90 \
op stop timeout=100 --clone

Создаем клонированный сервер Samba:

# pcs -f samba.cib resource create samba systemd:smb --clone

Создаем ограничения и порядок размещения ресурсов кластера. Настраиваем порядок запуска ресурсов: в первую очередь запускается ресурс файловой системы, затем ресурс CTDB и в последнюю очередь запускается ресурс сервера Samba:

# pcs -f samba.cib constraint order fs_smb_cluster-clone then ctdb-clone
Adding fs-clone ctdb-clone (kind: Mandatory) (Options: first-action=start then-action=start)

# pcs -f samba.cib constraint order ctdb-clone then samba-clone
Adding ctdb-clone samba-clone (kind: Mandatory) (Options: first-action=start then-action=start)

# pcs -f samba.cib constraint colocation add ctdb-clone with fs_smb_cluster-clone
# pcs -f samba.cib constraint colocation add samba-clone with ctdb-clone

Загружаем измененный файл, содержащий новые настройки кластера, samba.cib в кластер:

# pcs cluster cib-push samba.cib
CIB updated

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

Запуск ресурсов кластера может занять несколько минут. Если запустить вывод статуса кластера до того, как все ресурсы успешно стартуют, то будет выводиться сообщение об ошибке (например статус ресурса CTDB). После успешного старта всех ресурсов, сообщение об ошибке можно очистить командой pcs resource cleanup ctdb-clone

# pcs status
.......
 Clone Set: fs_smb_cluster-clone [fs_smb_cluster]
     Started: [ fs-01.rpn.int fs-02.rpn.int ]
 Clone Set: ctdb-clone [ctdb]
     Started: [ fs-01.rpn.int fs-02.rpn.int ]
 Clone Set: samba-clone [samba]
     Started: [ fs-01.rpn.int fs-02.rpn.int ]
.......

Если статус какого-либо ресурса говорит об ошибке, то можно запустить ресурс в режиме отладки командой resource debug-start resource. Эта команда запускает ресурс за пределами контроля кластера. Если ошибка устранена и ресурс успешно запускается, то необходимо запустить pcs cluster cleanup resource, для того, что бы кластер узнал об изменениях.

Если все ресурсы успешно запущены, то файловый сервер будет доступен по "виртуальному" адресу smb.rpn.int.

Настройка авторизованного доступа.

Мы успешно настроили и запустили файловый сервер Samba в отказоустойчевом кластере. Но т.к. мы используем  доменную стуктуру, необходимо организовать авторизованный доступ на файловые ресурсы. В первую очередь все узлы кластера должны быть членами домена FreeIPA. Настройка самой Samba ничем не отличается от процедуры, описанной в этой статье, за исключением двух моментов: регистрация CIFS сервера в домене FreeIPA и создания файла samba.keytab.

Т.к. у нас в кластере находятся два физических узла и один виртуальный (имеется ввиду два узла кластера, использующие одно "виртуальное" имя сервера для доступа к ресурсу), то в домене необходимо зарегистрировать все три имени сервера: fs-01.rpn.int, fs-02.rpn.int и smb.rpn.int.

Не забываем, что все изменения в файле smb.conf должны быть одинаковыми на всех узлах кластера.

Так же есть тонкости в получении файла keytab.

Выполняем на любом сервере кластера:

# kinit -kt /etc/krb5.keytab
# ipa-getkeytab -s dc.rpn.int -p cifs/fs-01.rpn.int -k /opt/smb_fs/ctdb/samba.keytab
# ipa-getkeytab -s dc.rpn.int -p cifs/fs-02.rpn.int -k /opt/smb_fs/ctdb/samba.keytab
# ipa-getkeytab -s dc.rpn.int -p cifs/smb.rpn.int -k /opt/smb_fs/ctdb/samba.keytab

Где dc.rpn.int - имя контроллера домена FreeIPA.

Тем самым мы создаем файл keytab для Samba и помещаем его в каталог на общем диске.

Настройка прав доступа на каталоги ничем не отличается от настроек, описанных в этой статье.

После того, как получен файл keytab и произведены настройки файла smb.conf, необходимо перестартовать ресурс сервера Samba:

# pcs resource restart samba-clone

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

Если все нормально, то пользователям Active Directory можно создавать групповые политики для подключения к файловому серверу. С пользователями домена FreeIPA дело обстоит несколько иначе. Можно локально настроить сервис autofs на каждом ПК для подключения к этим ресурсам. Но если клиентов много, то это не вариант. FreeIPA умеет централизованно управлять автомонтированием сетевых ресурсов на клиентских ПК (аналог групповых политик Active Directory от Microsoft). Хотя во всех мануалах указано, что данная функция работает только с файловым сервером NFS, мне удалось настроить соответствующую политику для автомонтирования ресурсов Samba через политики FreeIPA.

Настройка политики автомонтирования.

 Итак. Мы настроили файловый сервер Samba, работающий в кластере. Настроили авторизацию в домене FreeIPA согласно статье. Настроили разганичение прав доступа на разные папки согласно этой статье. В итоге имеем:

  1. Файловый сервер отвечает по FQDN smb.rpn.int
  2. Настроен общий ресурс "DST" для досупа пользователям домена FreeIPA (и пользователям доверенного домена Windows)
  3. Необходимо настроить политику автомонтирования общего ресурса на клиентах FreeIPA.

Переходим в консоль контроллера домена FreeIPA.

Получаем билет администратора домена:

# kinit admin
Password:

Создаем локацию, которая будет использоваться для управления точками подключения ресурсов файлового сервера:

# ipa automountlocation-add FileServer

Добавляем карту монтирования:

# ipa automountmap-add FileServer auto.smb

Добавляем ссылку на auto.smb в auto.master

# ipa automountkey-add FileServer --key "/-" --info auto.smb auto.master

Добавляем ключ монтирования в auto.smb:

# ipa automountkey-add FileServer --key "/home/NetFiles/DST" --info "-fstype=cifs,sec=krb5,uid=${UID},cruid=${UID}, ://smb.rpn.int/DST" auto.smb

В итоге после того, как на клиентах FreeIPA будет настроен механизм автомонтирования (на клиенте запускается команда ipa-client-automount --location FileServer), у них (у клиентов) появится папка /home/NetFiles/DST к которой будет предоставлен доступ тому или иному пользователю в зависимости от настроек Samba.

Дополнительная информация

  • Так же интересно:
Прочитано 6071 раз Последнее изменение Пятница, 01 июня 2018 09:47
Авторизуйтесь, чтобы получить возможность оставлять комментарии
Top
Этот шаблон Joomla был скачан с сайта ДжуМикс.