Исходные данные:
- Развернутые и настроенные два виртуальных хоста, объединенные в кластер (настройка кластера здесь).
- Сетевое хранилище, на котором выделен кусок пространства для организации файлового сервера.
- Имена узлов:
fs-01.rpn.int- первый хост кластера
fs-02.rpn.int- второй хост кластераsmb.rpn.int- имя виртуального сервера, к которому будут подключаться клиенты
Процесс настройки настройки кластера Samba в режиме active/active состоит из нескольких шагов:
- Создание кластера высокой доступности.
- Создание и конфигурирования кластерной файловой системы GFS2.
- Конфигурирование Samba на обоих узлах кластера
- Ну тестирование всего того, что у нас получилось.
Создание кластера.
Как таковой кластер мы уже создали (смотрим здесь). Требуется только добавить один ресурс и немного изменить параметры кластера.
Так как хосты кластера будут располагаться в виртуальной среде 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 том для совместной работы узлов кластера.
- Подключаем общий диск к узлам кластера как описано здесь.
- На всех узлах кластера устанавливаем необходимое ПО:
# 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 согласно статье. Настроили разганичение прав доступа на разные папки согласно этой статье. В итоге имеем:
- Файловый сервер отвечает по FQDN smb.rpn.int
- Настроен общий ресурс "DST" для досупа пользователям домена FreeIPA (и пользователям доверенного домена Windows)
- Необходимо настроить политику автомонтирования общего ресурса на клиентах 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.
