Samba/Cluster: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
 
(не показано 12 промежуточных версий 2 участников)
Строка 1: Строка 1:
{{stub}}
{{Broken}}
== Описание ==
== Описание ==
В этой статье рассмотрим обеспечение высокой доступности сервиса Samba. Для обеспечения высокой доступности мы будет использовать общее хранилище, которое будет доступно одновременно всем серверам в кластере. Для синхронизации доступа серверов к общему хранилищу используется DLM (распределенный менеджер блокировок). В качестве кластерной файловой системы будем использовать GFS2, но она не работает напрямую с блочными устройствами, поэтому нам придется использовать кластерную реализацию LVM. Для механизма блокировок Samba использует TBD (trivial data base), нам понадобится его кластерная реализация CTDB. CTDB будет управлять переносом IP-адреса и запуском сервиса Samba. Pacemaker будет управлять следующими ресурсами: DLM, CLVM, GFS2, CTDB.
В этой статье рассмотрим обеспечение высокой доступности сервиса Samba. Для обеспечения высокой доступности мы будет использовать общее хранилище, которое будет доступно одновременно всем серверам в кластере. Для синхронизации доступа серверов к общему хранилищу используется DLM (распределенный менеджер блокировок). В качестве кластерной файловой системы будем использовать GFS2, но она не работает напрямую с блочными устройствами, поэтому нам придется использовать кластерную реализацию LVM. Для механизма блокировок Samba использует TBD (trivial data base), нам понадобится его кластерная реализация CTDB. CTDB будет управлять переносом IP-адреса и запуском сервиса Samba. Pacemaker будет управлять следующими ресурсами: DLM, CLVM, GFS2, CTDB.
Строка 58: Строка 58:
Посмотреть доступные STONITH устройств можно командой:
Посмотреть доступные STONITH устройств можно командой:
<pre># stonith -L</pre>
<pre># stonith -L</pre>
Для примера выберем устройство meatware, которое реализует механизм с помощью сообщений на консоль, после которого оператор должен выключить узел вручную.  
=== Настройка meatware ===
Meatware это устройство, которое реализует механизм с помощью сообщений на консоль, после которого оператор должен выключить узел вручную.  
Описание устройств можно посмотреть командой:
Описание устройств можно посмотреть командой:
<pre># stonith -t meatware -h</pre>
<pre># stonith -t meatware -h</pre>
Строка 72: Строка 73:
<pre># crm configure location l-st-meat-01 smb-meat-01 -inf: samba01
<pre># crm configure location l-st-meat-01 smb-meat-01 -inf: samba01
# crm configure location l-st-meat-02 smb-meat-02 -inf: samba02</pre>
# crm configure location l-st-meat-02 smb-meat-02 -inf: samba02</pre>
=== Настройка external/ipmi ===
External/ipmi реализует возможность отключения узлов с помощью IPMI.<br>
Обязательные параметры:
<pre># stonith -t external/ipmi -n
hostname  ipaddr  userid  passwd  interface</pre>
Создадим для каждого узла отдельный ресурс:<br>
Для samba01:
<pre>crm configure primitive samba01-fencers stonith:external/ipmi params \
hostname="samba01" \
ipaddr="192.168.135.221" \
passwd="Pa$$word" \
userid="admin" \
interface="lan" \
pcmk_host_list=samba01 \
pcmk_host_check=static-list \
op monitor interval=600s timeout=240s on-fail=restart</pre>
Для samba02:
<pre>crm configure primitive samba02-fencers stonith:external/ipmi params \
hostname="samba02" \
ipaddr="192.168.135.223" \
passwd="Pa$$word" \
userid="admin" \
interface="lan" \
pcmk_host_list=samba02 \
pcmk_host_check=static-list \
op monitor interval=600s timeout=240s on-fail=restart</pre>
Запретим ресурсу стартовать на узле который он должен убивать:
<pre>crm configure location l-samba01-fencers samba01-fencers -inf: samba01
crm configure location l-samba02-fencers samba02-fencers -inf: samba02
</pre>
=== Настройка fence-pve ===
Этот ресурс реализует возможность отключения узлов, которые находятся в виртуальной среде PVE.<br>
Этот агент предназначен для использования с RGmanager, но Pacemaker также может его использовать. Для этого:<br>
Установим необходимый пакет:
<pre># apt-get install fence-agents-pve</pre>
Создадим папку для таких агентов:
<pre># mkdir /usr/lib64/stonith/plugins/rhcs</pre>
Создадим символическую ссылку на нужный нам агент:
<pre># ln -s /usr/sbin/fence_pve /usr/lib64/stonith/plugins/rhcs/</pre>
Теперь можно посмотреть описание:
<pre># stonith -t rhcs/pve -h</pre>
И параметры агента:
<pre># stonith -t rhcs/pve -n</pre>
Добавим stonith ресурс для samba01:
<pre># crm configure primitive smb01-pve stonith:rhcs/pve \
    params ipaddr="10.1.1.9" \
    login="admin@pve" \
    passwd="Pa$$word" \
    port="121" \
    node_name="pve03" \
    action="reboot" \
    power_wait=20 \
    power_timeout=60 \
    pcmk_host_list=samba01 \
    pcmk_host_check=static-list \
    op monitor interval=600s timeout=240s on-fail=restart</pre>
