Различия

Показаны различия между двумя версиями страницы.

--- centos_7_samba_cluster [2014/09/16 12:22]
metallic [Введение]
+++ centos_7_samba_cluster [2022/03/25 17:00] (текущий)
@@ Строка 1: / Строка 1: @@
 ====== Samba Cluster ======
 ===== Введение =====
-Предоставление файловых сервисов пользователям является типичной задачей и трудно найти офисную сеть в которой такие сервисы не работают. Наиболее распространенные протоколы - **NFS**(сетевая файловая система) и **CIFS**(windows shares и их аналог в *nix Samba), второй встречается намного чаще. В некоторых же бизнес-процессах файловый сервис занимает ключевую роль, например как в моей сети. У меня имеется хранилище объемом больше сотни террабайт и клиенты, которые исчисляются сотнями, работающие с этим хранилищем по протоколу CIFS. Каждый клиент подключен к сети по 1Гбит линку. Глядя на эти исходные данные, становится понятно, что CIFS-сервер должен быть достаточно производительным и иметь скоростной канал связи, например 10Гбит, но и этого со временем становится не достаточно, рано или поздно наступает момент, когда в высоту расти уже не получается(т.е. увеличивать производительность одного сервера), приходит время расти в ширину(т.е. увеличивать кол-во серверов), чем собственно в этой статье и займемся.
+Предоставление файловых сервисов пользователям является типичной задачей и трудно найти офисную сеть в которой такие сервисы не работают. Наиболее распространенные протоколы - **NFS**(сетевая файловая система) и **CIFS**(windows shares и их аналог в *nix Samba), второй встречается намного чаще. В некоторых же бизнес-процессах файловый сервис занимает ключевую роль, например как в моей сети. У меня имеется хранилище объемом больше сотни терабайт и клиенты, которые исчисляются сотнями, работающие с этим хранилищем по протоколу CIFS. Каждый клиент подключен к сети по 1Гбит линку. Глядя на эти исходные данные, становится понятно, что CIFS-сервер должен быть достаточно производительным и иметь скоростной канал связи, например 10Гбит, но и этого со временем становится не достаточно, рано или поздно наступает момент, когда в высоту расти уже не получается(т.е. увеличивать производительность одного сервера), приходит время расти в ширину(т.е. увеличивать кол-во серверов), чем собственно в этой статье и займемся.
-Итак, исходные данные: имеем сотни террабайт данных и сотни высокоскоростных клиентов. Задача: построить отказоустойчивый высокоскоростной файловый кластер под управлением **Linux** и **Samba**. Кластер должен выполнять задачу подмены вышедших из строя узлов, а также распределение нагрузки по всем узлам кластера.
+Итак, исходные данные: имеем сотни терабайт данных и сотни высокоскоростных клиентов. Задача: построить отказоустойчивый высокоскоростной файловый кластер под управлением **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]], он обеспечивает запуск нужных служб, на нужных узлах и в нужном порядке, а также отслеживает их состояние, т.е. выполняет мониторинг.
+Как видно из схемы, два(или более) сервера имеют доступ к общему хранилищу данных, чтобы корректно с ним работать, кто-то должен отвечать за контроль доступа к хранилищу и за блокировки, т.к. никак не связанные между собой сервера работают с общим ресурсом. Именно этой задачей, т.е. межпроцессной синхронизацией, и будет заниматься **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-соединение необходимо переустановить.
+Итак, кластерная ФС, которая доступна на всех узлах у нас уже есть, осталось запустить файловую службу **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>
@@ Строка 19: / Строка 19: @@
 В 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:
+.168.232.10 samba_node1
+.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.
+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.
+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
+Nodes configured
+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
+.168.232.10
+.168.232.20
+Файл public_addresses содержит IP-адреса узлов через которые кластер обслуживает клиентов. Как упоминалось, этот файл нужен в случае если адресами управляет CTDB, он сам решит на какой узел какой адрес отдать. После адреса через пробел указывается сетевая карта, которой этот адрес присвоить, нужно перечислить все возможные варианты на всех узлах.
+  # cat /etc/ctdb/public_addresses
+.0.0.100/24 eth1
+.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
+.0.0.100 0
+.0.0.200 1
+  # ip address show
+: 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 теперь можно попробовать подключиться со стороны клиента,  если нет, то создаем учетную запись пользователя.

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

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

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

Различия

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