Заметки на память

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Samba Cluster ======
===== Введение =====
Предоставление файловых сервисов пользователям является типичной задачей и трудно найти офисную сеть в которой такие сервисы не работают. Наиболее распространенные протоколы - **NFS**(сетевая файловая система) и **CIFS**(windows shares и их аналог в *nix Samba), второй встречается намного чаще. В некоторых же бизнес-процессах файловый сервис занимает ключевую роль, например как в моей сети. У меня имеется хранилище объемом больше сотни терабайт и клиенты, которые исчисляются сотнями, работающие с этим хранилищем по протоколу CIFS. Каждый клиент подключен к сети по 1Гбит линку. Глядя на эти исходные данные, становится понятно, что CIFS-сервер должен быть достаточно производительным и иметь скоростной канал связи, например 10Гбит, но и этого со временем становится не достаточно, рано или поздно наступает момент, когда в высоту расти уже не получается(т.е. увеличивать производительность одного сервера), приходит время расти в ширину(т.е. увеличивать кол-во серверов), чем собственно в этой статье и займемся.

Итак, исходные данные: имеем сотни терабайт данных и сотни высокоскоростных клиентов. Задача: построить отказоустойчивый высокоскоростной файловый кластер под управлением **Linux** и **Samba**. Кластер должен выполнять задачу подмены вышедших из строя узлов, а также распределение нагрузки по всем узлам кластера.

Для решения этой задачи будет использоваться свободный аналог Red Hat 7 - Centos 7, хотя я и являюсь сторонником GNU/Debian, но в данной задачей, когда речь идет о дорогом брендовом оборудовании, чтобы не поиметь проблем с совместимостью, лучше использовать рекомендованные и поддерживаемые вендором ОС.

Основные компоненты схематично указаны на рисунке ниже.

{{ :samba_cluster:samba_cluster.png?direct&500 |}}

Как видно из схемы, два(или более) сервера имеют доступ к общему хранилищу данных, чтобы корректно с ним работать, кто-то должен отвечать за контроль доступа к хранилищу и за блокировки, т.к. никак не связанные между собой сервера работают с общим ресурсом. Именно этой задачей, т.е. межпроцессной синхронизацией, и будет заниматься **DLM**(distrubuted lock manager). Далее нам понадобится кластерная файловая система, например **GFS**, в этой статье используется GFS2, она не работает напрямую с блочными устройствами, для нее нужен **LVM**(logical volume manager), но в нашем случае нужна кластерная его реализация - **CLVM**, но хорошая новость в том, что CLVM отличается от LVM по большому счету только наличием сервиса clvmd и небольшими настройками конфигурационного файла. Ну и наконец поверх DLM и CLVM находится сама кластерная ФС - GFS2. Всеми этими компонентами управляет [[pacemaker_theory|Pacemaker]], он обеспечивает запуск нужных служб, на нужных узлах и в нужном порядке, а также отслеживает их состояние, т.е. выполняет мониторинг.

Итак, кластерная ФС, которая доступна на всех узлах у нас уже есть, осталось запустить файловую службу **Samba**, в этой статье используется 4-ая ветка. Но просто так это сделать нельзя, если мы не хотим получить неожиданные результат, например в виде испорченных данных. Т.е. Samba также нуждается в механизме управления блокировками, более того у всех узлов должна быть общая БД. В Samba используется **TDB**(trivial data base), в нашей конфигурации потребуется ее кластерная реализация - **CTDB**, которая кроме всего прочего умеет еще самостоятельно управлять службами **winbind** и **smbd**, т.е. запускать и останавливать их на нужных узлах и самое главное - CTDB берет на себя ф-ию по управлению IP-адресами узлов. Что это значит? Допустим у нас есть два узла с адресами 1.1.1.1 и 2.2.2.2 и один из узлов стал недоступен, об этом сразу станед известно CTDB и эта служба перенесет оба IP-адреса на оставшийся работающий узел, а  также разошлет всем клиентам отказавшего узла уведомления о том, что TCP-соединение необходимо переустановить.