И для samba02:
<pre># crm configure primitive smb02-pve stonith:rhcs/pve \
    params ipaddr="10.1.1.9" \
    login="admin@pve" \
    passwd="Pa$$word" \
    port="122" \
    node_name="pve03" \
    action="reboot" \
    power_wait=20 \
    power_timeout=60 \
    pcmk_host_list=samba02 \
    pcmk_host_check=static-list \
    op monitor interval=600s timeout=240s on-fail=restart</pre>
Параметры:<br>
*'''ipaddr'''- IP-адрес PVE-ноды на которой запущена виртуальная машина
*'''login''' - Логин пользователя, имеющего право управления виртуальной машиной
*'''passwd''' - Пароль пользователя
*'''port''' - Номер виртуальной машины
*'''node_name''' - Имя PVE-ноды на которой запущена виртуальная машина
*'''action''' - Нужное действие
*'''pcmk_host_list''' - список узлов, которые может убивать этот stonith ресурс
Укажем ресурсам не запускаться на тех узлах, которые они должны убивать:
<pre>crm configure location l-smb01-pve smb01-pve -inf: samba01
crm configure location l-smb02-pve smb02-pve -inf: samba02</pre>
=== Включение STONITH ===
Включим механизм STONITH:
Включим механизм STONITH:
<pre># crm configure property stonith-enabled=true</pre>
<pre># crm configure property stonith-enabled=true</pre>
Строка 173: Строка 256:
Сервисом CTDB должен управлять Pacemaker, он не должен запускаться автоматически:
Сервисом CTDB должен управлять Pacemaker, он не должен запускаться автоматически:
<pre># systemctl disable ctdb</pre>
<pre># systemctl disable ctdb</pre>
Создадим на кластерной файловой системе каталог ctdb. В каталоге {{path|/etc/ctdb}} файлы nodes и public_addresses для Samba на каждом узле:
Создадим на кластерной файловой системе каталог ctdb. В каталоге {{path|/etc/ctdb}} файлы nodes для Samba на каждом узле:
<pre># mkdir /mnt/smbfs/ctdb
<pre># mkdir /mnt/smbfs/ctdb
# touch /etc/ctdb/{nodes,public_addresses}</pre>
# touch /etc/ctdb/nodes</pre>
В файле {{path|/etc/ctdb/nodes}} перечислим IP адреса всех узлов кластера:
В файле {{path|/etc/ctdb/nodes}} перечислим IP адреса всех узлов кластера:
<pre># cat /etc/ctdb/nodes
<pre># cat /etc/ctdb/nodes
192.168.135.221
192.168.135.221
192.168.135.223</pre>
192.168.135.223</pre>
В файле {{path|/etc/ctdb/public_addresses}} перечисляются все виртуальные адреса, которые будет обслуживать CTDB с указанием интерфейса:
Скопируем файл на другие узлы:
<pre># cat /etc/ctdb/public_addresses
<pre># crm cluster copy /etc/ctdb/nodes
192.168.135.251/24 ens18</pre>
Скопируем эти файлы на другие узлы:
<pre># crm cluster copy /etc/ctdb/public_addresses
OK: samba02
# crm cluster copy /etc/ctdb/nodes
OK: samba02</pre>
OK: samba02</pre>
Пример конфигурации Samba:
Пример конфигурации Samba:
Строка 229: Строка 307:
   ctdb_manages_winbind="no" \
   ctdb_manages_winbind="no" \
   ctdb_service_smb="smb" \
   ctdb_service_smb="smb" \
   ctdb_service_nmb="nmb"
   ctdb_service_nmb="nmb" \
  ctdb_start_as_disabled="yes" \
