В статье рассказывается об организации отказоустойчивого файлового сервера на базе пакета Samba. Для понимания материала необходимо иметь общие представления об администрировании ОС Linux, а также опыт работы с обычной версией Samba. 
Samba — это служба CIFS, предназначенная для предоставления семантики протокола CIFS (и, следовательно, доступа с компьютеров Windows) к среде, использующей файловую систему POSIX. Основная функция Samba — преобразовать богатую семантику, используемую клиентами Windows, в гораздо более бедную семантику файловой системы POSIX.
Для выполнения этих преобразований Samba использует различные внутренние базы данных метаданных, которые содержат дополнительную информацию, используемую при семантическом преобразовании.
Дополнительные параметры, в частности, отвечают за такие вещи, как одновременное открытие одного и того же файла с разных клиентов и многое другое.
Эта информация обязательно обрабатывается перед непосредственным открытием файла в POSIX. Это позволяет клиентам Windows прозрачно получать доступ к файловой системе POSIX. Отказоустойчивость Samba основана на трех принципах:
- Восстановление метаданных Samba
- Доступность пользовательских файлов на основе кластерной файловой системы.
- Механизм защиты от сбоев сети, заключающийся в передаче IP-адреса с вышедшего из строя узла на рабочий узел.
В данной статье описан только механизм создания отказоустойчивого сервиса CIFS. Обязательным условием ее реализации является использование параллельной кластерной файловой системы, которая используется непосредственно для хранения файлов.
Описание кластерных систем выходит за рамки данной статьи.
В качестве примера можно использовать файловые системы GPFS или Lustre.
Базы метаданных – Тривиальная база данных
Обычные некластеризованные версии Samba используют для хранения данных очень простую и малоресурсную базу данных под названием Trivial Database (TDB).TDB организована по принципу «ключ-значение» и аналогична организации Berkley DB. TDB обеспечивает очень быстрый множественный доступ, как для чтения, так и для записи, из различных процессов в системе POSIX. Отображение памяти (mmap) поддерживается большинством архитектур.
Каждое клиентское соединение с файловой системой обслуживается собственным процессом-демоном smbd. Эти процессы взаимодействуют друг с другом через базу данных TDB. Ранние попытки реализовать кластерную версию SAMBA заключались в простом размещении файлов, содержащих TDB, в кластерной файловой системе, такой как GPFS или Lustre. Эти реализации SAMBA работали, но были чрезвычайно медленными.
Снижение скорости произошло из-за высоких накладных расходов и задержек в протоколах синхронизации кластерных файловых систем.
Хотя для успешной работы Samba необходимо обеспечить очень быстрый доступ к TDB. В основе функционирования кластерных файловых систем лежит защита данных от потери.
Даже если клиент начнет записывать данные, а узел, куда они должны были записаться, выйдет из строя, они не будут потеряны.
Таким образом, кластерная файловая система должна либо записывать данные в общее хранилище, либо распространять изменения на все узлы кластера.
Однако это утверждение не совсем верно для метаданных Samba. В определенных ситуациях потеря этих данных не повлияет на возможность выполнения необходимого семантического преобразования между CIFS и POSIX. Таким образом, становится возможным реализовать кластерную систему, не требующую общего хранилища метаданных и репликации данных на основе записи.
Скажем сразу, это касается не всех метаданных.
Существует два типа баз данных TDB — постоянные и непостоянные.
Постоянный (Постоянные) — содержат долгосрочную информацию, которая должна сохраняться даже после перезапуска.
Эти базы данных в основном используются для чтения, а не для записи.
Скорость доступа на запись в базу данных этого типа не имеет решающего значения.
Здесь главное надежность.
непостоянный - например, база данных блокировки или сеанса.
Данные, хранящиеся здесь, имеют короткий жизненный цикл.
Частота записи в эти базы данных очень высока.
Их также часто называют «обычными TDB».
Для успешной работы Samba особенно важна высокая производительность при работе с «обычными TDB».
Потеря информации возможна только для непостоянных баз данных.
В таблицах ниже представлен список и описание баз данных, используемых в реализации кластера Samba. Таблица 1. Постоянные базы данных TDB
| Имя | ОПИСАНИЕ |
| учетная_политика | Параметры политики учетных записей Samba/NT, включая параметры срока действия пароля.
|
| group_mapping | Таблица соответствия групп/SID Windows и групп UNIX. |
| passdb | Существует только при использовании tdbsam. В этом файле хранится информация SambaSAMAAccount. Обратите внимание, что для этого файла требуется, чтобы информация об учетной записи пользователя POSIX была доступна из файла /etc/passwd или другого системного источника.
|
| реестр | База данных Samba, доступная только для чтения, в которой хранится скелет реестра Windows, обеспечивающий поддержку экспорта различных таблиц базы данных через Winreg RPC (удаленные вызовы процедур).
|
| секреты | В этом файле хранятся SID рабочей группы/домена/компьютера, пароль обновления каталога LDAP и другие важные данные среды, необходимые для правильной работы Samba. Этот файл содержит очень важную информацию, которую необходимо защитить.
Он хранится в каталоге PRIVATE_DIR. |
| поделиться_информацией | Хранит информацию ACL для каждого ресурса.
|
| Идмап2 | База данных IDMAP Winbindd. |
| Имя | ОПИСАНИЕ |
| блокировать | Информация о блокировках диапазона байтов.
|
| Блокировка | Таблица блокировки файловой системы |
| связи | Временный кэш текущей информации о соединении, используемый для отслеживания максимального количества подключений.
|
| Notify_onelevel | Предположительно используется для обмена сообщениями между демонами ctdb. |
| поставить в известность | Предположительно используется для обмена сообщениями между демонами ctdb. |
| идентификатор сессии | Временный кеш для различной информации о сеансе и служб utmp. |
Это информация о сессиях, блокировках, а также, судя по всему (нет данных в интернете) конкретная информация, необходимая для работы кластера.
При выходе узла из строя все открытые файлы на нем будут закрыты, поэтому потеря вышеуказанной информации не будет критичной.
Демон CTDBD и работа с базами данных TDB в кластере
Ключевым компонентом кластера Samba является демон CTDBD. Он обеспечивает поддержку кластерной версии баз данных TDB, называемой CTDB (Cluster Trivial DataBase), с возможностью их автоматического восстановления.CTDBD также контролирует узлы кластера и выполняет автоматическую реконфигурацию в случае сбоя.
Обеспечение балансировки нагрузки — еще одна задача CTDBD. В зависимости от типа базы данных она обрабатывается по-разному.
Работа с временной БТ
Ключевой особенностью временных БТ является то, что им не обязательно содержать все записи в кластере.В большинстве случаев временные БТ содержат только записи, относящиеся к соединениям этого конкретного узла.
Соответственно, если он упадет, будут потеряны только эти данные.
Система CTDB использует распределенный протокол для операций с базой данных метаданных между демонами CTDBD на каждом узле и локальный протокол для внутриузловой связи между демонами Samba и демонами CTDBD. В конструкции CTDB используется двухуровневая система хранения записей.
На первом уровне для каждой записи определяется мастер местоположения.
Этот владелец связан с записью с помощью ее ключа.
На втором уровне определяется перемещающийся «мастер данных».
Это последний узел, изменивший запись.
«Мастер местоположения» всегда знает, на каком узле находится запись и, соответственно, какой узел является «мастером данных».
«Мастер данных», в свою очередь, содержит самую актуальную копию записи.
Каждая запись содержит глобальный порядковый номер — RSN (порядковый номер записи) — 64-битное целое число, которое увеличивается каждый раз, когда «мастер данных» перемещается от узла к узлу.
Смена владельца записи «Мастер данных» всегда происходит через «Мастер местоположения».
Узел содержит только записи в локальной БТ, к которым у него уже был доступ.
Данные не распространяются автоматически на другие узлы, а могут быть переданы только по запросу.
Только один узел содержит актуальную копию записи — «Мастер данных».
Когда какой-либо узел хочет записать или прочитать запись, он сначала проверяет, является ли он «мастером данных» для этого узла.
Если да, то он записывает непосредственно в TDB. Если нет, то он запрашивает текущее содержимое записи у текущего «мастера данных», берет на себя роль «мастера данных», а затем выполняет прямую запись.
Таким образом, данные всегда записываются и читаются локально, что существенно повышает производительность.
Когда узел умирает, записи, для которых он был «мастером данных», теряются.
CTDBD начинает процесс восстановления.
Для этого выберите хост-узел процесса восстановления – «мастер восстановления».
После выбора узла в кластерной файловой системе он устанавливает блокировку определенного файла (который задается в конфигурации), чтобы другие узлы больше не могли претендовать на роль «мастера восстановления».
«Recover Master» собирает самые актуальные версии записей со всех узлов.
Актуальность определяется значением RSN. Запись с наибольшим RSN считается наиболее актуальной.
Работа с постоянной БТД
Для этой базы данных каждый узел всегда имеет полную и актуальную копию базы данных.Чтение всегда происходит из локальной копии.
Когда любому узлу необходимо выполнить запись, он выполняет транзакцию, которая полностью блокирует всю базу данных на всех узлах.
Затем он выполняет необходимые операции записи.
Затем изменения записываются в локальные копии базы данных на всех узлах, и транзакция завершается.
Таким образом, все узлы кластера всегда содержат полную и актуальную копию базы данных.
Задержки, возникающие в процессе синхронизации, не критичны, ввиду низкой частоты изменений в этих базах данных.
При выходе из строя одного из узлов вся необходимая информация доступна об остальных участниках кластера.
Механизм защиты от сбоев сети
Помимо защиты базы данных метаданных, CTDBD использует интегрированный механизм защиты от сбоев протокола TCP/IP. Он состоит из кластера, использующего набор общедоступных IP-адресов, которые распределены между узлами кластера.Эти адреса могут передаваться от узла к узлу посредством обновлений ARP (протокола разрешения адресов).
Если какой-либо узел выйдет из строя, все его общедоступные IP-адреса будут переданы рабочим узлам.
Публичные адреса — это адреса, по которым клиенты связываются с вами.
Для связи между узлами кластера используются внутренние IP-адреса.
Узел, перенявший IP-адрес другого, знает о старых TCP-соединениях только то, что они существовали, и не знает «номер последовательности TCP» этих соединений.
Соответственно, он не может их продолжать.
Так же, как и клиент, он ничего не знает о том, что сейчас устанавливаются соединения с другим узлом.
Во избежание задержек, связанных с переключением соединения, используется следующий прием.
Чтобы понять эту технику, вам необходимо понять основные принципы протокола TCP. Новый узел, получив IP-адрес, отправляет клиенту пакет с флагом ACK и заведомо неверным «номером последовательности», равным нулю.
В ответ клиент в соответствии с правилами протокола TCP отправляет обратно пакет ACK Reply с правильным «порядковым номером».
Получив правильный «номер последовательности», узел формирует пакет с флагом RST и этим «номером последовательности».
Получив его, клиент немедленно перезапускает соединение.
Задержки очень минимальны.
Без этого метода клиент может долго ждать пакета TCP ACK от сервера.
На практике
Как уже говорилось выше, при выходе из строя одной из нод и переносе IP-адреса вся ответственность за продолжение работы после сбоя лежит на клиенте.Все открытые файлы, связанные с вышедшим из строя узлом, закрываются.
Если вы скопируете или прочитаете какой-либо файл в проводнике Windows, в случае сбоя вы получите сообщение об ошибке.
Однако если вы используете инструменты, способные восстановить соединение после потери соединения, все пройдет гладко.
Например, утилита xcopy с ключом «/z».
При копировании файлов с помощью этой утилиты у вас возникнет лишь небольшая задержка при переключении IP-адреса.
После этого копирование продолжится.
Соединение с сетевыми ресурсами также не теряется.
Если вы открыли файл в редакторе, и момент сохранения не наступил при перемещении IP-адреса, то сбои также не влияют на работу.
Таким образом, часть ответственности за восстановление работы после сбоя в этом случае перекладывается на клиента.
Настройка кластера Samba Настройка кластера состоит из двух шагов:
- Настройка демона Samba для работы в кластере
- Настройка ЦТБД
Настройка Samba и сопутствующих сервисов
Начиная с версии 3.3, собственные тесты Samba имеют встроенную поддержку кластеризации.Однако для работы в кластере необходимо скомпилировать пакет, используя специальные ключи.
С сайта предприятияsamba.com вы можете скачать скомпилированную версию Samba с поддержкой кластеризации для популярных дистрибутивов: RHEL, SLES, Debian. Важная заметка.
Чтобы клиенты Windows могли успешно пройти аутентификацию в кластере Samba, желательно использовать внешнюю авторизацию.
Например, через Active Directory. Чтобы пользователи Windows могли получить доступ к файловой системе Posix, Samba сопоставляет пользователя Windows с пользователем системы POSIX (например, Linux).
Пользователь Windows должен получить доступ к файловой системе POSIX под именем какой-либо известной пользовательской операционной системы POSIX. Авторизация пользователя Windows происходит независимо от авторизации пользователя в ОС POSIX. Те.
Для того чтобы пользователь Windows получил доступ необходимо:
- Создайте локального пользователя в операционной системе POSIX, от имени которого будет работать пользователь Windows.
- Создайте пользователя Windows в базе данных Samba и установите для него пароль.
- Установить связь между этими пользователями
Однако локальная база пользователей не имеет такой возможности.
Те.
Каждый раз, когда мы создаем пользователей в Samba, нам придется создавать соответствующие локальные учетные записи на всех узлах кластера.
Это неудобно.
Чтобы этого избежать, имеет смысл использовать внешнюю базу данных вместе с локальной базой пользователей.
В нашем случае мы используем интеграцию с Active Directoty. Кластер Samba является членом домена.
В файле /etc/nsswitch.conf нужно написать: passwd: файлы winbind группа: файлы winbind тень: файлы Winbind Это означает, что помимо локальных файлов поиск пользователей и групп будет осуществляться в Active Directory через winbind. Служба winbind позволяет пользователям домена Windows входить на машины Unix. Это обеспечивает прозрачный контроль доступа.
Авторизация в домене Active Directory осуществляется по протоколу Kerberos. Необходимо сделать соответствующие настройки библиотеки Kerberos — «/etc/krb5.conf».
[Ведение журнала] по умолчанию = ФАЙЛ:/var/log/krb5libs.log kdc = ФАЙЛ:/var/log/krb5kdc.log admin_server = ФАЙЛ:/var/log/kadmind.log [libdefaults] default_realm = IT-DYNAMICS.RU – домен Active Directory dns_lookup_realm = true — избавляет от необходимости вручную регистрировать серверы dns_lookup_kdc = true — исключает необходимость ручной регистрации серверов Ticket_lifetime = 24 часа пересылаемый = да [область_домена] .
it-dynamics.ru = IT-DYNAMICS.RU .
it-dynamics.ru = IT-DYNAMICS.RU [по умолчанию] Пэм = { отладка = ложь Ticket_lifetime = 36000 renew_lifetime = 36000 пересылаемый = правда krb4_convert = ложь } И, наконец, вам нужно настроить саму Samba. [Глобальный] кластеризация = да имя netbios = smbcluster рабочая группа = otd100 безопасность = АДС область = IT-DYNAMICS.RU шифровать пароли = да клиент lanman аутентификация = нет клиент ntlmv2 аутентификация = да серверная часть passdb = tdbsam groupdb:backend = tdb серверная часть idmap = tdb2 идентификатор карты uid = 1000000-2000000 idmap gid = 1000000-2000000 fileid:алгоритм = имя_фс объекты vfs = идентификатор файла gpfs gpfs:sharemodes = Нет принудительно неизвестный пользователь ACL = да nfs4: режим = специальный nfs4:chown=да nfs4:acedub=объединить общие ресурсы реестра = да Ключевой параметр в /etc/samba/smb.conf — «clustering = yes».
Включите поддержку кластеризации.
В параметрах «netbios name» указываем имя нашего кластера, которое будет общим для всех узлов.
Чтобы прозрачно управлять общими ресурсами, вам необходимо включить поддержку реестра в настройках Samba – «разделы реестра = да».
В противном случае, если настройки общих папок содержатся в smb.conf, мы будем вынуждены синхронизировать этот файл между всеми узлами кластера.
В любом случае файл «/etc/samba/smb.conf» должен быть одинаковым на всех узлах.
Для успешной авторизации пользователей кластер Samba необходимо добавить в домен Active Directory с помощью команды: netadsjoin -U Администратор.
Где находится «Администратор», пользователь, имеющий права добавлять компьютеры в домен.
Настройка ЦТБД
CTDB поставляется в виде отдельного пакета.Исходные тексты можно скачать с сайта ctdb.samba.org .
Существуют также скомпилированные версии для RHEL x64. Для x86 вы можете скачать src.rpm и скомпилировать его самостоятельно.
Параметры CTDB находятся в файле /etc/sysconfig/ctdb.conf. Этот файл также должен быть одинаковым на всех узлах кластера.
Наиболее важные параметры: CTDB_RECOVERY_LOCK=/gpfs-storage/ctdb/lock Определяет расположение файла блокировки, который используется при выборе «мастер восстановления» при восстановлении после сбоя.
Должен находиться в кластерной файловой системе, поддерживающей блокировки.
CTDB_PUBLIC_INTERFACE=eth1 Интерфейс, через который клиенты будут взаимодействовать с кластером.
CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses путь к файлу, содержащему возможные публичные IP-адреса, через которые будет осуществляться работа с кластером.
CTDB_MANAGES_SAMBA=да Демон CTDB управляет службами Samba. Это удобно для корректной работы Samba в кластере.
CTDB сам запустит или остановит Samba, когда это необходимо.
В этом случае Samba следует убрать из автозагрузки.
CTDB_MANAGES_WINBIND=да Аналогично предыдущему случаю — управление Winbind. CTDB_NODES=/etc/ctdb/узлы Список внутренних адресов ловушки кластера.
Файл узлов должен быть уникальным на всех узлах.
В файле /etc/ctdb/public_addresses необходимо указать все возможные публичные IP-адреса для подключения клиентов.
В файле /etc/ctdb/nodes нужно прописать внутренние IP-адреса всех узлов кластера.
Балансировка нагрузки
Существует два возможных метода балансировки нагрузки:- Использование циклического DNS
- ЛВС
Балансировка, по большому счету, сводится к поочередному перенаправлению клиентов на разные узлы кластера.
Балансировка DNS по кругу
В этом случае для одного имени кластера в DNS прописывается несколько IP-адресов.При обращении клиентов DNS-сервер один за другим выдает им разные IP-адреса кластера.
Таким образом, каждый последующий клиент подключается к новому IP-адресу и так по кругу.
Балансировка LVS
В этом случае весь кластер предоставляется клиентам через один IP-адрес.Один из узлов выбран как LVSMaster. Ему присваивается IP-адрес кластера.
Все клиенты отправляют запросы на этот адрес.
Затем LVSMaster перенаправляет запрос на один из узлов.
Узел, в свою очередь, напрямую отвечает клиенту, не задействуя LVSMaster. Схема, использующая LVS, может дать очень хорошие результаты при нескольких операциях чтения.
А вот при операциях записи все будет зависеть от производительности и пропускной способности сети LVSMaster.
Управление кластером
Управление осуществляется с помощью команды ctdb. По умолчанию он запускается на текущем узле.Используя ключ «-n», вы можете указать другой узел.
Статус CDB – отображает состояние кластера Количество узлов:2 пнн:0 172.0.16.101 ОК pnn:1 172.0.16.102 ОК (ЭТОТ УЗЕЛ) Поколение:985898984 Размер: 2 хеш:0 лмастер:0 хеш:1 лмастер:1 Режим восстановления: НОРМАЛЬНЫЙ (0) Мастер восстановления:0 Состояние узла может быть:
- ОК – нормальная работа
- ОТКЛЮЧЕН – узел физически недоступен.
- ОТКЛЮЧЕНО – узел отключен администратором.
При этом он функционирует внутри кластера, но его публичный IP-адрес передается другим узлам и на нем не выполняются никакие сервисы.
Однако узел способен обслуживать части баз данных TDB.
- UNHEALTHY – проблемы в работе узла.
Демон CTDB работает нормально, но общедоступные IP-адреса были перенесены на другие узлы, и никакие службы не работают.
- ЗАПРЕЩЕНО — узел слишком часто пытался восстановиться и был отключен на определенный период времени.
По истечении этого периода узел автоматически попытается вернуться в строй.
- STOPPED — узел остановлен и не участвует в работе кластера, но способен принимать команды управления.
- PARTIALLYONLINE — узел работает, но некоторые интерфейсы, обслуживающие общедоступные IP-адреса, отключены.
Должен быть доступен хотя бы один интерфейс.
- Recovery mode – режим работы кластера:
- НОРМАЛЬНЫЙ – рабочий режим
- RECOVERY – кластер находится в режиме восстановления.
Все базы данных кластера заблокированы.
Сервисы не работают.
IP-адрес CDB показывает публичные IP-адреса кластера и их распределение между узлами Публичные IP-адреса на узле 1 128.0.16.110 узел[1] активен[eth0] доступен[eth0] настроен[eth0] 128.0.16.111 узел[0] активен[] доступен[eth0] настроен[eth0] Первая строка — текущий узел, на котором была выполнена команда.
Ctdb pnn – отображает номер узла, на котором была выполнена команда Ctdb отключить – переместить текущий узел в положение «Отключить» Включение Ctdb – возврат из положения отключения Ктдб стоп — переместить текущий узел в положение «Стоп» (кластер будет переконфигурирован) Ctdb продолжить — возврат из положения Стоп (произойдет переконфигурация кластера) узел moveip public_ip вручную передает публичный IP-адрес с одного узла на другой ctdb – отображает список баз данных CTDB.
Количество баз данных:13
dbid: 0x1c904dfd имя: notify_onelevel.tdb путь:/var/ctdb/notify_onelevel.tdb.0
dbid:0x435d3410 имя:notify.tdb путь:/var/ctdb/notify.tdb.0
dbid:0x42fe72c5 имя:locking.tdb путь:/var/ctdb/locking.tdb.0
dbid:0x1421fb78 имя:brlock.tdb путь:/var/ctdb/brlock.tdb.0
dbid:0xc0bdde6a имя:sessionid.tdb путь:/var/ctdb/sessionid.tdb.0
dbid:0x17055d90 имя:connections.tdb путь:/var/ctdb/connections.tdb.0
dbid:0xf2a58948 имя:registry.tdb путь:/var/ctdb/persistent/registry.tdb.0 ПОСЛЕДНИЙ
dbid:0x63501287 имя:share_info.tdb путь:/var/ctdb/persistent/share_info.tdb.0 ПОСЛЕДНИЙ
dbid:0x92380e87 имя:account_policy.tdb путь:/var/ctdb/persistent/account_policy.tdb.0 ПОСЛЕДНИЙ
dbid: 0x7bbbd26c имя: passdb.tdb путь: /var/ctdb/persistent/passdb.tdb.0 ПОСЛЕДНИЙ
dbid: 0x2672a57f имя: idmap2.tdb путь: /var/ctdb/persistent/idmap2.tdb.0 ПОСЛЕДНИЙ
dbid: 0xe98e08b6 имя: group_mapping.tdb путь: /var/ctdb/persistent/group_mapping.tdb.0 PERSISTENT
dbid: 0xb775fff6 имя: secrets.tdb путь: /var/ctdb/persistent/secrets.tdb.0 PERSISTENT
ctdb Shutdown – остановить демон ctdb (эквивалент остановки службы stdb)
Кластерный мониторинг
Папка «/etc/ctdb» содержит сценарий «notify.sh».Он вызывается каждый раз, когда изменяется состояние работоспособности узла.
В нем можно записывать, например, отправку SNMP Trap или отправку сообщений электронной почты администратору.
Заключение
В статье были показаны принципы организации отказоустойчивого сервиса Samba. Ключевые моменты:- Возможность потери определенных метаданных без нарушения процесса преобразования семантики CIFS в POSIX.
- Часть ответственности за продолжение работы после сбоя передается на сторону клиента
- Файлы, открытые на узле кластера в момент сбоя, закрываются.
- Балансировка нагрузки осуществляется путем последовательного перенаправления клиентов на разные узлы кластера независимо от нагрузки.
-
Ноутбуки Марки Toshiba
19 Oct, 24 -
Новые Gtld – Середина 2008 Г.
19 Oct, 24 -
Прокладка Кабеля Под Водой. Как Это Сделано
19 Oct, 24 -
Хиты 2009 Года
19 Oct, 24 -
Новые Слухи О Более Дешевой Версии Iphone
19 Oct, 24 -
Онлайн-Статистика В Telegram
19 Oct, 24 -
Спортсмен: Робот, Которого Учат Бегать
19 Oct, 24