<note>
Во всех документациях говорится, что по фен шую функционал по управлению службами smbd, winbind, а также IP-адресами должен выполнятся службой управления кластера Pacemaker. Т.е. CTDB должен быть сконфигурирован таким образом, что он не будет управлять ни службами, ни IP-адресами кластера. Он должен быть сконфигурирован как отдельный ресурс кластера, службы smbd и winbind также ресурсы кластера, которые запускаются после CTDB и IP-адреса аналогично, присваиваются после запуска smbd. Все это должно быть сконфигурировано таким образом с точки зрения красоты архитектуры, чтобы узлами кластера управляла одна система - Pacemaker, а не две Pacemaker и CTDB.
В Pacemaker есть даже **RA**(resource agent) //ocf:heartbeat:CTDB//, который управляет службой CTDB, есть RA ocf:heartbeat:IPaddr2 для управления IP-адресами, есть даже RA ocf:heartbeat:portblock для отсылки уведомлений клиентам о том, что узел более недоступен(Tickle ACK), НО до сих пор нет RA для управления smbd и winbind, поэтому этими службами все же должен управлять CTDB, якобы это временно и вот-вот должны появится RA для Samba, но это было написано в 2010г и на текущий момент(2014г) ничего не изменилось. Поэтому лично я не вижу смысла отдавать управление адресами и Samba Pacemaker'у, потому что, во-первых, это несколько усложняет конфигурацию кластера, во-вторых, с этой задачей неплохо справляется сам CTDB и у него хорошо проработанные утилиты для мониторига и отслеживания состояния кластера.
</note>

===== Подготовка системы =====
Имеем два хоста с установленной ОС Linux Centos 7. Выполняем обновление системы.
  # yum update

Отключаем SELinux, редактируем /etc/sysconfig/selinux:
  SELINUX=disabled
  
Выключаем фаервол
  # systemctl stop firewalld
  # systemctl disable firewalld

либо добавляем правила разрешающие узлам кластера взаимодействовать
  # firewall-cmd --permanent --add-service=high-availability
  # firewall-cmd --add-service=high-availability

Настраиваем сеть, на каждом хосте по два сетевых интерфейса eth0 и eth1, первый используется для внутрикластерного взаимодействия и имеет сеть 192.168.232.0/24, а второй для обслуживания клиентов, сеть 10.0.0.0/24. Если в кластере всего два узла, то рекомендуется подключить интерфейсы eth0 напрямую друг к другу кросс-кабелем, для того, чтобы избежать лишней точки отказа - свитча. Итак, конфигурируем сеть, у первого узла будет адрес 192.168.232.10, у второго 192.168.232.20. Пример конфига /etc/sysconfig/network-scripts/ifcfg-eth0:
  DEVICE=eth0
  ONBOOT=yes
  BOOTPROTO=static
  TYPE=Ethernet
  IPADDR=192.168.232.10
  PREFIX=24

Настраиваем имена хостов, допустим samba_node1 и samba_node2, соответственно на каждом узле отдельно, /etc/hostname:
  samba_node1

Теперь надо настроить надежное разрешение имен на обоих узлах, а еще лучше, чтобы не зависеть еще от одного сервиса(DNS) и избавиться от дополнительной точки отказа, пропишем соответствие адреса и имени на каждом узле в /etc/hosts:
  192.168.232.10 samba_node1
  192.168.232.20 samba_node2

Перезагружаем оба узла
  # reboot

Проверяем на обоих узлах
  [samba_node1 ~]# ping -c 1 samba_node2
  PING samba_node2 (192.168.232.20) 56(84) bytes of data.
  64 bytes from samba_node2 (192.168.232.20): icmp_seq=1 ttl=64 time=0.297 ms
  
  [samba_node2 ~]# ping -c 1 samba_node1
  PING samba_node1 (192.168.232.10) 56(84) bytes of data.
  64 bytes from samba_node1 (192.168.232.10): icmp_seq=1 ttl=64 time=0.323 ms

Устанавливаем необходимое ПО
  # yum groupinstall "High Availability"
  # yum install samba samba-client gfs2-utils ctdb

===== Первоначальная настройка кластера =====
На всех узлах устанавливаем пароль на пользователя hacluster
  # passwd hacluster

Включаем сервис pcsd на всех узлах
  # systemctl start pcsd.service
  # systemctl enable pcsd.service

Авторизуем узлы в кластере(команда выполняется на любом узле), авторизуемся с пользователем hacluster и паролем, который установили ранее
  # pcs cluster auth samba_node1 samba_node2
  Username: hacluster
  Password:
  samba_node1: Authorized
  samba_node2: Authorized

Создаем кластер(команда выполняется на любом узле)
  # pcs cluster setup --start --name samba_cluster samba_node1 samba_node2
  Shutting down pacemaker/corosync services...
  Redirecting to /bin/systemctl stop  pacemaker.service
  Redirecting to /bin/systemctl stop  corosync.service
  Killing any remaining services...
  Removing all cluster configuration files...
  samba_node1: Succeeded
  samba_node1: Starting Cluster...
  samba_node2: Succeeded
  samba_node2: Starting Cluster...
  
Здесь samba_node1 и samba_node2 - имена узлов кластера, а samba_cluster - имя создаваемого кластера. В результате выполнения этой команды будет сгенерирован файл /etc/corosync/corosync.conf примерно такого содержания:
  totem {
  version: 2
  secauth: off
  cluster_name: samba_cluster
  transport: udpu
  }
  
  nodelist {
    node {
          ring0_addr: samba_node1
          nodeid: 1
         }
    node {
          ring0_addr: samba_node2
          nodeid: 2
         }
  }
  
  quorum {
  provider: corosync_votequorum
  two_node: 1
  }
  
  logging {
  to_syslog: yes
  }