crm(live)configure# commit</pre>
crm(live)configure# commit</pre>
Склонируем ресурс:
Склонируем ресурс:
Строка 252: Строка 331:
<pre># sed -i 's/$start_as_disabled $log_option $pub_addr_option/$start_as_disabled $pub_addr_option/' /usr/lib/ocf/resource.d/heartbeat/CTDB</pre>
<pre># sed -i 's/$start_as_disabled $log_option $pub_addr_option/$start_as_disabled $pub_addr_option/' /usr/lib/ocf/resource.d/heartbeat/CTDB</pre>
см. {{altbug|33353}}}}
см. {{altbug|33353}}}}
== Настройка IPaddr2 ==
Теперь нам необходимо настроить ресурс, который будет управлять виртуальным IP адресом:
<pre># crm configure primitive ip ocf:heartbeat:IPaddr2 params ip=192.168.135.251 op monitor interval=20s</pre>
Укажем, что он может запускаться только после ресурса clonectdb:
<pre># crm configure order clonectdb-before-ip inf: clonectdb ip</pre>
Укажем, что он может запускаться только вместе с clonectdb:
<pre># crm configure colocation ip-with-clonectdb inf: ip clonectdb</pre>
== Проверка работоспособности ==
== Проверка работоспособности ==
Добавим пользователя и зададим ему пароль для samba на всех узлах:
Добавим пользователя и зададим ему пароль для samba на всех узлах:
Строка 275: Строка 363:
WORKGROUP    </pre>  
WORKGROUP    </pre>  
Выключим узел с виртуальным IP-адресом и повторим проверку.
Выключим узел с виртуальным IP-адресом и повторим проверку.
[[Категория:Samba]]
{{Category navigation|title=Samba|category=Samba|sortkey={{SUBPAGENAME}}}}

Текущая версия от 16:43, 21 декабря 2023

BrokenPage.png
Эта статья сломана.
Статья годная, но там что-то изменилось/поменялось и она уже не рабочая. Её нужно доработать.


Описание

В этой статье рассмотрим обеспечение высокой доступности сервиса Samba. Для обеспечения высокой доступности мы будет использовать общее хранилище, которое будет доступно одновременно всем серверам в кластере. Для синхронизации доступа серверов к общему хранилищу используется DLM (распределенный менеджер блокировок). В качестве кластерной файловой системы будем использовать GFS2, но она не работает напрямую с блочными устройствами, поэтому нам придется использовать кластерную реализацию LVM. Для механизма блокировок Samba использует TBD (trivial data base), нам понадобится его кластерная реализация CTDB. CTDB будет управлять переносом IP-адреса и запуском сервиса Samba. Pacemaker будет управлять следующими ресурсами: DLM, CLVM, GFS2, CTDB.

Тестовая конфигурация

Рассмотрим следующую конфигурацию:

  • samba01 - первый узел кластера (IP 192.168.135.221/24 ens18)
  • samba02 - второй узел кластера (IP 192.168.135.223/24 ens18)
  • 192.168.135.251 - виртуальный IP по которому будет отвечать один из узлов

На каждом узле доступно общее блочное устройство /dev/sdb
Настроен взаимный беспарольный root-доступ для первоначальной инициализации кластера
Необходимо обеспечить взаимно однозначное прямое и обратное преобразование имён для всех узлов кластера. Крайне желательно использовать DNS, но в крайнем случае можно обойтись соответствующими записями в локальном файле /etc/hosts на каждом узле:

# echo "192.168.135.221 samba01.localdomain samba01" >> /etc/hosts
# echo "192.168.135.223 samba02.localdomain samba02" >> /etc/hosts

Проверить правильность разрешения имен можно так:

# ping samba01
PING samba01.localdomain (192.168.135.221) 56(84) bytes of data.
64 bytes from samba01.localdomain (10.10.3.70): icmp_req=1 ttl=64 time=0.017 ms
# ping samba02
PING samba02.localdomain (192.168.135.223) 56(84) bytes of data.
64 bytes from samba02.localdomain (10.10.3.71): icmp_req=1 ttl=64 time=0.265 ms

Настройка Pacemaker

Установим необходимые пакеты на всех узлах:

# apt-get install pacemaker

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

# apt-get install crmsh python-module-yaml

На одном из узлов инициализируем кластер:

# crm cluster init nodes=samba01,samba02

Зададим имя кластера, для этого в добавим в файле /etc/corosync/corosync.conf следующий параметр:

totem {
...
cluster_name: samba_cluster
...
}

Применим конфигурацию corosync текущего узла на всех узлах:

# crm corosync push
OK: samba02

Добавим сервисы в автозагрузку:

# systemctl enable corosync
# systemctl enable pacemaker

Перезагрузимся и проверим состояние кластера:

# crm status
Stack: corosync
Current DC: samba01 (version 1.1.16-alt1-94ff4df) - partition with quorum
Last updated: Wed Apr 12 10:52:47 2017
Last change: Wed Apr 12 10:46:47 2017 by hacluster via crmd on samba01
2 nodes configured
0 resources configured
Online: [ samba01 samba02 ]
No resources

Настройка STONITH

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

# apt-get install cluster-glue-stonith

Проверим наличие необходимых ресурсов в pacemaker:

# crm ra classes | grep stonith
stonith

Посмотреть доступные STONITH устройств можно командой:

# stonith -L

Настройка meatware

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

# stonith -t meatware -h

Обязательные параметры устройства можно посмотреть командой:

# stonith -t meatware -n
hostlist  

В нашем случае обязательный параметр только hostlist задающий имена узлов которые от может убить.
Создадим для каждого узла отдельный ресурс:

# crm configure primitive smb-meat-01 stonith:meatware params hostlist=samba01
# crm configure primitive smb-meat-02 stonith:meatware params hostlist=samba02

Запретим ресурсу стартовать на узле который он должен убивать:

# crm configure location l-st-meat-01 smb-meat-01 -inf: samba01
# crm configure location l-st-meat-02 smb-meat-02 -inf: samba02

Настройка external/ipmi

External/ipmi реализует возможность отключения узлов с помощью IPMI.
Обязательные параметры:

# stonith -t external/ipmi -n
hostname  ipaddr  userid  passwd  interface

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

crm configure primitive samba01-fencers stonith:external/ipmi params \
hostname="samba01" \
ipaddr="192.168.135.221" \
passwd="Pa$$word" \
userid="admin" \
interface="lan" \
pcmk_host_list=samba01 \
pcmk_host_check=static-list \
op monitor interval=600s timeout=240s on-fail=restart

Для samba02:

crm configure primitive samba02-fencers stonith:external/ipmi params \
hostname="samba02" \
ipaddr="192.168.135.223" \
passwd="Pa$$word" \
userid="admin" \
interface="lan" \
pcmk_host_list=samba02 \
pcmk_host_check=static-list \
op monitor interval=600s timeout=240s on-fail=restart