Включаем автозагрузку кластера(команда выполняется на любом узле)
  # pcs cluster enable --all
  samba_node1: Cluster Enabled
  samba_node2: Cluster Enabled

Выключаем механизм stonith(команда выполняется на любом узле)
  # pcs property set stonith-enabled=false

<note important>
Механизм stonith отвечает за физическое отключение узла кластера, это может понадобится, когда связь с этим узлом потеряна и его состояние не известно, поэтому во избежании порчи данных узел с неизвестным состоянием изолируется(fence), т.е. физически выключается. Обычно для этих задач используют специальные адаптеры питания с функцией управления по сети. В боевых условиях отключать механизм stonith крайне не рекомендуется, но т.к. мы настраивает тестовую конфигурацию, мы так поступим.
</note>

Вот и все, первичная настройка кластера завершена, убедиться в этом можно выполнив следующую команду:
  # pcs status
  Cluster name: samba_cluster
  Last updated: Tue Sep 16 19:00:28 2014
  Last change: Tue Sep 16 19:00:11 2014 via cibadmin on samba_node2
  Stack: corosync
  Current DC: samba_node1 (1) - partition with quorum
  Version: 1.1.10-32.el7_0-368c726
  2 Nodes configured
  0 Resources configured
  
  
  Online: [ samba_node1 samba_node2 ]
  
  Full list of resources:
  
  
  PCSD Status:
    samba_node1: Online
    samba_node2: Online
  
  Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

Как видно, оба узла онлайн, в качестве DC(Designated Co-ordinator) выбран узел samba_node1. Пока что наш кластер работает в холостую и не управляет никакими ресурсами(сервисами), этим мы займемся дальше.

===== Подключение LVM к кластеру =====
Включаем cluster locking в конфиге LVM и включаем автозагрузку демона lvmetad, все это можно сделать одной командой:

  # lvmconf --enable-cluster
  
Проверяем, должно ровняться 3

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

Теперь создаем два клонированных ресурса. Первый распределенный менеджер блокировок и второй - кластерный LVM(команды выполняются на любом узле)

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

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

  # pcs constraint order start dlm-clone then clvmd-clone
  # pcs constraint colocation add clvmd-clone with dlm-clone

Проверяем, что ресурсы успешно стартанули на обоих узлах

  # pcs resource show
   Clone Set: dlm-clone [dlm]
       Started: [ samba_node1 samba_node2 ]
   Clone Set: clvmd-clone [clvmd]
       Started: [ samba_node1 samba_node2 ]

Ну а теперь создаем LVM том как обычно, все дальнейшие команды ничем не отличаются от обычной, не кластерной LVM(предполагается, что общий диск у всех нод - /dev/sdb). Команды выполнять только на одном узле.

  # pvcreate /dev/sdb
  # vgcreate samba_cluster /dev/sdb
  # lvcreate -n samba_cluster -l100%FREE samba_cluster
  
Смотрим на обоих нодах(по-умолчанию тома должны быть видимы на всех нодах)

  # ls /dev/samba_cluster/samba_cluster

===== Создание кластерной ФС и подключение ее к кластеру =====

Создаем кластерную ФС GFS2 поверх только что созданного LVM тома. Кол-во журналов(-j 2) соответствует кол-ву нод кластера, протокол блокировки для кластера - lock_dlm

  # mkfs.gfs2 -p lock_dlm -t samba_cluster:cluster_FS -j 2 /dev/samba_cluster/samba_cluster
  
  /dev/samba_cluster/samba_cluster is a symbolic link to /dev/dm-2
  This will destroy any data on /dev/dm-2
  Are you sure you want to proceed? [y/n]y
  
  Device:                    /dev/samba_cluster/samba_cluster
  Block size:                4096
  Device size:               10,00 GB (2620416 blocks)
  Filesystem size:           10,00 GB (2620413 blocks)
  Journals:                  2
  Resource groups:           40
  Locking protocol:          "lock_dlm"
  Lock table:                "samba_cluster:cluster_FS"
  UUID:                      a750c8de-b4bc-2b0b-90ef-0a609319a657  

После создания ФС можно попробовать ее примонтировать на обоих узлах

  # mount /dev/samba_cluster/samba_cluster /mnt/

Не забываем отмонтировать и проверить, что ФС не прописана в fstab, ее монтировать будет кластер.

Настаиваем кластер(все команды выполняются на одном узле). Задаем поведение, требуемое при отсутствии кворума(чтобы не пострадали данные в случаи split brain)

  # pcs property set no-quorum-policy=freeze