Запретим ресурсу стартовать на узле который он должен убивать:

crm configure location l-samba01-fencers samba01-fencers -inf: samba01
crm configure location l-samba02-fencers samba02-fencers -inf: samba02

Настройка fence-pve

Этот ресурс реализует возможность отключения узлов, которые находятся в виртуальной среде PVE.
Этот агент предназначен для использования с RGmanager, но Pacemaker также может его использовать. Для этого:
Установим необходимый пакет:

# apt-get install fence-agents-pve

Создадим папку для таких агентов:

# mkdir /usr/lib64/stonith/plugins/rhcs

Создадим символическую ссылку на нужный нам агент:

# ln -s /usr/sbin/fence_pve /usr/lib64/stonith/plugins/rhcs/

Теперь можно посмотреть описание:

# stonith -t rhcs/pve -h

И параметры агента:

# stonith -t rhcs/pve -n

Добавим stonith ресурс для samba01:

# crm configure primitive smb01-pve stonith:rhcs/pve \
    params ipaddr="10.1.1.9" \
    login="admin@pve" \
    passwd="Pa$$word" \
    port="121" \
    node_name="pve03" \
    action="reboot" \
    power_wait=20 \
    power_timeout=60 \
    pcmk_host_list=samba01 \
    pcmk_host_check=static-list \
    op monitor interval=600s timeout=240s on-fail=restart

И для samba02:

# crm configure primitive smb02-pve stonith:rhcs/pve \
    params ipaddr="10.1.1.9" \
    login="admin@pve" \
    passwd="Pa$$word" \
    port="122" \
    node_name="pve03" \
    action="reboot" \
    power_wait=20 \
    power_timeout=60 \
    pcmk_host_list=samba02 \
    pcmk_host_check=static-list \
    op monitor interval=600s timeout=240s on-fail=restart

Параметры:

  • ipaddr- IP-адрес PVE-ноды на которой запущена виртуальная машина
  • login - Логин пользователя, имеющего право управления виртуальной машиной
  • passwd - Пароль пользователя
  • port - Номер виртуальной машины
  • node_name - Имя PVE-ноды на которой запущена виртуальная машина
  • action - Нужное действие
  • pcmk_host_list - список узлов, которые может убивать этот stonith ресурс

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

crm configure location l-smb01-pve smb01-pve -inf: samba01
crm configure location l-smb02-pve smb02-pve -inf: samba02

Включение STONITH

Включим механизм STONITH:

# crm configure property stonith-enabled=true

Проверить работу механизма STONITH можно командой:

# stonith_admin --reboot samba01

После настройки STONITH наш кластер будет выглядеть так:

# crm status
...
Full list of resources:
 smb-meat-01	(stonith:meatware):	Started samba02
 smb-meat-02	(stonith:meatware):	Started samba01

Настройка DLM и Cluster LVM

Установим необходимые пакеты:

# apt-get install clvm

Сервисами DLM и CLVM должен управлять Pacemaker, они не должны запускаться автоматически:

# systemctl disable dlm
# systemctl disable lvm2-clvmd

На каждом узле включаем поддержку кластера LVM:

# lvmconf --enable-cluster

Проверяем включилась ли она:

# cat /etc/lvm/lvm.conf | grep "locking_type ="
    locking_type = 3

Создаем ресурс для DLM:

# crm configure primitive dlm ocf:pacemaker:controld op monitor interval=30s on-fail=fence

Клонируем ресурс DLM:

# crm configure clone clonedlm dlm meta interleave=true ordered=true

Создаем ресурс для CLVM:

# crm configure primitive clvmd ocf:heartbeat:clvm op monitor interval=30s on-fail=fence

Клонируем ресурс CLVM:

# crm configure clone cloneclvmd clvmd meta interleave=true ordered=true

Теперь настроим очередность запуска ресурсов, чтобы cloneclvmd должен запускаться после clonedlm:

# crm configure order dlmbeforeclvm clonedlm cloneclvmd

Также оба сервиса должны запускаться на одном узле:

# crm configure colocation clonedlm-with-cloneclvmd inf: clonedlm cloneclvmd

Проверим запустились ли ресурсы:

# crm resource show
 Clone Set: clonedlm [dlm]
     Started: [ samba01 samba02 ]
 Clone Set: cloneclvmd [clvmd]
     Started: [ samba01 samba02 ]
 smb-meat-01	(stonith:meatware):	Started
 smb-meat-02	(stonith:meatware):	Started
Внимание! Если у Вас при запуске ресурса clvmd возникла ошибка 'Setup problem: couldn't find command: /usr/sbin/clvmd'

То необходимо сделать символическую ссылку:

# ln -s /sbin/clvmd /usr/sbin/clvmd
см. altbug #33362

Далее создадим кластерный LVM на общем диске /dev/sdb:

# pvcreate /dev/sdb
# vgcreate --clustered y sambacluster /dev/sdb
# lvcreate -n sambastorage -l +100%Free sambacluster

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

# fdisk -l | grep samba
Диск /dev/mapper/sambacluster-sambastorage: 32 GiB, 34355544064 байт, 67100672 секторов

Создание GFS2

Установим необходимые пакеты:

# apt-get install gfs2-utils

Отформатируем наше устройство в GFS2:

# mkfs.gfs2 -p lock_dlm -t samba_cluster:sambaclusterfs -j 2 /dev/mapper/sambacluster-sambastorage
/dev/mapper/sambacluster-sambastorage is a symbolic link to /dev/dm-0
This will destroy any data on /dev/dm-0
Are you sure you want to proceed? [y/n]y
Discarding device contents (may take a while on large devices): Done
Adding journals: Done 
Building resource groups: Done     
Creating quota file: Done
Writing superblock and syncing: Done
Device:                    /dev/mapper/sambacluster-sambastorage
Block size:                4096
Device size:               32,00 GB (8387584 blocks)
Filesystem size:           32,00 GB (8387582 blocks)
Journals:                  2
Resource groups:           129
Locking protocol:          "lock_dlm"
Lock table:                "samba_cluster:sambaclusterfs"
UUID:                      6902041b-96bb-5cc1-b39d-cc027998372f

В данном примере файловая система использует протокол lock_dlm. Кластер имеет имя samba_cluster, имя файловой системы — sambaclusterfs. Файловая система создана на /dev/mapper/sambacluster-sambastorage и содержит 2 журнала по количеству узлов в кластере.
На каждом узле создадим папку для монтирования созданной файловой системы:

# mkdir /mnt/smbfs/

Монтированием файловой системы будет заниматься Pacemaker, для этого создадим ресурс:

# crm configure primitive clusterfs Filesystem device="/dev/mapper/sambacluster-sambastorage" directory="/mnt/smbfs" fstype="gfs2" "options=noatime" op monitor interval=10s on-fail=fence

Клонируем его:

# crm configure clone cloneclusterfs clusterfs meta interleave=true

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

# crm configure order clvmbeforefs cloneclvmd cloneclusterfs

Теперь наш кластер выглядит так:

# crm resource show
 Clone Set: clonedlm [dlm]
     Started: [ samba01 samba02 ]
 Clone Set: cloneclvmd [clvmd]
     Started: [ samba01 samba02 ]
 smb-meat-01	(stonith:meatware):	Started
 smb-meat-02	(stonith:meatware):	Started
 Clone Set: cloneclusterfs [clusterfs]
     Started: [ samba01 samba02 ]

Настройка CTDB

Установим необходимые пакеты на всех узлах:

# apt-get install samba samba-client ctdb resource-agents-CTDB

Сервисом CTDB должен управлять Pacemaker, он не должен запускаться автоматически:

# systemctl disable ctdb

Создадим на кластерной файловой системе каталог ctdb. В каталоге /etc/ctdb файлы nodes для Samba на каждом узле:

# mkdir /mnt/smbfs/ctdb
# touch /etc/ctdb/nodes

В файле /etc/ctdb/nodes перечислим IP адреса всех узлов кластера:

# cat /etc/ctdb/nodes
192.168.135.221
192.168.135.223

Скопируем файл на другие узлы:

# crm cluster copy /etc/ctdb/nodes
OK: samba02

Пример конфигурации Samba:

# cat /etc/samba/smb.conf
[global]
security = user
log file = /var/log/samba/log.%m
workgroup = WORKGROUP
server string = Samba Cluster
netbios name = SambaCluster
log file = /var/log/samba/log.%m
max log size = 100
security = user
domain master = no
domain logons = no
local master = no
os level = 33
preferred master = no
load printers = no
lock directory = /mnt/smbfs/ctdb
...

Добавим общую папку в конфигурацию samba на каждом узле:

# cat /etc/samba/smb.conf
...
[test]
comment = Samba Cluster Share
path = /mnt/smbfs/testshare
browseable = yes
writable = yes
...

Скопируем файл конфигурации на все узлы:

# crm cluster copy /etc/samba/smb.conf
OK: samba02

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

# crm ra meta ocf:heartbeat:CTDB

Создадим ресурс:

# crm configure
crm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \
   ctdb_recovery_lock="/mnt/smbfs/ctdb/ctdb.lock" \
   ctdb_manages_samba="yes" \
   ctdb_manages_winbind="no" \
   ctdb_service_smb="smb" \
   ctdb_service_nmb="nmb" \
   ctdb_start_as_disabled="yes" \
crm(live)configure# commit

Склонируем ресурс:

# crm configure clone clonectdb ctdb meta globally-unique="false" interleave="true"

Настроим так чтобы кластерная файловая система и CTDB запускались на одном узле:

# crm configure colocation clonectdb-with-cloneclusterfs inf: clonectdb cloneclusterfs

Настроим порядок загрузки ресурсов:

# crm configure order cloneclusterfs-before-clonectdb cloneclusterfs clonectdb

В итоге наш кластер будет выглядеть так:

# crm resource show
 Clone Set: clonedlm [dlm]
     Started: [ samba01 samba02 ]
 Clone Set: cloneclvmd [clvmd]
     Started: [ samba01 samba02 ]
 smb-meat-01	(stonith:meatware):	Started
 smb-meat-02	(stonith:meatware):	Started
 Clone Set: cloneclusterfs [clusterfs]
     Started: [ samba01 samba02 ]
 Clone Set: clonectdb [ctdb]
     Started: [ samba01 samba02 ]
Внимание! Если у Вас при запуске ресурса ctdb возникла ошибка 'Failed to execute /usr/sbin/ctdbd.' выполните:
# sed -i 's/$start_as_disabled $log_option $pub_addr_option/$start_as_disabled $pub_addr_option/' /usr/lib/ocf/resource.d/heartbeat/CTDB
см. altbug #33353


Настройка IPaddr2

Теперь нам необходимо настроить ресурс, который будет управлять виртуальным IP адресом:

# crm configure primitive ip ocf:heartbeat:IPaddr2 params ip=192.168.135.251 op monitor interval=20s

Укажем, что он может запускаться только после ресурса clonectdb:

# crm configure order clonectdb-before-ip inf: clonectdb ip

Укажем, что он может запускаться только вместе с clonectdb:

# crm configure colocation ip-with-clonectdb inf: ip clonectdb

Проверка работоспособности

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

# useradd smbtest
# smbpasswd -a smbtest

Проверим доступность файл-сервера по виртуальному IP:

$ smbclient -L 192.168.135.251 -U smbtest
Enter smbtest's password: 
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.6.2]

	Sharename       Type      Comment
	---------       ----      -------
	test            Disk      Samba Cluster Share
	IPC$            IPC       IPC Service (Samba Cluster)
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.6.2]

	Server               Comment
	---------            -------
	SAMBACLUSTER         Samba Cluster

	Workgroup            Master
	---------            -------
	WORKGROUP     

Выключим узел с виртуальным IP-адресом и повторим проверку.