Создаем ресурс ФС, в случае необходимости к опциям можно добавить acl

  # pcs resource create clusterfs Filesystem device="/dev/samba_cluster/samba_cluster" directory="/mnt" fstype="gfs2" "options=noatime" op monitor interval=10s on-fail=fence clone interleave=true
  
И наконец настраиваем порядок запуска и зависимости, т.е. ФС должна монтироваться после готовности LVM

  # pcs constraint order start clvmd-clone then clusterfs-clone
  # pcs constraint colocation add clusterfs-clone with clvmd-clone

Проверяем, что все работает

  # pcs resource show
   Clone Set: dlm-clone [dlm]
       Started: [ samba_node1 samba_node2 ]
   Clone Set: clvmd-clone [clvmd]
       Started: [ samba_node1 samba_node2 ]
   Clone Set: clusterfs-clone [clusterfs]
       Started: [ samba_node1 samba_node2 ]
  
  # df -h
  /dev/mapper/samba_cluster-samba_cluster    10G         259M  9,8G            3% /mnt

Как видим, ФС примонтирована и все ресурсы у кластера в рабочем состоянии. На этом настройка pacemaker закончена, переходим к заключительному этапу - настройка CTDB.

===== Настройка CTDB =====

Создаем на кластерной ФС директорию для Samba и файлы nodes, public_addresses для CTDB

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

Редактируем конфиг /etc/sysconfig/ctdb

  CTDB_RECOVERY_LOCK="/mnt/ctdb/.ctdb.lock"
  CTDB_NODES=/etc/ctdb/nodes
  CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
  CTDB_MANAGES_SAMBA=yes
  CTDB_MANAGES_WINBIND=no
  CTDB_MANAGES_NFS=no
  CTDB_DEBUGLEVEL=NOTICE
  
Если Samba интегрирована с Active Directory, то включаем еще опцию CTDB_MANAGES_WINBIND.

В файле nodes перечислены IP-адреса всех узлов кластера, через которые взаимодействует ПО управления кластером - pacemaker и CTDB, эти адреса могут быть на отдельных интерфейсах, как уже упоминалось.

  # cat /etc/ctdb/nodes
  192.168.232.10
  192.168.232.20

Файл public_addresses содержит IP-адреса узлов через которые кластер обслуживает клиентов. Как упоминалось, этот файл нужен в случае если адресами управляет CTDB, он сам решит на какой узел какой адрес отдать. После адреса через пробел указывается сетевая карта, которой этот адрес присвоить, нужно перечислить все возможные варианты на всех узлах.

  # cat /etc/ctdb/public_addresses
  10.0.0.100/24 eth1
  10.0.0.200/24 eth1

И наконец редактируем конфиг Samba, он должен быть одинаков на всех узлах.

  [global]
          workgroup = COMPANY
          server string = Samba Test Cluster
          netbios name = MEGACLUSTER
          max protocol = SMB2
          log file = /var/log/samba/log.%m
          max log size = 1000
          security = user
          domain master = no
          domain logons = no
          local master = no
          os level = 33
          preferred master = no
          load printers = no
  
  # ----------------------- Cluster Options ------------------------
          clustering = yes
          # Две опции ниже важные, должны обязательно указывать на кластерную ФС, иначе можно
          # получить странные глюки
          private dir = /mnt/ctdb
          lock directory = /mnt/ctdb
          idmap backend = tdb2		
          passdb backend = tdbsam
  
  #============================ Share Definitions ==============================
  
  [test]
          comment = Cluster Share
          path = /mnt/share
          browseable = yes
          writable = yes

Наконец включаем CTDB

  # systemctl enable ctdb.service
  # systemctl start ctdb.service

После чего он должен распределить адреса по узлам и запустить Samba. Проверяем:

  # ctdb status
  Number of nodes:2
  pnn:0 192.168.232.10   OK
  pnn:1 192.168.232.20   OK (THIS NODE)
  Generation:388325546
  Size:2
  hash:0 lmaster:0
  hash:1 lmaster:1
  Recovery mode:NORMAL (0)
  Recovery master:0
  
  # ctdb ip
  Public IPs on node 1
  10.0.0.100 0
  10.0.0.200 1
  
  # ip address show
  
  3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
      link/ether 00:0c:29:15:60:7b brd ff:ff:ff:ff:ff:ff
      inet 10.0.0.100/24 brd 10.0.0.255 scope global eno33554976
         valid_lft forever preferred_lft forever
  
  # smbcontrol smbd ping
  PONG from pid 1:5658

Если Samba интегрирована с AD теперь можно попробовать подключиться со стороны клиента,  если нет, то создаем учетную запись пользователя.
Заметки на память

Инструменты пользователя

Инструменты сайта

Инструменты страницы
